MICRO GUIDE FOR MICROSERVICES - nitorinfotech.com€¦ · MICROSERVICES What is Microservices Why...

MICRO GUIDEFORMICROSERVICES

What is Microservices

Why we need Microservices

Business Challenge

The last two decades have seen immensely swift advancement and adoption of technology. The last decade particularly brought forth a unique challenge for product organizations, i.e., to SCALE.

Businesses want to expand their reach in order to grow. To stay competitive, they need to come up with new features quickly (before their competitors). At the same time, the product needs to adhere to basic requirements like availability, reliability, and better performance (low latency).

Thus, it is a two-front challenge-

Microservices is an architectural style/approach of:

• Building a single application as a small suite of services each running in its own process

• Using mechanisms like HTTP APIs or message brokers for each process to communicate with the other through

• Building processes around business capabilities

• Fully automating Independent deployable mechanism

• Having a minimum centralized management (orchestration) of services

•• Using different data storage technologies

01

02

Implementing Microservices architecture helps you to achieve just this, and Nitor’s dedicated technology specialists will act as guides throughout your modernization journey. So, let us understand what Microservices exactly is.

Plan and roll our new features continuously without worrying about technical constraints to achieve it

Technical Challenge Design a product that will help the business achieve its goal. For this a product needs to be Scalable (horizontally and vertically), loosely coupled, reliable and available, and still have better performance.

01

MICRO GUIDE FOR MICROSERVICES

02

Independent Codebase

• Each service should have its own codebase

• Each service can select the technology of implementation as per its need. (It should not be extremely heterogeneous as well else it will result in other sort of challenges like diverse skill sets required in maintaining those services in long run, benchmarking performance of each services etc.)

•• We know the convention of DRY (Do Not Repeat Yourself). And DRY promotes code reusability/sharing. However, we should avoid using reuse/share code across various services. (Else, we will get into the problem of maintaining a Distributed Monolithic application.)

Private Data / Database per ServiceConventionally, monolith applications have a centralized database. And, all the functionality revolves around a centralized Conventionally, monolith applications have a centralized database. And, all the functionality revolves around a centralized database. Centralized database often become a scaling bottleneck. Moreover, the same database is often used for various activities like CRUD operations, reporting, logging etc. Typically, the application may need various databases based on its use case. The core of microservice architecture revolves around the principal of “You Build You Maintain”. This essentially means each service should have its own database. And data exchange across different services take place either through HTTP (REST/SOAP) or Service Brokers

