Deployment & Configuration options in Azure
Microsoft Azure
Microsoft Azure, formerly known as Windows Azure,which is Microsoft’s public cloud platform. It provides a wide range of cloud services, analytics, including compute, analytics and storage. Users can choose from these services to develop and scale new applications or run existing applications in the public cloud.
The Azure cloud platform has more than 200 products in the market and cloud services designed to help us bring new solutions to life and more over to solve the challenges of today and create the future. Build, run, and manage applications across clouds, on-premises, and at the edge with our choice of tools and frameworks.
How does Microsoft Azure work?
Once customers subscribe to Azure, they have access to all the services included in the Azure Portal. Subscribers can use these services to create cloud resources such as virtual machines and databases. Azure resources and services are then assembled into running environments used to host workloads and store data.
Azure Cloud Deployment Options
Microsoft Azure is a great platform to use and has many services and features. But how to proceed when deploying applications to the cloud and using them? There are several different options for deploying applications in the Azure cloud, and which one you use and where you run it depends on the amount of control and portability you want. In this article, we’ll look at some key concepts and the 4 primary Azure deployment models.
A. Key concepts
Trigger syncing and the Remote build are the key concepts which helps to understand how deployment works in Azure.
1)Trigger Syncing
When you change any of your triggers, the function infrastructure needs to be aware of the changes. Synchronisation occurs automatically for many deployment technologies. However, in some cases you need to synchronise the triggers manually. When you deploy updates by referencing an external package URL, local Git, cloud sync, or FTP, you must synchronise the triggers manually.
The triggers can be synced using :
- Restart your function app in the Azure portal.
- send an HTTP POST request to https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{functionAppName}/syncfunctiontriggers?api-version=2021-02-01. You’ll need to replace {subscriptionId}, {resourceGroupName}, and {functionAppName} with appropriate values for your Function.
2)Remote Build
Azure Functions can automatically perform builds on the code it receives after zip deployment. These builds behave slightly differently depending on whether your application is running on Windows or Linux. Remote builds are not performed if the application was previously set to run in Run from Package mode.
B. How to run application in azure cloud
There are four main ways to deploy our applications in Azure:
- Service Fabric
You can deploy your applications inside Azure Service Fabric. This is the ‘magic’ layer that has powered services like Azure SQL Databases and App Services for years, and is now available for you to use yourself. When you deploy your application to Azure Service Fabric, it is automatically load balanced. It becomes self-healing. It scales automatically. It is highly available. And when you deploy a new version of your app, it upgrades seamlessly and you can rollback.
Azure Service Fabric is usually marketed to run a micro services architecture, which is really good. However, setting up a service structure and running applications within it is not a trivial task. You really need to know what you’re doing, and that makes sense for the amount of magic you get out of it. You can run the Service Fabric framework anywhere.
2. Virtual Machines
When you need a lot of control, or when you’re lifting and moving applications to the cloud, you can run them in virtual machines. You can install everything you need to run the application on the virtual machine. You are able to control everything from the operating system to the antivirus.
Virtual machines are booted using images that describe everything that is installed on the virtual machine. You can also use them locally and on your own computer, but getting them to the cloud is a relatively slow process. They provide not only flexibility but also complexity.
3. Containers
Like virtual machines, we can use containers when you need a lot of control. They allow us to install any software we need to run applications, and they are much faster to deploy than virtual machines. Containers can be spun up and running in seconds, which is useful if we want to spin one up for testing and then get rid of it. In Azure, we can run containers on many different services. Microsoft wants us to eventually be able to use containers for every scenario. We can run containers in Azure in Azure Container Service, Azure Container Instances, Azure Service Fabric, and Web App for Containers.
This can help you understand which Azure service is right for your container needs:
4. App services
When you don’t need full control and just want to focus on building your app, you can run your app on Azure App Services. You can simply deploy your app to App Services and it’s up and running, you don’t have to worry about the operating system or antivirus. There are several types of App Service: Web Apps, Mobile Apps, Function Apps and Logic Apps.
The main advantage of using App Services is that they offer a lot of additional features such as auto-scaling, authentication, and deployment slots. These are all Platform-as-a-Service providers. The downside is that you have no control over the things that are installed in the environment. You cannot access or install anything on the core servers.
C. Where to Run Your Applications?
The options you have to run applications in the cloud can sometimes be used to run applications on-premises or in non-Azure clouds. Being able to run only in Azure is not always the best choice and sometimes you need to combine it in a hybrid way.
Azure Stack
In addition, there is Azure Stack, which was recently made available. Azure Stack is Azure in a box. You buy it and put it in your own data center and run Azure on-premise. It is an extension of the public cloud over which you have full control.
The idea is that you can run any Azure service on Azure Stack and that it’s exactly the same as a public cloud offering. This allows you to host services and data that must be on-premise in your own data center, with the option to move them to the public cloud later. However, Azure Stack is still evolving and you can’t run all Azure services on it yet.
Azure Cloud Configuration
Cloud applications often run on multiple virtual machines or containers in multiple regions and use multiple external services. Building a robust and scalable application in a distributed environment is a significant challenge.
A. Why to use azure configuration
App Configuration makes it easier to implement the following scenarios: Centralize management and distribution of hierarchical configuration data for different environments and geographies. Dynamically change application settings without the need to redeploy or restart an application.
B. Applications that benefited by configuration
Microservices based on Azure Kubernetes Service, Azure Service Fabric, or other containerized applications deployed in one or more geographies
C. Benefits of azure configuration
- A fully managed service that can be set up in minutes
- Flexible key representations and mappings
- Enhanced security through Azure-managed identities
- Encryption of sensitive information at rest and in transit
- Native integration with popular frameworks
D. Some scenarios
- Centralize management and distribution of hierarchical configuration data for different environments and geographies
- Dynamically change application settings without the need to redeploy or restart an application
- Control feature availability in real-time
Contributors
Mayuri Jaigude
Rohan Katkar
Sanket Kawade
Abhita Lakkabathini
