The course is part of these learning paths
Azure Compute Infrastructure
Microsoft Azure offers services for a wide variety of compute-related needs, including traditional compute resources like virtual machines, as well as serverless and container-based services. In this course, you will learn how to design a compute infrastructure using the appropriate Azure services.
Some of the highlights include:
- Designing highly available implementations using fault domains, update domains, availability sets, scale sets, availability zones, and multi-region deployments
- Ensuring business continuity and disaster recovery using Azure Backup, System Center DPM, and Azure Recovery Services
- Creating event-driven functions in a serverless environment using Azure Functions and Azure Log Apps
- Designing microservices-based applications using Azure Container Service, which supports Kubernetes, and Azure Service Fabric, which is Microsoft’s proprietary container orchestrator
- Deploying high-performance web applications with autoscaling using Azure App Service
- Managing and securing APIs using Azure API Management and Azure Active Directory
- Running compute-intensive jobs on clusters of servers using Azure Batch and Azure Batch AI
- Design Azure solutions using virtual machines, serverless computing, and microservices
- Design web solutions using Azure App Service
- Run compute-intensive applications using Azure Batch
- People who want to become Azure cloud architects
- People preparing for Microsoft’s 70-535 exam (Architecting Microsoft Azure Solutions)
- General knowledge of IT architecture
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 Container Service and Azure Service Fabric.
Azure Container Service supports the popular Kubernetes, DC/OS, and Docker Swarm orchestrators. It’s pretty clear that the future of container orchestration on Azure is with Kubernetes, though, because Microsoft has a new container service in preview called Azure Kubernetes Service and Microsoft is already saying that it’ll be the preferred solution.
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 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.
About the Author
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).