Part 2: Application Modernisation — Understanding Modernisation Strategies
Last time I discussed why cloud is such an important factor when modernizing applications. Reducing the burden of owning, operating, and maintaining IT assets is critical for enabling digital services as it allows us to focus less on the technology required to deliver applications and more time on getting business rules, data, and positive user experience into our applications.
This blog is going to carry through the same IT lifecycle management themes from the previous blog and dive a little deeper by looking at the strategies available and technologies that support each strategy.
The Application Modernisation Handbook defines the five possible modernisation strategies as:
Retire (decommission): Retire, decommission, and sunset application. Eliminate it from the portfolio.
Rehost (lift and shift): Redeploy applications to a different environment and change the application’s infrastructure configuration. Also called lift-and-shift. Move the application as is, or with minor changes, to a new hosting environment (small investment of resources).
Replatform ( lift, shift, and tinker): Change OS / middleware. Requiring some level of application change (medium investment of resources to change).
Refactor (reachitect): Application will be redesigned. Sections of the application will be re-written for improvement/optimization purposes (medium to large investment of resources to change).
Replace (repurchase): Replace the application’s capabilities by a new solution acquired or developed by the organization (medium to large investment of resources). The application will be decommissioned once replaced.
These are often known as the five Rs. Depending upon which vendor’s literature you follow, the five Rs may vary. The point is, when assessing your application portfolio for modernisation opportunities, a spectrum of strategies exist. Each requiring varying levels of effort, cost, and time, but also yielding varying benefits.
Let’s take a look at the spectrum available from public cloud providers.
Virtual Machines — Rehost
For over a decade now the go-to technology for delivering an application has been a Virtual Machine (VM).
We’ve observed that the majority of a typical organization’s application portfolio are being migrated to the cloud using a rehost strategy. In rehosting their virtual machines to the cloud, organizations typically optimize the compute and storage consumed by the application, but do not make substantial changes to the application architecture itself. In a traditional data centre environment long lead times and capital expenditures make over-provisioning a pragmatic approach. In the cloud, given the ability to resize resources quickly and an operational expense model ( you pay for what you consume), right sizing resources will limit cost overruns.
Organizations may also take the opportunity to deploy load balancers and implement a multi-AZ architectures for business continuity purposes. These types of changes start to drift towards a refactor strategy, but for the most part, this is the same monolithic application that existed before.
This is not a bad strategy. In fact from data available so far, more than 70% of an organization’s portfolio is modernized with a rehost strategy. It better positions an organization to take on further modernisation activities down the road.
From the perspective of IT lifecycle burden, the ownership of facilities, network, servers, virtualization, and storage have been eliminated by using cloud. On the other hand, a significant burden exists by having to maintain a fleet of virtual machines, each running an OS and likely some middleware.
Operating systems in particular represent a significant IT lifecycle burden. The Government of Canada frequently issues IT Policy Implementation Notices aimed at migrating away from end of life operating systems. A single version of an OS can be deployed on tens of thousands of virtual machines. Migration from one version of an OS can often require years of effort.
Containers — Replatform
If VMs virtualized the server then containers virtualized the Operating System. Beyond lifecycle burden considerations, containers have convenient features including immutability and configuration management. They are also considered portable as they can be moved from one environment to another with much greater ease than a VM.
The key lifecycle advantage for containers is the reduction of the number of instances of operating systems that are deployed. That operating system is usually considered to be “lighter weight” as it only contains the libraries and executables need for the application.
That being said, containers can also have a negative impact on lifecycle burden. Containers require orchestration software much the same way a VM requires a hypervisor. This orchestration software becomes another layer in the technology stack to own, operate, and replace. This why it is important to use container platform service available from the cloud provider such as AKS, EKS, or similar (right) and avoid a roll your own approach (left).
By the way, I’ve used a database as the example application being containerized. Please don’t containerize databases. Databases are commonly available through platform services. Use a platform service instead.
Platform-as-a-Service — Replatform/refactor
Platform services provide a growing list of common services such as databases, web servers, messaging, files, object storage, security, containers, and more without having to manage the servers and software needed to deliver the platform. These features combined with scalability, immediate availability, pay as you go pricing, and low IT lifecycle management burden makes PaaS very powerful.
Take an example of a typical 3 tier architecture that is popular amongst monolithic applications. The tiers of the application are divided into the data, logic, and presentation layers. The data layer is typically a database and presentation layer is served through a web server, both are readily available platform services. By migrating components of an application architecture to PaaS, you can help cull your fleet of VMs.
It’s also worth noting that Gartner considers cloud database services, sometimes called DBaaS, the future of databases.
This migration strategy can be a larger undertaking, however, starting with ‘low hanging fruit’ such as applications that has simple database requirements is a good place to start.
Serverless — Refactor
Serverless is a marketing term that gets used in a number of ways. For the purposes of this blog I’m referring to virtualization of the runtime. You deploy code without maintaining servers, operating systems, or middleware. Execution of your code it triggered based upon a configured event such as an API call. Serverless is just a specific type of platform as a service, but a growing one.
It’s not likely you’re going to refactor your monolithic application into a serverless architecture anytime soon. It’s a pretty big leap. For that reason, I’m not going to dive deep into this technology. It’s likely you’ll look at serverless for new applications, and I hope you do because it offers the least IT lifecycle management burden and quickest time to market for deploying an application.
SaaS — Replace
In modernizing an application, Software-as-a-Service can be a feasible choice, especially when it’s a like-for-like migration. In other words the software you operated in a data centre is now offered as a SaaS. In this case the migration can be performed with minimum disruption to users while still gaining the benefits of reduced IT lifecycle management burden. We observe this being a trend for back-office applications such as ITSM and email.
Non-like-for-like migrations to SaaS can be more difficult depending upon the complexity of the business rules, size of data set, and size of users. Replacing an ERP with a SaaS, while beneficial, is a major undertaking and a project within itself. We have not observed any cases of this as of yet.
What About Vendor Lock-In?
Often I hear IT professionals avoid platform services because they fear being locked in with a vendor. While vendor lock-in is a real concern, the assumption that by using a rolling your own solution you are saving ourselves from costly lock-in may not be the case.
When we talk about the cost of vendor lock-in we are talking about the costs of leaving a technology when it is no longer fit for purpose. Open standards can help reduce the friction of exiting a technology, but this far from a panacea. Typically, however, when one widely used technology decreases in popularity, the market responds with products and tools to aid migrations off that technology. Every major IaaS provider has database migration tools for example. VM migration tools are another. Both are aimed at the biggest names associated with those technologies. If a technology does not have a large user base, then the market will ignore that technology.
Probably the best summary I’ve read on vendor lock-in is from ThoughtsWorks. Even though it’s about serverless, I encourage you to read it and apply it to any technology. Key to the article is this equation:
Vendor lock-in cost = cost of migration — opportunity gain
We cannot ignore the opportunity gain that come by using a platform service. Those opportunity gains include:
- Lower IT lifecycle management burden
- Lower lead times for delivering business value
- Increased focus on the user, less on the technology
The biggest risk to increasing vendor lock-in is using a technology for which there is little competitive options. Migrating a database from one platform from another is not seamless, but it is manageable. If migrating from a self-managed database to DBaaS saves you from costly upgrades, patching, scaling, etc for the next five years, these opportunity gains can more than offset the migration costs. Another get article on how to mitigate against lock-in can be found here.
Now that we’ve gained a better understanding of the migration strategies available and the technologies to support those strategies, let’s move on to how we decide which is best for our application portfolio.
Next I will discuss assessing your portfolio to make decisions
as to which modernisation strategy works best for your applications.