Loosely CoupledPrincipal of “You Build You Maintain” promotes each team to build its own Technology stack (programming language, Principal of “You Build You Maintain” promotes each team to build its own Technology stack (programming language, database, platform etc.), define its own development roadmap, and define its release cycle etc. The overall aim is, for all services to be loosely coupled to each other and have no overlap or tight integration ( an ideal situation) with each other

Independently DeployableOne of the major disasters of implementing microservices architecture is creating a “Distributed Monolith”. This is term One of the major disasters of implementing microservices architecture is creating a “Distributed Monolith”. This is term used for microservices architecture when services are so tightly integrated with each other that it makes it almost impossible to deploy any service independently. And this violates one of the core attributes of Microservices architecture i.e. to be able to deploy services independently, making it possible to roll out changes without affecting the existing clients or other services. Having a well-defined versioning pattern is required to keep the clients compatible and to provide a smooth migration to the desired version of the service

Stateless and Self-BootableA Microservice should be able to boot itself into a valid state at any time without having tight dependencies on other A Microservice should be able to boot itself into a valid state at any time without having tight dependencies on other services or to past data. Microservices should be able to scale out horizontally at all times based on processing needs. It is recommended to avoid having a locally stored state such as local file stores, local db., and caching. Instead, store any state in centrally managed data stores to ensure any state is consistently shared between load-balance and auto-scaling setup

Attributes of Microservice2.1

Cohesive FunctionalityEach service in the microservice ecosystem should be fine-grained with a well-defined service boundary. It is a practice of defining a service boundary based on domain/sub-domain of an application. Additionally, it should also be noted that services should not be over fine-grained as it may lead to an operational nightmare.


03

Tiers of a Microservice Application2.2

Microservice Architecture Implementation2.3

Client End-users of product build using Microservices architecture. Users interact using either Web or mobile applications

ServicesServices are the core of Microservices architecture. In this tier, the services that we build interact with each other to Services are the core of Microservices architecture. In this tier, the services that we build interact with each other to achieve a common business goal. Services interact with each other through a defined boundary that exposes underlying functionality to meet the needs of outside consumers. It is advised to undertake DDD (Domain Driven Design) approach to define boundaries by defining a bounded context for each service

PlatformA microservice platform provides tooling, infrastructure, and high-level primitives to support building, deploying, and managing of microservices. A mature platform layer enables engineers to focus on building features, not plumbing

SecuritySecuritySecurity is a critical feature of any application. So is it with Microservices based application

ObservabilityThis is one of the most important layers for troubleshooting issues (exceptions, latency, etc.), monitoring system health, monitoring Individual services health, etc

Product engineering is in Nitor’s DNA, so we have worked with different products across different domains using different technology stacks. Through that experience, we have figured out that all products have few common requirements:

Scalability Maintainability

Intergratability Ability to use different technology for different aspects

Loosely coupled Ability for frequent and quick releases


04

Microservices Architecture (Traditional Implementation)

Option 1

We at Nitor always suggested and implemented Microservices architecture for clients using monolith applications and having one or more of the above requirements. You can contact us to read our Product Modernization Whitepaper and understand how we implement Microservice architecture.

We would like to classify Microservices' implementation as per the following:

In this approach, you select every tool of your Microservice architecture, e.g., resiliency, API Gateway, service discovery, key management, etc. In this case, the high-level architecture can be as described in the diagram below:


05

Microservice Architecture with Service Mesh

Option 2

You can choose a service mesh approach. This service mesh will take care of service discovery, routing rules, resiliency, and service registry. In this case, the high-level architecture is shown in the diagram below:

Difference between Traditional and Service Mesh implementation:

Full ControlNo Control (We have to go with the tool used by Service Mesh framework)

Feature Option 1 (Traditional Approach) Option 2 (Service Mesh)

Tools Selection

More complex to wire all tools together Less Complex (Service Mesh is an abstraction over underlying complexity) Complexity

Greater LessSetup Time

No (You can change tools as and when needed)

Yes (You need to update/replace Service Mesh vendor)Vendor Locked

Irrespective of the option you select, it is important to understand the various components/tools and patterns that help us build a robust Microservice architecture.


06

The components/tools and patterns to build a robust Microservice Architecture are as follows:

DDD (Domain Driven Design)A design principal to segregate software as per domain/ sub-domain. Each team owns a domain or subdomain

CommunicationInterservice communication and its pattern is the heart of Microservice architecture

Deployment ModelThe method in which services can be deployed so that deployment is automated, fast, and on demand

MonitoringMonitoringSince there are various tools and technologies working together, it is important to have monitoring technologies in place, which gives stakeholders a high-level view of system health

TransactionsOne of the biggest challenges of any distributed application is transaction. In this section, we will cover widely used techniques and patterns for handling transactions in a Microservice architecture

Domain-Driven Design (DDD)The core and most critical part of the Microservice framework lies in defining boundaries of each service. Ideally, each service should:

• Represent a domain/subdomain of application

• Be owned by a team/ Scrum Team

• Include selecting technology for implementation, designing database schema, selecting datastores, deployment and release lifecycle, etc. for it to be considered as owned

• Allow two different services to operate with different technologies, different release lifecycles etc.

However, the end goal is that, all services should work together as a well-oiled machinery ultimately achieving business However, the end goal is that, all services should work together as a well-oiled machinery ultimately achieving business goals together. And so, it becomes critical to define and segregate services as per the domain/sub-domain of the software. The software development approach of segregating software into logical units as per their domain/subdomain can be termed as “DDD – Domain-Driven design.”

DDD can be encapsulated as under:

• Context:The setting in which a word or a statement appears that determines its meaning. Statements about a model can only The setting in which a word or a statement appears that determines its meaning. Statements about a model can only be understood in a context

• Model:A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain

• Ubiquitous Language:A language structured around the domain model and used by all team members to connect all the activities of the A language structured around the domain model and used by all team members to connect all the activities of the team with the software

• Bounded Context:A description of a boundary (typically a subsystem, or the work of a specific team) within which a particular model is defined and applicable

03


07

Communication Why does a service need to communicate?

As per practice, services are designed to support a specific business domain/sub-domain. At the same time, each service

is designed to fully operate in a silo. However, each business domain needs to interact/share data for achieving a

common business goal.

Technically, this requires each service to exchange data with other services. In the real world, a group of microservices Technically, this requires each service to exchange data with other services. In the real world, a group of microservices

need to operate together either sequentially or parallelly to complete certain operations. This means one service may

initiate the chain of a service call for completing one functionality. This is called inter-service communication.

So, with the network now a part of the game, with all its complexity and unreliability. We often make some assumptions

that aren’t true:

• Network is reliable

• Latency is zero

•• Bandwidth is infinite

• Network is secure

• Topology doesn’t change

• One administrator

• Transport cost is zero

• Network is homogeneous

04

Communication Model4.1

Synchronous

This means one service calls other services and waits until it gets a response. Common pattern for synchronous data

exchange is

REST

• Rest Supports both synchronous and asynchronous communication. But its point to point communication.

• It is very widely used. But comes with overhead of http + JSON

• Not recommended for very high data intensive interservice communication.

SOAP Services (Not recommended in a Microservices world because of rigid schematic protocols which is not easy to

understand and heavy as compared to REST, which results in exchanging more data over the wire)

gRPC

• High Performance, standard-based, open source, general purpose RPC framework

• Remoting projected backed by Google. And widely used by Microservice pioneers like Google and Netflix.

• Based on HTTP/2 which is a binary protocol.

• Recommend to be used with Protocol Buffers as a serialization method.


08

GraphQL

• GraphQL, a query language for API and runtime uses existing data to fulfill queries. It provides a specific type system that can help you define data, make queries, change or subscribe to data updates by using a very specific query format.

• GraphQL provides an understandable description of data and flexibility to clients to ask for what they want, which makes it easier for GraphQL APIs to evolve overtime and make efficient use of the network bandwidth.

•• GraphQL is one of the ways to for interservice communication. However, typically, we have experience it to be used for

• UI Rendering – Querying and displaying data on UI

• Providing GraphQL API to other application/ End Client/ Customers.

• It can be used for Microservices with caution and need strong use case for implement it as interservice communication for Microservices.

• gRPC and Protocol Buffers together makes a very good pair for very efficient, light weight and high-performance mechanism for inter service communication.

• As per various benchmarks published by gRPC, Message transmitted by gRPC is about 50% to 60% smaller in size as compared to REST + JSON.

Queue

• Point-to-point messaging

• Can configure support for FIFO operations

• Can support ‘AT LEAST ONCE’ or ‘AT MOST ONCE’ Delivery Model

Asynchronous

Publish-subscribe


09

E.g.

• AWS SQS

• AWS SNS

• Azure Service Bus

• Azure Storage Queues

• RabbitMQ

•• ActiveMQ

• ZeroMQ

• RocketMQ

• Publish-Subscribe messaging

• Messages are sent to topics

• Messages are received from subscriptions

• Filters can determine message subscription

Locating other services – Service Discovery4.2

Services typically need to call one another. In a monolithic application, services invoke one another through a language-level method or procedure calls. In a traditionally distributed system deployment, services run at fixed, well-known locations (hosts and ports) and so can easily call one another using HTTP/REST or some RPC mechanism. However, a modern microservice-based application typically runs in a virtualized or containerized environment where the number of instances of a service and their locations changes dynamically.

With vast experience in Microservice architecture implementation, Nitor places special emphasis on getting the communication model right at all times. Because the goal of a microservice architecture is to have loosely coupled services and communication is vital for that to be achieved.


10

Resiliency 4.3

As mentioned earlier, Microservices are designed to communicate with other services through the network. And, the network is the single most cause of failure/outages across the world. This brings us to the point that we should design our system for failure. And, in case of failure, the system should fail fast and should have the ability to recover gracefully from failure. Failure in one service, if not handled swiftly, can result in cascading failures in other services, which can result in system-wide outage. System-wide outages are both complicated and costly (time and user experience).

Few tools available for Resiliency are

• Resilience4j

•• Hystrix

API Gateway4.4

APIs are an inherent tech debt. This means once you release an API, you are virtually contracted to keep it up and running for an infinite period of time. This essentially brings an overhead for the technical team, as they will have to spend equal efforts on:

a. Creating an API

b. Maintaining it

API Gateway helps tech team in maintaining API by covering the following aspects:

• Authentication

• Security, e.g., Cognito implementation in AWS and Azure

• Versioning

• Load balancing

• Rerouting

•• Communication Patterns (Base Request/Response objects)

• Error handling

• Testing/Uptime monitoring

• Traffic Control

• Analytics

• Transformations

• Logging

• Invoke Serverless Function


11

Service Mesh4.5

The simplest definition of a service mesh –‘a dedicated infrastructure layer for handling service-to-service communication’. A service mesh builds on CNI in Kubernetes. It provides inbuilt support for resiliency (timeout/retries), service discovery, simple routing, client-side load balancing, circuit breaking, etc. hence most of the work related to network communication is offloaded to the service mesh.

Components:

Data Plane: This is a collection of lightweight proxies distributed as sidecars. The proxies include NGINX, or envoy (AWS), in Kubernetes, the proxies are run in every pod next to the application.

Control Plane: Control Plane: A control pane centrally manages service mesh proxies. It provides the configuration for the proxies, issues the TLS certificates authority, and contains the policy managers. It can collect telemetry and other metrics and perform tracing.

Features:

• Resiliency for inter-service communications: Circuit-breaking, retries and timeouts, fault injection, fault handling, load balancing, and failover

• Service Discovery: Discovery of service endpoints through a dedicated service registry

•• Routing: Primitive routing capabilities, but no routing logics related to the business functionality of the Service

• Observability: Metrics, monitoring, distributed logging, distributed tracing

• Security: Transport level security (TLS) and key management

• Access Control: Simple blacklist and whitelist-based access control

• Deployment: Native support for containers. Docker, and Kubernetes

• Interservice communication protocols: HTTP1.x, HTTP2, gRPC

• Language agnostic: Works on top of standard protocols such as HTTP1.x/2.x, gRPC, etc.

Service Mesh Implementations:

• Linkerd: An open-source service mesh

• Istio: An open-source service mesh

• Azure: Azure Service Fabric Mesh is a fully managed service mesh

• AWS: We can use App Mesh with microservices running on Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS), and Kubernetes running on Amazon EC2

