“Life is really simple, but we insist on making it complicated.” — Confucius
As you might or might not know, HTTP & TCP are the protocols of the web. Everything builds upon them. I wanted to write something on SPDY - a Google proposed next-generation application protocol, that’s tries to fix some of HTTP limitations, while being extremely clever and staying backward-compatible. It tries to achieve that by building upon SSL to support “multiple concurrent, interleaved streams over a single TCP connection”. Thanks to this, you get the added security benefits of SSL. You do pay a latency penalty, but in the grand scheme of things, because most of the time only a single connection will be required per host to retrieve multiple resources and even support features like “server push” in the midst, it doesn’t seem like a lot.
Despite SPDY is out there replacing HTTP, it is really a sort of HTTP 2.0. It only changes HTTP components or features that are in need for a makeover. Starting from scratch would be way too much work.
I love SPDY’s motivation & goals. Back in school, I loved networking. I used to take graduate networking classes while still in undergraduate, to dig deeper and so as to have access to the professors and more importantly their research :) I was quite fascinated by the magic of packet switching & all the multiplexing, the switches, proxies, routers all that collectively work together to form the internet we know of.
HTTP was designed more than a decade ago, and it has practically gotten one big update in 1.1 - range requests, pipelining, chunked transfer encoding, etc. There have been a ton of proposed extensions and very few have gotten love. And for good reasons - you see, the success of the world wide web (WWW) has caused its own evolution to slow down. Really? Yes.
The world wide web is a great place to be. Anybody with a web server can join the network and start distributing content. There were very few authorities and policies in place, being started as a research project at CERN which itself was built upon the larger “internet” which too started as a research project (ARPANET) on packet switched networks in the late 1960s.
This distributed nature of WWW meant, drop by drop, servers started pouring in, especially as commercial uses poured in but don’t forget the Joe’s who started realizing the potential and started putting servers & content up there. This is one of the biggest cons of being distributed - if you are not in control of all the nodes in a distributed environment, you are in some sort of trouble. For example, you can not request all the nodes to update their servers or support a new protocol version for example.
Also, different corporations own different parts of the network from physical to software to applications. This is one of the internet’s greatest strengths, in how various parties contribute and work together to build a seemingly cohesive whole. Without this, the internet of something even remotely close to the internet’s scale simply would not be possible. A single owner would only get you so far. At some point in time, you have to open up platform to incorporate others.
Because of this nature and sheer scale, protocol level changes are very hard to support. You really have to evangelize, promote and hope folks will listen and update. In some cases, you can just put sheer pressure, in some cases you simply can not. For example, people use different browsers and are on different versions of the browsers. Being compatible with all of them is a big big challenge. Everything has to be backward-compatible to the extent possible. Hence, HTTP 1.0 stuck around for a while and the supposedly minor version update 1.1 took years to adopt. That’s amazing and well saddening. The most powerful system in the world is one of the hardest to upgrade. Even a spaceship upgrade should be simpler, while its floating in outer space I suppose. At least you are in control and make decisions to support the upgrade.
If you thought, the internet was perfect, think again.
HTTP 1.1 adds some great features on top of HTTP 1.0 while still being backward-compatible, but what’s next? Google clearly has its best interests in a faster internet. It provides a better experience, and supports forward looking initiatives to move the web forward. They also indirectly benefit revenue wise, since if the speed of browsing increases, so will searches & ad revenue. SPDY is Google’s attemp to a better HTTP and I am really glad that there is someone at Google actively pushing for these standards. Very few companies are in a position to make something happen here. Very few. Google, Microsoft, maybe Facebook. Maybe Yahoo. That’s it.
Google has some interesting research going on transport & internet level protocols, specifically TCP - See SCTP. But its hard to be backward compatible when you propose enhancements at these levels. And because of the distributed nature of the internet, changes like these take a very very long time. Nothing is perfect. Sometimes you just have to live with what you have at the moment. That’s certainly the case with a lot of the internet’s protocols.
I love Redis. Its simplicity & attention to minimalism is striking and I find myself right at home when working with Redis. Its no surprise, Redis is one of my favorite open-source project.
Well, you might have heard that Redis 2.6 RC was just released and it has native lua support! Now you might think, what the hell? But trust me, this is awesome. Think of it like PLSQL (well, kinda…) of Redis.
For things that you traditionally had to pull objects back from to redis to do, for example processing Redis objects and summarizing the results or generating stats or calculating mean/averages, you know can do it all right in Redis. That’s right, in Lua. Lua scripting is powerful. And thankfully Lua scripts are run in an atomic fashion - no other scripts are commands is executed while the script is executing.
Plus, Redis’ Lua support includes some of the most popular Lua libraries - base lib, table lib, string lib, math lib, debug lib, cjson lib & cmsgpack lib.
The one I am excited about is cjson! Yes, now that means you can “near-natively” process JSON in Redis. I say near-natively, since it still has to go through the Lua runtime. But that’s OK. Its an extension of Redis, the way I look at it. And this is better than native Lua support, because now sky is the limit. You want native YAML support, well, if yaml lib is included (can’t right now, but fingers crossed), you can get that via the same Lua based scripting system. Its quite ingenious way to cheat, to build more, by less.
A use case where we have a need for such processing is aggreagte value calculation. We store stringified JSON strings as values in Redis. An example is poll stats. If I were to calculate demographic level stats or just a total count of values, I would have to batch fetch the entire JSON object values and calculate the stats in my app layer (Node.js for example). With Lua, I can parse JSON (decode), loop through the matching keys/objects and calculate the stats and return them all from Redis, without ever getting back to the app layer. This is fantastic. (If this interests you, be sure to see some the PS’s below).
Here are some code examples - (Note: You use the eval command for executing Lua scripts. The Lua runtime is also sandboxed and not all Lua objects are available, for example io is not available, as it simply does not make sense.)
eval "return cjson.decode(cjson.encode('{v_rocks:true,whos_v:\"http://www.vishalshah.org\"}'))" 0
"{v_rocks:true,whos_v:\"http://www.vishalshah.org\"}"
Here’s another example where we set the following JSON string {v_rocks:true,whos_v:"http://www.vishalshah.org"}, which is encoded via cjson and retrieve it after decoding via the same.
redis 127.0.0.1:6379> eval "redis.call('set', 'vmeta', cjson.encode('{v_rocks:true,whos_v:\"http://www.vishalshah.org\"}'))" 0
(nil)
redis 127.0.0.1:6379> get vmeta
"\"{v_rocks:true,whos_v:\\\"http:\\/\\/www.vishalshah.org\\\"}\""
redis 127.0.0.1:6379> eval "return cjson.decode(redis.call('get', 'vmeta'))" 0
"{v_rocks:true,whos_v:\"http://www.vishalshah.org\"}"
Voila!
PS0: You still have have to JSON stringify/parse from the app layer when storing JSON values in Redis. However this is best done at the redis driver level. If you know of a Redis driver that does not have json stringify/parse wrappers, make sure you add them by extending/forking the driver yourself.
PS1. More than JSON support specifically, I am more excited about Lua in general. Stats calculations, log like processing, filters, and other checks can now happen in Redis.
PS2. Be careful - Lua scripts are atomically run. If you have a long running Lua script, other Redis commands will wait and hence you backend’s processing will slow down. With a lot of power, comes great responsibility. One way to cheat is to run Lua scripts on slaves that have less load or on staging servers running from most recent Redis dumps, so you can safely play around!
“
Tao of YouTube: choose the simplest solution possible with the loosest guarantees that are practical. The reason you want all these things is you need flexibility to solve problems. The minute you over specify something you paint yourself into a corner. You aren’t going to make those guarantees. Your problem becomes automatically more complex when you try and make all those guarantees. You leave yourself no way out.
Awesome. —V
” — 7 Years Of YouTube Scalability Lessons In 30 Minutes“Instead of sitting at your computer, and looking at books, go to a drycleaner, and sit there. The way to get an interesting idea is to go to the source. Stay there until you have thought of something interesting about drycleaning. Then, listen to that idea and it will design itself.” — Bob Gill on how to have a good idea
Reading about and practicing myself many many architectural styles & pattern, I think I have something rather interesting to share.
I have identified a very standard architecture pattern, most online-offline systems can use (an online-offline system is a word I made up :) that supports both online/realtime & offline processing).
Its not new or anything revolutionary. It just works. digg follows most of that standard/canned architecture - app server - caching layers - storage - messaging/queues - async/offline hadoop processing.
Such architecture supports everything from small to large use cases and products. It supports processing large amount of data via hadoop while quick data queries uses the cache and datastore. App server is where the “online” business logic is. Offline business logic is in hadoop.
Its so generic & balanced that you can scale individual layers/components without affecting rest of the system. Also it fits in our SOA, where apps on the top are nothing but service end-points with no UI, or they can be java/node/php… apps with a UI.
I am not proposing, this is one stack that everybody should use, but its sort of an architecture pattern that works for many problems. You can skip components as you wish and add them later. For ex, for a mobile app/service we are currently building, we have no need for offline processing & a dedicated messaging layer - hence the hadoop & messaging layer goes away! We can add in the future if we want to - to add lots of stats, processing, etc..
So, you can scale it back to just the app server, caching and data store if you need, which is not that exciting or revealing, but you know you can scale it to ridiculous extent, by adding the async messaging & offline MapReduce/Hadoop processing layer. And bingo!!
Here’s the digg diagram. I chose not to build my own diagram because I am lazy. Digg’s diagram has most of it. Don’t get too carried away with their arrows. The important thing to note are the components and layers and the purpose they serve.
— Vishal
“It’s not the consumers’ job to know what they want” — Steve Jobs when asked what market research went into the company’s elegant product designs
“If you think too much, you will make mistakes.” — Vishal Shah (1/27/2012) while planning with team on a software project
My answer to this question on Quora -
I am very excited about DynamoDB and I definately think its a game changer. Its killer features are easy to get started, auto-sharding, dynamic scalability per table & proportional AWS costs/billing, in-place atomic updates, both eventual and strong consistency support. But Dynamo has some work set before it can really catch on fire - mostly around queries
PS. using solid state drives for storage is awesome!
My answer to this question on Quora -
I for one would think that even if they do open Silk, browser vendors will be less inclined to use it.
Google (Chrome), for example has its own cloud infrastructure, potentially bigger than Amazon’s.
Safari (my current browser of choice) traditionally is very conservative on using any 3rd party services due to Apple’s focus on simplicity - not a bad thing at all in my opinion.
Firefox can benefit potentially but fundamentally it might not be a big win and here’s why.
Silk/computing in the cloud primarily aids mobile (including tablet) devices - with limited network & cpu/memory resources. That’s when this really shines! - the approach of offloading some of the processing and caching on the cloud.
For desktop browsers, some of the above constraints sort of, vanish - more cpu/memory/caching capacity available. And hence the benefits are smaller, much smaller. In fact, it might even negatively impact overall performance, if Amazon’s cloud is experiencing a lot of traffic for example.
I do believe however that the hybrid processing and caching model is a terrific idea when well executed for smaller devices. But there is just not enough motivation as of yet for more powerful devices.
I have so many developers & architect choose the wrong strategy for managing user presence, caches, stats and session information.
My simple advice that works - use redis + expire. Its blazing fast, stupidly simple and very scalable using file syncing and replication and/or sharing.
Don’t try to kludge in using the old school way using sql or custom in-memory hash tables or memcached used inappropriately.
As a software architect, the hardest thing to do is pick the right tool for the job while balancing complexity, cost, performance and learning. And if there is one tool I never forget and keep on getting back to is redis which is an intentionally kept simple but superb artifact of the KISS principle. On top of it, its genius is behind its beautiful command language that is easy to operate and learn and more importantly build upon for very-simple-to-very-complex systems based on data models that uses KV alone. It takes a while to get used to but KV > Complex data systems for most situations, especially for session management.
You will find yourself using Redis for counters, stats, caches all while not having the cold start problem since Redis fsync’s (file sync) the memory representation so you can always lose a Redis instance and bring another back up without a sweat.
And the icing on the cake? It complements and not competes with other NOSQL, especially persistent, systems. I get amused when people talk or search for redis vs cassandra vs riak vs …
The closest you probably know related to redis is memcached.
API’s can be fundamentally important for an organization. However, its use, contrary to popular belief, is not just for external clients & developers, but they can play an important role in building system wide applications & towards an API driven architectural style(more than in a separate blog).
So what are the good qualities to think about while designing APIs. In other words, I want to try to discuss, how to design APIs that are well designed, scalable (in its use) and some thoughts around related matters.
“Don’t be too much of a generalist where you don’t have confidence is yourself or what you build.” — Vishal Shah, 2011
“Be the change you want to see in this world” — Mahatma Gandhi