Our journey to monolithic to API-Led/Microservices architecture
or a challenging experience of my life and came out mostly unscathed…
I joined an organization where one of the transformation projects just started. It was a legacy application build on legacy tools. I have been asked to help the teams to move to new architecture- Microservices architecture. The current software was crucial and many people dedicated themselves to its creation.
Would you take a risk of bringing something new, when everyone is afraid of or against?
How do you motivate people to try something new?
How would we re-implement an eco-system?
How could I sell a new architecture without being the most hated person in the company?
Getting Started
This was going to require a vast amount of planning. We not only needed to understand where we wanted to be, but we needed to have an accurate understanding of where we were today. We had a huge task in front of us and we needed to set realistic expectations.
We were going to have to use every skill we had acquired in our careers. We needed to be Architects, Data Gurus, Systems Analysts, operational manager and relationship builders. We needed a plan and we needed to stick to it, even if we face a lot of challenges.
Our Steps To Success
1. Plan, Plan and more plan…..
Planning is very important. Whenever I think about the plan, I remember this quote.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe. – Abraham Lincoln
We don’t know what we don’t know.
Now that is true. We should never assume that because we did something once we now understand all the idiosyncrasies of this implementation.
How did this apply to our story?
We were new to the organization, we didn’t understand the history behind the services or the reason for their existance…
We came into this completely blind. This was going to be difficult because of the time we needed just to get to the knowledge level of the rest of the team. We still could never get full parity with them, some had already forgotten more than we could learn.
We needed to try to absorb as much as possible and create a temporary diagram that made sense, we could then validate it against the group to see if we were on track. This concept allowed us to prove that we understood the concepts and drawing our own diagram proved ot to the other teams
What did we learn about planning effectively:
- We needed to get the motivation behind the services, not just the technical reason for their creation. Understanding the business value is important.
- We had to gain a clear understanding of the current systems. This includes their inputs/outputs and dependencies.
- We needed to understand the difference between what they were created to do and how they were “actually” being used.
- Can we improve anything, or is it simply we are rewriting the same features.
- Listing down all the real requirements, nice to have and value-added features.
2. Re-evaluate
After we felt that we had a pretty good understanding of the current systems we moved on to re-evaluation. Our re-evaluation was in two parts. First, we needed to see if the current solution still filled the business’s needs. Second, we needed to help the current teams mentally adopt the API-Led, microservices.
Re-evaluate the Solution
We need to re-evaluate if the current software we had today still fit the business requirement. If our current requirement is matching what about the future requirements. Need to see, where the business wanted to be and when.
Thinking these things in our mind, we allowed us to build trust by showing how our re-architecting and re-building was going to let them iterate faster on business ideas. They can also see that we are more business values rather than just building another technical change.
At the end of this process, we needed to be where the business wanted to be, not where the business was.
Re-evaluate the Technology
We need to re-evaluate the technical solutions. We are analyzing the big monolithic application and understanding why it is built like this. Maybe because at that time, that was the best solution, or do we had some constraints that time? Are we still having that organization constraint now as well? How can we overcome this.?
We see this a lot in many organizations. We get something to the point that it works and before we address the 5% of things that we are not comfortable with we need to move on. After the next round, there are 7% of things we wish we had changed.
This was the reason we wanted to adopt an API-led architecture and Microservice and some sort of Serverless methodology. We wanted to remove the 5% we regret not addressing by having simpler, easier to configure, services. We did an analysis of whether microservices architecture really fits into our organization. What are the implications? Are we ready for this?
To our conclusion we came, microservices would be little overkill in all the scenarios and API-led architecture would be perfect. We still have a need for microservices architecture in some of the scenarios.
We needed to relate all of this to the engineers, we wanted the engineering teams as a whole to be on board with this ideology and process. Some groups took longer than others. Some adopted the ideas right away and even advanced our thoughts. We don’t know how it’s going to go until we try.
Technology is easy, Organizations are hard. — Vinay Kumar
The hardest part of this process will be the organization culture & people. Transformation or re-engineering projects are not only specific to technology change, but it’s also a culture change too. This can depend on a few factors in some cases:
- The closeness between an engineer and a service. Some are so close to a project that the thought of changing anything can be very difficult for them.
- The longer the engineer has been there. If an engineer has been around for a while the chance increases that they have seen failed attempts to change. Each failure reduces the person’s confidence that it can be accomplished.
- Their engineering generation. Old engineers are hesitant for changes and newer engineers adopt things differently. Some have started learning development on these newer patterns and do not have the experience that others do.
In re-evaluation, you want to ensure that you are actually doing the right thing and that the engineers are on board with it.
3. Preparation and standardize
Now that we knew the requirements and scope of re-engineering. Developer teams are on board, We needed to create the support tools to be efficient. In many cases, the tools already existed, but we needed to select what was going to work in our situation the best.
In this phase, we need to all the preparation for the re-engineering. Either this can be database cleaning, environment mapping or defining API definition ready. This can be anything. Most of the organization miss this phase, this is an important phase, where you need to do all the necessary tasks to be ready for the implementation.
In our organization, we focus very much of API first approach, where API definition is built and reviewed with business/product owners with multiple iterations. We have used Apiary for building API definitions using API blueprint format (human-readable.)
We also need to see, how the deployment would work? Were we going all-in with one provider or splitting services? Did we need to plan for a catastrophic “cloud” meltdown? Do we have sufficient tools for DevOps? Do we have enough licenses etc?
Focus more on implementation-related. When we speak about tooling we are “actually” talking about all the things required from project creation to development and deploy.
Project/Template Creation
We developed serverless service patterns to enable re-use. For instance, with many API’s you are doing the same thing over and over again. The only difference might be the size of the average payload and the usage pattern. Because of this, we create a blueprint that worked for 90% of the use cases.
A user can easily get a project started with all the initial files they needed. This also allowed the projects to follow the same build and file strategy which helped engineers move between projects easily. You can also build commonly used the template for the project.
Infrastructure Creation
The cloned starter project and blueprint allowed for us to take the heavy lifting out of creating infrastructure. It also lowered the barrier to entry for those who were not as familiar with that side of the house. The engineer only needed to modify a few lines in the configuration file for the blueprint.
The rest of the configuration had been tested and the engineer had confidence that the components would be able to talk to each other correctly.
Deployment
As we need containers, we need to define the full strategy for the container. If it is docker, get the license of docker enterprise edition, Kubernetes or openshift as a container orchestrator.
API management- As you are building API-led architecture, we need to have API Gateway or full-blown API management solution, it can be from any vendor. Choose wisely all the API management solutions and see which one fits for your requirements.
Recommendation- Its better to define or build the API standards and containers best practices. It is also good to learn some experiences on challenges on service discovery, API documentation, And APIs security. My architecture mantra is cloud-native, Knative and cloud/technology agnostic.
4. Create an iterative Process
Our teams were already agile and had a well-planned sprint schedule. We wanted to carve up these services in a way that allowed them to use agile to the fullest. If we had made things “too big” they would never complete all the tasks needed in a cycle.
Gaining the right balance meant that the team was able to take the user stories and easily make the modifications needed. We developed a process called MTME. (Measure, Test, Measure, Enhance)
The Results
Our journey took 2 years and it is still going on. Somewhat we got some stability now. If I could talk about all of the detail in the systems you would not believe that number. It was one of the most challenging things in my career, but also the most rewarding. We were dealing with more than code, we dealt with emotions, ideologies, and deep-seated concerns.
The end made the pain worth it.
In the sub-title, I said that I came through it mostly unscathed. That’s true, while during the process it might not have felt that way, afterwards, it wasn’t bad at all. I took my knocks, had arguments, and sleepless nights curious if we were off track. But, in the end, we build something we could all stand behind and now, with this architecture, the next pivot won’t be nearly as painful.
