DevOps and cloud infrastructure permutations

One of my DevOps concerns with data center applications is the testing of infrastructure and the applications that ride on top of it. It is overly complicated. Each application has thousands of parameter combinations that can be used. How does one know which parameters are critical and the range of options a given parameter can have? Testing parameter combinations is a nightmare. So, it is often neglected.

One of the key benefits of cloud computing are the limited set of processor, storage, and network bandwidth options that are allowed that support the cloud application. In contrast, data center applications have almost a limitless number of combinations of parameters for storage, processor, network, middleware, and other infrastructure components. If there is a defect in the combination of parameters it may not appear in testing because of the sheer number of combinations that can be used for each application. This unknown weakness therefore could cause problems in production.

Current cloud vendors are like car makers. There are car brands and models – a limited number of them. Also, each car model has an engine configuration. The engine configuration represents the guts of what makes the car run; it reminds me of the cloud infrastructure that supports an application. These limits on the number of parameters enable cloud providers to properly test various cloud configurations. Traditional data center applications cannot test some configurations because there are too many. In my traditional data center experience we had to get vendor sales engineers involved to get a realistic range of parameters for a given infrastructure component. This is to be done for each infrastructure component.

A main factor in the cloudification of applications is the use of containers to isolate applications from one another and to model networking, storage, and processing servers well. A significant number of containers adds a lot of complexity to the cloud application’s infrastructure and platform. The reliance on containers and their relationship with one another makes modeling the infrastructure more difficult. Container management products are currently in open source. It will take time for the container configurations to standardize for specific types of applications. Also, it will take time before container management tools are commoditized by a limited number of vendors.

So the container management simplification is out on the horizon. It will be some time before cloud applications have container model patterns like those for cloud infrastructure parameters that are used in product deployment. Just when virtual machines were fully commoditized and supplied by multiple vendors the container revolution showed up. Simplifying its parameterization will take some work.

So, cloud providers address configurable infrastructure support for applications users want in their cloud. They support access to those applications from around the globe. The cloud provider also can more easily support disaster recovery because of the ability to failover a cloud application from one cloud data center location to another.  The cloud infrastructure is robust; especially for companies that cannot afford to pay for a global infrastructure architecture for their critical applications.

Another issue is collecting the state of other infrastructure components that interact in the cloud. This may be difficult to gather. The state of the firewalls, load balancers, routers/switches and storage infrastructure all need to be snapshotted so that when application changes occur there is a way to get a cloud application back to a known state if failure occurs. This is because firewall and network equipment policies change all the time. Policy errors can lead to disaster in some situations.

In summary, cloud infrastructure providers support applications with a container model and a series of fixed storage, processing, and network models. This is a component of DevOps. Companies move their applications to the cloud to improve reliability (a security component) and allow for sharing of the application with multiple clients. The current container complexity concerns me; it will take time for the container complexity to be limited to a few configuration choices for use by applications. Lastly, infrastructure equipment policies need to be tracked centrally so that an application change is properly correlated to them in case a rollback to a known state is needed.