Armedia Solution Engineering Team

• Vishal Deshpande
• Andrew Slade
• William Phillips
• Naga Krishna Sumanth Kovvuri

What Are The Challenges Of Using Microservices?

Microservices have become the new architectural cool-aids in the IT world ever since Netflix open-sourced its microservices tools and published several blogs and articles on their design and architecture using microservices. Knowing Netflix and its user-base, microservices gained immediate popularity in the software architect and developer community.

With cloud-based “Software as a Service” model as the need of the day, Armedia is always looking to cater to large customer bases, and we need ways to scale the tools and services to that level. Microservice-based architecture does provide the scalability and flexibility for this unique challenge.

But microservice architecture is not without its share of challenges. The first challenge is for the Architects – it changes the way the architects typically think of system architecture and design and provides the first set of issues for them to resolve. This includes the following considerations:

• Composition of Microservice

Should every microservice have independent database making the service truly autonomous or should multiple microservices use a centralized database?

• Packaging and deployment of microservices

With multiple independent components, what would be a good deployment strategy for microservice-based application?

How Should I Design For Microservices?

Microservice design should make use of the DRY principle. Store information only once, and write code only once. Consider organizations that have multiple applications. With monolithic systems, there have been instances when every application replicated the user data (though some were smart to sync it with organization’s Active Directory, still had an independent copy in every application).

Soon, data between different applications got out of sync and it became an issue to track which application’s version of user data should be treated as true information. With a microservice-based design, you would encapsulate all the services around managing user data into a single service. This would include:

• Syncing up with the AD
• Single-Sign-On
• Managing user profile and user database

All other applications would use the REST/SOA APIs exposed by this microservice to deal with user-related services and activities like signing into an application, getting the user profile with appropriate roles and access controls etc. As there is only one microservice that deals with the user profile, the user data need not be replicated for every application.

There is one challenge with this approach and that is maintaining referential integrity with user table if an application needs it. Since the user database is segregated to the user microservice, managing the referential integrity becomes the task of the application that needs this (since the database can no longer maintain this due to segregation).

Having said that, with the database being protected behind application facades, this should hardly be an impediment in the adoption of microservices as the benefits of segregation outweigh the need for referential integrity.

There is another challenge with such centralizing of services – if too many applications are using the same user management microservice, would this not overload this component? And our answer to this lies in how we design the scalability factor for this service.

We can deploy this microservice as a clustered service and use intelligent caching mechanisms through a distributed cache system like Hazelcast to mitigate this issue of overload. With auto-deployment tools like Kubernetes which can handle auto-scaling of microservices at the VM level, this hardly becomes an issue.

This is exactly where the role of the Architect becomes critical. The burden is on the team to design the composition and the deployment and scaling strategies for various microservices that would strike a balance between modularity, reusability, and performance.