Blog

Public versus private IaaS deployments

So we left off discussing the strengths and weaknesses of both public and private IaaS. When you look at the current adoption models, SMBs are big supporters of public, while LEs seem to be running more private deployments. Long term, which model will “win”?

The answer is… “both”!  🙂

Seriously. There are times when each model makes the most sense. As public/private becomes entrenched in our architecture, choosing between them will become as common as choosing between a switch or a router. You’ll simply select the best “tool” for the job. The difference with servers however is that the criterion can be transient. The utilization model of a server which makes it a good choice for public deployment can change, thus making it a better candidate for a private deployment.

For example, let’s say we need to develop a new public facing application. Rather than delay development till a new server can be acquired and deployed, we leverage public IaaS. This means that development could literally commence before the end of the day.

Once the app is developed, we shift it into a private IaaS for deployment. If we already have an existing infrastructure in place, and our app sees little initial utilization, this would make the most economic sense.

Now assume or app gets Slashdotted or sees some form of dramatic increase in traffic which causes a spike in utilization. We now have a couple of choices:

  1. Let the site get saturated, causing connection refusal problems which turns away potential customers.
  2. Increase our Internet link speed and upgrade the servers. This would require a 4-6 week lead time minimum, thus missing the initial bust of increased traffic.
  3. Move the server to public space.

The third option is the only one that addresses the issue in a timely enough fashion to capture the increase in interest. Further, it is the only option that resolves the connectivity issues quickly enough to turn potential interest into paying clients.

Now let’s assume some period of time goes by and interest in our application has begun to wane. Utilization is back to to levels that can easily be handled by the internal infrastructure. At this point it may make sense to move the application back to internal resources.

As you can see in this example, it is possible for a server to see environment changes that shift best placement between public and private space. In the above example the server shifted locations three times based on current requirements. So when we refer to “hybrid” deployments, the choice between public or private space is not stagnant. One of the strengths of IaaS is that server deployments can be a mobile entities, shifting location as required.

If you are wondering if companies are already leveraging this type of flexibility, check out Zynga. They have built their business model around this type of flexibility. Many consider Zynga the model of the Gen3 revolution.

This mobility comes at a security “cost” however. When we talk about shifting between private and public space, what we are really talking about is moving a server across or perimeter boundary. This will obviously have an impact on the server’s risk exposure. So how do we mitigate this risk? We’ll get into that in the next blog post.

Chris

Related Posts