There are millions of articles that say how great microservices are and how awesome it is to use them from several points of view, but this article is not meant to measure the greatest of the microservices infrastructure but tell you the real cost, that nobody is telling/displaying you about implementing this kind of infrastructure. To do this kind of migration from a legacy monolith to a microservices solution is not easy and actually I dare to use the words “horrible” and “stressful” when done complete wrong.
There aren’t many success strategies to implement it from a management point of view, but before starting please take in mind the following(s):
- This is NOT a tutorial
- This is NOT a measuring article or manifest regarding if microservices are bad or not.
- This is NOT a story told from a Project Manager’s point of view. but it’s a story told from a developers point of view.
This article in exchange will attack the following points:
- Are you a core system ?
- Is your management aware of the costs ?
- Is your team aware of the costs ?
- Do you have someone in team that handled microservices in the past ?
- Is your infrastructure stable ?
Background of my work
In my area of specialization my application is in reality an ecosystem of applications that lives inside a large monolith composed of multiple different type of applications that are also part of their own ecosystem.
You can think about this infrastructure like a StateMachine infrastructure where you have the core StateMachine that represents the starting point of everything, maybe like the login page (as an example) that redirects you to the internal system that has multiple search inputs , links, etc. And those links open themselves small/large application that are StateMachines.
To bring a little background my main focus is on Banking applications.
Point 1: Are you a core system ?
In every large company the system that in most cases is monolithic even today in 2022 (but can also be applied on the rest of types) you have at a high level, two types of modules/system/projects/components how ever you wish to call them
- Type: core
- Type: consumer
NOTE: “This is just my personal terminology, if I find a more used term I will update the article”
Core means that your application is focused not around interfaces (UI) for an end user but your business is focused on core concepts that must offer support to other systems to consume (consumers) your logic.
Example:
- Core system: Payment System
- Consumer: Loan System paying for installments If you are a core system in that case your life is much easier because the number of sub-calls you need to do to other sub-system is less to none, thus making your communication in infrastructure less messy.
But as a core system you have a lot of pressure to satisfy the following points:
- Speed: your endpoints need to be as fast as possible you can’t have a reason to be slow, you as a core system that offers to other business need to think about how fast your endpoint is by using whatever strategy can be applied on your project (like caching or event based solutions). The reason if it’s not already clear is that, if consumers are coming to digest (call) your endpoint but that consumer represents a large business unit they can’t stay on your endpoint 1, 2 or 3 seconds, in my case if I see more than 800miliseconds we must have a discussions on what are you doing their.
Example:
In the above simple example we can see that an UI is responsible for creating online a loan for a client. It can have 2 sub call’s to systems that checks the credit line of an client and also creates an account for him if all is fine. But this simple communication with just 2 sub-system can take: 2s + 1.5s a total of 3.5 seconds and that’s without any business logic written on our UI part. So it’s clearly not fine and this should be the first call/sign to everybody, that you can’t migrate a product from a sync. communication environment to microservices and still want to have sync. communication and more speed, THAT’s impossible and breaks the basic rules of what microservices should be.
NOTE: Normally you shouldn’t have sync communication but normality is too costly and migrations should be as cheap as possible for the management so let’s move on.
- Logic: your endpoints should be done in a logical manner like REST Infrastructure where it dictates in simple terms “SMART ENDPOINTS”.
Point 2: Is your management aware of the costs ?
If you think you know the cost of microservices then multiple it by 2 or 3. It may sound crazy but the cost of migrating an application that is already leaving and written in a monolith style is giant. Or even if you start creating new microservices with a new business but you lack the basic infrastructure to do so then I wish you good luck and may you finish the project with your mind still not lost.
First sub-point is management should understand the basics of microservices, not at technical level but at the level where a common ground can be found to explain the smallest and simplest elements of this infrastructure. Some elements that are a must for a management to know for this infrastructure, are:
- API
- REST
- ENDPOINT
- MONOLITH
- SERVICES
- CONTAINER
- AUTHORIZATION
- AUTHENTICATION
- TRANSACTIONALITY
Second sub-point is management should know that to go to a microservice approach you should need a team structure that represent(s) correctly what you are trying to accomplish. For anyone that is new to infrastructure there is a law called “Conway’s Law” and states:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”
So that means that if your team is designed similar to this:
then that means that you are the type of organization that in general when you want to interact with DB people you raise tickets (Jira if you have Atlassian products) or mails to a group dedicated to DBA management thus making your software to look like in the above, a giant cake of layers.
In microservices this kind of structure is not going to get you far if you insist with this. But in ex-change it offers you the following clean solution:
Example in this image we see 3 team’s with a set of products or a product and this teams contains people focused on:
- QA
- UI
- DBA
- OPS
- DEV
- and more if the case needs to have..
This kind of organization actually boosts the people moral moreover, by giving the sense that they can climb some kind of hierarchy or job thus giving them something to be interested in giving a goal giving them something to focus them inside your company. At the end of the day isn’t it good for you as company to keep the people ?
Third sub-point is management should encourage the creation as many POC’s (Proof of concept) as possible so that nothing is lost in communication and everything that is proposed, is represented as small demo/POC to display what the goal must be in the end or at least a part of it.
Not doing POC’s will not give you a gasp on what really will result after the developing is finished, also a POC should show you if the system that we will have in the end is exactly like you thought about:
A POC or the DEMO should:
- Show the FrontEnd that must be achieved
- Should demonstrate via a large number if diagrams of all kind how the BackEnd is divided with reasoning + how the communication is done.
- Present the con’s and pro’s
- etc.
In short words Companies/Entities should invest money to get money, this in IT is called simply ARCHITECT DOCUMENT and will present everything that Management, QA team, Dev team, etc. will read understand and agree if it’s suitable for all.
Most people refuse to understand that if you start a project you must NOT fail it, but don’t gasp that as humans we make mistakes and making decisions without doing research will just make you lose money, time, and make your workers day a living hell. if after 3 month’s of generating the documents, schemes, diagrams , a POC you release that this can’t be maintain on this budget for this client, then it’s natural in my opinion to stop it and you learned something from this (YOU ALWAYS LEARN SOMETHING FROM FAILING).
Point 3: Is your team aware of the costs ?
sually (in my case) but also talking with other friends in other companies a migration is not done by the team that does the daily maintenance of the project but done by another team that was the role of coming doing the product in version 2.0 and then leave (what I like to call ninja’s).
At end when they leave the new product is given to the team that is doing the daily maintenance and continues to work on it like nothing happened.
Personal note: this kind of thing is brining value to the final actors and product, the actual team should be aware of what’s happening on the infrastructure and how to product will look because they know it better, to hire people with the purpose of rewriting but to know understand the business of the application is just stupid and the problem is on both side:
management: Not understanding that the start of this kind of project is not something that can be done overnight and key things should be first done, before accepting the migration and starting it:
- Manual that describes the product
- Sequence diagrams of simple teste cases and edge test cases.
- Understanding the number of interactions of the current system with other systems
- Understanding the business from a high level
- Understanding the platform from were you are leaving and the consequences of not being their
external team: Not all persons that have this position of going from project to project have the passion to understand the business and generate a beautiful product with a wonderful codebase and excellent guidelines as much as we wish (not most, because in my cases I had an excellent collaboration with me external team) but in general people are focused on bringing as much business as possible and don’t care about the quality of the software as result.
Going back to the cost for the team that is doing the management, let’s see what the team should know:
- What is the desired result of the migration ?
- Does the new version of the product handles all scenarios ?
- What is the new tech. stack that the team must know ?
- What is the new infrastructure that the team must understand ?
- What are the protocols for: production error, handling manual interventions, time to market.
- How difficult is the debugging of the application ?
- How difficult is to introduce new features ?
Point 4: Do you have someone in team that handled microservices in the past ?
In my opinion it’s critical for someone in the team to have handled in their past microservices infrastructure, especially when you aren’t starting a system from zero but your migrating from one big important monolith to microservices infrastructure.
Having someone in the team that handled in past this relative “new” infrastructure will save you :
- Time in experiments
- Bringing more cons or pros in decision making
- Show what streets work on long/short run
Point 5: Is your infrastructure stable ?
If you are the kind of project that goes on an infrastructure that was already tested by another product then please ignore/skip this section.
But if you are the kind of project that is the first project that goes in this microservices world in your organization that means that you will also be the first one to test the infrastructure and before starting you should understand the following things as developer and then as a product manager:
- You will be the tester of the infrastructure
As developer and product manager of course it’s going to be hard to understand this but this kind of infrastructure is very shaky when it’s so young in the company, things will shake and they shake hard until everybody learn’s to manage it.
In my personal view until the team responsible for servers were able to learn all, I had some rough times deploying, different stuff was failing ingress was failing, pods weren’t created, deployment weren’t updated and so on.
- You must understand the infrastructure needs to be monitored
Tools that never existed in your organization may be without question inserted to help in debugging problems and monitoring distributed systems.
Thank you all for the time I can imagine this article may not be what you needed but I hope that it presented to you some points that you should take in consideration when trying to move from monolith’s to microservice’s just for the fun of having this buzzword in your company.
Please leave a comment and like if you appreciate it, if not please offer constructive criticisms in comments.
Originally posted on: https://medium.com/@stefan.paladuta17/microservices-why-should-you-think-twice-before-migrating-from-a-giant-legacy-application-to-d020075dd8b
Top comments (0)