Is the microservice architecture not fragrant or the cloud not fragrant?

/ CoolShell | 酷壳

Original link: https://coolshell.cn/articles/22422.html

One of the hotly discussed issues in the technology circle these two days is that Prime Video, Amazon’s streaming media platform, released a technical blog on March 22, 2023, “ Scale-up Prime Video’s Audio and Video Surveillance Service, Costs Reduced by 90% ”, Subtitle: ” Transition from Distributed Microservices Architecture to Monolithic Applications Helps Achieve Greater Scale, Elasticity, and Lower Costs ” Someone moved this article to reddit and hacker news during May Day, on Reddit heated discussion. This topic is in stark contrast to the microservice architecture advocated in the industry. From “microservice architecture” to “monolithic architecture”, Amazon did it. This topic is hot enough. Then DHH continued to publish ” Even Amazon Can’t Understand Servless or Microservices ” after spraying Typescript , and continued to criticize the microservice architecture, so it instantly detonated the technology circle and became a hot search in the technology circle.

Several friends forwarded three articles to me on WeChat this morning, as follows:

Just look at these titles and you will know that these articles want traffic rather than writing a good article. After reading the second article, do you really think that Prime Video is all about Amazon? Then, looking at the follow-up comments behind these articles, I think 80% of people only read the title, and they don’t even read the original text. So, I guess I’ll have to write an article…

Interpretation of the original text

To understand this problem, you must first read the original text carefully. This article by the Amazon Prime Video technical team is not difficult to read, and there are not many technical details, but the core meaning is as follows:

1) This system is a monitoring system, which is used to monitor the on-demand video streams of thousands of users . It is mainly to monitor the quality and effect of the entire video stream operation (for example: video damage or audio out of sync, etc.), this monitoring is mainly to process video frames, so they have a microservice mainly used to split the video into frames , and temporarily stored on S3, which is the Media Conversion service in the figure below.

2) In order to quickly build the system, the Prime Video team used the Serverless architecture, which is the famous AWS Lambda and AWS Step Functions . The front-end Lambda is used as a gateway for user requests, and the Step Function is used as a monitor (detector). If there is a problem, it will be posted on SNS. Step Function obtains the data of Media Conversion from S3, and then summarizes the running results to a post Lambda configured and stored on S3.

The entire architecture looks very simple, not complicated at all, and the serverless architecture is used, and there is no shadow of the server at all. To be honest, isn’t this kind of development delicious? I think it is very fragrant, convenient and fast, completely ignore those boring infrastructure, directly convert the code into a service, and then use AWS’s Lamda + Step Function + SNS + S3 to build a decent monitoring system in minutes What’s wrong? !

But they encountered a relatively big problem, which is the scaling problem of AWS Step Function. From the article, I saw two problems (note the high energy ahead):

  1. Many, many concurrent AWS Step Functions are required, so the hard limit of the account is reached.
  2. AWS Step Function charges per state transition, so it’s prohibitively expensive.

Note that there are two key points here: 1) Accounts have restrictions on Step Function , 2) Step Function is too expensive to use .

Then, the team at Prime Video set out to fix the problem, and here’s how:

1) Write all Media Conversion and Step Function in one program, and Media Conversion communicates with Step Function through memory instead of S3. Results are aggregated into one thread and then written to S3.

2) To deploy the above monolithic architecture in a distributed manner, or use the previous AWS Lambda for entry-level scheduling.

There is no limit to the horizontal expansion of EC2, and you have the final say on how many CPU/MEM machines you want to buy, and these video transcoding, monitoring and analysis functions do not feel complicated, and should be written together, so it is not more fragrant ? Of course, it is more fragrant, and it is indeed more fragrant than the previous Serverless, because of the following reasons:

  1. No longer restricted by the Step Function, the technology is in your own hands and you have more freedom.
  2. Without the expensive Step Function, the cost of the cloud has indeed become lower. If you replace Lambda with Nginx or Spring Gateway or our Easegress , you replace S3 with MinIO, and you replace SNS with Kafka, your cost can still be reduced. Lower again.

