DevOps on legacy infrastructure
Much of the content and experience on DevOps is targeted at organisations on the “Happy Path” using common development techniques, user workloads and deployment models. There are often a number of common themes with these case studies. All of their users generally use the same version of the product – running on a mobile tablet, phone or in a desktop browser. Their workloads are running in AWS or Azure or similar and they have no legacy systems to be mindful of and no on-premise infrastructure.
Their users all have the same version of the software, and users can upgrade from one version to the latest one with no concerns around data or integration issues.
If you do fall into this category, your life is easier and your path to DevOps is clearer. In fact – for many organisations falling into this category, especially if your systems are only a few years old, you’d be unusual to not have your entire application estate in the Cloud and to not have some form of CI/CD in place already.
Working On The Happy Path
At Ten10 – whilst we work with customers on the “Happy Path” I’ve just described, a lot of our customers don’t fall into this category… Organisations who have been running their systems for many years, sometimes with parts of their systems running for decades, in a combination of on-prem and hybrid infrastructure.
Perhaps your organisation is a little bit of both. Often, we’ll speak to customers where everything seems fairly happy-path, they have their web and mobile front end running in The Cloud, they run microservices architecture and have continuous testing in place… all is good. Then, they lean in, lower their voice, look at you in a conspiratory fashion and say “there’s something else you need to see” and lift the corner of the architecture diagram to reveal an ancient mainframe, or AS400 based system running a large part of their workload. Or in the case of one customer, we worked with – they had not one but two separate duplicated systems, each running on its own mainframe, inherited in the early 90s through buying a competitor.
The decision was taken at the time, “of course we’ll consolidate both systems, but let’s run them both for a while and let the dust settle” 30 years on they’re still running both, but none of the original teams working within the business anymore. Nowadays, their headaches around change, testing and deployment increase exponentially with each passing year.
Perhaps you have a core platform that, in theory, is delivered in vanilla form to hundreds of customers – all of whom are running a dozen different versions of the core platform AND you have multiple teams working to develop features both at a client level AND at the core platform level. It’s mostly OK but three of those customers (sod’s law states they’ll be big, important ones) are on a version that’s past end-of-life support and are resisting all pressure to upgrade.
You may have a whole set of devices and hardware that isn’t the usual range of consumer iOS and Android devices. Perhaps they’re ruggedised or embedded devices you created yourselves – supporting automated testing and deployment on these is complex and a long way off the happy path but still possible.
Alternatively, your core application could integrate with many different services, all provided by different vendors, all with different release cycles, QA and release processes that vary between mature, comprehensive and effective to those that are barely fit-for-purpose.
We have experience of working to deliver automation and pipeline engineering services on all of the above examples, not just on the happy path but with organisations that are a long way away from it.
Yes, they present challenges, yes there isn’t the same breadth of tooling and solutions out there that exist for “Happy Path” technical stacks, but it’s all very possible. If you want to embrace modern engineering practices and be able to release frequently and with confidence, but you think your tech-stack makes that impossible, get in touch… We love a challenge!