Distributed software architecture - SOA architecture/microservice architecture/serviceless architecture

SOA architecture

Service-Oriented Architecture, service-oriented architecture. Service-oriented architecture is an architectural pattern that successfully solves the main problems of distributed services in a concrete and systematic way. Before understanding the SOA architecture, first understand the three representative architectural patterns of service splitting. These architectural patterns are the intermediate products of the SOA evolution process and the necessary prerequisites for the emergence of the SOA architecture.

Chimney Architecture (Information Silo Architecture)

Information chimneys are also known as information islands, and systems using this architecture are also called isolated information systems or chimney information systems. It refers to a design pattern that does not interoperate or work in harmony with other related information systems at all. Such a system does not actually have any "architecture design" at all. Following the example of an enterprise and a department in the previous section, if the two departments really do not interact at all, there is no reason to force them to work in the same building; two information systems that do not interact, Let them use independent databases and servers to achieve splitting, but the only problem, and the fatal problem, is, is there really a department in the enterprise that does not interact at all ? For the two information systems, even if there is really no business relationship, will the master data of the system, such as personnel, organization, authority, etc., be completely independent without any overlap? Such an "independent split" and "independent" system is obviously impossible for enterprises to hope to see.

Microkernel Architecture

Microkernel architecture is also known as plug-in architecture (Plug-in Architecture). Since in the chimney architecture, systems without business relationships may also need to share some public master data such as personnel, organizations, permissions, etc., it is advisable to use these master data, together with other public services that may be used by various subsystems , data, and resources are gathered together to become a core (Kernel, also known as Core System) that is commonly relied upon by all business systems. Specific business systems exist in the form of plug-in modules (Plug-in Modules), which can also provide Extended, flexible, and naturally isolated functional characteristics, that is, the microkernel architecture, are shown in the figure.

This pattern is well suited for desktop applications and is often used in web applications as well. Any computer system is realized by various kinds of software working together to realize specific functions. The software realized by different architectures listed in this section can be regarded as some kind of plug-in of the whole system. For platform applications, if we want to add new features or functions to the system in a timely manner, the microkernel architecture will be a good solution. The microkernel architecture can also be embedded into other architectural models, and provide customized development capabilities for new functions through plug-ins. If you plan to implement a software system that can support secondary development, the microkernel will also be a good choose. However, the microkernel architecture also has its limitations and prerequisites. It assumes that the plug-in modules in the system do not know each other, and it is unpredictable which modules will be installed in the system. Therefore, these plug-ins can access some public resources in the kernel, but will not interact directly. However, whether it is an enterprise information system or an Internet application, this premise does not hold true in many scenarios. We must find a way to not only split out independent systems, but also allow smooth communication between the split subsystems. call each other to communicate.

Event-Driven Architecture (Event-Driven Architecture)

In order to allow subsystems to communicate with each other, a feasible solution is to establish a set of event queue pipelines (Event Queues) between subsystems. Messages from outside the system will be sent to the pipeline in the form of events. Get the event messages that you are interested in and can handle, and you can also add or modify additional information for the event, and even publish some new events to the pipeline queue yourself. In this way, the processor of each message is independent , highly decoupled, but can interact with other handlers (if the message handler exists) through the event pipeline, as shown in the figure.

Exploration of SOA Architecture Era

The concept of SOA was first proposed by Gartner in 1994. At that time, SOA did not have the conditions for development. The situation did not change until 2006. IBM, Oracle, SAP and other companies jointly established the OSOA Alliance (Open Service Oriented Architecture). , used to jointly formulate and promote SOA-related industry standards. In 2007, under the initiative and support of the Organization for the Advancement of Structured Information Standards (OASIS), OSOA transformed from a loose alliance of software vendors into an international organization that sets industry standards. Together with the newly established Open CSA organization (Open Composite Services Architecture), this is the official management organization of SOA.

Software architecture has come to the SOA era, and many concepts and ideas can already be found in today's microservices, such as loose coupling between services, registration, discovery, governance, isolation, orchestration, and so on. Most of these familiar noun concepts in today's microservices are also foreseeable difficulties when distributed services were first proposed. SOA has carried out a more systematic and specific exploration on these issues, and even on the matter of "software development" itself.

