From the Blogosphere
Reference Architecture #Microservices | @CloudExpo #Serverless #AI #DevOps
The goal of microservices is to improve software delivery speed and increase system safety as scale increases
Dec. 29, 2017 12:00 PM
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Microservices Reference Architecture that highlights various sub systems needed to support Microservices deployment and execution.
Of late, enterprises are adopting technologies like analytics, mobility, social media, IoT and smart embedded devices to change customer relationships, internal processes and value propositions. Microservices acts like a bridge between these technologies and provides the building blocks for developing modern distributed enterprise systems to become one of the enablers in the digital transformation journey of the enterprise.
Adoption of Microservices provides the agility, reliability, maintainability, scalability and deploy ability to the enterprises as part of digital transformation process.
There exists many different architecture definition approaches for implementing Microservices across Industry. Many of them are unique and specific to the needs of individual development teams. Many enterprises, without understanding or highlighting the name, have been using an approach towards leveraging APIs that classified as Microservices. This demands a need for designing Reference Architecture to develop and deliver Microservices‑based applications that consumed across the Enterprises.
There exists, numerous articles and blogs on Microservices reference architecture, architecture principles and best practices. This paper summarizes the purpose of Microservices Reference Architecture, drivers for adopting Microservices, Microservices architecture principles and logical view of Microservices Reference Architecture.
Drivers for Microservice Reference Architecture
With Microservices, each service can scale independently to meet temporary traffic, complete batch processing and other business needs. Improved fault isolation restricts service issues, such as memory leaks or open database connections. The scalability of Microservices complements the flexibility of cloud services improves service and handle more customers simultaneously without interrupting service.
The following diagram represents few key drivers for Enterprises adopting Microservices.
Microservices Architecture Principles
Single Responsibility Principle: Each microservice must be responsible for a specific feature or a business functionality or aggregation of cohesive functionality completely.
Granular: Microservice granularity is contained within the intersection of a single functional domain, a single data domain and its immediate dependencies, a self-sufficient packaging and a technology domain.
Domain Driven Design: Domain driven design is an architectural principle in-line with object-oriented approach. It considers the business domain, elements and behaviors and interactions between business domains.
Encapsulation: Each Microservice encapsulates the internal implementation details, so that the external system utilizes the services need not worry about the internals. Encapsulation reduces the complexity and enhances the flexibility of the system.
Loose Coupling: There must be zero coordination necessary for the deployment with other Microservices. The changes in one microsystem should have zero or minimum impact on other services in the eco-system.
Separation of Concerns: Develop the microservices based on distinct features with zero overlap with other functions. The main objective is to reduce the interaction between services so that they are highly cohesive and loosely coupled. If we separate, the functionality across wrong boundaries will lead tight coupling and increased complexity between services.
Language Neutral: Microservices are composed together to form a complex application, and they do not need to be written using the same programming language. For example, Java might be the correct language for one application, and in others, it might be Python etc.
Hexagonal Architecture: Microservice exposes RESTful APIs for external communication, message broker interface for event notification and database adapters for persistence. This makes hexagonal architecture as a most suitable style for Microservice development.
Sizing of Microservices
Also, Microservices cannot be too large or too small. Large services are hard to work with, hard to deploy, and take longer to start and stop. On the other side, when Microservices are too small, the resource cost of deploying and operating such a service overshadows its utility.
Microservice granularity can also be determined based on business needs. Making services too granular, or requiring too many dependencies on other Microservices, can introduce latency.
Microservices allow teams to plan, develop, and deploy features of a system in the cloud without tight coordination. It is therefore, Microservice number and size be dictated by business and technical principles.
Microservices Reference Architecture
The following guidelines to be adapted while designing the services of Microservices Reference Architecture.
Below is the logical view of the Microservices reference architecture.
Fig 2: Microservices Reference Architecture - Logical View
Various components of the reference architecture are described below:
Channels: Channels represents various client side or consumer applications, which will interact with Microservices.
Edge Server: API services or edge services reside on edge server or the API Gateway. Channels interact with the edge services, which decouples the microservices, and keep them channel agnostic.
API gateway is the single entry point for all clients. API Gateway is responsible for aggregating data or, in some cases, acting as a simple routing layer for appropriate services. The API gateway act as a single point of failure. For the coordination between cloud and on premise communication, an API Gateway is used.
The following diagram shows the API gateway interaction patterns
Below diagram show load-balancing scheme.
Decentralized load balancing is the appropriate mechanism for distributing requests between available Microservice instances. Each Microservice can have its own load balancer handling only requests for that Microservice. Client is directly responsible for routing requests to an available Microservice.
API Service: API services need to be exposed either on the edge server or on API Gateway. The Service expose client specific API and can also act as coarse-grained services to orchestrate across multiple Microservices within or across bounded contexts. These services can interact with composite Microservices or directly with core Micro services.
API services can also communicate with the Enterprise Integration Infrastructure (typically ESB/MOM) to access any on premise Enterprise Applications
Composite Service: Composite services orchestrate across multiple core services. These services shall be communicating with the other services using the event-sourcing model or orchestration.
Core services: These services are the basic building blocks for Microservices architecture. These services encapsulate an entity or an aggregate (fine grained) within a given bounded context. Best practice is that, the granularity of the Microservices are always fine grained.
Circuit Breaker: Fault tolerance will ensure that when there is failure, the failed services does not adversely affect the entire system. Without proper mechanisms in place, errors, latencies will trickle up to the calling clients where they will potentially exhaust limited resources. When cascading failures occur, the overall system availability is significantly affected.
The three states of the Circuit Breaker is depicted below,
In open state, the circuit breaker reject invocations by either
Half Open State
Cloud Config: It is a single source of configuration data for all other services in a Microservice-based application. Each service can have its configuration in a repository, which centralizes the configuration across all environments. It decouples the configuration from the implementation, which helps to update the configuration without affecting any of the services. Every update on the configuration files in the repository are automatically propagated to the running instances.
Service Discovery: In Microservices application, the dynamic assignment of service instances network locations happens automatically. In addition, the set of service instances changes dynamically because of auto-scaling, failures and upgrades. Consequently, the client code needs to use a service discovery mechanism.
There are two main service discovery patterns: Client-side discovery and Server-side discovery.
Messaging & Events Stream: Lightweight messaging platforms like AMQP shall be used for exchange of messages between microservice within or across bounded contexts or in case of event sourcing used as part of the choreography.
Monitoring: As microservices are distributed and heterogeneous in nature, it is critical to monitor and visualize making sure that software is reliable, available, and performs as expected. Monitoring typically involves collecting metrics from all the applicable systems involved and analyzing/visualizing call graphs. These gets complex as the application complexity (again depends on number microservices and their interactions in a call graph) grows. There are many commercial and open source tools for monitoring microservices.
Distributed Tracing: Distributed tracing helps in how a request traverse through the application, especially when you may not have any insight into the implementation of the microservice you are calling. Tracing tools introduces unique IDs for logging which are consistent between Microservice calls which makes possible to find how a single request travels from one Microservice to the next.
Security: With microservices, security becomes a challenge primarily because no middleware component handles security-based functionality. Instead, each service must handle security on its own, or in some cases, the API layer be made more intelligent to handle the security aspects of the application. Security Frameworks like oAuth2 address the security concern. There are multiple ways of configuring security for microservices; by making API Gateway behave like reverse proxy or by securing each microservice using the security service (backing service like IAM) provided by the PaaS provider.
Backing Services: A PaaS provides services grouped into various categories like database, analytics, security, Data warehouse etc. used by the cloud application. These services expose lightweight protocols (like REST) and consumed by the cloud application by binding. PaaS providers provide consoles (UI based) to manage backing services.
On Premise Integration: API Gateway helps to mediate the communication between cloud and on premise applications. API Services will be used to orchestrate calls that span cloud and on premise by calling the enterprise integration infrastructure for calling any applications on premise.
Infrastructure: Infrastructure has two components; PaaS and IaaS. IaaS is the abstraction onto the hardware and provides on demand resource provisioning. Resources can be scaled out or in based on usage pattern. PaaS is cloud platform residing on top of IaaS. This layer provide the required support for the cloud applications to deploy and run. PaaS provides various runtimes and many backing services required for a cloud application.
Finally, Microservices based System Design is an ongoing story. It is not something that has to done once, and immediately. With the right people, processes, and tools, Microservices can deliver faster development and deployment, easier maintenance, improved scalability, and freedom from long-term technology commitment.
The authors would like to thank Hari Kishan Burle, Raju Alluri of Global Enterprise Architecture
Group of Wipro Technologies for giving the required time and support in many ways in bringing
Up the article as part of Global Enterprise Architecture Practice efforts.
Dr. Gopala Krishna Behara is a Lead Enterprise Architect in the SCA Practice division of Wipro. He has a total of 21 years of IT experience. Reached at firstname.lastname@example.org
Tirumala Khandrika is a Senior Architect in the SCA Practice division of Wipro. He has a total of 16 years of IT experience. Reached at email@example.com
Sridhar Chalasani is an Architect in the SCA Practice division of Wipro. He has a total of 12 years of IT experience. Reached at firstname.lastname@example.org
The views expressed in this article/presentation are that of authors and Wipro does not subscribe to the substance, veracity or truthfulness of the said opinion
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week