Cloud is good for us. So too are practices like DevOps and Continuous Delivery. It’s easy on the surface to read a few articles and think, “yeah, that’s a good idea,” but putting them into practice on the other hand isn’t so easy.
The reason things aren’t so simple is that technology is only a third of the problem. The other two thirds are culture and process in equal measure. As we adopt new technologies we have to make cultural and process change too.
You’ll often hear about how scalable the cloud is and how DevOps can lead to delivering value faster, but actually adopting a cloud or DevOps approach can often be glazed over. I think this is because the solutions are hard, not one size fits all, and not everyone has the answers.
When explaining the concept of gradual change I often use Henrik Kniberg’s agile versus big bang diagram. It compares delivery value of both agile and big bang approach over time. Agile providing an increasing amount of value right from the start and big bang providing its value all at once.
I’d argue that taking the gradual approach in software delivery is almost always the best option to take. The reason for this is that cost of change in software shouldn’t increase over time or, at least, not as much as say architecting buildings.
Analysing cost of change
Once you’ve built a building it is costly to significantly change its structure or function. It is expensive to build a floor and then change your mind based on learnings. This is why up front planning and design is necessary.
In software, there is also a cost to change but in comparison it is cheaper and it does not increase exponentially over time.
In the above graph you can see traditional cost of change increases sharply over time. Agile software delivery on the other hand does not; while there is a cost associated, the cost does not continue to rise over time.
The important takeaway from this is that, in software, it is attractive to adapt your plan after starting a project as the cost is not great. In fact you get many benefits from allowing learnings to change your plan. By not having a detailed plan up front, you save time, and can provide even greater value to your business as your learnings can be brought back into the delivery.
Applying cost of change theory to cloud
The world of data centres and on-premise are closer to building a building than delivering software. You need to plan in advance your requirements for new infrastructure, work out what capacity you are going to need when you put it live and predict growing demands on capacity over time. Getting this wrong, or changing later, has a significant cost associated with it.
In the cloud, things are different. Spinning up new infrastructure is quick, does not require trips to data centres and finding more space for racks. You can make and provision enough machines you think you need, if you later realise you over provisioned you can ramp things down in minutes rather than days and weeks. It goes the other way too; if you need to scale out to more machines, that again is trivial in comparison to a data centre.
Moving your operation to the cloud means you can – and in my opinion should – move to an agile delivery approach with less upfront planning.
A changing world
Not moving to an agile approach, in fact, is the underlying reason why cloud migrations fail. There isn’t enough history and knowhow for organisations to be able to know up front what they’ll need to provision in the cloud. In most cases it isn’t as simple as lift and shift. Ideas need to be reworked.
With a traditional hardware focussed operations team, going all in with cloud is going to be a rough ride. New skills need to be learned. Performance in cloud is a different beast too. Great performance can be achieved in the cloud but architectures need to be evolved for that to work. It’s no surprise performance is one reason cited for failure.
Organisations may recognise lack of skills in the organisation for cloud and end up outsourcing everything. Firstly, in doing this, you are ignoring a capable workforce that needs retraining. Perhaps more importantly for the bottom line, outsourcing to offshore companies doesn’t necessarily lead to success any faster. You’ll purchase a 2 year migration, it’ll be extended by a year after “unexpected delays”, and finally fail after millions are spent.
I’m not saying that there aren’t successes in lift and shift to the cloud nor am I saying you can’t get it all done in one go. What I am saying is that it’s a much riskier approach and unless you can validate in no uncertain terms why a lift and shift approach is a good idea, it’s most likely smaller steps will be safer.
Far better, embrace the fact that change in culture and process is necessary if you are to change the technology. Cloud is a new world where new techniques are required. Invest in your organisation’s future by embracing them.