Written by Saurabh Vatsa

Organizations have been striving to develop applications that are agile and easy to adapt. Microservices architecture addresses this challenge and therefore created a buzz within the enterprise IT world. Despite the initial hype, many companies still struggle to find and implement the right microservices architecture. In this blog, we can see about the various microservice patterns available across the microservices ecosystem and choose the one that suits your organization’s requirement and long term vision.

What is a microservice?

Microservice or Microservice architecture is an architectural style that structures an application with loosely coupled services or smaller components. The services are usually lightweight and protocols are stateless, such as JSON.

The primary goal of a microservices development is the innumerous business capabilities and autonomously deployable models. Switching to a microservices approach allows a company to quickly integrate assets, adapt to market needs and scale efficiently.

Adoption of Microservices: Finding the right fit

A recent survey by Vanson Bourne shows more than 68% of businesses are either using or investigating microservices and one-third currently using in development.

Organizations that have adopted microservices have reported increase in security, development, ease of integrating new technologies, improved infrastructure flexibility and faster collaboration.

Though companies recognize the benefit of microservices, they continue to grapple in finding the right approach that suits their business needs.

Purists may argue that, fine-grained SOA architecture is the way forward to implement microservices, but that approach is not always helpful and might backfire. Each organization is different in its size, technology, culture, and one architecture model might not fit all.

So, every organization should determine their best microservice pattern to serve for its long-term goals with minimal compromise.

Microservice Patterns

Why do we require a microservice pattern to work with?

The basic definition of a pattern is something that repeats itself, maintains consistency and is reusable. When we combine “Microservice” with “pattern” it basically results in building a microservice architecture that maintains consistency across its implementation, is reusable, institutes the baseline for all the future architectural decisions by defining standards.

Types of available microservice patterns

• Fine-Grained SOA
• Layered APIs over Fine-Grained SOA
• Event-Driven State Management over Layered APIs
• Isolating State in Layered APIs
• Replicating State in Layered APIs

Fine-Grained SOA

This pattern breaks and decouples a coarse-grained service into multiple smaller services (fine-grained microservices).

In terms of Mulesoft’s eco-system, deploying “Add to cart” and deploying “Remove from cart” as two different applications on the server (Runtime Plane) and exposing them as separate web services to the consumers is an example of Fine-Grained SOA.

Pros:

Cons:

• Interconnectivity of services increases the number of network hops required, which in turn increases traffic.
• As the number of services increase, proper management tools needs to be put in place to manage these services effectively.
• Proper monitoring must be in place to make sure all the services are up and running and performing optimally.
• When the number of services are vast, there will be continuous integration, testing and deployment. Therefore, automation is required to reduce manual errors.
• Orchestration becomes necessary to make sure the requirement is fulfilled end-to-end by calling different services in their defined steps.

Layered APIs Over Fine-Grained SOA

This is an evolution over Fine-Grained SOA which distributes microservices into layers and gives each layer a purpose. For e.g., An Experience Layer caters to end-users, a Process Layer handles orchestration, and a System Layer exposes systems and simplifies legacy implementation.

In terms of Mulesoft’s eco-system, bundling “Add to cart” and “Remove from cart” services into an application, defining it in a layer, deploying it (Runtime Plane) and exposing it as a web service with different resources is an example of Layered APIs over Fine-Grained SOA.

Pros:

• This pattern provides a structure to Fine-Grained SOA pattern by grouping together services in layers.
• When the standard is maintained across the pattern, it is very easy to make changes to the services in layers.
• Scalability is flexible (If a process layer requires more resources due to multiple layers using it as a child, it’s easy to scale this layer)
• Reusability is improved because any of these layers can be reused (by minor extensions ) within any similar requirement.

Cons:

• When microservices are structured in a layer, it becomes more complex to manage and monitor. It is difficult to keep track of every service in the layer, how the service is performing and if the service is up and running
• Traffic in between the layers will definitely increase when these layers will be calling each other and therefore that increases number of hops injecting network latencies.

Event Driven State Management Over Layered APIs

In this pattern, events are used to trigger the next set of events. An event is something that happened in the past with its own state and time stamp. Next, this event is published in a queue with its state, and interested recipients will use this state to replay the next event in the queue.

In terms of Mulesoft, let’s take an example of Warehouse order fulfilment service being implemented with event driven layered API. When the order is placed on website and once it reaches warehouse, warehouse needs to pick, pack and ship the order and at each event there needs to be subsequent actions that need to happen. When warehouse intimates the integration application about the order being packed, it is created as an event and pushed to the queue and any subscribers of that queue might plan their actions based on this “packed” event. Logistics might create a AWB, brands might notify customer with order status updates and so on.

Pros:

• This pattern ensures data integrity is maintained. Data is consumed by the subscribers with the same accuracy and consistency that a publisher intends.
• Scalability is achievable by scaling up and scaling down the layers based on the number of incoming events.

Cons:

• There are no standards defined, which makes the implementation inconsistent unless standards are agreed upon. Event means something that happened in the past and it contained a time stamp of completion and this event is then used to perform next order of events. But there are many implementations where event is being misunderstood with a command which means making something happen without any past event.

Isolating State in Layered APIs

With this pattern, we isolate each microservice with its own data store to maintain a single source of truth for each type of data, ensure data consistency at query time, and reconcile the internal store with the external one whenever necessary.

For example, a “Pricing” microservice would contain its own internal database that contained all the product pricing information, and would serve as a single source of truth.

In terms of Mulesoft eco-system, it means creating layers with their own object storage to store the transactional data and writing the data to backend system at defined intervals. For e.g., creating an experience layer for adding and deleting items from a cart, whenever a customer adds an item to the cart, data is maintained in the experience layer’s object storage and if the customer chooses to delete the item from same cart, it is also reflected in the same object storage. This maintains a strong consistency of data. Data from internal object storage is then written to backend database eventually at defined frequencies.

Pros:

• Data integrity is maintained because service is the master of data and therefore, data consistency and accuracy is maintained without worrying about any external factors.
• Clean and simple architecture of isolating and maintaining databases within the layers and syncing them with the external database whenever needed.
• Changes can be made faster and without worrying about other services because of isolation and independent nature of pattern.

Cons:

• Data sync between internal and external database needs to be reliable to avoid inconsistencies.
• Scalability is challenging because scaling a process involves scaling the data store along with it.

With more organizations adopting microservices architecture, there exists a rise in competition for others to embrace the technology as well. By choosing the right pattern, your organization can reap the benefits of microservices and adapt to the ever-changing technological landscape.