Another revolution in software development is the move to microservices. Traditionally, applications have been written in monolithic fashion, where all of their various functions are tightly coupled in a single stack. The advantage of this approach is that it’s easy to manage a single, self-contained application. It also tends to have relatively high performance because the components inside the application communicate very quickly with each other.

But there are many disadvantages to this approach. The biggest one is that you can’t easily make changes to a monolithic application. If you need to make a change to a single component, then you have to retest and redeploy the entire application. That’s a big problem, especially if you’re trying to use an agile development methodology.

The microservices approach solves this problem by breaking an application up into numerous independent components. Then if you need to update a single component, you can do it without having to update all of the other components. This is only possible if you have a well-defined interface for calling that microservice. As long as you don’t make a breaking change to a microservice’s interface, then other microservices can continue to call it in the same way, even after an update.

Another advantage of microservices is that you don’t need to use the same programming language or supporting software for all of them. Since microservices communicate with each other through language-independent APIs (usually REST APIs), you’re free to choose whatever technologies you’d like to implement a particular microservice. It’s usually better to choose a few standard technologies, though, so you don’t end up with a patchwork quilt that’s difficult to support.

The biggest downside of the microservices approach is complexity. It’s harder to get a coherent view of an application when it’s so fragmented. These applications may also be slower since the services communicate with each other over longer distances and through more layers. This complexity makes management much more difficult. How do you handle deployment, monitoring, and availability when your application is spread out all over the place?

Luckily, there are some very good solutions. First of all, containers are almost a requirement for implementing microservices. Using VMs alone would be far too expensive and difficult to manage. Containers run on top of VMs and only include the software sitting on top of the operating system, so they’re smaller and can be deployed much more easily.

Azure provides several alternatives for creating and managing containers. The simplest is Azure Container Instances. If you want to deploy a single container quickly, you only need to specify a few details like the number of cores and the amount of memory. Container Instances will take care of the rest and spin up a container for you in seconds. It’s a pretty limited solution, though.

To implement microservices effectively, you need full container orchestration and scaling. Microsoft provides two alternative services for this: Azure Kubernetes Service and Azure Service Fabric.

Azure Kubernetes Service supports the popular open-source Kubernetes container-orchestration system.

Azure Service Fabric is Microsoft’s proprietary container orchestrator. It powers a wide variety of Microsoft services, including everything from Power BI to Cosmos DB.

And that’s it for microservices.