1. More specific
   "More specific" is reflected in that although SOA itself is still an abstract concept rather than a specific technology, it is more operable than the single architecture and the three architectural models listed above. It cannot be simply regarded as an architectural style, but can be called a basic platform for software design. It has Open CSA, an organization that leads the development of technical standards; there are clear guiding principles for software design, such as service encapsulation, autonomy, loose coupling, reusability, composability, statelessness, etc.; Protocol, relying on the SOAP protocol family (WSDL, UDDI and a large number of WS-* protocols) to complete the publishing, discovery and management of services; using a message pipeline called Enterprise Service Bus (Enterprise Service Bus, ESB) to implement each The communication and interaction between subsystems enables services to communicate with each other without interdependence under ESB scheduling, which not only brings the benefits of loosely coupled services, but also facilitates the further implementation of business process management (BPM) in the future. Provides the foundation; use Service Data Object (Service Data Object, SDO) to access and represent data, use Service Component Architecture (Service Component Architecture, SCA) to define the form of service encapsulation and the container in which the service runs, and so on. With the support of this whole set of technical components that can cooperate closely with each other, if judged only from the perspective of technical feasibility, SOA can be regarded as successfully solving the main technical problems in the distributed environment.

2. More systematic
   "More systematic" refers to the grand ideal of SOA. Its ultimate goal is to summarize a set of top-down software development methodology, hoping that enterprises can solve the problem of software in a package only by following the idea of ​​SOA. All problems in the development process, such as how to mine requirements, how to decompose requirements into business capabilities, how to arrange existing services, how to develop, test and deploy new functions, and so on. Technical issues are indeed key and difficult, but they are only one of them. SOA not only focuses on technology, but also on requirements, management, processes and organizations involved in the R&D process. If this goal can really be achieved, software development may enter the stage of industrialized mass production. Just imagine that one day writing software that meets customer needs will be as traceable and law-based as writing stereotyped essays. It may be boring for software developers, but the efficiency of implementing informatization in the whole society will definitely be greatly improved.

SOA was once popular in the first ten years of the 21st century, and many industry giants such as IBM shouted for it, attracting many software developers, especially enterprise-level software developers to follow, but finally died down. It fell silent. In the later section of remote service invocation, the author will mention the essential reason why the SOAP protocol is gradually marginalized: too strict specification definition brings excessive complexity. And many superstructures such as ESB, BPM, SCA, and SDO built on the basis of SOAP further aggravate this complexity. After all, the development of information systems is not stereotyped articles. Overly sophisticated processes and theories also require professionals who understand complex concepts to be able to control them. From the day SOA was born, it was doomed to be an exquisite luxury of a few systems. It can realize the complex integration and interaction between multiple heterogeneous large systems, but it is difficult to be used as a widely applicable system. Promoting a revolutionary software architectural style. The fatal flaw of SOA's failure in the end is exactly the same as that of EJB back then. Despite the support of giants such as Sun Microsystems and IBM, EJB is still defeated by the "grassroots framework" represented by Spring and Hibernate. It can be seen that once it is separated from the people , will eventually be submerged in the ocean of the masses, even information technology is no exception.

After reading this, you might as well think back to the question "how to use multiple independent distributed services to jointly build a larger system", and then recall the design gist of the distributed service proposed by Unix DCE in the section "Original Distributed Era" : "Let developers not care whether the service is remote or local, and can transparently call services or access resources." After thirty years of technological progress, information systems have experienced architectural patterns such as boulders, chimneys, plug-ins, events, SOA, etc., but applications are increasingly hindered by architectural complexity, and the word "transparency" is farther and farther away. It's getting farther and farther away. Does this count as unconsciously forgetting the original intention of the year? The era of microservices we are talking about next seems to be opened with such introspective questions.

microservice architecture

In fact, the term "microservice" was proposed and used by Dr. Peter Rodgers at the 2005 Cloud Computing Expo (Web Services Edge 2005). The term at the time was "Micro-Web-Service", referring to a single-responsibility-focused, language-independent, fine-grained Web service (Granular Web Services). The term "microservice" is not a concept created by Peter Rodgers directly out of thin air. The earliest microservices can be said to be a product that was born while SOA was developing, just like the Spring and Hibernate frameworks were born during the promotion of EJB. Microservices at this stage are proposed as a lightweight remedy for SOA. As of today, on the English version of Wikipedia, people still define microservices as a variant of SOA. Therefore, it is completely understandable that microservices are involved in concepts such as SOA and Web Service during their birth and initial development stage.

