The Age of Compute Services

In the past ten years we've seen the "Rise of the cloud".
Almost everyone moved their in house IT and infrastructure to Amazon/ Rackspace/ IBM/ Azure/ Google/ Whatever, got rid of their huge racks and pizzaboxes, and went on with their lives.
Enter the rise of Devops - A caste of people who control the know how of building, deploying and maintaining your servers. Mostly due to poor documentation of the host platform.
Then Docker came along - The ability to create containers for applications, which makes it even easier to run them - However, Docker comes with its own disadvantages (Irrelevant to this post.)

But recent years show a new trend - Where services like Amazon Lambda, Google Cloud Functions are actually code containers (Rather than full blown OSs).

This changes the paradigm even further - No OS needed. Just code, deploy and go. Connect it to a file system (Amazon EFS)/ storage/ database/ whatever as a service, and you've got yourself a full working server with no OS, no deployment, all managed, secured, scaled and charged on demand.

This changes the economy of cloud services, as you actually pay for what you consume, and not for what you MIGHT consume (Even if you scale down during downtimes, it's never immediate)

It also changes the paradigm of programming - No need for security concerns (All managed), just a collection of volatile services.

In this new paradigm, cloud cyber, virtualization and devops businesses should take notice. Soon, their business might be completely irrelevant.

From one hosting to another...

This weekend, we moved our cluster from Rackspace to Amazon.

It was a very tense process, as we need to transport GBytes of data seamlessly from one server to another, as well as shift our data writing server from the old database to the new one, while losing as little data as possible.
Eventually, it was done in less than two hours, most of which were exporting data from the old server and transporting it into the new one.

My main tips for performing such a move:
- Sit down before, and write the process step by step. Preparations for the new server, exporting and transporting the data, updating DNS services, testing. Discuss and review with your team.
- Review the process, and estimate risks and contingencies. What happens if it takes too long to transport the data? What happens if you have to roll back? What happens if the new server crashes?
- In case of DNS updates, it would be faster and more reliable to add the new domain ip to /etc/hosts instead of waiting for DNS to refresh, which might take time. Don't forget to jot down the IPs of your old servers, you might need them :)
- In our case, we also had some one premise sensors with no access to DNS, which means we had to use both the old and new stacks active, both working with the new database, until we're able to access those sites and change the destination IP.
- After you've got your plan laid down, do a dry run. There's nothing like a dry run to sort out bugs and add missing steps.
- Be 100% clear about who performs which step and when, but keep one person in charge of the whole process.
- Keep everyone in the loop - Upgrade was performed Friday night, so we decided to do it from home.. We were a team of three, using Google Hangout to communicate while everyone is online.

Eventually, process went quite well, Amazon SSD servers are fast and zippy, and we're ready for our next scale challenge, which would have us scaling to tables larger than 100m records while keeping our high performance standards.

Shifting weights... And Cluster Performance.

At the beginning, there was one machine.

One server ran our database and web application.

But as our database began to scale, we needed to separate them.
Separating the servers is easy - Just define an 'internal' network, and let the machines communicate via the internal leg.

However, this caused another problem - We began to experience long lags when transferring large datasets between the machines.
When dataset was larger than X items, performance began to degrade, and was substantially slower due to network lag. Below that, performance was actually better.

Part of it was due to node's mysql drivers. They're just slow. (Compared to native mysql drivers)
The other part was network lag.

So how do you solve it?
Part of my original design was using mysql as a data store - Only use simple sql, no arithmetical operations and aggregations. This allowed us to move from mysql to mongodb easily, and eased CPU load for the database.

But now it's time to shift the weight, because bandwidth is our new bottleneck.
So we're moving some of the heavier processing into the database so that a smaller dataset would transfer faster. Much faster.

Performance is a delicate art of balance. Always remember that paradigms change as scale changes. Don't be afraid to shift weight in order to keep your system balanced.

Reading time #3

Once again, some nice reference stuff to read and enjoy.

First, a must read for every dev manager/ architect: I bet you over-engineered your startup - Try and read the comments as well - There's one I really like about backbone.js.

Here's something nice: An app for bullying reports. I think municipalities and local police departments should implement such apps, to see 'hot spots' of violence, and also make reporting a lot easier. A mobile phone does so many things, it's about time that it would help the community keep themselves safe.

My friend Moshe Kaplan from dSero with a nice article about SEO in Amazon AWS news.

Some new frameworks and tips:
- KineticJS makes 2d drawing easy, and is also pretty fast.
- A wonderful tutorial for creating clouds with css3. Opens your mind for lots and lots more ideas (Try use faces instead of clouds...)

Another useful UX related article: Overhauling a UI without upsetting the users (Thanks Itai:)).

And finally, a thought: The big tech companies have learned from the pharma industry: Since anyone can develop everything right now, and manufacturing is easy, intellectual property is the only way to make sure you have control over the market.
And unlike the pharma industry, you don't need to be a scientist, and spend years of FDA approval to get your product out there. Microsoft are buying patents from AOL, Apple is suing everyone, Samsung counter sues, and seems like the big techs' legal budget is going to be bigger than their R&D.

This is going to kill the small and medium businesses in the industry, unless legislation will somehow be able to protect them. Otherwise, we might as well give up our jobs, or relocate to China, where copyright rules are... More flexible :))

"Never underestimate the bandwidth of a truck full of backup tapes"

Said Andrew S. Tanenbaum, back in '96.
Netflix's CEO, when asked about their concept of sending DVDs and return envelopes to subscribers, quoted him as inspiration - Back in 2002, I was in Boston , lecturing about telephony switches test simulators, and discussed that quote with a manager from Intel when speaking about big bandwidth networks and the fact that they might replace physical media, eventually.

Few years down the road, and looks like Amazon were listening: http://aws.amazon.com/importexport/.

Thanks to Boaz Ziniman, zend's cloud expert, for the link.