Skip to main content
Version: 1.0.1

What is Microservices?

Microservices, or microservices architecture, is a architectural model where different business capabilities are structured independently of each other. In this architecture, large systems are divided into smaller services, each responsible for a different task and independent of each other. Behind the scenes, all these services are referred to as microservices.

In short, a microservice is a small, independently deployable service with a specific responsibility.

This approach is inspired by Service Oriented Architecture (SOA), and both come from the client-server architecture. However, the design principles of microservices architecture differ from those of service-oriented architecture. While SOA is an enterprise-level architecture, Microservices Architecture is an application-level architecture.

Microservices architecture, first discussed by Martin Fowler and James Lewis, provides various advantages such as ease of distribution, flexibility, and scalability.

One of the key features of microservices architecture is that it does not share data structures. Each microservice has its own data storage area (such as a database schema or table). This means that each service is responsible for its own data model and data. Other services cannot access storage areas they do not own.

To better understand the concept of microservices, it's important to know what monolithic architecture is and understand the differences between the two architectures.

Microservices and Monolithic Applications​

Monolithic architecture means that the software is designed as a self-contained unit, forming a "single piece" according to a standard. In this architecture, components are designed to be interdependent rather than loosely coupled.

Generally, having the entire application as one piece makes it both large and complex. If one of the tightly interconnected components fails, it affects the entire system negatively. In other words, if a monolithic system fails, it stops all services it provides.

Additionally, monolithic applications are not very flexible due to their high cost and time-consuming nature.

Microservices, on the other hand, treat each service as a different piece, unlike the single-piece monolithic architecture. Microservices architecture provides advantages such as ease of distribution, flexibility, and scalability.

microservices-vs-monolith.png

Advantages and Disadvantages of Monolithic Architecture​

In the world of applications, the monolithic approach, despite bringing significant advantages, also has critical disadvantages.

Advantages:

  • Manageability, scalability, maintenance, and monitoring are straightforward.
  • Quick and cost-effective development for small and medium-sized projects.
  • Components and functions can establish consistent relationships within their own working context.
  • Transaction management is comfortable and under control.

Disadvantages:

  • All services are provided through a single application. Therefore, if corrections or improvements are needed, the entire application needs to be recompiled, potentially causing partial interruptions in service.
  • All components are considered as a cohesive whole. If a change is made in one part due to the interaction with an unrelated part, it can block and affect other areas of the process.
  • One of the weaknesses of monolithic structure is the language and platform dependency imposed by the holistic approach. Building the entire application requires all modules to be developed in the same language and on the same platform. This restricts the use of different languages and platforms, leading to unnecessary workloads and deviations from the intended purpose of the language and platform.
  • Collaborative work on applications developed by multiple people often results in a complex code and structure.
  • Due to dependencies, a small change in one area can lead to new changes in other areas.
  • Version management becomes challenging.

Advantages and Disadvantages of Microservices Architecture​

Although microservices architecture turns many disadvantages of monolithic architecture into advantages, it has its own unique pros and cons.

Advantages:

  • Adding new features or maintaining existing structures is easy when each service is independent of others.
  • It promotes teamwork. Especially for new team members joining the project, the modular structure allows them to focus only on the service they are responsible for.
  • It allows each service to scale independently based on its needs.
  • Version management is straightforward.
  • Each service can be written in a different language and platform as needed.

Disadvantages:

  • Managing transactions becomes more challenging when multiple services and databases are involved.
  • Managing and monitoring services becomes more complex.

Best Practices for Microservices Architecture (2023)​

One of the characteristics of microservices architecture is its continuous evolution. Therefore, engineers should always be aware of upcoming changes and constantly update best practices.

1. Clearly Define Microservices

Microservices architecture is used by IT organizations ranging from startups to Fortune 50 companies. However, just because it worked for someone else doesn't mean it will work for you. Make sure you understand the value that microservices architecture can add to your technology and invest in the most logical tools accordingly.

There should be a clear distinction between business functions, services, and microservices. Without these boundaries, your microservices may become too large, making it difficult to take advantage of the benefits of microservices architecture.

