In this post, I’m going to summarize the main challenges to achieving high performing continuous delivery that I’ve been sorry to see but also motivated to try to overcome over the last few years. I borrowed the electronic engineering term “impedance” for two reasons. One, it basically means resistance which can be defined as: “refusal to accept to comply with something”, “the use of force to oppose something”, and “the stopping effect exerted by one thing on another.” All apt ways of characterizing the things that get in the way of continuous delivery.
Two, in electronics, impedance is the resistance to alternating current which seems appropriate given continuous delivery is cyclical. Also, given the current mania for everything digital, analogue things appeal to me.
So how can infrastructure impede continuous delivery?
A foundation of continuous delivery is the ability to automate, not just application code deployments, but as much as you can (i.e., as far down the stack as possible.) It is unfortunately common in my experience that infrastructure solutions are just not conducive to this.
I believe that the public cloud presents the best experience possible here and is extremely conducive to automation. For example in AWS, CloudFormation allows you to provision whole (virtual) data centers from scratch. Heat does the same in Open Stack clouds. When using the CloudFoundry PaaS, Bosh can be used with AWS and also VMWare underpinned data centers to do the same thing. Many solutions are becoming readily available.
These are incredibly empowering as they allow you to create environments from version control and scale up and down the number and types of environment dynamically during the software release lifecycle (pipeline). They allow the infrastructure to be treated as code and subjected to software engineering and quality processes. This significantly helps break down the barrier between Development and Operations teams.
Unfortunately, the fantastic world of public cloud is not available to many. Their options range from a less sophisticated cloud that offers limited features to the dreaded world of manual request for a manually created physical server to be selected, purchased, delivered, racked, stacked etc. (running into months of lead time). Continuous delivery can be exponentially harder to do the less your infrastructure solution resembles public cloud:
Getting the servers you need can be the first problem with long lead times.
Once servers have been created, it is not uncommon to struggle to gain access to them. With a public cloud, you are fully in control and can adopt a virtual private networking solution native to the IaaS provider, or implement your own. I’m not saying this doesn’t need to be done responsibly and with due diligence, but it significantly simplifies things both technically (software-driven networking is a given in the cloud) and also from a people perspective.
Once you’ve gained access, you may not be empowered with super-user access and hence unable to implement automation. You are forced to treat them as “pets” as “opposed to cows”, for example, it is difficult to destroy and replace them and far more tempting to manually tweak them, creating snowflakes. Without IaaS, it isn’t uncommon to have to tolerate glaring differences between non-production and production servers such as different operating system. It isn’t easy to build and trust a continuous delivery pipeline with that level of inconsistency.
It’s fair to say that automated configuration management tools like Puppet and Chef can provide help in improving consistency between even physical servers (although it’s not unheard of for infrastructure and security teams to actually outlaw these). But without the mindset that servers are fully disposable, it is all too easy to log on to servers and for integrity to slip (creating a smell).
With the above in mind, I highly recommend starting small by allowing development and test to use public cloud and understand first-hand how powerful it can be. Demonstrate the benefits achieved there as early as possible and start the cultural acceptance of cloud.