Yes and No. Yes when we are facing problems that it solves, and No when we blindly follow that “trend.”

Once my boss read somewhere about how amazing Microservices are, he instantly asked the development team to, “Let’s do Microservices.” He’s purely a businessman but always wants to apply the newest technology. How lucky am I, but it’s also a challenge when switching a system design to another. Actually, it sounds cool to us, so there was a quick agreement between the boss and developers. So let’s do Microservices.

1. What is Microservices ?

Microservices, as clearly stated, is a system design approach; I personally don’t consider it a technology. A microservices system itself is composed of multiple technologies, with each piece solving a specific business problem or problems that may arise within the microservices architecture. The opposite approach to microservices is called monoliths—an all-in-one big service, which is what most systems nowadays are, composed of a single set of an API server and a database. Switching to microservices, in technical terms, involves dividing the functions of one big service into multiple small services that run independently, connecting them together so we can choose the most suitable technologies for each small service. Each technology here can exist as a programming language, a framework, software, a third-party service, or a tool.

The simplest form of a Microservices system can be thought of as being composed of multiple Monolith systems. Each Monolith system contains its own server and database and exposes its own API gateway. Monolith systems communicate with each other by either calling the APIs of others directly or listening to shared event channels, depending on the use case.

Microservices are NOT a new skill set. Microservices are composed of multiple monolithic services, so to work with microservices, developers must be good at building monoliths first.

2. Misconceptions About Microservices

2.1. Better Design

There is a reason that every boss wants to move to microservices: they think it is good. However, I believe not everyone understands WHAT it is good for. Microservices are NOT a purely better design than other designs. They are an adaptation to overcome problems that emerge when a system grows too big and complex, both in terms of traffic and logical complexity. So, if your system is not meant to be the next Amazon or Netflix, a monolithic design is fine for you, as it is much simpler to set up and maintain. A few thousand users with a few hundred connections per second are within the capabilities of most technologies nowadays, such as Spring, Node, Ruby on Rails, or PHP, etc. However, it is hard to estimate the threshold because each system has different features, and the best way to find out its maximum capability is to conduct stress tests—essentially sending as many requests as possible and then analyzing the response time. When you know your system’s capabilities, you will have a numerical reference to decide when to move to microservices. Microservices are a journey, so only carry on when you are well prepared.

2.2. Better Performance

Microservices do NOT magically increase the system load threshold, unless the services are divided and designed appropriately. Remember that I/O processes constitute the main part of the delay between request and response. In a monolithic design, all services reside in the same memory, making it the fastest way for services to cooperate with one another. However, if we blindly deploy services to multiple different locations just to resemble microservices, there will be increased I/O time since services have to send more requests to others they depend on, which will significantly degrade the system’s performance. This may be the most common mistake when creating a microservices system. Microservices are NOT simply about distributing all services across multiple servers. We must analyze the system to identify bottlenecks before deciding to move related services to independent servers. Furthermore, it is NOT merely deploying the current service’s source code to another server. The new server may offer beneficial points, such as greater processing power that enhances the service, or it may involve redesigning the service with other technologies that provide essential benefits.

A good example of redesigning the service is to separate the READ and WRITE data into two services for the same domain object (same table). The purpose is to support a large number of concurrent reading and writing of data with low latency. Assume that we have a monolithic system, but after a period of growth, we have a very large amount of data and a complex data schema in a SQL database, so that every time a query is issued, it freezes the whole system for a few seconds. This is bad, and we want to improve. At that moment, we may come to this solution: we will divide the service into READ and WRITE aspects. The READ data service may use a NoSQL database as persistent storage, with fast reading speed to reduce user waiting time. The WRITE data service may use an in-memory database, such as H2, to process data updates as quickly as possible before gradually synchronizing in-memory data with the persistent storage of the READ service. These two services should run on different machines to maximize resource usage. This is a true story of microservices. If we simply deploy another identical service on a different server to handle more traffic by routing based on IP or zone, this is referred to as load balancing.

2.3. Lower Cost

