From Service Mesh to Serverless

Part Ⅲ of Chapter Three The Container Structure in the IT Field

TL; DR

• Service mesh does not meddle in business logic or service integration/ composition.
• The serverless architecture scales quickly. Its horizontal scale happens with automation and flexibility while managed by service providers.

The Two Pizza Rule put forward by Amazon CEO Bezos has it that no meeting should be so large that two pizzas can’t feed the whole group. That is to create teams that are no larger than that can be fed by two pizzas. Microservices hit the target of low coupling and high cohesion in software development. The architecture lines up services with functional parts of the organization, making sure no passive ripples happen. Each siloed service updates, scales, and restarts independently, not affecting others. Thus, service teams come in small, unassociated bundles. Eventually, these loosely coupled, siloed, compact teams open the door to sustained update and agile collaboration.

Microservices are plagued by challenges and restrictions.

• Technical thresholds. When implementing the microservices, the dev team has always been confronted with tough calls including basic service discoveries, configuration centers, and authentication management. Also, the service government level deals with various challenges, including load balancing, fuse degradation, grayscale release, failover, distributed tracking, etc. All sets the entry up high.
• Code intrusion. Intrusive mainstream frameworks, such as Spring Cloud and Dubbo, drive up technological upgrading and replacement cost. Inactive willingness from development teams paves a strenuous path for microservices to be launched.

That is where the service mesh steps in for a change.

The Service Mesh Architecture

Sidecar is core to a service mesh. In the below chart, each microservice is accompanied by one sidecar. Sidecar frees our mind from non-business features such as service governance to business logic only. Inbound and outbound traffic, service subscription, discoveries, fuse, traffic limit, and other non-business functions are all pealed from services and integrated into sidecars.

Service mesh and API gateway are two tightly knitted concepts, with resemblances as well as specialized missions. On a certain basis, a service mesh can be perceived as a distributed, micro-level API gateway, satisfying microservice demands such as service discovery, debt balance, flow control, etc.

Pros and Cons of the Service Mesh

Pros

• Commodity features are implemented outside microservice code, and they are reusable.
• It solves most of the problems in Microservices architecture which we used to have ad-hoc solutions: Distributed tracing, logging, security, access control, etc.
• More freedom when it comes to selecting a microservice implementation language: You don’t need to worry about whether a given language supports or has libraries to build network application functions.

Cons

• Complexity: Having a service mesh drastically increases the number of runtime instances that you have in a given microservice implementation.
• Service mesh won’t solve any of the business logic-related or service integration/composition-related problems.
• Service Meshes address a subset of problems: The service mesh only addresses a subset of inter-service communication problems, but there are a lot of complex problems such as complex routing, transformation/type mapping, and integration with other services and systems, to be solved at your microservice’s business logic.

The Serverless Architecture

The philosophy of serverless prevails way ahead of the service mesh. The serverless architecture constructs and manages microservice frameworks. Compared to traditional architectures, this event-triggered mechanism is run by a third party in stateless, temporary computing containers. Underlying concepts include Functions as a Service (FaaS). Developers upload functions to FaaS platforms provided by cloud vendors. Functions are instantiated only when requested and then destroyed. The on-demand solution drastically releases server resources/occupation and cuts billings. Serverless computing is generally applied to stateless scenes with low emphasis on real-time response, such as emergency handling, statistical analysis of data, video decoding, offline batch computing, etc.

Pros and Cons of the Serverless Architecture

Pros

• Cuts operating costs as a simple outsourcing solution. Hires vendors to manage servers, databases, applications, and even logic.
• Shrinks development costs. Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) is based on the premise that server and operating system management can be commodified. Serverless Backend as a Service, on the other hand, is a result of entire application components being commodified.
• Scales quickly. Horizontal scaling is automated, flexible, and managed by service providers.
• Manages easily. This architecture runs in a rather plain manner compared to others.

Cons

• Wipes out flexibility for stateful services.
• Latency haunts highly distributed and loosely coupled serverless applications.
• Local testing is a fairly large challenge. Local simulations of application connections are run in mere chances, especially when associated with performance and scaling.

Relations of production rest upon productive forces. Notions of cloud computing blossom as the two elements are allocated and optimized. We don’t ride the horses faster. Instead, we strive to invent cars like Ford, patent dynamite like Nobel, and experiment with peas like Mendel, etc.

The Writer says...
NetX aims at building the Web3 organism. We try to figure out solutions confronted by the present IT industry. To do that, we will look into every module of it to find out setbacks. Then we’ll focus on finding solutions through experiments. It’s a dynamic evolving process. To get the best solution, we have to be clear about the problems and this will be the main idea of Chapter Three. It makes me feel excited when thinking about sharing my thoughts and I do invite you to join me in this exploration and contribute to the evolvement of NetX.

📚 Must Reads

NetX series 1.1 | NetX series 1.2 | NetX series 1.3 | NetX series 2.1 | NetX series 2.2 | NetX series 2.3 | NetX series 3.1 | NetX series 3.2

NetX, the Chain-Native Internet for the Digital Living of Trustworthy and Reliable Intelligent Autonomous Systems (Trias)

Triathon | Ethanim | Tusima | Behemotum | Octavius | Leviatom |Divina

New to trading? Try crypto trading bots or copy trading