independent thinking

Okay, now that the original text has been read, do you have your own independent thinking? Here are my independent thoughts for your reference:

1) Whether AWS’s Serverless, microservices, or monomers, they are all very popular in suitable scenarios . This is just like cars. Sports cars, trucks, and off-road vehicles each have their own scenes. Whether you use a sports car to pull goods or use a truck to pick up girls is not a good decision.

2) The business in this example in this article is too simple, and it can be done with one or two services. It is a matter of transcoding and analysis. If it is to be separated, just two microservices (one for transcoding and one for analysis) can be streamlined. If you don’t want to divide it, it’s okay to put it together. This granularity is nothing wrong with microservices. There are many principles for the division of microservices, and I will only list a few of the more important ones here:

  • Bounded context . The granularity of microservices cannot be larger than the Bounded Context in the domain driver (you can Google it yourself), that is, a business domain.
  • Single responsibility, high cohesion, low coupling . Combine those that change for the same reason (cohesion), and separate those that change for different reasons (decoupling)
  • Transactions and Consistency . For two heavily dependent functions that need to complete a transaction and ensure strong consistency, it is best not to disassemble them, but to put them together.
  • Match the organizational structure . Put things from the same team together and keep things from different teams separate.

3) The problem encountered by Prime Video is not a technical problem, but a problem of insufficient processing power of AWS Step Function, and the charging is still very expensive . This is a product issue with AWS, not a support issue. Therefore, everyone should not use a product problem to come to the conclusion that there is a problem with the microservice architecture. This has no causal relationship. Just ask, if Step Funciton can be expanded infinitely, and the price of cabbage, will the Prime Video team still have the motivation to change to a single unit? Won’t they blow up Serverless in turn?

4) Prime Video and AWS are two independent accounting companies, just like Amazon’s e-commerce and AWS, they are also two companies. Amazon’s e-commerce and AWS’s understanding and operation of service or microservice architecture, I personally think that there is no other company in this world, including Google or Microsoft. If you have time, you can read the previous article on this site ” Steve Yegg’s complaints about Amazon and Google platforms ” and you will learn more.

5) The case of Prime Video is essentially “off the cloud”, off the cloud of AWS Serverless . The cost on the cloud is high, one is the cost issue, and the other is the lock-in issue. The Prime Video team should be very fortunate that this monitoring system is not complicated, and it can be rewritten quickly, so a more traditional “service-oriented” + “cloud computing” distributed architecture can be used quickly, otherwise, it has to be like DHH Gritting your teeth and leaving the cloud like that – ” Why We’re Leaving the Cloud ” (this blog post Our Cloud Spend in 2022 by their SRE explains the difficulty of leaving the cloud and how much cost it saves)

postscript

Finally let me make an ad of my own. In the past few years of entrepreneurship, I have helped many companies solve these problems of distributed, microservices, cloud native and cloud computing costs, if you have similar problems. Welcome, contact me: [email protected]

In addition, we released a platform MegaEase Cloud this year, in order to allow users to obtain lower costs (at least 50% of cloud computing costs) by building their own high-availability infrastructure without losing the cloud computing experience. Ways to reduce costs at present:

  1. Basic software: self-built through open source software,
  2. Content distribution: MinIO + Cloudflare’s free CDN,
  3. Cheap GPU computing resources that are ready to be released and directly cooperate with the underlying IDC…

Everyone is welcome to try it out.

how to access

Note: These two areas are completely independent, and the accounts are not interoperable. Because of the force majeure of the network, do not use it across regions.

Product Demo

Introductory article

(full text)

(Please indicate the author and source for reprinting articles on this site Cool Shell – CoolShell , please do not use for any commercial purposes)

The post Is the microservice architecture not fragrant or the cloud not fragrant? first appeared on Cool Shell – CoolShell .

This article is transferred from: https://coolshell.cn/articles/22422.html
This site is only for collection, and the copyright belongs to the original author.