Beena Jacob, Chief Technology Officer
In my first discussion of Donoma’s transformation to cloud native application delivery, I focused on providing context on cloud native. That discussion was designed to help those still skeptical of the benefits to gain a better understanding of why cloud based SaaS applications are the industry standard. To help illustrate the principals, I provided examples of how we have integrated these benefits into all our solutions.
Here in my follow up second discussion, I’ll focus on one of cloud native’s most important components, micro-services. Like I did when explaining cloud native architecture, I will provide background, then examples for context. I’ll also explain the benefits and challenges you can expect to face with the transformation to micro-services from a monolithic architecture.
Building Software is Similar to Lego Blocks
User demands and technological capabilities are constantly evolving and expanding. You have to innovate faster to deliver what your users need. 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? Our team is doing just that by adopting micro-services as part of our development tactics. The “plug and play” design of the micro-services allows for very agile development to respond to shifting customer demands.
What Exactly are Micro-services?
Let’s briefly define micro-services. Micro-services, also known as Micro-service Architecture (MSA), is a software architectural style where applications are composed of small, loosely coupled services that do one single thing. These service are then collectively connected and organized to support more complex services. Micro-services have their own compute, runtime, framework and data store. In a micro-service 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.
Micro-services 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 savvy customers 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 micro-services.
Is Micro-service 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. Micro-services 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 Micro-service is Key
Having a good knowledge of your domain and sub-domains before transforming to micro-services from monolith is key. Making your services too small will require managing large numbers of them. But making them too big will result in the loss of agility. Start small and look for components that can be easily transformed and not dependent on other components. Easy examples are the notification service or the print service. These can be easily transformed to micro-services and continue to co-exist with the monolith. As you understand your domain better, your bounded contexts will be more fine-grained.
Benefits of Micro-services
There are quite a few benefits that come with a transition to micro-services:
- Each service can be scaled independently of the other.
- Flexibility to experiment with a new technology and not impact the other services. They can be developed using the best technology for its function.
- Secure against the failure of other services. This makes the overall system more robust. Continuous delivery is also easier due to size.
- The micro-services are only loaded when called. This makes the application faster to load and have a faster deployment compared to a monolithic system.
- Micro-service architecture enables continuous delivery and deployment. Each service can be deployed without interrupting any other service. Since each service is small in its codebase, it’s easier for developers to manage and maintain each service.
- Breaking a large application into components 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 Micro-services
Many of the disadvantages of micro-services are similar to those with implementing any new technology. 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 micro-services:
- There is not a commonly agreed upon definition of the size, scope, and boundaries of a micro-service.
- Without continuous deployment and orchestration services, managing the deployment can be challenging.
- Implementing transactions correctly and maintaining their safety can be challenging when multiple services are involved. Security of each 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.
- 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.
Conclusion
Micro-services have played an integral role in the roadmap of all our solutions. In the first discussion, we briefly discussed the implementation of cloud-native principals into our OneVault and OneView solutions. We also included a micro-service into our OneVoice solution, providing the ability to transcribe audio messages using cloud Speech2Txt APIs.
