In the first discussion of our Strategy and Design Series, we focused on providing context and background on cloud native, as well as our implementation of its principals into our solutions. Here in our second discussion, we’ll focus on one of cloud native’s most important components, microservices. On top of providing background and context, we’ll explain the benefits and challenges you can expect to face with the transformation to microservices from a monolithic architecture.
Building Software is Similar to Lego Blocks?
In today’s business environment, user demands, and technological capabilities are constantly evolving and growing. You have to innovate faster to keep up with the changing market conditions. What used to take months to accomplish now has an expectation to be done within in a few weeks.
What if we could build software like Lego blocks and snap them together easily? Industry disruptors and innovators are doing just that by adopting microservice architecture. The plug and play design of the microservices allows for the high velocity software development to respond much more quickly to market demands.
What Exactly are Microservices?
Let’s briefly define microservices. Microservices, also known as Microservice Architecture (MSA), is a software architectural style in which applications are composed of small, loosely coupled services that are focused on doing one single thing and modeled around a business domain. Microservices have its own compute, runtime, framework and data store. In a microservice architecture there is no centralized database – each service has its own data store and can be developed without interrupting other services. Hence the time to market is faster with low risks.
Microservices vs Monoliths
Monolithic application is like a big container where all the components are tightly packaged with minimal options for plug and play. Traditionally, enterprise applications are complex and follow a monolithic architecture. But there are some major drawbacks that come with this type of architecture. Such as:
- Failure of one component impacts the entire system and uptime of the application.
- It’s unable to scale specific components independently.
- Slow software delivery velocity, causing the team to struggle to keep up with business demands.
Today’s end users are expecting a consistent experience across a wide range of devices. Cloud based applications that are quickly accessible and scalable are in high demand. Monolithic approach fails to meet these expectations, leading to many companies embracing the transformation to microservices.
Isn’t Microservice Architecture (MSA) Just Another Name for SOA?
Traditional Service-Oriented Architecture (SOA) is about sharing as much as possible between components, usually requiring Enterprise Service Bus (ESB) for communication. Microservices share as little as possible to create minimal dependencies, and this is achieved through “bounded context”. So, to answer the question, a microservice architecture is not another name for SOA. SOA focuses on business functionality, while MSA is about bounded context.
Bounded Context and Single Source of Truth
Bounded context is a central pattern in Domain-Driven Design. It attempts to define the boundaries of the domain into a business context and is the limit in which a domain model is consistent.
Consider a typical e-commerce application that consists of a Shipping Service, Catalog Service and Order Service. All these services require product information, as well as specific product attributes that are key for each of these services. Catalog service is about product image, while order service is about product price, and shipping service is about product category for shipping.
If a single representation of the product is used, then it ends up being shared data and dependencies between the microservices. The bounded context ensures that the concept of the product is kept internally within each service and not shared externally. This also means keeping multiple sources of truth consistent. Event Sourcing and Command Query Responsibility Segregation are well known patterns to achieve a single source of truth.
Right Sizing a Microservice is Key
Having a good knowledge of your domain and sub-domains before transforming to microservices from monolith is key. Making your microservices too small will require managing large numbers of them. But making them too big will result in the loss of the benefits that comes with a microservice architecture, turning soon into another monolith. Start small and look for components that can be easily transformed and not dependent on other components for eg: the notification service or the print service. These can be easily transformed to microservices and continue to co-exist with the monolith. As you understand your domain better, your bounded contexts will be more fine-grained.
Benefits of a Transformation to Microservices
There are quite a few benefits that come with a transformation to microservices:
- Each service can be scaled independently of the other.
- Since microservices are independent there is the flexibility to experiment with a new technology and not impact the other services. They can be developed using the best technology for its function.
- Microservice systems can be secured against the failure of other services, so that the overall system is robust. Continuous delivery is easier because of the size of the microservices.
- The microservices or modules of the website are only loaded when required so it can make the application faster to load and faster deployment time compared to a monolithic system.
- Microservice architecture enables continuous delivery and deployment. Each service can be deployed without interrupting any other service. Since each service is small in it’s codebase, this makes it easier for developers to understand and maintain each service.
- Breaking a large application into components by business capability enables development teams to focus on one small set of functionalities at a time. The overall coding and testing process for individual services is more precise as a result.
Challenges of a Transformation to Microservices
Many of the disadvantages of microservices are similar to those with implementing any new technology or architecture. Just as with the benefits, the specific disadvantages that might apply to your project are directly related to its specifics, your team, and your organization. But here are some of the main points you need to be aware of as you look into utilizing microservices:
- There is not a commonly agreed upon definition of the size, scope, and boundaries of a microservice.
- Without continuous deployment and orchestration services, managing the deployment of multiple microservices can be challenging.
- Implementing transactions correctly and maintaining their safety can be challenging when multiple microservices are involved. Security of each microservice has to be considered.
- Reliable and fast network connections are required to support the increased amount of network communication from services interacting with each other.
- Proper monitoring and logging tools are a must for microservices deployed in production.
- Being able to choose a different technology stack for various services results in non-uniform application design and architecture. This can increase long-term maintenance costs. Choose wisely and not just because a different technology stack can be implemented.
Microservices have played an integral role in our most recent solution releases. In the first discussion, we briefly discussed the implementation of cloud-native principals into our OneView solution. The solution’s latest release included a microservice that was built around Contact Center Queues. Along with OneView, we also included a microservice into our Unify for Gmail solution, providing the ability to transcribe audio messages using cloud Speech2Txt APIs.
There is still much more to unpack in this Strategy & Design Series. Join in next time as we’ll continue covering the core components that make up cloud native. Our focus will shift from microservices to Continuous Delivery and Deployment.