Deciding whether to invest in a cloud offering or not on the surface seems to be a simple financial exercise. The ability of the provider to share the cost of what would otherwise likely be expensive infrastructure across many customer benefits everyone with lower costs. And it’s not just the capital investment that’s shared, it’s the ongoing operating expenses associated with maintenance that gets shared, too. But sharing network infrastructure means sharing network infrastructure everything – including configuration options that may or may not be appropriate for your application, and the risk that goes along with it.
On Christmas Eve last year there was an incident inside Amazon that ended up impacting a fairly small percentage of its infrastructure. Unfortunately, the cloud is shared infrastructure which means the impact was felt by a much wider audience. In a nutshell, the loss of infrastructure state data for ELB caused improper configuration of some load balancers which in turn resulted in degraded performance and errors for customer applications using those load balancers.
The incident illustrates well the potential negative impact of shared infrastructure. In this case the problem wasn’t the sharing of load balancers, as one might think, but the sharing of the state management infrastructure (i.e. the database in which load balancer state was stored).
Whether it is a router, or a switch or a database full of state or configuration data, shared infrastructure necessarily generates shared risk. If three customers share a switch or a physical server and there is a failure, all three customers will be impacted. This is the subtle difference between multi-tenancy and fault isolation. The former does not guarantee the latter, and the latter is somewhat incompatible with the former.
In the cloud, however, infrastructure is necessarily shared at some level, and its underlying configuration with respect to performance and fault tolerance is rarely under the control of the customer. Such configuration options and architecture may be wholly unsuited to a particular customer’s risk tolerance and business requirements. But the lure of cloud and its economic incentives is hard to resist. To take advantage of the benefits while addressing the risks of sharing infrastructure may require a more traditional architectural approach.
Addressing Risk without Giving up the Benefits of Cloud
Before deciding to migrate an application to the cloud and into a shared infrastructure environment it is vital to examine its existing environment, particularly its supporting infrastructure.
Consider carefully the entire delivery chain – from router to firewall to load balancer to security solutions all the way back to the database. For each piece of infrastructure, determine the impact to the availability and performance of the application. Are policies in place at any point in the chain that, if removed, may negatively impact the security posture or performance profile of the application? Can these policies be duplicated in the cloud on the shared infrastructure services offered?
In many cases, the answer to that last question is likely no. Any policy that may involve tweaking or tuning of parameters in the network stack are not likely available for shared infrastructure services. That’s because, well, they’re shared and one application’s improvement may be another application’s impairment. If such tuning is required it may be necessary to eschew the cloud service and instead deploy a more dedicated – but still cloud deployed – option that can be isolated to serving just your application.
Similarly it may not be possible to tighten security to satisfy business or operational requirements. For example, locking down access to specific ports on a shared firewall may not be possible because other applications require them. Such responsibility may need to be moved closer to the application – if not within it.
There are a growing number of options in cloud environments that include both shared services and more traditional “dedicated” service options. It is vital to maintaining security and performance requirements of applications moving to the cloud to understand what options are shared and on what infrastructure and how that aligns with existing policies that support the delivery of the application in question. Key options and services critical to the successful deployment and delivery of that application may require alternative deployment architectures to ensure that the shared risk of shared infrastructure does not negate the shared savings and benefits.
Lori MacVittie is senior technical marketing manager at F5 Networks (News - Alert) (www.f5.com).
Edited by Stefania Viscusi