Improving Client Experience with Microservice Architecture
The speed of business continues to accelerate and technology is key to helping deliver more, faster. At HealthSparq, our technology utilizes a microservice architecture to enable the rapid, frequent and reliable delivery of our large, configurable health care applications for health plans, their groups and their members. At the end of the day, a microservice architecture helps us better serve our clients with higher reliability and responsiveness.
We didn’t always use a microservices architecture, but we’ve found that this architecture is beneficial because it uses relatively small, autonomous services that are built, tested, deployed and managed independently of other services. The transition to this approach has enabled our organization to deliver higher quality features more rapidly and enables automated scaling of microservices to match transaction volume. In this article, I’ll share some of the benefits we’ve realized with the use of microservices and some things to consider if you are interested in using this model at your organization.
Microservices vs Monolithic: Understanding the Architectures
With a traditional, monolithic architecture, the user interface, business logic and data interface are combined into a single, releasable application such as the one depicted in Figure 1: Monolithic and Microservice Architectures below. The application’s data stores typically contain data from multiple logical sources and are stored together for convenience. While this is a simple architecture, for applications of significant size, it impedes making rapid changes because the entire application must be built and tested regardless of the extent of any given set of changes. In addition, if one portion of the application incurs significantly more transaction volume than others, the entire application must be scaled up to handle the volume.
A monolithic application is also more difficult to maintain and extend because developers must understand it in its entirety. However, the larger and more complex an application becomes, the more difficult it is for a developer to understand it. Changes are riskier than if they could be made in a smaller context, which translates into a higher rate of defects and diminished user experience.
Contrast this with the microservice architecture example shown in Figure 1 below. Here functional pieces of the overall application are separated into multiple, smaller microservices, and the application is made of a user interface and backend services that run as individual services. Each service has its own business logic and data, and is built, tested and deployed separately. Builds run faster. It reduces the testing effort because each microservice is tested independently of the others. And, it can be scaled independently depending on its own transaction volume, reducing overall costs for running the application.
The Benefits of a Microservices Architecture
The primary benefits at HealthSparq include accelerating the delivery of high-quality features to our clients and ensuring availability via automated scaling to match demand. Applications designed using microservice architecture add flexibility in other areas as well, such as which programming language to use for implementation. For example, Microservice G may be written in Java, but Microservice H may be written in Scala or Go. This allows us to take advantage of different teams’ capabilities since you are not limited to a single, common language. In addition, since microservices are built, tested and deployed independently, teams can be geographically distributed without negative impact.
Instilling Microservices Into Existing Good Practice
While any architecture must accompany good software design practices, deciding what to put into each microservice can be challenging. Software design concepts you may be familiar with, such as encapsulation, loose coupling, high cohesion and separation of concerns, as well as design patterns, are as important for designing microservices as for any other design activity. Here are a few of the things to keep in mind when establishing a microservices architecture:
- Fully encapsulated: A microservice must own its own data and no other microservice should access it directly; for example, Microservice A’s data must be accessible only through Microservice A’s interface.
- Independently deployed: It is important to ensure that there is no order dependence when deploying microservices, i.e. Microservice C does not require Microservice B to be deployed first to successfully deploy Microservice C.
- Focus on interface design: As you might imagine, interface design is a key element for good microservice design. It is important to maintain backward compatibility when making interface changes because you cannot remove any particular interface until all other services using that interface have upgraded to its newer replacement.
- Advanced skillsets required: Developing and supporting distributed systems with microservices also requires more advanced skill sets compared to monolithic application development. In addition to fundamental software design principles and patterns, it is important to understand common microservice architecture patterns and when to apply them. Domain modeling, wherein an application models a real-world system, is a useful tool for identifying and assigning responsibilities within a distributed system.
- Keep a focus on security: Managing security is more challenging with a distributed architecture with distributed data, individual microservice configurations, Docker containers and the like. Understanding and implementing best practices for managing security are essential for protecting your data and ensuring availability of your applications.
It is important to have good DevOps automation in place for building, testing and deploying microservices. This isn’t easy, but there are more and more capabilities becoming available to help companies utilize DevOps effectively. HealthSparq has made a large investment in DevOps to ensure successful microservice deployments that, when combined with high-quality microservices, serve to meet the growing needs of HealthSparq clients.
If you’re interested in deploying a microservices approach, here are some useful references to learn more about the architecture:
- Microservices: a definition of this new architectural term, by Martin Fowler
- Architecting for Scale, by Lee Atchison
- Building Microservices: Designing Fine-Grained Systems, by Sam Newman
To understand more about the DevOps automation needed to support distributed applications, look for an upcoming blog on Continuous integration, delivery, and deployment, (CI/CD) considerations for monolithic versus architectures.