Deploying microservice applications can pose a challenge, at Nitor we believe that for successful deployment a few requirements must be met:

• Ability to deploy or un-deploy independently

• Scalability • Resiliency

Deployment Model05


12

VMs and Physical machinesA traditional deployment approach. You can still continue to deploy your services on virtual and physical machines. Cloud providers like AWS and Azure have capabilities to let us automate scaling VM as per our needs. But scaling VMs takes more time as compared to containers.

Containerization This is a modern-day approach of application deployment. Deployment can be fully automated (Cloud and On-Prem) and This is a modern-day approach of application deployment. Deployment can be fully automated (Cloud and On-Prem) and is lightweight compared to VM. We can provision/de-provision containers in seconds. Widely used Container Technologies are Docker and Kubernetes (container-orchestration)

Scalable One of the problems that Microservices architecture solve is scaling. In Microservices Architecture, you can deploy each service independently. And each service can scale as per their requirement. It is advised to leverage containerization in order to scale your services swiftly.

Load BalancingLoad BalancingLoad balancers are the proven way of distributing the load across various servers in a cluster thus helping us to get better performance. Load balancer is a proven warrior, and we can use it in Microservices architecture as well.

Config ManagementCentralized configuration management is one of the major requirements in a microservice system. Although one of the Centralized configuration management is one of the major requirements in a microservice system. Although one of the major proponents of a microservice system is decentralized services, certain parts still need to be centralized to ease deployment pains. The centralized configuration is simply the main location where all microservices can pick their specific configurations to help them run perfectly. Some of the well-known implementations are-