What is microservicesMicroservices is a software development technique — a variant of the service-oriented architecture （SOA） structural style.—— Wikipedia, Microservices

But when we look at it now, Wikipedia's definition of microservices is actually a bit outdated. After the concept of microservices was proposed, it has not received much attention in the past 10 years. If it is just a tinkering of the existing SOA architecture, it is indeed difficult to arouse more enthusiasm among technical personnel. However, in the past 10 years, microservices themselves have also been thinking and changing.
In 2012, at the "33rd Degree Conference" held in Krakow, Poland, James Lewis, Chief Consultant of Thoughtworks, gave a keynote speech entitled "Microservices - Java, the Unix Way", which mentioned single service responsibility, Conway Law, automatic expansion, domain-driven design and other principles, but did not mention SOA at all, but advocated that the design philosophy of Unix (As Well Behaved Unix Services) should be regained, which seems to be the same as the author said in the previous section. Self-examination" echoes from afar. Microservices can't wait to break away from the vassal of SOA and become an independent architectural style. Perhaps, it will also be a revolutionist of SOA.

The real rise of microservices was in 2014. I believe that most readers who read this article also learned about microservices for the first time from the article "Microservices: a definition of this new architectural term" co-written by Martin Fowler and James Lewis, and It does not mean that you must have read this article, or to be precise, the "microservice" you know today is the "microservice" proposed in this article. In this paper, the concept of modern microservices is defined: "Microservices is an architectural style for building a single application through the composition of many small services, which are built around business capabilities rather than specific technical standards. Individual services can use Different programming languages ​​and different data storage technologies run in different processes. The service adopts a lightweight communication mechanism and an automated deployment mechanism to achieve communication and operation and maintenance." In addition, the article lists nine core business and technical characteristics of microservices, which the author lists and interprets as follows:

1. Organized around Business Capabilities (Organized around Business Capabilities)
   here once again emphasizes the importance of Conway's Law. A team with any structure, size, and capabilities will produce products with corresponding structures, scales, and capabilities . This conclusion is not a coincidence encountered by a certain team or a certain company, but an inevitable result of evolution. If the functions that should belong to the same product are divided into different teams, a large amount of cross-team communication and collaboration will inevitably occur. Crossing team boundaries will have higher costs in terms of management, communication, and work arrangements. An efficient team It will naturally be improved. When the team and the product are adjusted and stabilized, the team and the product will have a consistent structure.
2. Decentralized governance (Decentralized Governance)
   This is to express the meaning of "whose children will be in charge". The development team corresponding to the service is directly responsible for the quality of service operation, and should also have the power to control all aspects of the service without external interference , such as choosing technologies that are heterogeneous with other services to implement your own services. There is some leeway for this point in practice. Most companies will not use Java for one service, Python for another, and Golang for the next. They usually unify the mainstream languages ​​and even have a unified technology stack. or proprietary technology platforms. Microservices neither advocates nor opposes this kind of "unification". As long as the team responsible for providing and maintaining the basic technology stack has the consciousness of being relied on by all parties, and must be mentally prepared to "often be woken up by the alarm clock at 3 o'clock in the morning", good. Microservices emphasize more that when technical heterogeneity is really necessary, they should have the right to choose "non-uniformity" . For example, Node.js should not be forced to develop report pages, and Python should be able to choose when doing artificial intelligence calculations, etc. wait.
3. The reason why Componentization via Services
   emphasizes building components through "Service" instead of "Library" is that the class library is statically linked into the program at compile time. Functions are provided through local calls, while services are out-of-process components that provide functions through remote calls. In the previous article, we have analyzed that although remote services have higher invocation costs, this is a necessary price for bringing isolation and autonomy to components.
