Cloudy with a chance of hurdles

Before leaping head-first into the cloud, spinning up a few EC2 nodes or Azure web roles, it pays for an existing company with established servers to set up private cloud, virtualise your existing servers, spin up a second e-commerce server to prototype a multi-node solution, and sort out all the snags.

So the Cloud is a big deal; it’s the incarnation of the utility computing model that I started hearing about more than 10 years ago. It promises to free you not only from the need for infrastructure, but also from the need for those who support the infrastructure. You only pay for what you need, and theoretically there’s infinite capacity. The entry barrier is now extremely low for anyone who wants to start a business or build an application. In the early stages, while you’ve only got a few customers, you won’t need much computing power so your costs would be low. As your business or user base grows, your resource consumption and cost will grow too. But who cares, because you’ve got more revenue (or so the thinking goes). I buy that argument for the most part.

But I’m not starting a company or building a new application. My applications are already built; an e-commerce site and a multitude of line of business applications, for a company that already has infrastructure, staff, costs, and revenues that are more or less understood. How does the Cloud help us? What about the Cloud do we want to leverage, and how do we go about ‘cloudifying’ our applications?

It’s a stretch

For us, the most compelling feature of the (public) Cloud is its elasticity. It doesn’t take a genius to see why that would be attractive for our e-commerce site. I love the idea of spinning up and down web server nodes to handle load spikes like Black Friday/Cyber Monday, where we see disproportionately higher traffic. We got clobbered by that load last year. At the time we had one physical web server which talked to one database. And that database isn’t single purpose, as it’s used by the myriad line-of-business apps on the back end. That architecture immediately raised a whole host of challenges.

  • With the single web server configuration, we were using in-process session state management. That doesn’t scale across nodes.
  • Similarly, we’re using an in-process memory cache. That doesn’t scale across nodes either.
  • Our multi-purpose database means the e-commerce site isn’t self-contained and can’t be moved to the Cloud without dragging other applications with it. We either move everything or create a hybrid of cloud and on-premises based applications, with matters of security, reliability, complexity, and performance to be worked out.
  • There are PCI compliance considerations for where credit card data is stored and transmitted.

Additionally there are a couple of key business questions:

  1. How does our fixed cost of private infrastructure truly compare with the variable cost of utility infrastructure? Does it make sense for us?
  2. How do we make sure the resource utilization is aligned with revenue generation? A spike in resource consumption that isn’t the result of a revenue generating event could be problematic. Will a memory leak or CPU intensive bug cost us real money in the cloud?

Are you [cloud] ready…For what’s to come…Oh I said Are you ready?

Given those challenges it’s pretty clear our first step wasn’t to spin up a few EC2 nodes or Azure web roles and let the good times come. Rather, we began moving to a more cloud friendly architecture, slowly but surely, taking the following steps:

  1. We started by virtualizing our web servers, and then most of our other servers, except for our database server which at this point remains physical. I’m not sure what the technical definition of a private cloud is, or whether this meets it, but that’s loosely what we have. It provides us with considerably more flexibility to move, clone, and allocate resources to our servers as necessary. It also theoretically enables these images to be deployed to a public Cloud provider someday down the road. That takes me one step closer to the edge.
  2. We also spun up a second e-commerce web server which forced us to adapt our application to scale across multiple nodes. While we could have accomplished additional scalability by simply beefing up the resources on the single web server, or by implementing a sticky session solution, it would not have forced us to change our applications in a way that’s consistent with cloud thinking. Therefore, we implemented distributed caching to synchronize both the session state and the cache across the nodes. This proved to be much more painful than anticipated and we’re still working out the kinks, but I believe this approach is more consistent with what would be necessary to leverage the elasticity the cloud offers.
  3. By remaining on a private infrastructure, for now, we’re able avoid the complexity of a mixture of on-premises and cloud services, as well as forestall the other questions of PCI compliance, and the cost benefit analysis of utility computing

I’m a cloud, I amuse you?

I think the cloud holds great promise, and if you have a small or self-contained app, or one with well crafted, modular architecture, the path can be short and compelling. But for the rest of us there’s a little bit of work to be done, and maybe a private cloud is a good compromise and as far as you need to go. After all, you don’t want to fly too close to the sun on wings of pastrami.