There was a very popular blog a while ago, which talked about the monitoring system of a global streaming media company changed from Serverless + microservices to a single unit, and the cost was actually reduced by 90%!
At this moment, it can be fried on the Internet, especially some fans who are not used to microservices and monolithic applications can't sit still.
The well-known microservice critic DHH (author of Ruby on Rails, founder of 37signals) also jumped out and wrote an article: "Replacing microservices with monoliths...simplifies the system, which is really a victory... Microservices let you Your system is unnecessarily complex, and Serverless makes it worse."
DHH was also my idol. If you have followed his blog for a long time, you will know that DHH is not against microservice architecture. His point of view is against premature optimization or premature complexity, and he advocates keeping the architecture simple in the early stage of the project. , Wait until the application is large enough to split into microservices to gain substantial benefits before considering the microservice architecture.
In the case of the monitoring system, is the user at fault, or is DHH at fault?
I also went to study the original English text carefully, reading it word by word.
I found out that's not the case at all. It's not just a "return" to the monolithic application as the people who eat melons see, or everyone's focus is on that cost reduction of 90%.
Most people overlook two things:
(1) Architecture evolution
（2）Serverless First
1
Architecture Evolution
The earliest version of the video surveillance system did choose a distributed architecture, which mainly includes three components:
1. Media conversion service: convert the video into "frames" and store them in Amazon S3.
2. Defect Detection Service: Analyzes video "frames" in Amazon S3 for defects.
3. Notification service: When a video defect is found, a real-time notification is sent.
The advantage of this architecture is that it fully utilizes the infrastructure of Amazon cloud technology.
Amazon S3 helps transfer data between multiple services, and Amazon Step Functions helps combine and coordinate multiple services.
With the support of Serverless, each component can be independently and automatically expanded according to traffic.
This architecture is very simple, but a simple architecture is not necessarily a single architecture, it may also be a serverless architecture, because Amazon cloud technology encapsulates all the complex details, programmers can focus on business development, and can quickly implement and enter market.
This is exactly in line with what DHH said: oppose premature optimization and maintain a simple architecture in the early stages.
But when the traffic is heavy, this architecture exposes two problems:
(1) The service granularity is too finely divided. After combining them with Amazon Step Functions, there will be too many state transitions, and the charges will naturally be high.
(2) Using Amazon S3 to temporarily store video frames requires a certain fee for data access. When the number of video streams is large, the fee will increase accordingly.
Obviously, the original microservice architecture no longer meets the needs and must be evolved.
The team's choice was to put all services into one process and deploy them to an Amazon ECS. Data communication no longer uses Amazon S3, but directly uses the memory of Amazon ECS.
Since it is in a process, Amazon Step Functions is not needed, and the cost of state transition is gone.
When one Amazon ECS is not enough and needs to be expanded, multiple Amazon ECS can be deployed.
In this way, costs are reduced by 90%.
But what many people don't realize is that the operating cost is only reduced by 90%, and the development cost is not included.
The original system uses Amazon Step Functions, which is naturally unnecessary in the process of converting the microservice architecture into a single body, but what about the coordination functions undertaken by Amazon Step Functions? What about its built-in retry function and exception capture function? What should I do if there are unhandled exceptions, run timeouts, Socket timeouts, etc.?
These problems require programmers to manually recode the implementation!
In addition, the use of a monolithic architecture loses the natural horizontal expansion capability of the original Serverless, and it is impossible to expand specific microservices based on traffic. Now the smallest unit of expansion has become Amazon ECS, and the team has to estimate it by itself. Traffic, programming to forward requests between multiple Amazon ECS.
So you see, architecture design is essentially a trade-off (Trade-Off). It is impossible to have a perfect architecture that can solve problems once and for all. suitable for yourself.
The architecture of this monitoring system is an evolutionary process, starting from microservices + serverless, and finally converted to a single unit due to cost considerations, implementing expansion by itself, managing infrastructure by itself, and developing part of the code by itself.
Amazon's CTO Werner said: Building an evolvable software system is a strategy, and you must re-examine your architecture with an open mind.
2
Serverless First
Now you should understand that the case of the Prime Video monitoring system is actually a natural result of the evolution of the architecture.
Now if you want to build a new application, don't be a fanatical believer in a certain architecture. You can't say that this is good and that is not good. Everything depends on the situation. Keep it simple first, and then evolve slowly.
But what I want to suggest to everyone is: You must have a Serverless First mentality.
The reason is very simple. Using Serverless, you can abandon the burden of infrastructure maintenance, focus on business implementation, quickly build a system in a few days or weeks, push it to the market and reap benefits.
Serverless is truly paying by value. Users will only incur fees when they use the products you develop. If there is no traffic, there will be no fees at all.
When the business is successful, there is continuous and stable traffic, you are sensitive to the cost of the cloud, you are willing to maintain the infrastructure yourself, and you can accept some additional development work. At this time, you can consider making some architectural adjustments, such as shifting workloads to containers.
It's a market-oriented, business-oriented approach, and a more agile approach.
It would be a huge waste to spend too much money and effort setting up virtual machines, containers, software, etc., only to find out that the product is not what the market wants.
Serverless and EDA (event-driven architecture) are a perfect match. When you adopt them, you will be forced to think continuously, turning the entire system into a loosely coupled state, so that each component in the system is more independent and does not affect each other. This is one of the goals of good design.
Even if you want to "return" to the monolith in the future, or part of the whole system uses microservices and part uses monolith, most of the previous component codes can be reused, just like the video surveillance system, all you have to do is put these components into Into a process and a Container, and then manually code to supplement and improve the capabilities originally provided by Serverless.
If, on the other hand, the system is not loosely coupled at the beginning, and then wants to become microservices and serverless, the cost of splitting will be very high.
3
Summarize
The discussion of the case of the video surveillance system is very valuable. It has sounded the alarm for us. It is not that microservices and serverless are not good, but that we must choose the right architecture at the right time.
The architecture design of modern applications must have a Serverless First mentality, do not think too much about infrastructure, but focus on business implementation, quickly launch products and services, and then adjust according to actual needs, so as to maximize business value change.