• Apache Zookeeper • etcd • Azure Key Vault • AWS KMS

• https://www.chef.io/ • https://www.vaultproject.io/

Monitoring

Monitoring is a critical part of managing any IT system. And the challenge is unique in case of Microservices because compared to the monolithic application, which typically has one application, Microservices have multiple applications working in tandem.

It’s important here to understand:

• Why should systems be monitored?

• How is monitoring microservices different from monitoring monolithic applications?

• What data should be gathered when monitoring?

•• What tools are available for publishing, gathering, and storing monitoring data?

• How can we configure monitoring tools to send alerts?

• How can we implement automation around monitoring tools to trigger features like scaling up/down resources etc.

06

6.1 Monitoring Tools

Here are a few examples of deployment models:

Cloud vs. On-PremiseYou can deploy your application on Cloud, On-Premise, in a Hybrid manner (Few services on the cloud, and few on premise), or you can create your own private cloud-based on business need. Deploying applications on the cloud gives more flexibility in terms of automated scaling of resources as and when needed.


13

Distributed tracing is also an application monitoring technique. It is used by both Tech and business team in the following ways:

• Tech Team

• Identify performance bottleneck and latency by analyzing logs.

• Be the first point of getting application insights while handling production issues

• Business Team

• Gives insights of usage of each feature/service

