Introduction to the

The respective benefits of microservices and singleton services have been made clear in previous articles. This article is not about which service architecture should be used. Instead, we assume that the project will eventually adopt a microservice architecture. There are two scenarios: one is to start the project with a single service and then convert to microservices over the course of the project, and the other is to start with a microservice architecture.

This article will discuss the reasons for adopting both approaches.

First monomer and then micro service

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

Because there is an administrative service cost associated with using microservices, this cost can slow down the team’s development. So for simpler applications, using singleton services is simpler. So proponents of this approach argue that new applications should be built as monolithic applications initially, even though it is likely that they will eventually be converted to microservices.

The first reason is that at the beginning of the system, we don’t know how many users it will have, and in the first phase of software, we usually think about the speed of software development, so people may prefer to use individual applications. If a microservice is used, if the microservice is poorly designed, then the system cannot be extended and will have to be redesigned.

The second reason is that they work well only if good, stable boundaries are proposed between services, and any functional refactoring between services is much more difficult than standalone applications. But even experienced architects working in familiar territory have a hard time determining boundaries at the outset. By building a single service first, you can figure out what the right boundary is, and then transform the microservice on top of that boundary.

One way to turn a monolithic service into a microservice is to design the monolithic service properly, such as paying attention to the modularity within the software, including API boundaries and data storage. If you can do this right, the subsequent move to microservices is a relatively simple matter.

Another approach is to start with monolithic applications and gradually strip away the microservices at the edges. This approach can leave a large singleton at the core of the microservices architecture, but most new development uses microservices, and singleton applications don’t scale anymore.

Another is to completely replace monomer applications. This allows you to completely abandon the architectural burden of monomers and start over. The price is more manpower 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 with microservices directly

Of course, there are others who hold different opinions, because they think that:

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

In other words, both individual services and microservices need detailed requirements analysis before they are built. After thorough analysis, the need to use microservices is well understood and the boundaries of each service are defined. So why not use microservices directly?

The main benefit of microservices is that they create a boundary between different services. This makes it harder to get things wrong, such as 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 certain rules and establishes clear boundaries in the overall application, but in practice this boundary will always cross domains.

You might assume that there are many microservices that can be nicely isolated hidden in your single project, waiting to be extracted. But in practice, it’s hard to make that 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 parts will depend on the characteristics of the platform they all use. They will communicate based on shared abstractions 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. Even worse, these parts will share domain objects (almost) freely, relying on the same shared persistence model, assuming database transactions are always available and therefore without compensation… This makes it very difficult to split transactions again. So it’s very difficult to separate existing units into separate 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 building something in a few weeks, you don’t need to use microservices at all.

conclusion

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

This article is available at www.flydean.com/10-microser…

The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!