Posted in:

I've been a bit quiet on this blog recently mainly because I've been busy working on a new Pluralsight course Microservices: Architectural Strategies and Techniques, which essentially replaces my previous Microservices Fundamentals course, although they cover slightly different topics. In this course, I wanted to make sure I addressed some of the "pushback" against microservices, as it's fair to say that there has been some legitimate questions asked about whether microservices are being applied to problems where they don't actually help.

However despite their challenges, I do think there are situations in which microservices can make a lot of sense. And that's because when a software product becomes large enough, with many teams of developers, and many user-facing websites or applications, and many APIs, then it's inevitable that it becomes a distributed system.

In some ways you can think of microservices as simply a more disciplined approach to distributed systems, where you take care to ensure that each service is independently deployable. This helps you avoid the pitfall of building a "distributed monolith" - an architecture famous for combining the worst aspects of both monoliths and distributed systems.

In fact, the majority of the tools, techniques and strategies I discuss in the course are not strictly specific to microservices. That's because most of the key concerns about observability, security, scalability, testability, automated deployment are things that you'll need in a distributed system regardless of whether you are explicitly trying to create "microservices".

Are Microservices Becoming Easier?

One of the hopes in the early days of microservices was that over time, we'd develop tooling that helped us overcome many of the challenges of building, testing, and deploying distributed systems.

In some ways that is true. For example, Kubernetes is incredibly powerful and flexible and has established itself as the de-facto standard for hosting microservices. However, I certainly wouldn't describe it as simple to learn and manage. But we are seeing the emergence of simplified microservices hosting platforms, such as Azure Container Apps which is built on top of Kubernetes, but takes away a lot of the complexity and streamlines the process of hosting your microservices.

Another favourite toolkit of mine for building microservices is Dapr, which offers a set of "building blocks", to enable you to build secure and reliable microservices. I've actually created a Dapr Fundamentals Pluralsight course. The way Dapr delivers these capabilities is by exposing APIs from a sidecar container. This approach has the benefit of making Dapr programming language agnostic, and cloud-agnostic as the building blocks each offer a variety of backing services to implement the capability, giving you a lot of freedom to use the languages and services you are familiar with.

In the .NET world, .NET Aspire aims to improve the experience of building microservices by providing various tools, templates and packages that especially enhance the local development experience. So it does feel like things are moving in the right direction towards simplifying the overall microservices experience.

And in my Pluralsight course I also wanted to include a brief section exploring the ways in which AI is able to streamline the experience of building, deploying and managing microservice applications. A lot of the pain points of microservices revolve around the complexities of managing a system made up of so many interconnected parts. It's still early days for AI, but I am hopeful that it could make a big difference especially in the area of monitoring and troubleshooting distributed systems.

Summary

Microservices remain an valuable architectural pattern, despite the potential troubles you can run into with them. Generally, my architectural preference is to keep things as simple as possible, and only reach for more advanced patterns and tools when you have proved that you really need them. So most of the tools and techniques I show in the course are not so much a prescription of what you should do, as suggestions for things you might reach for if you're experiencing the problems they're designed to solve. If you're a Pluralsight subscriber, why not check out my Microservices: Architectural Strategies and Techniques course, and as always I'm very interested in learning from other people's experiences so do feel free to get in touch via the comments.