Breaking up a Monolith to Micro Services — Part I

In this article series, I’ll start first to share our own experiences and motivations to break monolith architecture to micro services in Yemeksepeti before joining the Delivery Hero Tech Hub. The article series will continue with Kick-off and the migration phases.

Years ago, our software architecture was Modular Monolith and it was doing its job well. But we were suffering on some topics. Before deep diving into those problems, let’s have a look at what Monolithic architecture is and its benefits.

A monolithic architecture is a model of software structure that is created as one piece. A monolith has one code base with multiple modules. This architecture has been used as a model for many years and countless applications have been successfully built as monoliths.

Some advantages of monolithic architecture

• Easy and fast to develop because the available tools are ready to be integrated into apps.
• Deployment is very simple, no complex operations.
• Much simpler developer workflows, and monitoring, troubleshooting, and activities like end-to-end testing can be greatly simplified as well.
• Of course we can count many advantages more, but the monolithic architecture has one major advantage: simplicity. Due to its simple structure there is no need to perform many complicated operations and extra activities that are required for complex systems.

Like every architecture of course the monolith also has some disadvantages.

Such as

• A large code base can be harder to understand. This makes the workflow more difficult.
• The Integrated Development Environment can become overloaded, and size may also affect startup time
• It is difficult to change to a new technology, language, or framework.
• Problems with scalability, because each element has different resource requirements

For many organizations, the monolith can be an excellent choice.

Breaking monolith to micro services architecture has been the hottest topic for years. Many tech companies would like to transform their monolithic architecture to micro services. But before that decision has been made, there are essential questions to be asked.

1 — Do we really need to transform?

2 — What benefits we will gain?

3 — What other tools or improvements will we add? e.g. Orchestration

4 — What are the key topics that micro services architecture do but monolith?

5 — The most important question is that Do our organizational structure is ready or suitable to handle these changes of transformation?

We tried to answer these kinds of questions first and tried to understand our needs. And now let’s have a look at our own motivations and reasons to break our monolith.

Organizational needs:

Melvin Conway says that Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.

The more you grow a team, the harder it is to communicate effectively. In a growing technology team, decision-making becomes a huge deal. Great work can mostly become unnoticeable in larger organizations.

Our aspirations around the software world have changed. We need to be Agile as possible to catch business needs. We want to ship software much more quickly than ever before. That is driving us to make different choices about the way we organize our teams, so that we organize them in terms of the way we break our systems apart. [Sam Newman — Monolith to Microservices]

So we have considered our organization structure. After long discussions with whole team members and with product teams about which model we should use, then we decided to implement a Cross Functional team model all together.

Cross Functional teams

We have transformed our teams to Cross Functional Team model and teams were people with different expertise working together to achieve a common goal. Team consists of BE, Android, Ios, Web developers, QA and systems analysts.

What did we provide and achieve with this new organization?

• Improved coordination across functional areas especially with remote working
• Reduced cycle and lead times for production
• Improved problem-solving.

Domain based teams

With this model,

Reducing context-switching, Because;

• Multitasking is efficient and context switching can break motivation.

Increasing domain knowledge;

• A team learns the domain and the technology more deeply and easily.
• The initial learning curve for domain knowledge does not have to be repeated in every project. This saves time and expense for the organization.

Total alignment with your business goals and full control of project’s planning.

Improved visibility, this is the other important benefit of this model.

Architectural needs:

• Updates can be a big challenge: Because of a single large codebase and tight coupling, the entire application would have to deploy for even the smallest update.
• Reliability: If something goes wrong in monolithic architecture, it can stop the whole structure. But in micro services architecture, breaking one service will not cause critical problems in the overall application.
• Large code base is harder to maintain.
• Deployment duration: Since you have a single and large codebase, deployment process is able to take time to all servers you have. And if you want to rollback your deployment for some reason, again deployment takes time.
• Scalability problems — Auto scaling: Many e-commerce companies have rush hours depending on business area, for example dinner times ,football derbies times, promotion period etc. In these limited time zones throughputs are able to increase dramatically. At that point, adding more resources can become a headache and in this process we are strongly dependent on human things. We need systems that have suitable architecture for auto scaling without needing any humans.
• Learning curve and Development: Imagine you have a new friend that is joining the team. It’s gonna take time to understand the whole domain. And it’s gonna affect your adaptation to us or to the company. So the learning curve is very important especially for those joining new or even current employers.
• Load test: Difficult to make a load test to monolith architecture.
• I think one of the most major reasons is Lack of Ownership. We strongly believe that ownership feeling increases efficiency. That is why the best structure is the one which gives the team full ownership. Usually, the ownership means the independent deployability of the services the teams are working on.

Summary

These topics were our own reason to break our monolith architecture to micro services architecture. Before decision has made for transformation, find your own reasons to start. Having a monolith architecture is not a always wrong solution. Sometimes that could be a good fit for your company or project.

Hope you liked this article and thanks for reading.

Resources that I read:

Sam Newman — Monolith to Microservices

Sam Newman — Building Microservices, 2nd Edition