Application Modernization: What to Prioritize for Migration (Part 2)

3 min read

What, why and how to migrate in your application modernization process.

Having reviewed the application modernization process in “Application Modernization: What to Do in the Initial Process (Part 1),” the big remaining question is how to determine what applications you should migrate.

First, perform due diligence and work with your business team to understand what applications are really adding value to your organization in terms of need and critical logic. Then, you need to start understanding how to analyze your monolith application and break it into logical microservices. There’s a number of common techniques to understand the entities inside a monolith application that you would evolve to become a first-class microservice.

As you take that journey of evolving to microservices, a monolith application may break down into 20 or more microservices. Each microservice needs special treatment to flourish.

Microservice maturation

Committing to modernize a microservice is like committing to raise a child. You make a conscious decision to create, evolve, manage, and nurture the microservice. Mistakes may occur along the way, but it can eventually mature and add value to your business and society.

The physical code that sits inside the microservice encourages an engineering team to invest time and energy to nurture it. An engineering team rarely deletes a microservice one week or so after creation due to the amount of time spent on creating thousands of lines of code.

It’s common to take a piece of code from a microservice and keep maintaining, repairing, and evolving its logic. This activity especially is true when more than one engineering team in your enterprise wants to expand the technical choices behind a microservice.

Microservices and the 10-10-10 rule

When modernizing applications and building up a suite of microservices, a good policy to use is the 10-10-10 rule, which consists of limiting the following elements during the activity:

  • Ten developers in charge of maintenance
  • Ten microservices undergoing maintenance
  • Ten points of business application integration interacting with those microservices

Those figures help you determine the amount of work and changes that your team can handle and the amount of flexibility that they can operate with around the microservices. If you have too many microservices overseen by too few people, you get very little forward momentum on your application modernization. Or, should you involve too many integration points, the result can be more possible risk and exposure than you’re ready to address.

Under this rule, you have teams managing the evolution of their modernization element or building brand new application innovation. Additionally, they’re managing the delivery, support, and other tasks necessary to keep those microservices functioning 24/7.

Making microservices into business contracts

Many organizations put their suite of microservices in a wrapper, controlling the flow of execution for deploying each component. These wrappers use a single application programming interface (API) that offers a point of integration to another suite of 10 microservices or another team of 10. That wrapper would turn the set of microservices into a business contract, which can benefit your organization.

Let’s say you’ve got 100 microservices, all with different APIs. You can straddle a set of business APIs so they project a client-friendly API to a user interface. For a large cloud native organization, you can create tiers of APIs so you can talk to one API about customer management and that business contract will behave as you expect.

A business contract is like a service-level agreement (SLA) for your API performance. By installing a business contract around evolving your API performance, you establish what you can commit to deliver while allowing for the flexibility of change in your applications.

Application modernization and planning for the future

As you make decisions about your architectural solutions, you need to balance what needs to change rapidly, what doesn’t need to change, and what business contracts will you provide consumers. Say you’re modernizing from a structured database to a nonstructured one. Exactly why are you doing that? Do you want more flexibility of data storage, or a style of data you want to persist, or some other reason?

Some services you need to evolve. Other services you may need an API contract so you can augment into your modernized application to improve a business process. You have to make these decisions as your business evolves from one platform to another and needs to modernize applications at the same time.

Application modernization and IBM Cloud Satellite

IBM has core solutions around data, AI, machine learning, and more that can add value around your API. You can migrate your application or build some logic around the application to manage that interaction.

Consider using IBM Cloud Satellite as part of your journey to application modernization. IBM Cloud Satellite is a distributed cloud offering that brings IBM Cloud services like the managed Red Hat OpenShift on IBM Cloud to the infrastructure of your choice. 

Learn more about IBM Cloud Satellite and join the ongoing beta.

See the following video for an introduction to IBM Cloud Satellite:

Be the first to hear about news, product updates, and innovation from IBM Cloud