4. Product thinking (Products not Projects)
   avoids software development as a process of continuous improvement and improvement. For example, operation and maintenance should not be regarded as the work of the operation and maintenance team, but development should be regarded as the work of the development team. The team should be responsible for the entire life cycle of the software product. Developers should not only know how software is developed, but also know how it is developed. How it works, how users give feedback, and how the after-sales support work is carried out. The users served here may not necessarily be end users, but may also be another service that consumes this service. In the past, under the monolithic structure, the scale of the program determined that it was impossible for all personnel to pay attention to the complete product. Members in the organization who had a detailed division of labor such as development, operation and maintenance, and support only focused on their own work, but under microservices , it is advisable to hope that everyone in the team has product thinking.
5. Decentralized Data Management (Decentralized Data Management)
   microservices clearly advocate that data should be managed, updated, maintained, and stored in a decentralized manner. In a single service, each functional module of a system usually uses the same database. It is true that centralized storage is inherently It is easier to avoid consistency problems, but the abstract form of the same data entity is often different from the perspective of different services. For example, the book in the Bookstore application focuses on the price in the sales field, the inventory quantity in the warehousing field, and the introduction information of books in the commodity display field. If it is used as a centralized storage, all these fields All must be modified and mapped to the same entity, which makes different services may affect each other and lose independence. Although it is very difficult to deal with the consistency problem in a distributed environment, traditional transaction processing cannot be used to guarantee it in many cases, but the lesser of two evils, there are some necessary costs that are worth paying.
6. Smart Endpoints and Dumb Pipes (Smart Endpoints and Dumb Pipes)
   Weak Pipes (Dumb Pipes) are almost directly opposed to the complex communication mechanisms of SOAP and ESB by name. ESB can handle message encoding processing, business rule conversion, etc.; BPM can centrally orchestrate enterprise business services; SOAP has dozens of WS-* protocol families that handle a series of tasks such as transactions, consistency, authentication and authorization, and these functions built on communication channels may have some services in a certain system It is needed, but it is an imposed burden for more services. If a service needs one of the above functions or capabilities, it should be resolved on the service's own Endpoint, rather than all-in-one processing on the communication channel. Microservices advocate a simple and direct communication method similar to classic Unix filters, and RESTful communication is a more suitable choice for microservices.
7. Fault-tolerant design (Design for Failure)
   no longer illusoryly pursues the eternal stability of services, but accepts the reality that services will always go wrong. It is required that in the design of microservices, there should be an automatic mechanism for rapid fault detection of the services it depends on. Isolate when the error persists, and reconnect when the service is restored. Therefore, facilities such as "circuit breakers" are not optional peripheral components for microservices in the actual production environment, but a necessary support point. If there is no fault-tolerant design, the system will easily be damaged due to one or two The avalanche effect brought about by the collapse of a service is overwhelmed. Reliable systems can be composed entirely of error-prone services. This is the greatest value of microservices, and it is also the meaning of the title of this open source document "The Fenix ​​Project".
8. Evolutionary Design (Evolutionary Design)
   Fault-tolerant design admits that services will fail, and evolutionary design admits that services will be obsolete. A well-designed service should be able to be scrapped, rather than expected to be developed for a long time. If there is an irreplaceable and irreplaceable service in a system, it does not mean how important the service is, but a system The performance of fragility in design, the independence and autonomy brought by microservices, is also a manifestation of opposition to this fragility.
9. Infrastructure Automation (Infrastructure Automation)
   Infrastructure automation, such as the rapid development of CI/CD, has significantly reduced the complexity of construction, release, and operation and maintenance work. Since the number of services to be operated and maintained has an order of magnitude increase compared with the monolithic architecture, teams using microservices are more dependent on the automation of infrastructure, and it is impossible for humans to operate and maintain hundreds of thousands or even thousands of services.

The description of the characteristics of microservices in the article "Microservices" is quite specific. In addition to defining what microservices are in this article, it also specifically declares what microservices are not - microservices are not variants or derivatives of SOA, and should be clearly defined. Draw a clear line with SOA, and no longer label any SOA. In this way, the concept of microservices can be regarded as a truly plump, independent, and specific architectural style, laying a theoretical foundation for it to shine like a star on the technology stage in the next few years.

