Legacy Modernization through Kubernetes

A realistic approach

First of all, if you think I am going to talk about adopting microservices, you couldn’t be more wrong, okay :D

When talking about modernization, we start from the place where companies already have their applications running, and of course, in 2023 many people have already heard of microservices, of Martin Fowler, of decoupling, of single responsibility, and so on. There are many articles on the subject out there. Here, I want to mention a realistic approach to modernization.

The central point of this theme is that companies today already have their applications and they are already making money, so why mess with a winning team? Because this is the best time for it, since the business is not facing a crisis; therefore, they have time and money to invest with a certain peace of mind. The occasion is also favorable for the team to dedicate its cognitive abilities to learning and putting into practice new approaches and processes.

Obviously, this would be the scenario in an ideal world. After all, we know that the existing application has its own demands, such as updates, lifecycle, monitoring, and operation. Leaving it aside to work on a second version is not possible.

It is considering the mentioned points that I arrive at a strangling approach, or Strangler Application Pattern, which makes a lot of sense to me and I will explain a bit more.

In this approach we have the legacy coexisting with the new features and approaches, so we do not have a "switch-turning" moment here, but rather a transition (as smooth as possible) between versions. The most important thing here is the moment of planning and engagement of the teams, which will have as their biggest obstacle continuing to implement features in the legacy system. After all, the teams already know the old processes. That is why it is so important to align engagement even with client teams, without tightening deadlines so this does not cause giving up.

Here a doubt may arise: why not simply rebuild from scratch? This is an important question, as rebuilding from scratch implies a major investment of time. Imagine it took a year to create the existing application. Even with the experience gained, your team will need at least 9 months to give birth to the new version. How much can your market change in those 9 months? Does your company have the breath to invest all this time in development? Why not go ahead with the strategy of launching features, testing, and improving? Thus, throughout the process your applications will be evolving, your team will be improving, and we won't have any "all or nothing" breaking points, facilitating errors and corrections.

I want to go back to the point of non-microservices or a realistic approach. Microservices' needs are gigantic. Working with decoupling by itself is already a difficult task, which depends on great planning and vision from leaders. Still, this approach requires quite some time to bring results, given that there are many small parts to be built before they start participating in the process. That is why I want to leave a reflection here that Ross Garrett made some time ago about "Miniservices", where modernization happens in phases without skipping any steps, keeping current services running, creating increasingly decoupled services, and aiming for microservices. However, without the pretension of achieving that goal right in the first phase.

Ok, and where does Kubernetes enter into all this history?

Kubernetes is the foundation for all this transformation to occur. For this planning to become a reality, a few points are necessary:

• Ease of creation

• Integration between tools

• Well-defined processes

• Governance

  
  

Initially, the focus should be on how easily teams can create environments and have availability to use them, of course following governance parameters and processes. However, the integration between environments and tools prevents these processes from becoming rigid, as was the case with ITIL. For example, Kubernetes brings freedom by allowing the integration of existing processes and even automating them, because it makes no sense to perform actions like having to open a change management ticket (GMUD) to update an application that has already gone through CI/CD processes. However, it does make sense to have this process within your pipeline, which updates the application from a change made and approved in a branch.

Having an infrastructure that enables the agility and scale necessary for these changes is fundamental to the success of your company's modernization or transformation. The level of automation that Kubernetes natively possesses will not only give you this advantage but also other uncomputed benefits, such as: a modern stack where your team will be happy to work, where your applications of all kinds can be born standardized, and your teams can work on features rather than keeping the infrastructure standing.

I mentioned in different paragraphs a modern or cloud-native stack, and perhaps some might think that this is an "overkill" solution or a bazooka for a fly. It is important to clarify the matter, as much is said about Kubernetes' complexity and how its robustness applies to large environments. However, Kubernetes was not developed solely for giant environments, but rather to be the infrastructure for all environments, since initially every application needs computational resources and is a process running on machines.  It is precisely this that is the goal of Kubernetes, keeping these processes running and tasks being executed, simple as that.

Up until now, bringing resilience and monitoring to an application that works to keep other applications running (and this applies from functions for your APIs, a virtual store, giant streamings with millions of APIs, to machine learning environments operating Terabytes of data), was a task for the operations team. 

Kubernetes fits into all environments and scenarios. We can start with small environments and grow as necessary for the business without having to create a new stack just because it is now size X.

Keep in mind as well that a modern and cloud-native stack is not composed only of Kubernetes and the application. Consider factors such as monitoring, governance, pipeline, security, logging, tracing, not to mention the countless applications that run inside Kubernetes itself, such as Databases, Messaging, API Gateways, Service Mesh, among others.

So do not treat this issue as a sprint, but rather as a journey that will require a lot of effort.

Here are my tips for a modernization:

• Planning: Have a plan with clear objectives and goals that can be measured.

• Automation: Automate everything possible from your pipeline to governance processes. CI/CD and GitOps are great starting points.

• Look at this beautiful definition: “Continuous delivery is the repeatable process that allows a fast, predictable, cheap, frequent, and low-risk delivery of software.”

• Monitoring: It is necessary to measure everything, not just applications and infrastructure, but also tests, deliveries, and the goals themselves.

• Communication: Keep the team updated, aligned, and motivated. Nothing is better than an engaged team to successfully complete a plan.

• Eliminate "Waiting Time", this is definitely a huge gain for deliveries.

• Documentation: Include it in the modernization process; today there are several applications, including monitoring ones like Calico Enterprise, that display an updated map of your applications and how they communicate, which is very important as the number of applications increases.

My final tip: Start! Sit down with your team and begin planning the modernization of a simpler application where you can learn and break some ground, and then move forward. And it would certainly be a pleasure for us to participate in this phase.

To advance on this journey, speak with a specialist.