Introduction to the

The respective benefits of microservices and monolithic services have been made clear in previous articles. This article is not about which service architecture to use. Instead, it assumes that the project will eventually adopt a microservice architecture. There are two scenarios. One is that the project starts with monolithic services and then transitions to microservices over the course of the project, and the other is that the project starts with a microservice architecture.

This article will discuss the reasons for adopting both approaches.

First monomer, then microservice

Microservices are a useful architecture, but even their proponents say that using microservices is only useful for more complex systems.

Because using microservices itself has an administrative service cost, this cost slows down the team’s development. So for simpler applications, it’s easier to use a single service. Proponents of this approach therefore argue that new applications should be built initially as stand-alone applications, even if they are likely to be converted to microservices at the end.

The first reason is that in the early days of the system, we don’t know how many users it will have, and in the first stage of the software, we usually think about the speed of the software development, so people may be more inclined to use monolithic applications. If a microservice is used, if the design of the microservice is poor, then the subsequent system cannot be scaled and has to be redesigned.

The second reason is that services only work well when they present good, stable boundaries between them, and any functional refactoring between services is much more difficult than individual applications. But even experienced architects working in familiar areas struggle to define boundaries at the outset. By first building a single service, you can figure out what the right boundaries are, and then transform the micro-service on top of them.

One way to transform a monolithic service into a microservice is to design the monolithic service properly, such as paying attention to modularity within the software, including API boundaries and how data is stored. If you can do this well, then moving to microservices is a relatively simple matter.

The other approach is to start with a single application and gradually peel away marginal microservices. This approach can leave a large monomer at the heart of a microservice architecture, but most new developments use microservices and monomer applications are no longer scaled.

Another is a complete substitution of monomer applications. This allows you to completely discard the architectural burden of the monomer and start over. The price is more labor and time.

So, if you can’t build a well-structured monolithic application, what makes you think you can build a well-structured set of microservices?

Start directly with microservices

Of course, there are also people who hold different opinions, because they think:

If you can really build well-structured monolithic applications, then you probably don’t need microservices in the first place.

In other words, whether it is a single service or a micro service, it needs to carry out a detailed demand analysis before construction. After thorough analysis, it is clear whether it is necessary to use a micro service at one click and the boundary of each service has been defined. So why not use a micro service directly?

The main benefit of microservices is that they create a boundary between different services. This makes it hard to get things wrong, like connecting parts that shouldn’t be connected, and coupling parts that shouldn’t be coupled.

In theory, you don’t need microservices if your program follows specific rules and establishes clear boundaries within the overall application, but in practice, the boundaries are always cross-domain.

You might assume that there are many well-separated microservices hidden in your single project, waiting to be extracted. But in practice, it’s hard to make such a distinction.

If you start with a whole, the parts become very tightly coupled to each other. That’s the definition of a single application. These components will depend on the characteristics of the platform they all use. They will communicate based on a shared abstraction because they all use the same library. They will communicate in a way that is only available if they are hosted in the same process. Worse, these parts will (almost) freely share domain objects, rely on the same shared persistence model, assuming that database transactions are always available, so there is no compensation… This makes it very difficult to split the transaction again. So it’s very difficult to break down the existing monomer into its individual parts.

So when you start, think about the subsystems you’re building and build them as independently as possible. Of course, you should only do this if you think your system is large enough to warrant this. If it’s just you and one of your colleagues who built something in a few weeks, then you don’t need to use microservices at all.

conclusion

The world of software architecture is always interesting and we learn a lot of different perspectives as we explore it.

This article has been included in http://www.flydean.com/10-microservices-monolith/

The most popular interpretation, the most profound dry goods, the most concise tutorial, many you do not know the tips to wait for you to discover!