•• Helps take business decision around those services

Technically, it is important to understand the below diagram, which explains logs being generated across the request life cycle.

Without distributed tracing, we cannot trace the request lifecycle as random logs will be generated. So typically, a Unique ID is generated when a request originates. This unique ID is used by all services in the request life cycle for logging information. Logs can later be aggregated based on the Unique ID to replay the request life cycle.

6.2 Distributed Tracing

Logically speaking, logs generated using distributed tracing will be of no use if we unable to extract information out of them. Logs generated are pushed to the log analytics framework. Log Analytic framework like Sumo logic lets you query over the logs and derive meaningful tech and business information. In a microservices environment, random logs are nothing more than a collection of unnecessary items because of its nonuse to tech or business teams and, not using Log Analytics is as good as not generating logs.

6.3 Log Analytics


14

TransactionsOne of the biggest advantages of monolith architecture is transaction management. And, at the same time, it is the biggest challenge for Microservices architecture. Microservices best practices strongly recommend us to use the Single Repository Principle (SRP), which means each microservice maintains its own database, and no other service should access the other Service’s database directly. Technically, there is no direct and simple way of maintaining ACID principles across multiple databases. This is the challenge for transaction management in Microservices.

As its name hints, 2pc has two phases: A prepare phase and a commit phase. In the preparation phase, all Microservices will be asked to prepare for some data change that could be done automatically. Once all Microservices are prepared, the commit phase will ask all the Microservices to make the actual changes.

Normally, there needs to be a global coordinator to maintain the lifecycle of the transaction, and the coordinator will need to call the Microservices in the ‘prepare’ and ‘commit’ phases.

Possible solutions for this challenge are:

07

7.1 Two-Phase commit

The Saga pattern is another widely used pattern for distributed transactions. It is different from 2pc, which is synchronous. The Saga pattern is asynchronous and reactive. In a Saga pattern, the distributed transaction is fulfilled by asynchronous local transactions on all related Microservices. The Microservices communicate with each other through an event bus. Saga patterns come in two types:

