I have apis written in asp .net core which can be easily containerized, i want to deploy these apis in azure app service, but i am not able to decide whether i should containerize these api and deploy as containers in web app or i can deploy directly as code, On what basis this can be decided i see that App service gives scale out capacity for both way of deployment and other factors like continuous deployment also look same , so how shall i decide which approach to take , or it really doesn't matter in this case?
In my opinion since container is buzz word doesn't mean we definitely need to use it , unless we have very specific reason to. Containers have picked up reputation after since microservice architecture has gained popularity and in that case it works great.
Use Web App for Containers when
You are trying to package application where dependencies (run-time , tooling etc) are required and critical , so you can bundle them up.
You want to become cloud agnostic. Containers are best way to switch to other cloud provider e.g. AWS if you have to without making any code changes.
Lift and shift scenario where you want to move old/legacy code to cloud.
At some point in future you intend to use API as Microservice and that would require the service being used with orchestration service like AKS (Azure Kubernetes service).
Some advance cases where you want to run containers as serverless to deal with spikes
(Container Instances e.g.)
You are well aware of containers debugging, ports etc and how they work.
Any other case i would rather stick to App Service as code deployment. You need to aware containers are good but it can be overhead if you don't know how to deal with them.
Related
I am facing the following problem: I need to execute on-demand long running workers on Azure VMs. These workers are wrapped in a docker image.
So I looked at what Azure is offering and I seem to have the following two options:
Use a VM with docker-compose. This means I need to be able to programatically start a VM, run the docker image on it, and then shutdown the VM (the specs we use are quite expensive and we can't let it run indefinitely). However this means writing orchestration logic ourselves. Is there a service that maybe we could use to make life easier?
Setting up a k8s cluster. However, I am not sure how pricing works here. Would I be able to add the type of the VMs we use to the cluster, and then use the k8s API to start on-demand containers? How would I get priced in this case?
If the only thing you need are workers, there are a few more options you have. Which service suits best depends on the requirements you have. Based on what's in your question, I would think one of the following two might fit best:
Azure Container Instances
Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.
Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs.
Azure Container Apps (preview)
Azure Container Apps enables you to run microservices and containerized applications on a serverless platform. Common uses of Azure Container Apps include:
Deploying API endpoints
Hosting background processing applications
Handling event-driven processing
Running microservices
According to Azure's Container services page, here are your options:
IF YOU WANT TO
USE THIS
Deploy and scale containers on managed Kubernetes
Azure Kubernetes Service (AKS)
Deploy and scale containers on managed Red Hat OpenShift
Azure Red Hat OpenShift
Build and deploy modern apps and microservices using serverless containers
Azure Container Apps
Execute event-driven, serverless code with an end-to-end development experience
Azure Functions
Run containerized web apps on Windows and Linux
Web App for Containers
Launch containers with hypervisor isolation
Azure Container Instances
Deploy and operate always-on, scalable, distributed apps
Azure Service Fabric
Build, store, secure, and replicate container images and artifacts Azure
Container Registry
EDIT:
Based on the comment
Let's say the only requirement is that I am able to use the resources on-demand, so I only end up spending the amount of money that would take for a certain job to finish execution. What would you use?
the answer would most probably be Container Apps, if the code you have available is not easily migrated to an Azure Function. The most important reason: they are Serverless, which means they scale to zero and you only pay for actual consumption. Next to that, you have to write limited to no orchestration logic, since the container apps can scale based on event sources.
Enables event-driven application architectures by supporting scale based on traffic and pulling from event sources like queues, including scale to zero.
Another great resource is Comparing Container Apps with other Azure container options.
I have an ASP.NET core 3.1 based web api ready to deploy to Azure for production use. For test / development, I have been deploying it to a traditional app service on Azure which I believe is a shared Windows VM under the hood. I have been on F1 tier and it suits my needs for test and dev.
But for production, even the cheapest plan costs me $93.44 per month which I would like to avoid if I can.
In order to lower the cost, I have decided to containerize my app and deploy it using "web app for containers" or "azure container instances". My question is, based on your experience, which method will give me reasonable production-scale performance while minimize my monthly cost? Or would containerize my app save me any money at all?
Please note that I have evaluated Azure Functions and decided it is not what I would like to use.
For your requirements, first of all, you need to know that the Azure Container Instance benefits for its quick start and running. See this:
Azure Container Instances is a great solution for any scenario that
can operate in isolated containers, including simple applications,
task automation, and build jobs.
It's good for the simple application, but not good for scenarios where you need full container orchestration, including service discovery across multiple containers, automatic scaling, and coordinated application upgrades. And I think it's also not stable for the production use, it's more appropriate for the test.
And the Azure App Service is cost according to the service plan, the service plan billed on a per second basis. You can plan the use with time as you need and the App Service has more features than Container Instance. Or if you do not satisfied with App Service, maybe you can take a look at the Azure Kubernetes Service, it has more control and feature then the Container Instance.
As of beginning of 2022 looks like Container Instances and Web Apps for containers will be the same ~32eur which is a bit better than the app service ~50eur.
Recently I've started experimenting and getting familiar with some of the Azure offerings. I made a simple app, connected it with azure functions and azure storage as well as some other offerings like service bus for example.
So far so good, the app is working great and I got my feet wet with some great Azure services.
But now I'm unsure on how best to proceed because what I have so far is a development version of my app. If I wanted to make a prod version do I have to provision a different set of all the azure resources used for the dev version?
So basically, I would have mydevsite.azurewebsites.net and myprodsite.azurewebsites.net. Is this correct? I can restrict mydevsite.azurewebsites.net with some IP address restrictions so that is not publicly available but I still feel this is a hacky way of doing this and that there should be a better way.
Is there a common approach to a scenario like this?
This is a bit of a broad question, but I can tell how I have done it before.
A common setup would be three environments, Dev, Test and Production.
Dev mostly runs on the developer's machine (as much as it can). We use a local IIS installation to run the web app, and a local SQL Server as a database. Azure Storage and Cosmos DB can also be emulated locally. Certain services like Search for example can't be run locally so you would have to run those in Azure anyway.
Test and Production are basically two identical resource groups with the same resources, just configured slightly differently. So double the App Service Plans, SQL databases etc.
Depending on how you want to do it though, you can of course share resources across environments. But it is a good idea to somehow make sure they do not accidentally use the other environment's stuff. And the definite bad side of this is that you are putting production data in the same place as test data, which frankly should not be together.
I know some organizations run a Dev environment fully in Azure. There can be a couple reasons for this: very heavy environment which can't really run on dev machines, or they want to test ARM template deployment at dev stage too.
Having duplicated services allows you to use ARM templates for automatically deploying and updating the infrastructure, which is pretty nice.
If you are on Standard or higher, you might think to use Deployment Slots in App Service for different environments, but they are really not meant for that purpose. We use them to reduce application downtime when deploying a new version, and as a fallback if the update turns out bad. So the deployment goes to a "staging" deployment slot, which gets swapped with the other one, and the new version is live. We then stop the deployment slot so we are not running the older version in the background unnecessarily.
But otherwise we have a separate App Service Plan with separate Web Apps with their own staging slots.
Deployment slots documentation: https://learn.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing
I'm pretty new to Azure, so for the sake of learning, I have deployed Node.js applications in Azure both as Docker containers and Azure web apps on Linux. Since Azure web apps are containers anyway, is there any good reason why I should use them instead of my own containers, which I have better control over?
One problem I stumbled upon was that you have to take quite a few things into account with the preconfigured containers in Azure web apps, some of that described here. If I instead use my own Docker containers, I don't have to take the extra steps that are sometimes required to get your Node.js application with its dependencies up and running as an Azure web app.
Am I missing something, or is it as it now seems to me, less work to deploy my apps in Azure as Docker containers?
Sebastian
I am not 100% sure but I think there is a difference in the security updates of application SW (e.g. NodeJs). When you use a custom docker image you might be responsible for keeping the containers up to date.
I have been busy breaking up a monolithic service layer into about 30 small 'chunks' that can be independently deployed (C#, web API).
At the same time, we are moving to Azure.
How should these microservices be deployed?
We need 4 environments (devint, QA, UA and Prod) so we were going to use 4 slots per PaaS, and a new Paas for every microservice.
But this would get expensive and hard to manager.
Are there better approaches? (I know little to nothing about Azure so any help is appreciated).
Thanks
Azure Service Fabric is built for Microservices, and would likely be the best option to go with. Especially for forward thinking when running on the Azure platform. However, depending on your time line the fact that Service Fabric is still in Preview may be an issue. Azure features in Preview don't have the full SLA guarantee that they will when made Generally Available (GA).
The simplest hosting solution to use for Microservices in Azure App Service would be to deploy the different services as Web Apps, possibly using Web Jobs for any background processing. Web Apps and Web Jos work extremely well for building Microservices, and I have used this approach on projects in the past.
Regarding you comment about "4 slots". If you are referring to Web App Deployment Slots, then you will want to reconsider having 4 deployment slots of the same Web App to host your different environments. Especially in Production, there should be a Deployment Slot used for the Live Production instance, and one slot for a Staging area used for testing deployments before swapping them. When it comes to Dev/Int, QA and UAT then you'll want to have 1 or more Web Apps with necessary Deployment Slots to fit your needs. The last thing you want to do is mix up your Dev/Int, QA, UAT and Production environments. It's also very important to understand that all the Deployment Slots for a single Web App run on the exact same Virtual Machine; which means if you have all 4 environments as Deployment Slots then your Dev and QA environments could affect the performance of Production; which would be horrible.
You should consider using Azure Web Apps to host your chunks because it doesn't require any customization of the API or Websites you code (unlike Cloud Services which have their packaging and deployment format). The same WebDeploy mechanism will work on any IIS server (on your own server, AWS or Azure)
Take a look at Azure Resource Manager (ARM) to define the underlying resources such as the hosting App service plan (equivalent to a web server), web apps and databases. You will in all likelihood have the same set of resources in each environment and different configuration (such as different API URLs) or minor tweaks (such a premium SQL plan or larger/more instances of the web applications). ARM template can thus be shared across the 4 environments with each environment having its own ARM parameter file.