Posted in:

I'm pleased to announce a new Pluralsight course - "Microservices Architecture: Executive Briefing". This is a short (30 minute) high-level overview of what a microservices architecture is, why you might want to use it, and some pointers on how to be successful with it.

It was also my first foray into live video recording. Unlike most Pluralsight courses, this one is mostly a video of me speaking (apologies for making you look at my face!) It was certainly a steep learning curve. I had to buy a fair bit of equipment including a new camera (I went for the Canon EOS 250D) and some video lights, and after several failed attempts I finally managed to get the desired level of image quality. I'm certainly no expert, so I'm sure there's a lot of room for improvement but I'm pleased with how it turned out in the end.

This course is aimed at executives and decision makers rather than at programmers, so I've kept things quite high level and focus more on the why than the specifics of how. I have a couple of other course in the library (Microservices Fundamentals and Building Microservices) that are much developer-oriented if that's what you are looking for.

In the course I try to answer seven simple questions. First, what are microservices? This question can be answered purely in terms of what it means from a software architecture perspective (that microservices are small and autonomous), but it is also important to understand that microservices are a way to scale teams. This point was excellently made by Brendan Burns recently in his talk at the recent .NET Focus on Microservices conference. I highly recommend you take some time to watch some of the sessions from that event.

Second, what problems do microservices solve? "Monoliths" are not necessarily bad, and may actually be the right approach in some circumstances, but the most common problem you can run into with monoliths is the problem of scaling. Again, this is not just scaling from a software perspective, but scaling your team so that many developers can worth together efficiently on the same overall product.

Third, how can microservices help? By breaking our system into microservices, there is a lot more freedom to evolve and upgrade those services independently, and for each one to use the right tool for the job.

Fourth, what does a typical microservices architecture look like? In this section I used the same eShopOnContainers reference architecture that I used in my Microservices Fundamentals course, to show some common patterns such as backend for frontends, and using an event bus for communication between microservices.

Fifth, what are some challenges of microservices? It's really important to understand that microservices don't magically make all your problems go away. In fact, they introduce some significant technical and operational challenges. Deploying and monitoring many small services is more difficult than deploying and monitoring a single monolith. And it can be difficult for developers who need to start many services to work on the system. Thankfully we have seen an explosion of new technologies and tools over the past decade explicitly designed to address these challenges. Which brings us onto...

Sixth, what tools and technologies do I need? One great thing about microservices is that they give you complete freedom to use whatever tools and technologies you want. It can even be different for each microservices. For example, one microservice might use a document database while another uses a relational database. But I do think containerization has established itself as the most appropriate way to package and deploy your microservices, and so I recommend Docker and Kubernetes.

Finally, how can I successfully lead a microservices project? This is where my "imposter syndrome" kicks in a bit. I obviously can only speak from my experience of transitioning towards microservices and so my suggestions and advice might not necessarily be relevant in all contexts. But in this section I do highlight the importance of a change of mindset throughout the company - it's not only about a new way of architecting software, but new approaches to team structures, releasing new versions and new skills needed to monitor applications in production.

I hope that the brief answers to these questions I provide in this course prove helpful to anyone considering whether to adopt a microservices architecture. And I'd love to hear your good (or bad) stories of how embracing microservices went for you. Learning from other people's success or failure stories can save a lot of wasted time and effort.