Choreographed SagaIn Choreographed saga pattern, each saga participants collaborate by exchanging events. Each step of a In Choreographed saga pattern, each saga participants collaborate by exchanging events. Each step of a choreography-based saga updates the database (e.g., an aggregate) and publishes a domain event. The first step of a saga is initiated by a command that’s invoked by an external request, such as an HTTP POST. Each subsequent step is triggered by an event emitted by a previous step.

The disadvantage of this pattern is that since the request lifecycle can be complex, so can be saga chain. And over time, it becomes extremely difficult to debug/trace issues.

Orchestration based SagaAn orchestration-based saga has an orchestrator that tells the saga’s participants what to do. The saga orchestrator An orchestration-based saga has an orchestrator that tells the saga’s participants what to do. The saga orchestrator communicates with the participants using request/asynchronous response-style interaction. To execute a saga step, it sends a command message to a participant telling it what operation to perform. After the saga participant has performed the operation, it sends a reply message to the orchestrator. The orchestrator then processes the reply message and determines which saga step to perform next.

7.2 Sagas

CQRSCQRS aka Command Query Responsibility Segregation is an implementation pattern which helps us in segregating our business logic for Query (GET or retrieve data) and Command (PUT/POST/DELETE or Data Manipulation)

Benefits of CQRS are as follows:

• Simplify business logic implementation through separate Command and Query model

• Easily optimize and scale one part of the system separately as per load because of segregated command and query

7.3 Queries in a distributed world


Event SourcingEvent Sourcing pattern is widely used in an event-driven architecture wherein every action in an application is an event. Data exchange between various services is triggered based on events. The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. Application code sends a series of events that imperatively describe each action that has occurred on the data to the event store, where they're persisted. Each event represents a set of changes to the data.

SummaryMany organizations have successfully implemented Microservice Architecture, e.g., Netflix, Uber, Spotify, etc. And it has given them great flexibility to roll out new features quickly.

Implementing Microservices architecture is a paradigm shift from the conventional approach of developing a software product. E.g., DRY (Do Not Repeat yourself) vs. No code reusability, Monolith vs. Segregating Software as logical Services, Single Package Deployment vs. Independent Service deployment, ACID Transactions vs. Distributed transaction.

Implementing Microservice architecture can be very complex if it is not properly designed. Incorrect/ faulty design is a Implementing Microservice architecture can be very complex if it is not properly designed. Incorrect/ faulty design is a single point of a disaster of Microservice Architecture. And, with this paper, we have tried to walk you through the various tiers of Microservices Architecture, components, and tools that can be used, implementation options, and design patterns that will help you in designing your product using Microservices architecture.

09

Why Nitor for Microservice Architecture We at Nitor understand the complexity involved in building products using Microservices architecture. One wrong decision and this can be an inherent technical debt for the product. Modernizing your architecture ensures business viability and top-notch customer experience.

With over 350+ technology consultants with an understanding of both Traditional IT (legacy) and Transformational IT (new-age technologies), Nitor can give customers maximum value for their investment. Through our experience, we have championed patterns, practices, tools, and infrastructure required for creating Brownfield and Greenfield Microservices products.

You can write to us at [email protected] to know more about our Product Modernization services. You can write to us at [email protected] to know more about our Product Modernization services.

08

© 2019 Nitor Infotech. To learn more about Microservices,please reach out to us at [email protected].

www.nitorinfotech.com

About NitorNitor Infotech is a software product development services company that builds world-class products and solutions by combining cutting-edge technologies for web, Cloud, data & devices.

Using digitalization strategy as the centerpiece, Nitor helps build disruptive solutions for businesses using readily deployable and customizable accelerators.

Headquartered in Pune, India, we have offices in Chicago in the US.

MICRO GUIDE FOR MICROSERVICES - nitorinfotech.com€¦ · MICROSERVICES What is Microservices Why...

Documents

Transcript of MICRO GUIDE FOR MICROSERVICES - nitorinfotech.com€¦ · MICROSERVICES What is Microservices Why...