Microservice Architecture : Benefits and Challenges

What is a microservice?

Each microservice is a componentized (and ideally, stateless) service built around a single domain of business capabilities.  Whereas a monolithic application typically represents a tightly coupled, but ultimately “complete” solution:  The goal of a microservice is to encapsulate a small area of distinct and discrete functionality into a modular service that can be used in conjunction with other modular services to build whatever aggregate capabilities a business might need.  This is also the goal of a mini-service (another term you may have heard recently), but a purist approach to microservices favors an event-based communication mechanism and a publish-subscribe integration pattern.  The presence of a messaging queue (such as Kafka) is therefore implied and sharing of data internal to the service is discouraged.  Mini-services, on the other hand, may encapsulate more than one service domain and permit the sharing of data across these domain boundaries.  Mini-services also sacrifice the looser coupling of microservices in favor of more widely understood request-response messaging strategies like REST and SOAP.

2018 Gartner, Inc. and/or its affiliates. All rights reserved.

Why should I care?

Microservices are a proven and popular way of increasing the speed and reducing the cost at which innovation is delivered to the business.  They accomplish this by shortening the development and deployment lifecycles that turn requirements into functional business services.

What are the benefits of using microservices?

A properly designed, deployed, and managed set of microservices have a multitude of potential advantages:

1. Manageability: Loosely coupled microservices contribute to more manageable, less brittle solutions by permitting functionality to be introduced where it’s needed without impacting areas outside of scope.  A properly constructed microservice will expose a limited interface to other services (using a pub-sub messaging queue for purists [e.g. Kafka], but could alternatively use REST, SOAP, JMS, etc.).  It will also strive to not leak non-pertinent logic, data, or implementation details.  This means that internal functionality can be enhanced or corrected without any deleterious impact on the service’s consumers.  It also means that new functionality can be exposed in a manner which does not disrupt existing points of integration.
2. Shortened development and deployment cycles: Microservices have one area of compartmentalized, target functionality.  Size is the key to much of a microservice’s appeal.  By focusing on a relatively small functional domain the development cycle shortens and testing and deployment cycles shorten, enabling continuous delivery and allowing new capabilities to be brought to market faster.  Development agility + deployment flexibility = business agility!
3. Technology and geographical independence permit greater team autonomy. Polyglot development teams from different locales or with different skillsets and missions can work with the technologies most familiar to them and best suited to the problems they’re trying to solve.  For example, a .NET team in Geneva can create microservices using the language they prefer while benefiting from the functionality exposed by a separate, Java-based microservice created by a team in San Francisco; all thanks to microservice interoperability.  This further contributes to innovation agility by allowing the teams to operate within their respective areas of highest proficiency.
4. Low overhead and hyper-scalability: Microservices typically run as containerized applications, right-sized to their own specific requirements and with very little overhead.  Because an ideal microservice will never be granted more resources than it needs, considerably more processing power, memory, and storage can be liberated to run …other microservices!  This approach is also responsible for the high speed at which clustered copies of microservices can be deployed; allowing for hyper-scalability.
5. Resiliency and elasticity: Being able to quickly redeploy microservices and elastically scale them up and down also enables very high service resiliency (failure recovery).  A new instance of a microservice can be dynamically deployed to meet surge requirements, replace a frozen or broken running copy, or to phase in updates at a controlled pace.
6. High reusability: The modularity of microservices can make it considerably easier to combine pieces of data and functionality in ways that were previously not considered.  In other words, the high reusability of a well-crafted microservice means that it can be leveraged in a wide ranging and diverse set of workflows instead of being unreachable functionality embedded deep within a single monolith.

And all of this can be delivered in a cloud-native package!

 

What are the challenges of embracing microservices?

Choosing a microservice architecture can deliver a lot of benefits, but those benefits do come with a cost.

• Operational complexity is likely to increase
• New skillsets will be required by your development teams and your operational teams (including security)
• You will need to have a microservice-friendly infrastructure in place to support your new continuous delivery workflows.
• Latency will necessarily be introduced by the need to traverse the network in order to execute a complete workflow.

These requirements, coupled with new development and deployment paradigms, can add up to a lot of changes for your teams and your business.  It is a good idea to experiment with and refine some of these elements with one or more pilot programs before taking the full plunge.  You may ultimately decide that a hybrid approach (leveraging some microservices, some mini-services, and maybe even a monolith or two) is necessary to meet your business goals and give your teams time to establish and implement new best practices.

 

How do I get started?

1. Begin by reading the Twelve Factorsto see if you have the appropriate infrastructure in place.
2. Make sure you have appropriate DevOps technical resources, infrastructure, and workflows in place! These are obligatory if you want to capitalize on the real value of microservices (as further emphasized in step 3).
3. Identify a target for your first microservice. Ideal targets will offer completely new functionality with little to no dependencies on existing services or integration points.  They will also preferably be stateless (with no reliance on a datastore).  This will permit you to experiment in isolation not only with the microservice development process, but also with infrastructure changes, policy creation, developer and operations training, and the very important CI/CD pipeline.  Having a properly implemented CI/CD pipeline will be necessary to take the fullest advantage of the agility microservices can offer.
4. If you have one or more monolithic apps in place, try to avoid integration between the monolith and your new microservice(s) initially (you may decide later to start breaking these monoliths down, but this is a process that must be handled somewhat delicately). If there must be integration with your monolithic apps, be careful to keep your dependency on the monolith at the barest minimum.  You will lose the advantage of agility if your microservice is subject to the glacial pace of the monolith development cycle.

 

There are many other aspects of operational readiness which should be explored before diving too deeply into microservices, but they are beyond the scope of this article.  If you would like to consult with SmartWave, SA concerning our approach to microservices architecture, delivery, and management you can contact us here.  Please check back frequently for future articles on long term operational requirements, and deep dives into subjects like API management, service meshes, CI/CD pipelines, testing, monolith deconstruction, and message queues.