Whenever I start working with a new client -- no matter who it is or what business they’re in -- there is one thing that happens every time. Without failure, the moment comes where someone will look you dead in the eyes and tell you about this single unique problem that they have, that nobody before them has ever experienced, much less solved.
Except, of course, this problem they so earnestly describe is far from unique. I have seen it so many times that I have come to think of it as “Legacy Lockdown” -- the restrictions and limitations imposed by a vintage system that prevent developers from working to their true potential because they are blocked from using modern tools and technologies. It may feel like your own special problem but, trust me, it happens everywhere, all the time. The situation is generally caused by deadlines, skills, misunderstandings, cognitive bias -- or a mixture of all of these.
In a Legacy Lockdown situation you will often find some highly qualified, highly paid system engineer doing the same monotonous task day in and day out because everybody is too scared to push forward in case it breaks the legacy systems. You will see companies going to extreme lengths in order to work around their “uniqueness” when all is needed is a bit of time and funding to bring this vintage architecture up to date.
Therein lies the problem that Cloud Native tools like GitOps and Kubernetes fix. These give you an automated, version controlled, configuration setup for your infrastructure, so you can be “moving fast without breaking things” (a great quote I learned from my Container Solutions coworkers). Done right, you are very quickly and easily able to roll back changes to avert any large scale catastrophe.
Unfortunately, however, changing to Cloud Native-optimized workflows is not an easy feat and it will be necessary to work through the five stages of transformation.
Generally, as a consultant, you are called in to help out with, or improve upon, a current project...yet it never amazes me how you will walk in and have to fight every step of the way to do just this!
So the first milestone of a transformation project will always be deny, deny, deny. My favourite thing to hear (not) is, “It won’t work for us because of our unique situation” or “Let’s just set it up again from scratch, it’ll work the second time around.”
My general advice on this has always been, and will always be: If you are looking into it you would most probably need it. And, if you do need it, don’t cut corners. It’s so much faster to do it right the first time.
Right, so you have gotten to the point that you understand there is a lot of work ahead of you. Now comes the accusations and insults.
As you peel away the complexities layer by layer, the anger of what has been done in the past will rise up. Everyone's looked at some legacy code and wondered what addled code magician wrote this function, only to see in the commit history that it was you.
However painful, this is an important step to go through. You need to know exactly what technical debt has incurred so that you come to grasp that working fast is not necessarily the same as working efficiently.
To move along from Stage 2, first let all your frustrations out (politely). Then learn from the mistakes of the past so that when you start implementing the next stage, it is in the correct way. Congratulations! You have learned, first hand, the downsides to shortcuts.
Now that you know what you need to do, you can start the process of planning. That is, taking all the tasks and bits of infrastructure that you got so angry about and formulating them into some kind of plan.
This is dangerous territory, though. When your team has heavy pressure to show progress, the first thought is of course “What can we do to get things done fast?” -- a natural reaction. And also the same thing that made you so Stage 2 angry in the first place.
What every team needs to understand is, when you first start a project it is just going to be slow. If you try to rush things there is the inevitable trade-off between speed and quality, and it is a bad bargain to even try to rush things at the outset. However, there is good news too: when you lay the foundation of a good system then you eventually get to the point where speed and quality come together. Best to start without cutting any corners, lay a slow but solid foundation -- and reap the velocity benefits later down the road.
All talk and no action will get you nowhere, it’s time to start the implementation.
Undoubtedly, you will start questioning why you started this process. Transformation is a lot of hard work. You need not only to undo bad code but also to undo bad habits. You also need to put policies and procedures in place (eeeeewwww). This is the part that nobody likes but it is essential to get to the end goal.
In a previous project, we had to go back night after night to set up a Kubernetes cluster which, every morning as the sun rose, we would then need to roll back because some component or another wasn’t playing nice.
Persistence is key to surviving Stage 4 of the transformation process. Just work through your tasks one by one and make sure you communicate with your team members.
You have finally made it! You watch with excitement as you push to your master branch and that updates your infrastructure running in production with no downtime. This is the beginning of beautiful things and your team is all wired at the possibilities for the future.
Pause for a moment of well-earned rest and enjoy. An excited team is a motivated team and this will carry your company far in terms of technology. That said, the last and final point to make here is that success is still a moving target. You will need to maintain and update your projects -- but because of your great foundation this will no longer be the monolithic task it was in the past.
It’s a long journey to get to a working Cloud Native system. Getting there successfully requires a fundamental shift in thinking for developers and management alike. However, once you finally achieve your destination you will see the benefits -- faster turn around time on work, and also shorter recovery time from major outages. Remember: it’s a long journey. Just take it step by step.
If you'd like to read more on Cloud Native, download our free eBook, The Cloud Native Attitude, below: