If you are in the IT world, especially in a software team in the organization, you have probably heard of the concept of Microservices. If you haven’t, search for microservice architecture on Google, and you’ll find many articles.
People who start to learn about microservices in IT world usually have two main opinions (I am not counting those who already knew the topic and applied it in their products):
“This architecture doesn’t suit us, we can’t design our systems using this approach.”
“Let’s try this thing.”
Why do different approaches emerge? Why do some say “it is suitable,” while others who produce more or less the same types of products and say “it is not suitable”? Is it a psychological issue or are there tangible, measurable data behind it?
By the way, I am not talking about the architecture of a new product or project. If you do not have much time and money for a new product, you already should start with a monolithic one. Here, we will examine whether an existing but cumbersome product or product group can be designed using the microservices architecture, or why you should or should not do it.
So, let’s examine this topic from three perspectives that involve the questions “Does it suit enterprise companies?” “Is it not suitable?” or “Do they have to comply?”
1- Strategic Dimension
Very successful corporations produce software very quickly and put it into the market. Using a standard monolithic architecture does not meet this need. If you use the microservices architecture, you can continuously put your application into live environments. Because there are many small services instead of one large application. You may have heard that Amazon performs deployment every 0.6 seconds. They can do this only thanks to the microservices architecture.
When we consider the strategic dimension, the question should not be “Does this architecture suit us or not?” but it should be like this: “Do we have to comply with this architecture?”. As an enterprise company, you have no choice but to switch to this architecture if you aim to:
• Gain an advantage over your competitors.
• Quickly entering new markets.
• Respond quickly to changing market conditions.
• Avoid losing to market disruptors.
• Developing innovation-based products.
• Responding quickly to business requirements in terms of architecture.
• Gaining the ability to make quick decisions and implement them quickly.
As I mentioned before, Amazon performs a deployment every 0.6 seconds. Was it always like this? Of course not. The old monolithic system of Amazon’s flagship e-commerce website had become so cumbersome that they had to switch to the microservices solution. Even a simple bug fix or library update was very difficult to perform. As the complexity of the system increased, even simple issues began to create major problems. In addition to the Amazon example, two other similar examples are Uber and Netflix. Uber had to switch to microservices because its monolithic application, which worked very well in a single city, could not be applied to hundreds of cities. Similarly, Netflix had to switch to microservices architecture because its monolithic system had become so large and cumbersome that even simple updates and bug fixes were causing major problems.
2- Technical Dimension
People who are not interested in the microservices architecture idea are usually more experienced ones. For example, IT workers who have developed monolithic applications for more than 15 years generally do not warm up to the microservices idea. They especially do not prefer it in the finance sector because the eventual consistency issue scares them when money is involved. Imagine a customer making a money transfer from the mobile branch, the transaction passes through microservices in the background and completes its job. However, when the customer’s assets are displayed on the screen, the asset aggregate service cannot reflect the recent transaction in its summary database eventually, and the customer sees the asset without being reduced. Or the receipt service cannot show the receipt because it has not yet taken the transaction. These scenarios make it challenging for the microservices architecture to settle in financial systems. Very experienced IT people tend to reject microservices as a whole due to these scenarios. However, as much as possible, such business scenarios should continue being served in synchronous services, and the remaining significant percentage of other scenarios should be turned into microservices.
Technically, microservices actually fit into many systems, but it should also be known that if you switch to the microservices architecture, roses will not fall from the sky. You will face a lot of problems that are not present in the monolithic architecture and you have to solve them. If you proceed with the “Technically, this is difficult for us” perspective, you will never be able to help the strategic side of your products. For example, if you have a zero-time target, you have no chance of doing this with a monolithic architecture. Or, if you are going to make an instant campaign and increase sales five times in one day, will you invest unnecessary, maybe five times more system hardware investment for the whole year? Or will you quickly perform this campaign with microservices architecture and cloud-based consumption and then reduce resources back. Another example is working under load. It is essential for applications running under load to have asynchronous structures. If you have a monolithic application that passes through a single point, that single point will always cause problems for you (single point of failure). To overcome this, you should divide the system into microservices and increase the number of points as much as possible to prevent a general system stopping when some functionalities fail.
In conclusion, the technical dimension must support the strategic dimension to meet the needs of the strategic dimension of the job.
3- Company Compatibility Dimension
Strategically, you have decided that the microservices architecture is very suitable for your company and will revolutionize your corporate products. You do not have many question marks about the technical dimension. You have examined the situation and saw that this architecture fits you. However, your company will have to make some cultural preparations and change a bit for this.
Prerequisites for Microservices Architecture
*Believe and Patience
There must be a believing team, team leader, and sponsor for this. If there is a problem in any of these chains, the project will start, but it will fail shortly. When the large firms we mentioned above started on these projects, they did so believingly. Senior executives generally have difficulty understanding these issues or the company CTO tries hard to explain.
Being patient is as important as believing, because you will have to deal with challenging issues that you have never encountered before.
*Appropriate Conditions
Financing and time are necessary for this type of transformation. When you first start, designing a microservices architecture will take more time and cost more than you think. Don’t be afraid of this. Especially with the recent explosive growth of open source products, you have to solve some issues through these products. This way, you can save both money and time.
*Good Team, Good Architects
We said above that the team should believe and be patient, but that’s not enough. You should have one or more architects who will have an overview of the entire system. However, everything shouldn’t depend on them. Teams should self-organize their systems, but these architects should constantly review the system and steer it in the right direction.
*Culture
You cannot do this without doing code review, pair programming, and establishing a well-designed DevOps approach. Microservices architecture is not just a technical topic. A culture is needed where independent teams can develop, change, and deploy independently. You cannot have these types of things fully with classic waterfall methodologies, and you should not.
Result
Companies, even countries, are in incredible competition in the world, and large corporate companies have a chance in this competition if they can offer their products as high-performance applications. Nowadays, corporate companies are no longer doing business, actually they are in a position to produce business with software. IT organizations that perform well can distribute their software faster, more securely, and more frequently. In addition, companies with well-performing IT organizations perform better in business, profitability, productivity, and market share. In other words, if a corporate company wants to be successful in its business, it must also be successful in software development.
For this, they must choose the right architecture. Although monolithic architecture is still on the table -if speed, performance, and time-to-market are important- it doesn’t seem possible to avoid microservices architecture.
