Are Microservices the Silver Bullet for Traditional Enterprise E-Commerce Solutions?

In recent years, microservices has become one of the most popular technical terms, especially under the influence of e-commerce giants such as Amazon and Ali. Many traditional enterprises have also moved closer to the microservice architecture in the process of implementing e-commerce. Compared with the monolithic architecture, Microservices do have many advantages, as Sam Newman states in "Building Microservices" [1]:

• technological heterogeneity

• elasticity

• Scalability

• easy to deploy

• …

But computer science is a balanced science, any technical architecture will have its limitations while bringing benefits. As a system architect or decision maker, you must have a clear understanding of this. This article will focus on the prerequisites for successful microservice implementation, the main challenges and risks faced, the decision-making elements of traditional enterprises in the process of implementing e-commerce, and the correct implementation strategies. BTW, the author himself has no prejudice against microservices. I have been in contact with microservices architecture during my work at amazon, and I am also a huge fan of Adrian Cockcroft. So you microservice controllers, don't beat the bricks.

Prerequisites for Successful Microservice Implementation

In general, prerequisites for a successful microservice implementation include:

• matching organizational structure

• Strong technical team (including development/testing/operation and maintenance)

• Clear business boundaries

The first of these is Conway's Law[2], which is one of my favorite laws, and there are no exceptions in every case that I have encountered in reality:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

Conway's Law, in simple terms, is that any software reflects the organizational structure of the team that made it, because people work in a way that reflects how they are organized. In other words, an organizational structure that adopts a microservices architecture should also be decentralized. Look at those companies that have successfully implemented microservices in reality: Amazon, Netflix, Ali that is not a decentralized organizational structure.

As for the reasons for the latter two, I will discuss them in depth in the next section.

Challenges and Risks

 longer learning curve

mainly includes:

• In addition to understanding the business logic, it also takes a lot of effort to learn the various services provided by the underlying microservice framework and comply with their contracts. The following figure is an example. In order to implement an e-commerce based on a microservice architecture, the technical team needs to master the following:

• Business logic and the interface between

• Container-based deployments and tools such as Docker, Kubernetes, etc.

• Learning of the microservice framework itself, including API gateway, service discovery and registration mechanism, circuit breaker, distributed configuration, etc.

• Even the theory/design patterns behind it, such as CAP, BASE, etc.

 More dev/test work

E.g:

• Because the common microservice architecture is that each service has its own database, it will become very complicated to implement functions such as statistical reports across tables

• For the development and testing of microservices that depend on other microservices, you have to install all the dependent microservices locally. Even if Docker containers are used, the fundamental problem has not changed. Compared with the development of single services, the development of Testing becomes cumbersome

• The code itself must also comply with various contracts of the microservice framework. For example, a code that uses the Hystrix circuit breaker mechanism is as follows:

@Service

public  class  MyService {

@Autowired

RestTemplate restTemplate;

@HystrixCommand(fallbackMethod = "errorHandler")

public String myService(String name) {

return restTemplate.getForObject("http://MYSERVICE/myservie?name="+name,String.class);

}

public String errorHandler(String name) {

return  "There is an error for service "+name;

}

}

 cost of refactoring

Due to various reasons (especially when the understanding of the business is insufficient or the business changes frequently), the microservices that have been launched are found to be inappropriate and need to be refactored. For example, the pricing service needs to be re-merged into the product service, at least according to the following Steps (please refer to the picture below):

1. First, create a table related to pricing in the product database, and create an import tool to import the data in the pricing database into the product database. It should be noted that if the product service and the pricing service use different databases, additional development costs are required to write import tool. After this step is completed, the product service does not provide any pricing function, but the data in all pricing services will be continuously (synchronously or asynchronously) imported into the product database.

2. Introduce the pricing function into the product service and expose the corresponding interface. After sufficient testing, configure an API gateway (such as Zuul or Istio) to offload the pricing function calls. During this period, all data flowing into the old pricing database will still be imported into the product database.

3. After a period of canary release, eventually all invoicing function calls go into product/invoicing service, and the old invoicing service and corresponding database are uninstalled.

Of course, this is in a very ideal situation, but the reality is much more complicated than this. For example, some parts need to be merged and some parts need to be split, different programming languages ​​are used, different database technologies are used, and other microservices depend on related microservices, etc. . In addition, in a typical microservice architecture, different microservices are maintained by different groups/departments, and related communication and collaboration are also a cost that cannot be ignored. Therefore, the price of rashly implementing microservices when the business is unstable or insufficient understanding is very huge!

 more rigorous design

Microservice architecture is more prone to problems than monolithic services, not only because of various problems (such as consistency problems) caused by the complexity of distributed computing itself, but also because of various popular microservice frameworks. Taking e-commerce business as an example, user 1 needs to put a batch of new products on the shelves. In order to improve concurrency and reduce the coupling between services, the current microservice architecture uses a message bus to notify the pricing service/warehouse service/product service for corresponding processing. Unfortunately, due to the asynchronous nature of the message, it is very likely that for a certain product, the product service is finally notified. During this period, if User 2 queries the corresponding inventory but finds that the related product does not exist (as shown in the following figure), This clearly violates causal consistency!

 Difficulty of Correction

