My production operations is spread over many generations of tech - from legacy, bare-metal to cloud VMs / containers. Are there any patterns from the cloud native world that can/should be used on the legacy side or is it better to leave the legacy to follow its old deployment model (i.e. pets that require a lots of hands-on love) until the boxes disintegrate?
Hi Greg! Boy, do we have some patterns just for you, lol. As we were writing this book, we actually were working with a client who wanted to go from running COBOL on a mainframe straight to containerized microservices orchestrated by Kubernetes. So we feel your pain, and there are patterns in the book (also, significant sections in Chapter Six, "Tools for Understanding & Applying CN Patterns") to address exactly this kind of legacy scenario.
I would in particular point you toward the following patterns: Lift & Shift at the End, Manage for Proficiency, Strangle Monolithic Organizations, Strangle Monolithic Applications (related but very different) and Avoid Reinventing the Wheel. All of these would be applied to the legacy side of things, with the understanding that there are some things that—assuming they are stable, working well, and don't require frequent updating—can simply be packaged up and moved over intact to the new cloud platform when it's ready. Rather than trying to recreate, from scratch, a huge legacy codebase that evolved over years, decades even, and has reached perhaps millions of lines of code, it's cheaper (and makes more sense) to build a wall around it and then build bridges between your legacy bare metal and the cloud. Then, once up and running, you can begin to split it into pieces as you have time and resources to do so, and as it makes sense for your own situation, and refactor them over time to run on the cloud. In your case you'd have to stay one step ahead of disintegrating boxes
In particular, we describe this process (illustrated through patterns) in the WealthGrid transformation design in Chapter 12, the "Strangle All the Old Things" section.
Right now I'm working with a customer who also has some substantial Cobol codebase together with other outdated technologies.
Such environment cannot provide long term competitive advantage (although those systems are in place for decades now).
So, the change and reinvention is essential for healthy growth.
But it is also important to remember that the change is not a goal of itself. There has to be a well articulated business reason and a well defined strategy and a plan to make it happen without destroying a successful business.
In most cases it is a long and painful process, but in our experience, once the things start moving, people get very motivated and keep pushing for improvements until full modernisation of the underlying systems.
It sounds like the book has some patterns that I'll be able to employ. I'm certainly not interested in change for change's sake. My concern is keeping ahead of degrading hardware and adopting migration patterns that provide a smooth transition for our customer services.
Thanks for your feedback!
Run away! Run away! Here, take this tiny ad with you:
Free, earth friendly heat - from the CodeRanch trailboss