Microservices Adoption : Why, When & How

July 5, 2022 Holt Hackney Applications & Technology, Microservices, Strategy & Planning 0

By Dr. Gopala Krishna Behara

In software development, smaller is usually better. More minor things are easier to code, easier to maintain, simpler to test, and easier to deploy. Systems built this way can be more scalable, more flexible, and deliver value with greater speed. Microservices supports this kind of development.

However, adoption of Microservices Architecture requires an enterprise to undergo changes across various areas.  The Major changes are,

  • Organizational Cultural Changes
  • Architectural Changes
  • Operational Changes
  • Governance Changes

Below diagram describes the changes in detail.

 

gopola 7 5 1

Fig 1: Changes affecting the Enterprise

Today, 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 as building blocks for building modern distributed enterprise systems and become one of the enablers in the digital transformation journey. Microservices provides the agility, reliability, maintainability, scalability and deploy ability that aid enterprises through their digital transformation process. It helps the enterprise in achieving the following factors,

  • Focus on Business Need
  • Agility, enterprises can introduce new products or enhancements into the market quickly
  • Enhancing the customer experience
  • Reliability, if a service is down, the customer will not be able to use the functionality provided by that specific service, but the rest of the system is still usable
  • Scalability, the system can be configured to auto-scale (up / out) and during off-peak hours, it can go back to its normal configuration resulting in a better customer experience and cost-savings for the customer
  • Can be developed & deployed independently of other services

There exists, numerous articles and blogs on Microservices best practices, designing good services, and a robust supporting backbone. The following section of the paper summarizes, when to adopt Microservices and when not to use Microservices.

 Characteristics of Microservices

Microservices is an architecture style, in which software systems or applications are composed of one or more independent and self-contained services. It is not a product, framework, or platform. It is a strategy for building large distributed systems. Microservices are loosely coupled and deployed independently of one another.

Microservices can be developed in any programming language, each running in its own process and communicating with lightweight mechanisms like HTTP resource API such as REST. Each Microservices focuses on completing one task and that one task represents a small business capability. There exist no criteria on how small a microservice must be. These services lead the application decomposition into smaller pieces. This helps to scale up parts of applications rather than scaling up the entire application.  The below diagram depicts the major characteristics of Microservices which are classified as,

  • Business
  • Technology
  • Process
  • People

Gopola 7 5 2

Fig 2: Characteristics of Microservices

Business

  • Service Independent: As Microservices are autonomous, each Microservice can change in its lifecycle in an independent manner with other services.
  • Self-Contained: Services are easily replaceable and upgradeable. It promotes single ownership of the service. To achieve self-containment proper granularity in decomposition is essential.

Technology

  • Decentralized: Microservices decentralizes architectures, patterns, languages, standards, component & data responsibility and governance because of its architectural style.
  • If one of the Microservices goes down, it won’t necessarily bring the whole application down as it would with a monolithic
  • Polyglot: Microservices architecture supports multiple technologies, to be specific, a technology that is most fit for the purpose.
  • Single Responsibility: A Service is aligned to a single business activity and is responsible for that business activity and deliver the complete business logic necessary to fulfill the business activity.
  • Scalability: Microservices can be deployed and scaled independently of each other.
  • Decoupled: Microservice should implement a single atomic business function. This helps in maintaining minimum dependency on other services

Process

  • Implementation Agnostic: Implementation shall support multiple development platforms and technologies and can be deployed in any of the containers
  • Blackbox: Microservice shall be a black box (no internal details will be exposed outside the service boundary) for other components / systems using / invoking it.
  • Bounded Context: This is one of the important characteristic of Microservices. Other services do not need to know anything about underlying implementation or architecture of other Microservices.
  • New versions of small independent services can be deployed more rapidly, making it easier to experiment and innovate.
  • Quality: Composability and responsibility, more maintainable code, better scaling and optimization

People

  • End-to-End Ownership: This is a cultural shift for the project team. The development team will maintain each project built using Microservices architecture as opposed to the regular practice (of handing it over to the support and maintenance team).
  • Independent Governance: Single team owns the complete ownership of the Microservice life cycle. This team owns the all the aspects of the Microservices including governance. Governance is decentralized and autonomous.
  • Smaller Microservices code bases are easier for developers to understand, making changes and deployments easier

Monolithic Vs Microservices

Microservices Architecture is based on SOA vision, which is decomposition of software systems into loosely coupled services. Microservices extends the principles of SOA like business alignment, dependency minimization, and service contracts. Each Microservice has its own data store, and centralized governance. The Microservices architecture is scalable and allows for easy implementation of changes. These advantages have made microservices one of the most sought architectures in recent years.

Microservices use continuous integration (CI) and continuous delivery (CD) methodologies and practices, as well as several critical components that were not as common in Monolithic, such as:

  • Polyglot programming and persistence.
  • Containers or immutable virtual machines (VMs).

Below, table summarizes difference between Monolithic and Microservices.

