Author: Barry Luijbregts
With so many Azure services available to run applications and store data, choosing the right service for the right project can feel overwhelming. Understandably, developers have questions!
In our recent webinar, Discover the right Microsoft Azure service, Microsoft MVP Barry Luijbregts answered questions from attendees, but he couldn’t get to them all. So, Barry took five of those unanswered questions and provides explanations in this post. Dive in and explore which Microsoft Azure services can make your apps truly next level.
What’s the difference between Azure Functions and WebJobs?
The differences between Azure WebJobs and Azure Functions aren’t that big. Both are part of Azure App Service and are meant for running small pieces of code, and they can even be used as microservices. However, Azure Functions can scale automatically without configuration and run cost effectively— you can’t do that with Azure WebJobs. Let’s look at each in more depth.
Azure WebJobs
Azure WebJobs is part of Azure App Services. When you create one, it always needs an Azure App Service Plan, which is an abstraction of resources, like CPU and Memory. Running on an Azure App Service Plan means you pay for an Azure WebJob (the resources it runs on) all month, regardless of whether it executes. Running on an App Service Plan also enables you to scale. You can scale up or down or out and in (see Cloud Design Patterns for the Auto-Scaling Pattern). You can also scale automatically and manually. When you scale automatically, you have to configure the rules for scaling.
Azure Functions
Azure Functions live inside Azure App Services Function Apps, so they’re also part of Azure App Services. In fact, Azure Functions are built on top of the WebJobs SDK, so they can do the same things. There are ways you can call Azure Functions from external resources (triggers), and they enable you to read and write to and from external services, like Azure Storage (bindings). Functionally, they are similar.
Advantages of Azure Functions:
- Running on top of an Azure App Service Plan (but they don’t have to)
- Running in “consumption mode,” which is a serverless mode
- In consumption mode, you pay only when the Function is executed (and a little for the Azure Storage account it uses for management)
- Scale automatically in consumption mode (spin up Function instances for as many Functions as are triggered, and those will go away when they’re done executing)
What does “multi-model” mean in regard to Azure Cosmos DB?
Azure Cosmos DB is the evolution of Azure Document DB. It’s a NoSQL datastore that supports multiple ways of storing your data. When you use Cosmos DB, you need to indicate what type of API you want to use (MongoDB, Graph, SQL, Table and so on). This choice determines how the data is shaped and stored in the underlying data storage mechanism. This is the multi-model part of Cosmos DB. It supports multiple data store models depending on the API you choose. If you choose the Graph API, you use a Graph data model. If you use the Table API, you use a key/value data model.
How do you replace BizTalk orchestration in Azure?
Typically, Microsoft-based companies use BizTalk for integration tasks. The equivalent in Azure is Azure Logic Apps. There used to be Azure BizTalk services, but that has been deprecated and enterprise integration features are now part of Azure Logic Apps.
What is a Logic App?
A Logic App is basically an orchestrator that is triggered by something (a schedule or an external source like a new message on a queue), and then executes a complete process. Such a process consists of evaluating messages and calling APIs. Logic Apps provide many APIs to external systems like SAP and Dynamics out of the box, and have enterprise integration APIs that enable you to replace BizTalk functionality. You can also expose your own APIs and Azure Functions so they can be used by your Logic App.
Benefits of Azure Logic Apps
The cool thing about Azure Logic Apps is they’re serverless. They only run when triggered, which means you only pay for them when you use them. And they scale automatically without having to configure anything. Logic Apps are a hidden gem in Azure and you should know about them.
How do you plug Azure services into existing applications?
Even if your application is not running in Azure, you can use Azure to make it more intelligent and reliable. Services like Azure Backup and Azure Site Recovery ensure your application and files are always backed up, so you can recover quickly after failure.
Intelligent services, like the Azure Cognitive Services, add AI capabilities to your existing application. This is really easy to do as the Cognitive Services are just APIs that you call. Some of them help you identify people, faces and other things in images and videos. Others help you with search and text translation. There’s a whole world of capabilities out there. (You can learn more in this course: Azure Cognitive Services: The Big Picture.)
Should I use containers in Azure for my application?
Containers are much better than Virtual Machines in many ways. They’re faster and more lightweight, and they’re great for running applications anywhere: on your local machine, in the cloud and in your on-premise datacenter. They provide an environment that is always the same and moves through your CI/CD pipelines, which reduces errors and can increase your rate and the reliability of deployments.
Containers, like VMs, still fall under the infrastructure as a service (IaaS) umbrella. Although containers run an abstraction of an operating system, you’re still responsible for making sure the OS is up to date and secure. You’re also responsible for things like load balancing, network setup and security and so on. Azure provides many mechanisms to run containers, such as:
Some of these services allow you to run containers only on Linux, while others already support Windows containers. And some of them come with - container orchestrators, like Kubernetes.
Containers: What else you should consider
Modern solutions often consist out of many services, like microservices. To get all of these up and running and communicating with each other, you need a container orchestrator. There are many flavors out there, like Kubernetes, DC/OS and Azure Service Fabric (which has its own orchestrator). These make provisioning and scaling containers much easier, but keep in mind that we’re still in the early days for these container orchestrators, and they tend to change nearly every week.
In contrast, you can also run your applications in something like Azure App Service. This provides you with a lot of extra features, like deployment slots, easy authentication and authorization, hybrid connections and so on. And they just run, without you having to worry about load balancing or the operating system. However, App Service is an Azure service, and can’t run on-premises (if you discount running it on Azure Stack) or in other clouds.
Choosing the right Azure services
Learning to apply the right services to your application may seem like an art. It can take trial and error, discovery and practice. But uncovering the latest technology offerings opens the door to exciting new potential when it comes to the speed of your apps and the efficiency of your data storage.
Learn more about Microsoft Azure services—watch the on-demand webinar: Discover the right Microsoft Azure service.