I’m really happy with the Continuous Deployment journey within our Company.
We’ve come a long way since establishing an application pipeline to production with all the associated automation – even including the automatic creation of a change request!
As we have moved from from Continuous Integration through Continuous Delivery to Continuous Deployment, I thought that our destination had been achieved. In fact I’m thrilled that our Platform as a Service (PaaS) provides the technical agility that is being driven by our DevOps structure and also by our #TotalFlow Lean Software Development framework.
But the age old issue of Environments and Capacity demands haven’t really gone away. Infrastructure as a Service (IaaS) is not really a ‘service’ until it’s built. Hence the Cloud is the only real viable IaaS available – in my opinion.
In a Private Cloud scenario (i.e. your own Data Centre) coupled with the right tools, then IaaS can be planned one step ahead of demand. But every now and then, there is a delay in capital expenditure or the delivery of kit and the Lean “just in time” approach hits the wall. Then agility becomes in-agility (if such an expression exists) and projects get delayed.
Hence the Public Cloud is the best IaaS option out there and as security concerns decrease, ubiquity is inevitable and ultimately the Cloud will give you (almost) unlimited burst capacity – subject to cost. But more excitingly it also allows almost unlimited Continuous Engineering possibilities.
Continuous Engineering to me means environments that are controlled by the applications that live in them. They make resource requests on demand and automate a systems role that has become more and more complex as the demands on itself become exponential.
Some say that this discipline is being driven by the Internet of Things and that might be the case. But intelligent apps that can handle their own capacity ‘peaks & troughs’ and their own ‘monitoring & health’ is an engineering dream. Unless your job is creating environments or indeed selling the hardware that underpins the infrastructure that they run on. But in reality I still have plenty of work for our engineers to do and sales people will just switch from physical devices to selling the consumption of cloud based resources.
Anyway it’s a shame that Infrastructure as code (or programmable infrastructure) lends itself best to Public Cloud because many organisations still have a shed load of legacy that is not going away any time soon. But legacy, like the bad debt of the Banking crisis, is being sectioned off or made into a grand-fathered service. Hence I guess that’s why we are seeing the rise of the Chief Digital Officer as mobile software eats the world and the power of the Pass which automates it.