Partly Cloudy

A recent study commissioned by IBM showed that 60% of CIOs are ready to move to cloud computing. That means a lot of applications which were never designed for use in the cloud are going to be moving there over the next few years.

For those who are putting an application in the cloud for the first time and wondered, perhaps, what challenges they will face, have a look at the short overview I just put together for LinkedSeattle.com.

read more

On April 21, starting at about 1:40 in the morning, Amazon Web Services had their worst outage ever, putting customers large and small out of commission for days. As of this writing, services are nearly restored, but some work remains.

Not only was it a disappointing misstep for Amazon, but cloud computing as a whole took some lumps, with some even asking if the cloud computing hysteria was officially over.

The list of affected companies reads like a who’s who: Quora, Reddit, Netflix, Eli Lilly, Heroku, Zynga and possibly hundreds of others, especially Silicon Valley startups.

And yet, Amazon’s stock ended the week at $185.89, over $7 higher than it stood at the end of the week prior. Why?

Because, perversely, the outage at Amazon served as a reminder of what a cloud computing powerhouse they’ve become. And it happened on top of a slew of articles like this one in the Wall Street Journal, touting the Gartner and Forrester projections for Cloud Computing’s growth.

Amazon had a difficult week, and attention immediately focused on their legendarily secretive culture. At the same time, the far-reaching nature of the outage has only underscored the magnitude of their leadership in cloud computing. And the stock price shows it.

read more

As evidence, see Scale and Scalability: Rethinking the Most Overused IT System Selling Point for the Cloud Era in IT Expert Voice.

Perhaps, as Name.com’s Sean Leach advises, there’s a lesson to be learned from Twitter: Rather than planning to scale incrementally — which, if a business finds or regains success, may now be impossible — it should plan to rework its fundamental architecture as needed, in phases, as old architectures that met earlier requirements are no longer applicable.

The coefficients of Leach’s formula may sound a bit obtuse, but in light of Twitter, perhaps the sky’s the limit. “Let’s say, the biggest you’re ever going to get is a trillion customers. But instead of designing for a trillion customers, design to a million customers so that when you get halfway there, you can redesign the system over time to be able to support a billion customers. Then when you get to almost a billion… just build it and get it out there, and then you spend your time up front and don’t worry about scaling. Plan in phases where you scale to X, and then when you get close to X, you start thinking about Y…as opposed to waiting until X happens before you worry about scaling,” he says.

The performance requirements that spawned the first generation product will impede the development of the second generation. And the best practices of just a few years ago are no longer adequate to the challenges ahead of us. This trend has only accelerated.  Over the years, Twitter has replaced their original Ruby on Rails technology stack completely, and put in place a new stack based on the JVM with Scala as the primary programming metaphor.

When taking an existing system and moving it to the cloud, you must drive a number of architectural shifts as the audience grows bigger that more or less recapitulate the industry migration from the ASP model to the cloud model. For example:

1. Separating the database systems and the web application so that the CPU and I/O usage of each one can be optimized separately, which leads to:
2. Switching from a database instance per customer to a single database instance with sharding to reduce the cost of deployments and upgrades.
3. Switching from a single database host to a database cluster to permit balancing between read and write operations; web applications are usually very read-intensive.
4. Introducing multiple web application servers to permit more users to be served simultaneously, which leads to:
5. Adding a caching layer in between the application and the database to reduce the amount of I/O required by each web application host, which leads to:
6. Cache coordination between application hosts to further reduce the I/O to the database layer, and reduce the chance of conflicting changes to shared objects, which leads to:
7. Introduction of a formal Object-Relational Layer (ORL) on top of the caching layer, to permit the web application to treat everything as a first-class object and to abstract away the work of persistance in the database.
8. Separating the web application into a set of REST interfaces and a UI tier on top, permitting the same basic structure to serve web users, mobile users, business partners, your vendors.
9. This leads to a realization that a relational database covered by a caching system and an ORL is actually a very expensive way to have an object-oriented or document-oriented database. If the size of the data has not already demanded the switch before this point, this is where teams realize the wisdom of CouchDB, Cassandra, HBASE, or MongoDB.

And so on. No one is making faster processors. They’re just making more of them. If your data structures and algorithms do not permit the work to be broken up and processed by an army of threads working on a grid of unremarkable machines, then you don’t have scalability. You just have size.

read more