What does “App Modernization” Mean Anyway ?

Recently, I have been working with customers on “App Modernization.” This is the new emerging term focused around taking existing applications and changing them. I have captured a list of different definitions I have heard from different practitioners and customers. A bunch of them relate to microservices.

  • Refactor Applications into microservices.
  • Strangle a Monolith over time with new microservices.
  • Completely rewrite all of it as new microservices
  • Augment Old Code with new microservices representing new features by calling new APIs or some cloud API.
  • Containerize an Existing Application / Workload.
  • Move an application into a Cloud.
  • Expose API’s out of existing applications or databases, so they can be called by new applications, chatbot.
  • Do a bunch of automation (provision scripts, CI/CD, testing, Infra as code)

I spoke about the dangers of making microservices a goal. Usually they are attached to a Digital transformation of sorts, for example, redoing your website, etc….

App Modernization that involves rewriting applications should be Business Driven, and not a technology lead endeavor. There has to be a business driver that leads to new revenue or significant saving.

Some factors that you should look at.

  • I need to release specific features at a very fast pace. Usually customer facing applications have really good reasons to refactor, rewrite, and technical teams should work directly with Product Owners. Do NOT preplan a “number of microservices” ahead time as a scoping exercise.
  • I need to enable concurrent development. Some caution, if you find a high amount of coordination between squads to release things, you have divided TOO much or incorrectly. If the same 5 microservices are always released together, maybe there should have only been 1 application, unless, it maybe that you still get efficiencies of Development through a certain stage of testing.
  • I need to scale individual pieces up and down independent of others.

It is hard to rewrite a 15+ year old application, and splitting it up into small pieces with the same exact functionality will not make your life easier. It is harder to manage 20 little things than 1 thing.

However, there are many other technical goals in modernization. Much of the emphasis in modernization is focused on the developer. However, in more cases than none, the developer is probably the most modern person on the team already.

What we really need to modernize is the Operations teams and DevOps teams. The first modernization journey should be focused on containerizing a candidate application and learn how to do the proper automation, deployment, and that you can actually troubleshoot, monitor, and manage that application. From there you can grow and build upon that foundation. So for example:

  • Containerize an Existing Application / Workload. Existing Java Middleware is usually a good candidate. However, you may need some assessment help.
  • Automate Software Configuration, including adopting Infrastructure as Software. This includes Platform DevOps (terraform, cloud formation, etc…), provisioning (or configuring a managed one) a Kubernetes Stack, creating namespaces, network, storage, etc…. and do it repeatedly.
  • Get your architecture set. How do environments map to number of clusters, How do you configure HA/DR, how do you handle internal and external networking, how you handle storage, how do you replicate state, how do you failover (yes containers restart themselves, but you can can still have bad behaving applications, failed Pods, Nodes, Machines, Regions, Buildings, Blocks, Cities, states, countries, world, planets [I went too far didn’t I] )
  • Automate deployment of existing application. You might be doing CI/CD, but there may be significant changes. For example, it is now application teams providing Docker Images, CI/CD might do things like orchestration with HELM. Much more testing, including Unit Tests, Functional Tests, Performance Tests, Smoke Tests, No downtime upgrade testing. Embedd DevOps into squads where developers are authoring or updating Application Configuration.
  • Setup the right management stack and learn how to do logging, troubleshooting, monitoring of containers, monitoring of kubernetes, etc…

If you have these things going, then you have already modernized, and set yourself up for managing more complex applications that follow a distributed or microservice style.

In summary, I want to share an experience. I once held a workshop. The shop had both a development team and an operations team in the room. The development team had a vision for a modern stack, but a 3 year roadmap to get there. They blamed the operations teams for the length of time. The Business did not like waiting 3 years because they had a business reason to move the app. The groups started arguing a bit and I felt like a therapist. It became apparent that it just cannot be a development team modernizing, but an operations team needed to as well. They were not going to do a Spotify model overnight.

We white boarded a Journey for them that looked something like this.

Starting Journey

The board had much more details, and eventually teams split into even smaller efforts (SRE adoption, Security and compliance, Application Assessment) but it gave a fuller set of modernization tasks across the various roles they already had and they started working towards a common goal. The Journey was also much less time.

> Learn more about how you can co-create with the IBM Cloud Garage.