Pathways to the Cloud
Over the past couple of years we have helped and advised a range of organisations (both public and commercial) in relation to cloud adoption, largely based on our experiences in that space to date. At the recent AWS ReInvent there was a lot of chatter amongst exec about the approach to cloud adoption - unsurprisingly most organisations still seem to follow the ‘lift and shift’ approach to getting out into the cloud.
Broadly speaking there are two pathways to cloud - one is the lift & shift and the second is re-engineering for cloud. Each pathway comes with its own set of considerations as well as risks & benefits. We have experience with both approaches and I thought it might be useful to capture highlights from each approach here.
The lift and shift approach requires little up front work and can get you into the cloud faster. On the downside this pathway can require a fair amount of clean up work. Post shift you will mostly likely need to remediate things like network & security configurations to make best use of cloud environments & tools as well as a bunch of cost optimisation work to ensure you’re getting best bang for buck in terms of CPU, storage etc. costs. Looking at things like machine sizes/types, reserved vs non-reserved instances and the like requires someone who understands cloud infrastructure to optimise your application/infrastructure environment.
Problems tend to start cropping up when organisations complete the first part of the lift and shift and then don’t do the follow up actions. You essentially end up with the worst of both worlds, and the benefits of neither. I think a lot of people who are disillusioned with cloud adoption are in this camp. Like I’ve said countless time - cloud adoption isn’t simply about someone else running your infrastructure and yet so many people still seem to get stuck there.
On the flipside a re-engineering for cloud approach requires more time and investment up front. In effect this involves converting the existing application/infrastructure to take full advantage of cloud based technologies such as serverless and ‘as a service’ components such as a databases. This approach simplifies the migration and helps you realise the benefits associated with cloud adoption quicker. It’s also the more future-proof of the two approaches.
Either approach is a valid pathway to the cloud but you need to understand the implications of both pathways and select the one that makes sense for your organisation and strategy. Whichever way you approach it you do need to ensure you have a robust plan and sufficient funding/resources allocated to the effort.
We have kicked off the modernisation of our core line up business application (actually roughly 17 apps in one molithic stack, thousands of lines of Java code, approaching 15 years old) and as part of that we are replatforming the database, implementing a container based infrastructure and converting the monolithic applications to microservices & APIs. This is squarely down the re-engineering pathway.
We are doing all of that on a hybrid of public and private cloud but operating under a ‘cloud first’ principle. The plan is to modularise the application to create more choices (some of the modules might for example be replaced by SaaS offerings) before modernising components and eventually rebuilding the UI/UX elements.
Part of this modernisation will include a move towards a more DevOps-style operating model and and adoption of continuous integration and continuous delivery (CI/CD). We are investing a lot in building capability in that space and helping people & teams transition from the current operating model and tools to the future operatng model.
Modernisation of a legacy application is always inherently risky (and expensive) - you only need to look at other modernisation efforts like Kiwi Bank to see examples of that. Utilising cloud-based technologies helps us accelerate the change and trial/test options to find the best way through the modernisation effort.
We expect our modernisation efforts to take between 18-24 months and they are an integral part of our wider organisational digital transformation efforts. We will continue to migrate other workloads, and builds new applications, on public cloud infrastructure during that time.