Introduction
Microservices are a very common pattern in tech today. We suspect a fair number of readers will come to this article thinking, "I've heard this word a thousand times, but I'm not quite sure what it is or why it matters." Hopefully this article can help. It's an important theme to consider whether you're buying or building your policy software.
If you google "microservices Amazon story" today as I write this, you'll be inundated with hot takes from May 2023 about Prime Video actually abandoning microservices. That's a recent development, and pundits are still deciding loudly what it means. But the common story started more than twenty years ago, when Jeff Bezos sent out a memo to all teams at AWS, described in this fairly typical, thorough write-up from Nordic APIs.
In layman's terms, a microservices architecture means you break your system down into discrete parts. Those parts operate independently and communicate with each other via services. Services can be anything, though often they're REST APIs. What's important is that they're clear and well defined. You don't want the team that handles one part of the code base to have to dive into the internals of another team's code just to do their job.
The opposite of a microservices architecture is often called a monolithic architecture, or just a monolith. Monolith is a very evocative word for it; it means "made from a single block of stone." You're not building from independent parts, and it's much less flexible.
A related principle is that your UI should use those same services, and in a sense grow out from them. This stands in contrast to the much older pattern of offering a UI first, and then creating APIs after the fact as need arises. If you're doing it right, anything available in your UX should also be available in your APIs; the APIs are a first-class citizen along with the user experience. This is called an API-first approach. It's not the same as microservices, but they often go hand-in-hand. Swagger has a nice write-up on it here.
Benefits
A microservices approach enables the development of highly scalable, modular applications that can be rapidly built, tested, and deployed. A microservices architecture breaks down applications into smaller, independent components that can be developed and managed independently. It has several benefits, including:
Scalability
One of the primary benefits of microservices is scalability. Since microservices are independent components, they can be scaled up or down based on demand, allowing organizations to quickly and easily adjust to changing traffic patterns and user loads. This scalability also enables organizations to optimize resource utilization, reduce costs, and increase efficiency.
Flexibility
Another key benefit of microservices is flexibility. Since microservices are independent components, they can be easily replaced or updated without affecting the entire system. This makes it possible to rapidly develop and deploy new features and services, without having to worry about the impact on existing applications.
Customization
If you buy a platform based on a microservices architecture, it's much easier to develop your own custom microservices and deploy them within that platform's ecosystem. (InsureMO, for example, is built around this premise; see connectivity.) This customization enables customers to build highly specialized applications that meet their unique business needs, while still taking advantage of the platform's core functionality and infrastructure.
Efficiency
The use of microservices enables developers to work more efficiently, since they can focus on specific components rather than having to deal with the entire application stack. This approach allows developers to work more independently and make changes more quickly, resulting in faster time to market for new features and services.
(This is a big deal for your developers. Most folks who code have war stories of code bases that were too monolithic to wrap their heads around. If you talk to a develop who hasn't, they're either lucky or early-career!)
Modularity
The microservices architecture allows organizations to create highly modular applications, which can be easily maintained and extended. This modularity also makes it easier to reuse components across different applications, reducing development time and costs.
Building with microservices
If the idea of microservices is new to you, you have options. You can research the pattern, of course, with this article as a jumping off point and all of YouTube at your disposal. You can hire people well versed with the approach. Or—and this approach has been used successfully by many companies—you can start with more of a monolith, and break your code down into microservices later. You can even explore all of these options at once.
Buying with microservices
Many of the policy platforms we review here follow a microservices approach. In fact it's uncommon for someone to say they don't. But for all the reasons listed above, it's worth verifying.
Only two policy platforms we've reviewed so far, InsureMO and to some extent Dais, also allow third parties to develop, host, and deploy their own microservices within their system. This provides a highly customizable solution that can meet the needs of a wide range of customers. With the ability to rapidly develop and deploy new features and services, customers can stay ahead of the competition and deliver innovative solutions to their users.