Microservices

Chapter 12

Microservices

12. 1 Introduction

Monolithic applications

An application constructed as a single, self-contained piece of software. 

Monolithic applications tend to be both large and complex. 

They contain code to perform many functions that can span a wide range.

Example

Software engineers have pointed out that the monolithic approach has some disadvantages when run on a cloud data center.

1. Monolithic applications cannot be replicated as quickly as cloud-native applications. 
2. First, starting a VM has higher overhead than starting a container. 
3. Second, a monolithic design means all code must be downloaded when the application starts, even if pieces are not used.

12.2 The Microservice Approach

• The microservices approach to software divides functionality into multiple, independent applications. 
• Each of the independent applications is much smaller than a monolithic program, and only handles one function. 
• To perform a task, the independent applications communicate over a network.

12.3 The Advantages of Microservice 

The advantages can be divided into two broad categories: 

• advantages for software development 
• advantages for operations and maintenance

12.3.1 Advantages For Software Development 

• Smaller scope and better modularity 
• Smaller teams 
• Less complexity 
• Choice of programming language 
• More extensive testing 

Smaller scope and better modularity

    Software engineers focus on one small piece of the problem at a time.

    Engineers are less likely to make mistakes.

Smaller teams. 

    Each microservice only requires a small development team.

    The resulting code will be more uniform and less prone to errors.

Less complexity.

    The microservices approach eliminates global variables.

    Since there is no sharing of variables among services, complexity is reduced.

Choice of programming language.

With the microservices approach, software engineers can choose the best         language for each service. 

More extensive testing.

Each service can be tested independently, allowing more extensive and thorough assessment.

12.3.2 Advantages For Operations And Maintenance 

The microservices approach also offers operational advantages: 

• Rapid deployment 
• Improved fault isolation 
• Better control of scaling 
• Compatibility with containers and orchestration systems 
• Independent upgrade of each service

Rapid deployment. 

Since each service is small,  a given microservice can be created, tested, and deployed rapidly. 

Improved fault isolation. 

When a problem occurs, a manager can identify and test the misbehaving microservice easily while allowing applications and other microservices to continue normal operations. 

Better control of scaling. 

Each microservice can be scaled independently. 

Compatibility with containers and orchestration systems. 

Because it is small and only performs one task, a microservice fits best into the container paradigm. 

Independent upgrade of each service. 

Once an improved version of a microservice has been created, the new version     can be introduced without stopping existing applications and without disturbing other microservices. 

12.4 Disadvantages Of Microservice 

• Cascading errors 
• Duplication of functionality and overlap 
• Management complexity 
• Replication of data and transmission overhead 
• Increased security attack surface 
• Workforce training 

Cascading errors

    If one of the microservices fails, the failure may affect many others as well as the applications that use them.

Duplication of functionality and overlap

    When functionality is needed that differs slightly from an existing microservice, it is often easier to create a completely new one than to modify the existing microservice.

Management complexity. 

Each microservice must be monitored and managed.

It can be difficult for a manager to understand their behaviors, interdependencies,

and the interactions among them.

Replication of data and transmission overhead

The microservices approach requires each microservice to obtain a copy of the needed data.

An application that invokes many microservices may experience excessive overhead.

Increase security attack surface

The microservices approach creates multiple points that an attacker can try to exploit. 

Workforce training

    Software engineers need new skills to create software for microservices. This will include cost and the type of training to be given to each software engineer.

12.5 Microservice Granularity 

The size of microservice forms one of the key decisions a software engineer faces when following the microservices approach.

For example, a single microservice for payment processing

or a separate microservice for each type of payment processing.

How much functionality to be included in a microservice? There is no easy answer. 

However, three heuristics can help developers choose a granularity: 

• Business process modeling 
• Identification of common functionality 
• Adaptive resizing and restructuring

Business process modeling. 

One rule-of-thumb suggests that each microservice should be based on a     business process.

Identification of common functionality. 

A second rule-of-thumb follows: when designing a piece of software, consider the pieces of software that can use it, and ensure it satisfies all of them.

Adaptive resizing and restructuring.

The third rule-of-thumb takes advantage of the size: iterate to find the best size and structure for a microservice. 

It may be better to restructure existing microservices to make them useful for both existing and new applications

12.6  Communication Protocols Used For Microservice

• Like other applications in a data center, microservices communicate using Internet protocols.
• For the transport layer protocol, most microservices use the Transmission Control Protocol (TCP), with TCP being sent in Internet Protocol (IP) packets.
• Although a software engineer can design a special-purpose transfer protocol for each new microservice, using an existing protocol makes it easier to write code.
• Several transfer protocols exist and satisfy most needs. For example,

• HTTP – The HyperText Transfer Protocol used in the Web 
• gRPC – An open source† high-performance, universal RPC framework

HTTP. 

• When an entity uses HTTP to communicate with a microservice, data can flow in either direction. 
• That is, the entity can send data to the microservice or request that the microservice send data.
• Each request message specifies a data item by giving the item’s name in the form of a Uniform Resource Identifier (URI).
• The following figure lists six basic operations that HTTP supports.

 

gRPC - Google Remote Procedure Call

• It provides a general framework for communication and allows a specific set of operations to be defined for each microservice.
• RPC - The functions or procedure may reside in a remote computer and can be invoked from the local system just like a local function call.
• The function call is sent to the remote system in the form of communication messages.
• The message contains arguments for the procedure being called, and a reply message contains the value returned by the procedure. 
• The RPC system generates all the code needed to gather arguments, form a message, send the message to the remote procedure, receive a reply, and send the results back to the caller.

The following figure shows the RPC concept.

gRPC follows the traditional RPC approach of using stubs, but extends the technology in two ways.

• First, gRPC allows a choice among programming languages, including C, C++, Java, Go, Node.js, Python, and Ruby. 
• Second, gRPC does not specify a data format to be used over the network. Instead, gRPC includes a technology known as protocol buffers that allows a software engineer to build software that serializes data for transmission.

12.7 Communication Among Microservices 

The interactions among microservices can be divided into two broad types: 

Request-response (REST interface) 

Data streaming (continuous interface) 

REST expands to Representational state transfer

• A microservice that uses request-response interaction follows the same pattern of accepting a request and returning a response.as in case of HTTP access

Data streaming.

• Data streaming interaction avoids repeated requests by allowing the microservice to provide a stream of data items as a response. 
• The microservice sends a sequence of one or more data items in response to the request.

The use of a proxy allows a microservice to be scaled and isolates the communication used internally from the communication used to access the microservice. 

12.8 The Potential for Deadlock

• If each microservice in the cycle is waiting for another microservice, a deadlock can result.
• With thousands of independent microservices, circular dependencies can arise and may result in deadlock.

The following figure shows the deadlock situation among microservices.

One solution for deadlock

If any service is completely terminated and restarted, the system continues to work correctly as soon as the restart occurs.

Normally, only one microservice will restart at any time, and the system will continue to operate. However, if a massive power failure occurs, all services will restart simultaneously, and a deadlock can result.

12.9 Micro-services Technologies 

Many technologies have been created to aid software engineer in the design and operation of microservices. For example,

• Linkerd, a project of the Cloud Native Computing Foundation (CNCF), 
• Istio, a project joint among Google, IBM, and Lyft. 
• Spring Boot - framework ro create and manage microservices