• Tweet

• Tweet

Four common techniques for performing compute in Azure: 

• Virtual machines 
•  Containers
•  Azure App Service 
•  Serverless computing 

Ranking from top to bottom, users are getting less control over the service orchestration, but more concentration on application related logic. Thus, virtual machines and containers are not candidates for hosting workers. Before we get to our final choice, we would first go through these technologies to contrast and compare them. 

Azure Virtual Machine is a service where users build computing environments for their applications. It uses the following features to ensure availability, scalability, and redundancy. 

•  Availability sets (for availability and redundancy) 
•  Virtual Machine Scale Sets (for scalability and responsiveness) 
•  Azure Batch (for scalability and low latency) 

Azure provides 2 services to manage containers, users can use these services to deploy their containers on the fly. 

•  Azure Container Instances (ACI) 
•  Azure Kubernetes Service (AKS) 

But to have the application work in the network system, users need to build the server environment, so these 2 services are not out-of-box options for hosting an application. We would move forward to the other options. 

• “Lift and shift” is a strategy for migrating a workload to the cloud without redesigning the application or making code changes. Also called rehosting.  
• Cloud optimized is a strategy for migrating to the cloud by refactoring an application to take advantage of cloud-native features and capabilities. 

Azure App Service enables 4 types of app services hosting.

•  Web Apps 
•  API Apps – One can build REST-based Web APIs using their choice of la nguage and framework.   

•  WebJobs – WebJobs are often used to run background tasks as part of your application logic. They can be scheduled or run by a trigger. 

•  Mobile Apps 

API Apps or WebJobs could be a type for worker. App Service is not for microservices, which means that when it is scaling for increasing, it would scale up the whole application, but not the service part that is called.  And such monolithic application would induce some constraints on continuous deployment. So,  to factor the code into microservices structure such that  future updates could fit into such a structure, you might need to consider other options. 

Before heading to a complete out-of-box alternative, there is a service that sits in the area of microservice but less abstraction. 

Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices and containers.   

Users would need to build a cluster to host the application, Service Fabric takes care of the orchestration, but configurations need to be specified by the users to work on demand. And using the microservices structure, each service scales independently. 

Serverless computing might be a better relief, it is the abstraction of servers, infrastructure, and OSs along with auto scaling. And users are simply working on the method calls for each trigger, so the scaling scope is still for independent function. 

Azure support 2 types of such service: 

•  Azure Functions, which can execute code in almost any modern language. Azure Functions can be either stateless (the default), where they behave as if they’re restarted every time they respond to an event, or stateful (called “Durable Functions”), where a context is passed through the function to track prior activity. 
•  Azure Logic Apps, which are designed in a web-based designer and can execute logic triggered by Azure services without writing any code. Logic Apps execute workflows designed to automate business scenarios and built from predefined logic blocks. 

Serverless computing is a good fit for workloads that respond to incoming events. Events include triggers by timers (for example, if a function needs to run every day at 10:00 AM UTC), HTTP (API and webhook scenarios), queues (for example, with order processing), and much more. And common functions could be called and utilized by other functions. 

But the limits of libraries/dependencies that functions support could be a hold-back to test code easily on the portal interface.