Five characteristics of dividing micro service boundary


When we talk about microservices, we learn more about how to implement them. When you master the microservice technology, you will find that the division of microservices is also a difficulty. When dividing microservices, we usually consider the division according to business functions, ensuring that services and services should be decoupled, etc. However, these methods may still have many problems when designing microservice systems. So how to divide microservices correctly, the following articles can provide a good reference.

Is your micro service too small? Or too tightly coupled? This design guide can help.

Designing microservices is often more like an art than a science. This paper puts forward five suggestions

  1. It does not share database tables with other services
  2. It has the minimum number of database tables
  3. It is designed to be stateful or stateless
  4. Its data availability requirements
  5. This is the only source of truth

Avoid arbitrary rules

When designing and creating microservices, don’t fall into the trap of using arbitrary rules. If you read enough advice, you’ll come across some of the rules below. Although attractive, these are not all the right ways to divide microservice boundaries. As follows:

1. “Microservices should have X lines of code”

Let’s make one thing clear. There is no limit to how many lines of code there are in microservices. Microservices don’t suddenly become monolithic boulders because you write a few extra lines of code. The key is to ensure that the code in the service is highly cohesive (more on this later).

2. “Turn each function into a microservice”

If a function calculates something based on three input values and returns a result, is it a microservice? Is this function a separately deployable application? It really depends on what the function is and how it serves the entire system.

Other arbitrary rules include rules that don’t take into account the overall context, such as team experience, Devops capacity, what services are doing, and data availability requirements.

Features of well-designed services

If you’ve read about microservices, there’s no doubt you’ll find suggestions for well-designed services. In short: high cohesion and loose coupling. If you are not familiar with these concepts, there are a lot of articles on these concepts. Although reasonable, these concepts are quite abstract.

I’ve talked to dozens of CTOs on this topic and learned from them how to divide the boundaries of microservices. Here are some potential features for you.

Feature 1: it does not share database tables with other services

When designing a microservice, if you have multiple services that reference the same table, this is a red warning, because it may mean that your database is the source of coupling.

“Each service should have its own tables [and] should not share database tables.” -Darby Frey, co founder of lead honey

This is actually about the relationship between services and data, which is what Oleksiy kovrin, head of elastic swiftype SRE, told me:

“One of the main basic principles we use when developing new services is that they should not cross database boundaries. Each service should rely on its own set of underlying data storage. This allows us to centralize access control, audit logging, caching logic, and so on, “he said.

Kovyrin went on to explain that if part of the database table “has no or little relationship with the rest of the dataset, it’s a strong signal that components may be isolated into a separate API or a separate service.”

Feature 2: it has a minimum number of database tables

As mentioned in Chapter 1, the ideal size of a microservice should be small enough, but not too small. The same is true for the number of database tables per service.

Steven czerwinski, head of scayll’s project, explained to me in an interview that the sweet spot of scayll is “one service + one or two database tables.”.

Feature 3: it is designed to be stateful or stateless

When designing microservices, you need to ask yourself if you need to access the database, or if it will become a stateless service that processes TB data, such as email or logs.

“We define the boundaries of services by defining their inputs and outputs. Sometimes a service is a network API, but it can also be a process of processing input files and generating records in the database (this is the case with our log processing service) “- Julien Lemoine

Be aware of this frontier, it will lead to better design services.

Feature 4: its data availability requirements are taken into account

When designing microservices, you need to keep in mind which services will depend on this new service, and what the impact on the system will be if data is not available. With this in mind, you can properly design a data backup and recovery system for this service.

When talking to Steven czerwinski, he mentioned that their key customer row space mapping data is replicated and split into different partitions in different ways because of its importance.

“And each fragment information is in its own small partition. If the partition is down, there is no backup available, but it only affects 5% of the customers, not 100% of the customers, “czerwinski explained.

Feature 5: This is a single source of truth

The last feature to keep in mind is to design a service to be the only source of truth about something in the system.

For example, when you order an item from an e-commerce website, an order ID is generated. This order ID can be used by other services to query the order service for complete information about the order. Using the pub / sub concept, the data passed between services should be the order ID, not the properties / information of the order itself. Only the order service has complete information and is the only true source of a given order.

Think about a bigger team

For large systems, organizational considerations play a role in determining service boundaries. Two things to note: the importance of independent release schedules and different launch times.

“The most successful microservice implementations we’ve seen are either based on software design principles, such as domain driven design, service-oriented architecture SOA, or architecture that reflects the way organizations are organized,” said khash sajadi, CEO of cloud66.

“So for the payment team,” sajadi continued, “they have a payment service or a credit card verification service, which they provide to the outside world. This is mainly about business units that provide more services to the outside world. “

“[Amazon CEO: Jeff Bezos] came up with the ‘two pizzas’ rule – a team can’t have more than two pizzas to eat.” – Travis Reeder, CTO

Amazon is the perfect example of a large organization with multiple teams. As mentioned in an article published by API recommenders, Jeff Bezos issued an authorization notice to all employees that every team in the company must communicate through the API. Anyone who doesn’t will be fired.

In this way, all data and functions are exposed through the interface. Bezos also managed to decouple each team, define their resources, and make them available through the API. Amazon always builds a system from the bottom up. This allows each team within the company to become partners with each other.

Me and Travis Reeder, chief technology officer of Bezos, talked about Bezos’ internal plans.

“Jeff Bezos forced all teams to establish APIs to communicate with other teams. He also proposed the ‘two pizzas’ rule. A team can’t have more than two pizzas enough for them to eat.” He said.

“I think the same applies when a small team starts to get clumsy or slow in development, management, and production, it means that the team may be too big,” Reeder told me.

How to judge whether the service is too small may not be correctly defined

In the testing and implementation phase of microservice system, the following two phenomena need to be kept in mind.

The first phenomenon to note is any over dependence between services.If two services constantly call each other, it is already a strong coupling signal, and they may be better if they merge into a service.

The second phenomenon: the cost of setting up a service outweighs the benefits of being independent.In this case, it’s better to merge into one service.

“Every application needs to aggregate its logs somewhere and need to be monitored,” Darby Frey explained. You need to set an alarm. Then you need to have a standard response operator and run it when things break down. You have to manage SSH access. In order for the application to work properly, a lot of infrastructure support must be prepared. “

reference resources

original text