The topic of microservices architecture comes up often in our discussions with clients. There’s a lot of interest but also confusion. What is it? How small or large does an application need to be to use it? When should you use microservices architecture to build an application?
Here’s the short answer. This is a very complex topic—far bigger than we can cover in one blog post. So we’re starting this microservices “miniseries” to provide some insight from our experiences and to get more discussion going on this topic. This first post addresses a bit of the “what” and the “why.”
What is microservices architecture?
A lot of discussion about microservices architecture seems to center on specific technologies. But microservices architecture isn’t really about the technologies at all—it is about the core principles involved for delivering focused, isolated services that allow flexibility and evolution in your architecture.
To understand microservices architecture, it helps to start by thinking about the traditional way of building a large software system—for example, an online retail e-commerce presence. This system requires an array of functionality: searching for products of interest, checking available stock, processing credit card or other forms of payment, managing user accounts and profiles, making recommendations based on previous purchase history, applying promotional codes or coupons, presenting shipping options, accumulating loyalty points, allowing one-click ordering, calculating the taxes on orders, and so on. Each of these is a discrete “service.”
Traditionally, such a system has been built on a single software architecture that encompasses all of the services required to complete a business process—in this case, making an online purchase. This approach is often lovingly referred to as “monolithic or a “big ball of mud”. While this may be easier to deploy it’s more difficult to evolve. For example, updating the sales and use tax rules to comply with new regulations would require the entire system be updated and deployed, which is more disruptive to the system as a whole. Given the complexity of such systems, it can take a long time to complete and test certain new features or products. That’s why you’ll often hear that it might take many months to “go live” with a seemingly small feature.
But we live in a world where business is changing faster than ever. There are more regulatory changes, new and evolving customer demands, and more pressure to make system changes quickly. This is hard to do with a system developed on this type of monolithic architecture. So the questions start rolling in: How can I upgrade my application without having to make a major additional investment? How can I add this specific feature without breaking the application? How do I respond to a regulatory change without impacting how the system runs today? How can I scale certain functional areas of the system independently?
Microservices architecture seeks to address these questions by breaking a down the application into numerous small, well-defined services that run independently of the other services that are part of the system. This architecture is typically deployed and supported in a highly automated fashion to lower the maintenance and reduce the risk of human error causing outages.
These are key characteristics of microservices architecture:
- It is isolated from other services that comprise the larger application; for example, in our e-commerce example, tax processing, search functionality, and customer profile management would be built as separate services. This isolation extends from the platform to the database – meaning the service doesn’t share the same database with another service – and is often deployed using containers provided through a solution like Docker.
- From a business perspective, the functionality usually is focused on a specific task or feature, and the service is developed in a way that allows the system to perform that task or feature very, very well.
- There are clear boundaries between the service and other services, including clearly defined interfaces and communication patterns that change infrequently.
When and why is it beneficial?
Isolating a service on its own architecture enables developers to build, test, and release a new feature—for example, a new customer-facing program for accruing loyalty points for purchases—without having to touch other core elements of the system, such as credit processing. Moreover, the developers have the flexibility to use the best tools and technologies for the particular business need rather than working under constraints of the larger system. This isolated environment facilitates fast prototyping and agile development, which in turns can accelerate the path to addressing customer demands or introducing a new product.
In the same vein, you can upgrade or change features—for example, changing tax processes to comply with updated state and local sales tax regulations—faster and without having to touch and potentially compromise other elements of the system.
Microservices architecture also is useful in situations where you need to scale certain system features but not others; for example, product search and check-out/purchase features on Black Friday, when sales volume will be 10-times that of “normal” shopping days.
There are also benefits from a resource management perspective. For example, IT and engineering functions can build smaller and more efficient teams to focus on solving a specific business problem by building new microservices. In addition to accelerating development, this structure also can promote greater innovation given the lack of constraints compared to a traditional monolith. It allows companies to venture into new business territory and test new models more quickly without impacting the current state.
A few caveats before you jump in
Microservices architecture is certainly a hot topic—and for good reasons. If your business environment is dynamic and requires frequent or rapid systems and software changes, then this is an approach you should be considering if you aren’t already. But it isn’t an “either-or” solution applicable in every circumstance.
It is important to understand that with the benefits come a few added challenges. For example, while microservices architecture can help simplify and speed up development and testing, it doesn’t necessarily simplify architecture. In fact, it may require more complex integration and communication among services, and that requires proper planning, design, and management. Certain quality-of-service attributes, such as resiliency, become more important. If you don’t automate and monitor those connections properly and have a team prepared to manage the overall architecture, you can end up with a real maintenance challenge on your hands. Finally, there will be new frameworks and architectural patterns for your teams to learn in order to effectively build systems in this new architectural style.
We have found it helpful to start small, experiment, and be willing make a few mistakes from which you can learn—without disrupting key systems and your business. We will begin to get into some of these issues and some best practices in the next post in this “microservices miniseries.”
We look forward to some robust dialogue around this topic and encourage your thoughts and questions to spur that discussion.