One of the features we are seeing from organisation is a move from virtual to container based platforms for their workloads as part of a migration strategy. I use the word ‘migration’ rather than modernization here as there are some differences. For any migration strategy there are potentially three options:
- leave alone
Leave Alone wasn’t always possible as it meant leaving legacy platforms and software in place, where cost savings weren’t realised as licensing and maintenance costs remained the same or even increased even if the workloads were left. They might be difficult to integrate to and pain to maintain. Leaving nothing behind was the only option and blowing away the platform you were migrating away was a necessary action. Using the traffic light system any application environment can be rated green (straightforward), amber/yellow (possible not easy) and red (really difficult or not possible). Leave Alone is now an option, partly because you can wrap an API or some form data virtualisation around the existing application and negotiate a favourable deal to keep the platform until you can turn it off or find a viable replacement. Letting these applications whither and die slowly of natural causes is less traumatic and much easier to manage.
Migrate is really a re-platform, where lets say a Java application moves from say Websphere to EAP on Linux virtualised, which is a lot cheaper both at the app server level and potentially OS platform level. This might be a move from a physical or virtual environment to a new lower-cost virtual environment and it isn’t seen to be cloud ready. But more on this below. There are migration tools and some automation that can take place to re-platform an application which can make it relatively straightforward but still takes managing and planning. Migration will also involve changing the processes and organisation needed to build and run these applications.
Modernize is really taking an existing virtual workload and making it cloud ready. That is redesigning and rewriting it as a set of microservices and running it as a container and having a fully cloud-ready workload. There are no real automated options and it’s essentially a re-write of the code to take account of the new architecture.
However, increasingly the target platform for any migration is a cloud orientated one, one for containers rather than VM’s. Therefore you find virtual machines as containers, monolithic and large and not exactly as a set of microservices. These microliths (monolithic containers) are good in that provide greater flexibility in managing the platform and applications, and its a step in the right direction for fully modernized workloads. Adopting a container based approach also means you can set up the tooling and practices needed going forward; you can improve process and organisations gradually with the familiar application development process. The operational process also allows teams to build, deploy and redeploy development and test environments a lot quicker than with virtual environments.
One of the pitfalls however, of having a virtual workload on a PaaS platform in a container, is that the platform cannot provide high-availability (for example) and that a lot more of this type of functionality therefore it needs to be in the application design and build. It might not important, especially for platforms in Dev and Test and really speed up development times. Not having to maintain virtual and container platforms is an advantage, and whilst creating microliths seems a bit perverse, there is some logic if its understood that as well as beginning to understand what it is needed in the future, the means of developing and running this type of platform is underway.