Microservices: To Do or Not to Do

Source:- sys-con.com

As enterprise business moves from monoliths to microservices, adoption and successful implementations of microservices become more evident. The goal of microservices is to improve software delivery speed and increase system safety as scale increases. Documenting hurdles and problems for the use of microservices will help consultants, architects and specialists to avoid repeating the same mistakes and learn how and when to use (or not use) microservices at the enterprise level. The circumstance when microservices is an appropriate solution described in this article and based on the authors’ work experiences, best practices available in the microservices community. However, using microservices architecture does not guarantee success to the enterprise.

Introduction
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,

1. Organizational Cultural Changes
2. Architectural Changes
3. Operational Changes
4. Governance Changes

The following diagram describes the changes in details.

Figure 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 [1-3]. The following sections of the paper summarizes, when to adopt Microservices and when not to use Microservices. It also highlights enterprise adoption of Reference Architecture using 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

Figure 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, components and data responsibility and governance because of its architectural style.
• Resiliency: 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.
• Innovation: 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: A 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.
• Manageability: Smaller microservices code bases are easier for developers to understand, making changes and deployments easier.

Microservices Modeling – Example
Below is an example of microservices identification in e-Governance domain, the License Management application consists issue of license for various categories like starting of business, trading, weapon license etc. The application consists of several components including the LicenseFrontUI, which implements the user interface, along with some backend services for tracking, calculate fee, inspection etc. The application consists of following set of services. The below diagram depicts the sample application of License Management System using Microservices,

Figure 3: Microservices Modeling-Sample Application

SOA 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.

SOA is preferred for an enterprise having plenty of legacy systems, heavy weight middleware and diverse applications.  The environment for Microservices architecture is the borderless enterprise: end-to-end, cloud-centric digital applications leveraging virtualized infrastructure.

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

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

The following table summarizes the difference between SOA and Microservices.

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 traditional SOA to cloud based applications, Microservices are preferred
• To develop highly distributed systems
• When the enterprise primary businessrevolves around extremely high volumetransactions
• 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.

Microservices Patterns
There are many patterns related to the Microservices Architecture. Following are some popular patterns used by applications built using Microservices architecture.

1. Circuit Breaker: Circuit breaker pattern used in Microservices for fault tolerance to ensure that the failed service does not adversely affect the entire system.
2. Gateway: API Gateway is responsible for aggregating data or, in some cases, acting as a simple routing layer for appropriate services. The API gateway seen as a single point of failure. A better approach may be to create multiple API gateways for the different platform or frontends that your application needs to support.
3. Bounded Context: A bounded context contains models describing the domain and a boundary for the meaning of these models.
4. CQRS: Command and Query Responsibility Segregation is a pattern that segregates the operations that read data (Queries) from the operations that update data (Commands) by using separate interfaces
5. Orchestration or choreography used to execute and manage business processes or workflows.
6. Bulkhead: This pattern is to use to avoid faults in one part of a system to take the entire system down.

The following diagram shows the holistic view of the Microservices Pattern commonly used across the enterprise.

Figure 4: Microservices Patterns

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

Conclusion
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.