Category: DevOps Practice

There are many reasons an organization may find itself on the path to considering the risky journey of application modernization. It could be to gain an edge or to build a more competitive positioning, or a business could have a legacy system running on infrastructure that is no longer viable, leaving them no other choice. But the conundrum for organizations still resurfaces when considering app modernization; they must select one of these two routes: Either “the failure rate is high, and failure is simply not an option” or “Everyone is still doing it, so let’s forge ahead.”

The Benefits of Choosing Application Modernization

Whether an organization chooses this path out of necessity or ambition, modernizing an old IT environment can deliver several benefits, ranging from reducing outdated hardware and software to creating new value through innovation. Specifically, the key benefits are:

● Reducing technical debt and improving the underlying infrastructure: Improved security, operations, reliability and scalability.
● Decreasing expenses: Lowering the cost spent on expensive hardware and software improves the utilization of resources, thereby decreasing the total cost of ownership of technology operations.
● Accelerated time to market: Modernized IT and product development gain value from technological improvements that decrease the time it takes to develop and deploy new products and services.
● Agility in the market: Modernization enables an organization to react to changes at an accelerated rate, providing a competitive edge in the market.

Choosing the Best Path to Application Modernization

There are different paths to modernization, each with its own focus. On the one hand, there’s the infrastructure aspect of building your platform engineering practice versus adopting a service approach with a platform-as-a-service (PaaS). On the other hand, there is the actual process of modernization with options like refactoring, re-platforming or rewriting your systems, either in-house or through outsourced services. It ultimately starts with modernizing the relationship of the application with its infrastructure and changing some assumptions.

Once you have a baseline, running everything else should come from a cost-benefit analysis. A scalable, well-managed monolith is valuable despite its age. Ensuring horizontal scalability and a robust backup strategy are key to effectively managing mutable data.

First, understand the blockers in your current implementation that would complicate a shift to the cloud. Or identify where the result may not deliver any value.

There are very common anti-patterns that remain anti-patterns, whether on the cloud, running on managed hosting or on-premises. Identifying them allows you to start absorbing technical debt regardless of whether a move to the cloud happens as intended.

Anti-patterns to look out for are:
● Weak separation of code and configuration: You want to be able to run many parallel instances of each application as separate environments. Telltale signs are hard-coded URLs and service credentials. The dependency is the capability of running ephemeral preview environments that are quick to launch and quick to destroy, such that you know that you are “cloud ready.”
● Weak separation of the read/write domain from the read-only domain: In a cloud deployment, you want a build step that creates immutable artifacts that are not modifiable in production, and you need to know where all the actual data resides. Older applications tend to “believe” they own the whole disk.
● Manual configuration of services: You should be able to run “stock” services without any manual configuration in case the need for a specific database configuration arises and signals the likelihood of an application issue that requires debugging.

Simply packaging a Docker container or a VM image and deploying to an IaaS won’t create any benefit and only increases costs. The first step to success is a thorough clean-up and update of the documentation to start the process.

The one basic rule to follow is the ability to run an arbitrary number of instances of every element. Achieving this will allow everything else to flow. There is no need to rush to transform all Crons into “separate workers” and break the monolith into microservices. But the proof that it is possible now exists.

The Best Approach to Application Modernization: In-House or Outsourced

A mixed approach between in-house and outsourced is often optimal. There are many elements to consider. If you have a minimal in-house understanding of what the cloud imposes as constraints, you may be tempted to go for the simplistic lift-and-shift approach. Outsourcing everything can lead to huge amounts of lock-in.

There are ways to cut corners that could simplify and accelerate the initial project, but this could increase the costs down the line. There needs to be a level of abstraction where using a PaaS is a winning proposition and can provide quite a bit of abstraction at no cost.

Without control, the project may end up as something that “runs on the cloud” without the actual benefits. But there are many ways to do that.

The Right Mindset Will Help Avoid Pitfalls Along the Way

By neglecting constraints and skipping the necessary preparation, the costs may escalate. Running big chunks of hardware continuously versus using small ephemeral resources as needed typically leads to significantly increased costs over time. Full rewrites often go wrong when trying to obtain all the benefits immediately.

A simple four-step approach for success is:

● Start with modernizing the relationship of the application with its infrastructure and changing assumptions.
● Identify and address the blockers in the current implementation–this makes a shift to the cloud less complicated and enables a smoother transition.
● Set a baseline that allows everything else to run from a cost-benefit analysis. Ensure horizontal scalability and implement a robust backup strategy to effectively manage mutable data.

Accepting that app modernization will be a journey and that the initial implementation is a slightly more scalable and resilient version of the original. This is often a better mindset that leads to a more effective process.