Microservices and SOA
This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA , perhaps service orientation done right. Either way, the fact that SOA means such differ ent things means it's valuable to have a term that more crisply defines this architectural style
Because of its consistent expression with SOA, this makes microservices supporters more urgent to refuse to be labeled as SOA, although some people insist that microservices are the essence of SOA A variant that may be true from the service-oriented side, but in any case, SOA and microservices are two different things, and as such, use a different name to concisely define this Architectural style is even more necessary.
- Martin Fowler / James Lewis, Microservices

From the above definitions and characteristics of microservices, it can also be clearly felt that microservices pursue a more free architectural style, abandoning almost all the constraints and regulations that can be discarded in SOA, and advocating "practice standards" instead of "normative standards". ". **However, if there is no unified specification and constraint, wouldn't the distributed service problems solved by SOA all of a sudden reappear? **Indeed, service registration discovery, tracking governance, load balancing, fault isolation, authentication and authorization, scaling, transmission and communication, transaction processing, etc., these problems, there will no longer be a unified solution in microservices, even if only Discuss the microservices that will be used within the scope of Java. Just one inter-service communication problem can be included in the candidate list of solutions: RMI (Sun/Oracle), Thrift (Facebook), gRPC (Google), Motan2 (Sina ), Finagle (Twitter), Arvo (Hadoop), JSON-RPC, REST, etc.; just one service discovery problem, you can choose: Eureka (Netflix), Consul (HashiCorp), Zookeeper (Apache), Etcd ( CoreOS), CoreDNS (CNCF), etc. The situation in other fields is similar to this. In short, it is a situation where the Eight Immortals cross the sea and each shows their magical powers.

The freedom brought by microservices is a double-edged sword. When software architects pick up this sword, one edge points to the complex technical standards set by SOA, and at the same moment when they regain the power of choice, the other edge It was also reflecting a cold light towards itself. In the era of microservices, the complexity of software development itself should be said to have been reduced. A simple service may not necessarily face all the problems in distributed at the same time, and there is no need to carry the heavy treasure bag of SOA. Technical baggage. Whatever problem needs to be solved, introduce any tool; whatever technology the team is familiar with, use whatever framework. In addition, a glue-style family-bucket tool set like Spring Cloud further shields the complexity from specific tools and frameworks through consistent interfaces, declarations, and configurations, reducing the cost of switching between different tools and frameworks , So, as an ordinary service developer, as a "screw" programmer, the microservice architecture is friendly. However, microservices are full of malice to architects, and the requirements for architectural capabilities have been raised to an unprecedented level. The author has repeatedly emphasized in many places in this document that the first responsibility of technical architects is to make decisions. Decision-making is required for disadvantages, and trade-offs are required for trade-offs. If the architect's own knowledge is not enough to cover the content of the required decision-making, and he is not clear about the pros and cons, he may inevitably fall into the dilemma of choice difficulties.

The era of microservices is full of freedom, and the era of microservices is full of confused choices. Software architecture will not stop at freedom, and microservices are still not the end of architecture exploration. If there is a next era, I hope that information systems can have the freedom of microservices at the same time, and build their own services around business capabilities without being restricted by technical specifications. But at the same time, it doesn't have to come at the expense of taking responsibility for solving distributed problems on your own. Who cares about his trade-offs! Children only do multiple-choice questions, but all adults do!

post-microservice era

In the microservice architecture, there will be some problems that must be solved, such as registration discovery, tracking management, load balancing, transmission communication, etc. But these problems have always existed in the original distributed era. What is the most common solution:

• If a system needs to be scaled and expanded , we usually purchase new servers and deploy several sets of replica instances to share the pressure;
• If a system needs to solve the problem of load balancing , we usually arrange a load balancer and choose an appropriate balancing algorithm to divert the traffic;
• If it is necessary to solve the problem of secure transmission , we usually arrange a TLS transmission link and configure a CA certificate to ensure that the communication will not be eavesdropped and tampered with;
• If we need to solve the problem of service discovery , we usually set up the DNS server so that service access depends on stable record names instead of volatile IP addresses;
• … …

In the era of microservices, the reason why we have to solve these distributed problems at the application service level rather than at the infrastructure level is entirely because the infrastructure composed of hardware cannot keep up with the flexibility of application services composed of software .