Imagine that the implementation of the order service needs to call multiple services such as warehouse service, pricing service, payment service, etc. Any error in the middle link will lead to order processing failure. Sometimes in order to improve the concurrency of processing, an asynchronous method based on message bus is often used. It is a big challenge for developers to quickly locate the source of the error. Generally speaking, we have to start from two aspects:

• Application-level associations, all asynchronous calls must introduce message ID associations

• With the help of the distributed tracking mechanism of the microservice framework, log aggregation and other functions (such as zipkin, CloudWatch, etc.)

Even so, the difficulty and time required for error debugging are not of the same order of magnitude as that of a single service, and in most cases, problems that are easy to reproduce in a single service and quickly solved by single-step tracking locally, It's not so easy for microservices.

 Rely on automated deployment capabilities

In many articles introducing the advantages of microservice architecture, a common one is "easy to deploy". In fact, the reason for "easy to deploy" is to compare a single "microservice" with a single service, but deployment constitutes an enterprise The overall complexity of dozens or even hundreds of microservices in a business is definitely much larger than that of a single service, which is why all applications based on the microservice architecture must rely on automated deployment capabilities. Aspects requirements:

• Master automated operation and maintenance tools (such as Ansible) and related design patterns (such as server provisioning mode, server template management mode, infrastructure definition mode, etc. [3])

• Microservices themselves are a match for rapid deployment, if not they need to be refactored [4].

business thinking

From a business perspective, we must think about the following questions:

• How big is your business, will it grow into the next giant that is similar to/close to Amazon/Netflix/Google/Alibaba/Tencent?

• If so, for that long, years or decades?

• Who will do the product upgrade/operation and maintenance/expansion after the implementation of e-commerce, and whether it can provide enough technical strength to deal with various potential risks in the microservice framework

• Is the understanding of the business very deep, or is it only in the initial stage?

• Is the company organizational structure conducive to implementing a microservices architecture?

• Is there any other simpler solution

In a word, as system architects or decision makers, what we need to do is to understand the essence of various technical architectures through the appearance of "gorgeous packaging" so as to avoid excessive design to bring huge risks to enterprises. In this regard, Jeff Dean stated in his The classic saying in "challenges in building large-scale information retrieval systems" is worth learning from [5]:

Design for ~10*growth, plan to rewrite before ~100*

Evolution route

Martin Fowler clearly states in his "MonolithFirst" article[5]:

• Almost all successful microservice cases come from monolithic services with sufficiently complex businesses

• Almost all unsuccessful microservice cases are developed directly from scratch

In fact, a safe solution for implementing e-commerce as a traditional industry is to start from a single unit, and gradually evolve to micro-services as the business becomes more and more complex. Specifically:

• Good programming habits need to be adopted in the implementation of a single service, so that the entire system is modularized and the business boundary is clear. If you are not familiar with the business at the beginning, this requires continuous refactoring.

• The monolithic service itself should try to follow the basic principles of cloud deployment, such as being stateless, injecting configuration information through environment variables, etc. [4].

• Under the circumstance that the e-commerce business becomes sufficiently complex, the relevant services will be gradually split. It should be noted that this is only a logical split.

• Strengthen the construction of automated operation and maintenance capabilities.

• Eventually, with the gradual adjustment of the organizational structure of the enterprise, it transitions to a microservice architecture.

in conclusion

The emergence of microservices provides a powerful/flexible/agile framework for traditional enterprises to implement e-commerce, but at the same time it also puts forward higher/stricter requirements for both technology and business. Not paying attention to these potential risks will bring huge risks , so microservices are not a silver bullet for enterprise e-commerce solutions. Usually, we can only achieve our goals by adopting a more pragmatic and rigorous evolution route.

I started to participate in architecture design in about 2006. I thought that learning architecture is like learning programming languages. First, I understand the basic syntax, then study the details and principles, and then I can quickly grasp it with practice. But after really going deep, I found that the difficulty and complexity of architecture design are much higher.

It took me at least 8 years from the earliest contact with architecture design to the feeling that I completely grasped the essence of architecture design. I used to think that it was because I was stupid and stupid. Later, I brought the team and saw that almost every programmer faced various confusions and bottlenecks that I had encountered when trying to design the architecture.

Today, I would like to share all my past experiences in the skirt 69-75-79-75-1 , which I carefully recorded into videos for free download, hoping to help you quickly become an architect.

References

1. Building Microservices: Designing Fine-Grained Systems, Publisher: O'Reilly Media; 1 edition (February 20, 2015)

2. https://en.wikipedia.org/wiki/Conway%27s_law

3. Infrastructure as Code: Managing Servers in the Cloud, Publisher: O'Reilly Media; 1 edition (June 27, 2016)

4. https://12factor.net

5. https://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf

6. https://martinfowler.com/bliki/MonolithFirst.html