Microservices do NOT reduce development costs. In fact, they increase them. Firstly, we need more machines to run independent services, as well as more machines to run monitoring tools. Microservices are an architectural design approach; they provide a view of the whole system, NOT of how each service is coded. They do NOT magically reduce bugs. You may read here for a better understanding of the sources of bugs. However, when services are well divided, it enhances the boundaries between them, helping developers avoid using incorrect components and minimize the creation of cross-cutting concern components with hidden logic. Microservices create a real need for DevOps positions, who will take responsibility for deploying multiple services as quickly as possible to ensure the lowest downtime between deployments. They obviously must create a CI/CD system to automate the deployment process, calculate system load, and install monitoring tools to keep track of how the services are performing relative to one another. When a bug occurs inside a microservices system, it is more complicated to fix than in monoliths, as there are now multiple places to identify the true source of a bug. Developers must also set up an identical system on their local machines for development and testing. A system with multiple services requires a more powerful machine for developers. A system with too many services may be impossible to deploy on a single machine, necessitating the use of mocking techniques to create fake API gateways that act on behalf of the services. Writing automated tests becomes more challenging too, among many other behind-the-scenes tasks that can disrupt developers when transitioning to microservices. More work, more jobs, more salary.

2.4. Newest Technologies

Microservices is NOT about freely applying the latest technology. I bet that your team won’t want to work in a tech soup. While Microservices open up the ability to mix multiple technologies to leverage their advantages, it is essential to understand those benefits before implementation; otherwise, your system may become more complex without any significant gain, leading to frustration. Microservices is NOT only about technology; it’s also about people. It may depend on how your team is organized, their skills, and what they excel at. Learning new technologies does take time, and if you’re in a rush, it’s better to stick with tools you are familiar with. For example, if we are about to create a small service to handle employees’ documents in one month with only one thousand employees, our developers are experts in Java. Even if Go is the trending language, the point is that our developers will build that new service faster in Java than in Go, and having one thousand users does not necessitate switching from Java to Go.

2.5. Boundaries

Microservices is NOT about creating boundaries between teams; rather, it is about establishing boundaries between the services that your teams are developing—technical boundaries only. The more developers know about other services, the greater the chances they will identify problems early and the lower the communication costs between teams. Don’t use architectural design as a political tool within an organization. A developer can work on multiple services depending on his or her abilities. Those individuals often serve as important bridges between services. While some managers may want to divide teams to manage them more easily, I believe this is not an effective way to structure an organization: people will come to work with doubts and envy because, to some extent, all services are necessary at certain times, but at any given moment, some are more important than others. Non-boundary teams also facilitate cross-checking, which can help teams move forward, but it may also reduce job security. A lack of sharing and checking among employees can gradually lead some to believe they are irreplaceable, which fosters toxic thinking within an organization.

3. When to Go Microservices?

3.1. Exceeding the Limitations

Microservices do not help to reduce costs, do not help to improve performance, and do not help to be “better.” So why are they trending? Because they come from big tech companies, and people tend to believe that what comes from the big players is always “better.” We easily blindly copy without diving deep to understand why they do that. With big tech companies, they hit the limitations of technologies, and a single monolithic system can’t help them anymore, so they have to use multiple monoliths to solve problems. The result is a system they named microservices. Technology changes every day, and who knows what will come in the next few years? We see many frameworks, languages, and platforms come as “better” options, then die. So the key point to decide to move to microservices is to know the limitations of the current system by testing the load thoroughly.

3.2. Parallel Development

Another reason we might need microservices is to implement many projects at the same time. For example, if we need to build a Pricing Engine module and an ERP module to manage employees simultaneously, we might assign them to two teams since the business logic of the modules does not depend on one another. Each team can develop their own service on a separate server, so the deployments of each service are independent as well. If two modules are built into one monolithic service, an issue occurring in one module may block the entire deployment process, creating risks in the production environment. So the key point when dividing services for teams is the dependency between services; they should be loosely coupled. This means each service can act as a separate product without knowing or needing the existence of the other services.

3.3. Reusing Services

When each service is truly independent, it can be reused too. Example your companies has multiple projects but using the same employees for all projects, so to avoid duplicating features like authentication, employee manager, or full text search service, etc, we can carving them to separated services that can be reused by different projects.

3.4. Rewriting the Legacy System

One scenario that can indicate your system resembles Microservices is when you are rewriting the legacy system with up-to-date technology. Rewriting the entire system is time-consuming, so we usually rewrite it module by module. Each rewritten module can be deployed on a separate server, and in the process of rewriting the legacy system, you are utilizing Microservices.

Build – Secure – Evolve with the-tech-lead.com

---