Alternatively, there is a possibility of having too many microservices. This can lead to an increase in operational management costs, overshadowing the benefits.

The key is to achieve a balance by designing services that are specific to application functions.

2. Deploy and Host Microservices Separately

Deploying microservices separately is crucial if you want to minimize the resources each service consumes. By using dedicated infrastructure to host microservices, you can isolate them from errors in other services. This minimizes the possibility of a complete system outage.

Additionally, containerizing microservices allows them to work together without compromising the independence of microservices.

3. Build Microservices with Domain Driven Design (DDD)

Domain Driven Design (DDD) is a design principle that involves designing microservices around business domains using practical rules and ideas. It specifically entails designing microservices around business domains.

4. Be Aware that All Stakeholders Will Be Involved in the Process

Implementing microservices architecture requires more participation from your engineering team than before. The costs of the transformation, business impact, and organizational restructuring require support from all relevant stakeholders.

These stakeholders include not only your management team but also extend to the entire organization. Microservices architecture requires a cultural transformation and a change in how your business operates. This requires participation not only from top to bottom but also from bottom to top.

5. Make Unique Provisions for Data Storage for Each Microservice

While data can be shared and should be shared among microservices through APIs, each microservice should have its own data storage. If multiple microservices share the same data storage, it will lead to dependency, undermining the purpose of microservices.

6. Invest in Observability

Microservices architecture is much more complex than monolithic architecture. Therefore, traditional monitoring methods may not yield the expected results. As part of your microservices transformation, invest in an observability platform.

Observability platforms collect metrics, logs, and traces, bringing all your data together in one place to uncover crucial insights. Regardless of which microservice triggers an error, you can trace problems back to their root causes. This allows your development team to spend less time diagnosing an issue and more time fixing it.

When to Use Microservices Architecture​

This architecture is developed as an alternative to meet the modern needs of applications that require frequent updates to services. The primary goal of microservices architecture is to break down an application into small independent services with different and unique capabilities.

Microservices architecture offers significant benefits in applications that require frequent

scaling (the principle of scalability). If there is a frequent need for scaling, this architecture provides advantages. For example, if the number of requests to a service has increased significantly compared to other services, you can simply increase the number of instances of that service without having to scale the entire system, as in a monolithic application.

Another example is an application that runs campaigns on certain days of the week. Traffic on campaign days will be very high, and on other days, it will be very low. For these special days, you can scale the microservices accordingly. There are also PaaS products with auto-scaling features that can handle this without manual intervention.

If you have a large system with a need for a significant number of human resources to work, dividing workflows into microservices can be beneficial.

Using microservices can be suitable when the stopping or failure of one service should not affect other functions of the system. This principle is known as isolation of failure.

If some services or functions need to be continuously updated, microservices architecture allows you to make changes without having to overhaul the entire system. Because services are independent of each other, this helps speed up the deployment of business units to the market.

It can also be used to adapt to the current programming languages or technology products to rewrite old applications when needed.

When Not to Use Microservices Architecture​

To clarify when not to use it, it's essential to first ask whether there is a need to break down the application into microservices. Microservices architecture helps solve the complexity of a complex system. Therefore, if you don't have a complex or complicated system, there may be no need to use it.

If there is no frequent need for scaling, there may be no need to use it.

If the scope of the application is not very clear, there may be additional operational, development, and maintenance burdens.

Companies or development teams often tend to jump into the world of microservices just to follow trends and are ready to use it as soon as possible. Making this transition just for the sake of it can lead organizations to the situation mentioned in Conway's Law. Conway's Law briefly states that the architectural structure of applications tends to closely resemble the structure of the team that created it, rather than meeting the needs of users.

In most cases, in large enterprises, during this transition, there may be a tendency for large teams to develop many microservices instead of assigning a few microservices to small teams. These microservices may be shaped not based on user requirements but based on the team's structure. This is not a desirable situation.

From a technical perspective, systematic problems are more challenging to find in this architecture. For example, to perform error analysis, there is often a need to combine multiple log files.

References:

Original Source