The solution to problems such as registration discovery, tracking governance, etc., relies on virtualization technology and containerization technology. The achievements in the era of microservices are inseparable from the great contributions of early containerization technologies represented by Docker .

container wars

The early container was simply regarded as a fast-starting service operating environment, and the purpose of using it was to facilitate the distribution and deployment of programs. Therefore, the container for a single service in the early stage did not really participate in the solution of distributed problems.

2017 can be said to be a milestone year in the history of container ecological development.

Docker Swarm, Apache Mesos, and Kubernetes are the main contenders in the "container wars." Kubernetes finally stood out from many container management systems and "coronated", which represented the end of an era in the development of containers. And I can say that the virtualized infrastructure it brings, such as inter-container networking, services, load balancing, and configuration, will also be the key to the next era of software architecture development.

For the same distributed service problem, compare the application-level solutions provided by Spring Cloud and the infrastructure-level solutions provided by Kubernetes. Although the starting points of Spring Cloud and Kubernetes are different, and the methods and effects of solving problems are also different, Kubernetes does provide a new and more promising problem-solving idea.

When the virtualized infrastructure begins to develop from a single service container to a service cluster composed of multiple containers, as well as all the communication and storage facilities required by the cluster, the boundaries between software and hardware begin to blur.

Once the hardware can keep up with the flexibility of the software, then these technical issues that have nothing to do with the business are likely to be separated from the software level and quietly resolved within the hardware infrastructure, allowing the software to focus only on the business , truly "build around business capabilities" teams and products. So the distributed architecture problem that can only be solved at the software level, so there is another solution: the application code and the infrastructure software and hardware are integrated, and they work together to deal with it.

With this, we have come to the era of "cloud native" that is often mentioned in media articles.

Kubernetes has become the winner of the container war, marking the beginning of the post-microservice era, but Kubernetes does not actually solve all distributed problems perfectly .

From the perspective of flexible and powerful functions, Kubernetes is not as good as the previous Spring Cloud solution. This is because some problems are at the edge of the application system and infrastructure, and it is difficult for us to completely solve them at the infrastructure level.

For example, microservice A calls two services published in microservice B, we call them B1 and B2, assuming that B1 behaves normally, but B2 has a continuous 500 error, after a certain threshold, we will B2 should be fused to avoid an avalanche effect.

This kind of problem is actually not difficult to deal with in microservices implemented by application code such as Spring Cloud. Anyway, code (or configuration) is used to solve the problem. As long as it is logical, any function can be used, but it will be limited The developer's imagination and technical ability. However, the infrastructure is managed as a whole for the entire container, and its strength is relatively rough. In fact, similar situations do not only occur on circuit breakers. Services such as monitoring, authentication, authorization, security, and load balancing all require detailed management. For example, load balancing during service invocation often needs to adjust the level and algorithm of load balancing based on traffic characteristics. Although DNS can achieve a certain degree of load balancing, it usually cannot meet these additional requirements.

In order to solve this type of problem, the microservice infrastructure quickly underwent a second evolution, introducing the "Sidecar Proxy" (Sidecar Proxy) that we call "Service Mesh" today .

Specifically in our current context, "sidecar" means that the microservice infrastructure will automatically inject a communication proxy server (equivalent to the sidecar) into the resource container of the service (referring to the Pod of Kubernetes) by the system , use a method similar to the man-in-the-middle attack in network security to hijack traffic, and quietly take over all external communications of the application without the application being aware of it.

In addition to implementing normal service calls (called data plane communication), this agent also accepts instructions from the controller (called control plane communication), and analyzes the content of data plane communication according to the configuration in the control plane to achieve Various additional functions such as fuse, authentication, measurement, monitoring, load balancing, etc.

In this way, it achieves the goal of not requiring additional code at the application level, but also providing fine management capabilities that are almost as good as application code.

Although it is difficult for us to conceptually determine whether a proxy service running in the same resource container as the application system should be regarded as software or infrastructure, as long as it is transparent to the application, there is no need to change any Software code can achieve service governance, and that is enough.

no service era

