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.

Azure Service Fabric is quite flexible. Considering that it has Azure in its name, you might think that it only runs on Azure, but surprisingly, you can also run it on-premises on both Windows and Linux, and you can even run it on other cloud platforms like AWS. You can develop microservices that run on Service Fabric using any code you like. And you can develop both stateless and stateful microservices. It also provides application management and lifecycle capabilities. You can use it to deploy, monitor, and upgrade your applications.

When you start building microservices-based applications, you’ll quickly run into the problem of how to make these microservices accessible. Sure, you can create APIs for them, but should you let clients call those APIs directly? If you did, then the client code would have to know the architecture of your application, which would make it complex. Even worse, what if you decide to refactor your application? Would the client code have to change? Also, how would you handle security?

Fortunately, you can solve these problems by using Azure API Management. This service makes it easy to provide APIs that can be used by both internal developers and external partners and customers. It acts as a gateway between clients and your backend microservices. Not only does it provide an easily accessible front-end to your application, but it also handles important management tasks, such as security, monitoring, analytics, and rate limiting.

It’s easy to add an existing API to the API Management service. You only need to supply a few details, such as its name and URL. Then you can secure it and manage it. You can even transform your legacy APIs into modern ones that use REST.

And that’s it for microservices.