Monolithic Architecture Microservice Architecture
Started as SOA conceptual architecture, SOA technologies have evolved from the concepts Microservice architecture was derived from real software development patterns observed within numerous organizations
Monolithic is limited to few aspects of an enterprise such as technology and governance Microservice architecture is broad, covering the patterns, principles, culture, and enterprise governance and technologies
Monolithic architectures aim to control and standardize enterprise application integration Microservices goal is to be as responsive as possible to customer needs while maintaining high levels of software quality and system availability
Focus on standardization at enterprise level and follows the monolithic approach. Allows different applications / teams to evolve autonomously.
More complex protocols like BPEL, WS-Choreography are used Uses representational static transfer (REST) protocol
Loose or decoupled services Atomicity is main feature of Microservices
In Monolithic applications data service layers are implemented using web-services-based data services. The exposed legacy data create-read-update-delete (CRUD) queries as web service operations. Microservices abstract data services as RESTful resources, where individual microservices respond to RESTful calls by abstracting underlying CRUD operations.
Replacement of existing applications is complex and requires business case evaluation Replacement is easy and most cost effective
Based on heavy weight technologies (SOAP, ESB etc) and not highly scalable Based on lightweight technologies and is very scalable.
Application development and deployment takes longer time and its complex Application development and deployment is rapid and simple. Less overhead
Centralized Governance. Does not support multiple development teams Local and distributed governance. Supports multiple development teams working simultaneously and independently
Services need not be independent Service has to be independent of other service

When to do Microservices

The following are the factors, which drive the enterprise to use Microservices as their solution.

  • Development for cloud-based systems. Ie when enterprise decides to move from Monolithic to cloud based applications, Microservices are preferred
  • To develop highly distributed systems
  • When the enterprise primary business revolves around extremely high volume transactions
  • If the functionality to be highly available. Deploy the functionality as service in multiple, redundant providers so that some are available even when others are not.
  • For the solutions that require the integration of business capability from disparate systems and programming models
  • For aligning business and IT functionality
  • For business and technology agility
  • Better ROI
  • For incremental development (Agile) and continuous deployment of business software

When Not to do Microservices

The following are the factors, which negates the usage of Microservices.

  • Scenarios where monolithic and centralized application architecture make more sense (for more simple, small and low available application development)
  • For applications where consistency is high priority over eventual consistency
  • Small enterprises with homogeneous network and technology confined to the single vendor.
  • Scenarios where standards based integration not needed. The solution might be simple data exchange between applications and external systems.
  • When there is no frequent release because of changing requirements
  • Non cloud-based development
  • Re-Architecting data platforms. If service relies upon a system of record (Mainframe, Oracle database, SAP system, and others), then Microservices do not fit the definition.
  • Scenarios where there is no product like ownership is required from the project teams
  • Cultural shift in enterprise in terms of team autonomy, long-term commitment to a technical / product stack is not possible or required.

Benefits of Microservices

Microservices are build using lightweight framework, open-source technologies. It offers quick time to market.

  • Improves fault isolation, larger applications can remain largely unaffected by the failure of a single module.
  • Provides business agility, supports Continuous Delivery. New Functionality can be added easily and quickly. Development teams work independently
  • Eliminates long-term commitment to a single technology stack, develop the code independently using whatever technology the developer feels right for delivering business function. Different part of systems can use different technology stack if needed for better performance.  Technology heterogeneity or polyglot programming is one essential benefit of Microservices.
  • Developer perspective, makes it easier for a new developer to understand the functionality of a service
  • Smaller codebases help developers focus and have a higher empathic relationship with the users of their product, leading to a better motivation and clarity in their work
  • Ease of deployment, one part of the system can move to another machine or to another cloud while rest of the service could stay on premise

Summary

This article narrates the situations, when to use Microservices and when not to use. Microservices are recommended for the usage at enterprise level.  Adoption of Microservices by an enterprise provides the extreme time to Market and establishes the bridge between Business and IT of the enterprise. Microservices implementation provides interoperability and flexibility to the enterprise.

In Microservices the functional logic is modeled and exposed as software service and is available on demand to other applications. Microservices is recommended cautiously, when the performance is important requirement, functionality is highly available, and security is important.

Extensive use of Microservices and “compositional development” by assembling services rather than low-level programming can eventually leave IT with a collection of Microservices and not really a collection of applications.

Microservices are deployable on independent technology stacks. While they leverage Cloud models to deploy and orchestrate Microservices, individual Microservices can still reside on legacy platforms, as per the requirement.

To achieve success with Microservices, enterprises must first build a well-designed application according to existing platform standards; refactor the application into a collection of Microservices as necessary to meet business needs. 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.

Finally, do not create too many Microservices.  Every new Microservice uses multiple resources. Split larger services into Microservices only when the demand is for scaling, lifecycle, or data. Making them too small transfers complexity from the Microservices into the service integration task. Also, avoid sharing Microservices between systems.

It is up to the Enterprise IT architecture team to decided, when to adopt Microservices and when not to go for Microservices based on IT strategy assessment.

Acknowledgements

The author would like to thank Kiran M.R & Raju Alluri of Wipro Digital Architecture Practice of Wipro Ltd for giving the required time and support in many ways in bringing up this article.

Author

Dr.Gopala Krishna Behara is a Distinguished Member and Lead Enterprise Architect in Wipro Technologies with 25+ years of extensive experience in the ICT industry. He serves as an Advisory Architect, Mentor on Enterprise Architecture, Application Modernization and continues to work as a Subject Matter Expert and Author. He is certified in Open Group TOGAF, AWS Solution Architect -Associate, IBM Cloud Solutions and UNPAN. Published number of research papers, books in IT industry. He has been a speaker at National and International forums and bodies like The Open Group, National e-Governance Forum. He has been a moderator and panel member for multiple technical/business forums like IGI Global, AEA, Open Group and Premium College meets. Recipient of EA Hall of Fame International Award – Individual Leadership in EA Practice, Promotion and Professionalization Award.  He can be reached at: gopalkrishna.behra@wipro.com.

Public profile: https://www.linkedin.com/in/gopalbehara/    

 Disclaimer

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.