Finally, let's talk about the "serverless architecture" that has only emerged in the past one or two years. In the industry, in 2012, iron.io took the lead in proposing the concept of "serverless" (Serverless, which should be translated as "serverless", but now it has become a habit to use "serviceless"); since 2014, AWS released a commercial serverless application named Lambda, which was gradually recognized by developers in the following years and developed into the world's largest serverless operating platform; by 2019, China's Alibaba Cloud, Vendors such as Tencent Cloud have also released services-free products. "No service" has become one of the "new Internet celebrities" in the recent technology circle.

The background of the evolution of the serverless architecture is also evolving through multiple stages as mentioned above. Computer development has also gone through mainframes, minicomputers, PCs, virtual machines, and cloud servers (most cloud servers are also virtual machines)

In the era of cloud computing, cloud service vendors provide IaaS, PaaS, and SaaS capabilities to realize free hosting and out-of-the-box capabilities from hardware to software.

The serverless architecture is not as complicated as the microservice architecture and SOA architecture. Its biggest feature is simplicity. Only the backend facilities (Backend) and functions (Function) are involved.

BaaS (Backend as a Service, backend as a service)

Back-end facilities refer to databases, message queues, logs, storage, etc., which are used to support the operation of business logic, but have no business meaning. These back-end facilities are all running in the cloud. It is "Backend as a Service" (Backend as a Service, BaaS).

FaaS (Function as a Service, function as a service)

Functions refer to business logic codes. The concept and granularity of functions here are already very close to functions from the perspective of program coding. The difference is that functions in no-service run on the cloud without considering computing power or capacity planning (from You don’t have to consider it from a technical point of view. From a billing point of view, you still have to weigh whether your wallet is enough), and no service is called “Function as a Service” (Function as a Service, FaaS).

The vision of serverless is to allow developers to focus purely on business .

1. No need to consider technical components, no purchase, copyright and model selection troubles;
2. There is no need to consider how to deploy, the deployment process is completely hosted on the cloud, and is automatically completed by the cloud;
3. There is no need to consider the computing power, with the support of the entire data center, the computing power can be considered unlimited;
4. No need to worry about flavor, it is the responsibility of the cloud service provider to maintain the continuous and stable operation of the system;

Different from monolithic architecture and microservice architecture, some inherent characteristics of serverless architecture, such as cold start, stateless, limited running time, etc., determine that it is not a universal architectural model.

If the microservice architecture is the ultimate goal of the distributed system, then the serverless architecture may be the starting point of the "non-distributed" cloud system.

We can only see a short distance ahead, but we can see plenty there that needs to be done.
– Alan Mathison Turing, Computing Machinery and Intelligence, 1950 – Turing, Computing Machinery and Intelligence, 1950

IaaS/PaaS/SaaS

The definitions of IaaS, PaaS, and SaaS in the serverless architecture are as follows,

IaaS (Infrastructure as a Service) infrastructure as a service

Provide the computing infrastructure (servers, network technology, storage and data center space) as a service to customers. It also includes providing operating systems and virtualization technologies to manage resources. Consumers can obtain services from a well-established computer infrastructure through the Internet.

advantage:

• No need to care about the underlying hardware structure principle;
• Scale infrastructure on demand to support changing workloads;
• Flexible, innovative and on-demand services.

PaaS (Platform as a service) platform as a service

Platform-as-a-service providers host hardware and software on their own infrastructure and deliver that platform to users via an Internet connection as an integrated solution, solution stack, or service.

Primarily aimed at developers and programmers, PaaS allows users to develop, run, and manage their own applications without having to build and maintain the infrastructure typically associated with the process.

Developers simply write code, build and manage applications without the hassle of software updates or hardware maintenance. The system will provide a build and deployment environment.

advantage:

• Develop applications and deliver them faster;
• Deploy new web applications to the cloud in minutes;
• Reduce complexity with middleware as a service.

SaaS (Software as a service) software as a service

Software as a service provides a complete product that is run and managed by the service provider. What people often refer to as software-as-a-service is end-user applications. When using SaaS products, users do not need to worry about the maintenance of services and the management of the underlying infrastructure. Users only need to consider how to use the SaaS software.

advantage:

• Innovative business applications can be registered and quickly used;
• Apps and data are accessible on any connected computer;
• The data is in the cloud and will not be lost if the computer fails;
• This service can be dynamically expanded according to usage needs.

the difference between the three