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
Related
Our company website will soon be hosted in an App Service in Azure. The website communicates with an API layer that also hosted in Azure and links to our internal systems and databases. The architecture at this level cannot be changed at this time and has quite a bit of background history, etc.
We are looking at implementing always on deployments using Deployment Slots in the App Service in Azure. The API layer will have non-breaking changes for each deployment and deploying the APIs will be the first part of any release, with the website following.
Is have a clear separation between our environments and the release will be tested in Dev, Test and Pre-Prod environments before the production deployment begins. Overall the whole process is fairly simple until it comes to post-implementation (PI) testing that is currently this is mandatory in our company.
We need to be able to test the production deployment prior to the customers using the site. Currently we feature toggle the site into maintenance mode unless its being accessed from a select IP address list. We now need to perform the PI testing on the new version of the site whilst the customer continues to use the older version of the site. I wasn't sure of the best way of achieving this.
One idea I did have is having a subdomain that links directly to the websites _staging deployment slot bypassing the deployment slot settings. In turn some logic in here could go direct to the API _staging deployment slot. This would give the option to post implement the change just prior to clicking the 'Swap' button to swap over the deployment slots.
I know the overall process isn't ideal, but at the moment this can't be changed. Does anyone have any thoughts or other suggestions on the above please?
Azure makes it easy to create deployment slots for App Services. It’s available in the Standard or Premium App Service plan mode. Deployment slots are actually live apps with their own hostnames. App content and configuration elements can be swapped between two deployment slots, including the production slot.
Azure customers can easily perform the following steps
- Deploy the web application to an online deployment slot.
- Run the tests on a deployment slot, within the live environment that potential testers are going to use. Testing environment and production environment exist side-by-side and provide the similar environment.
- Perform an internal swapping of the IP addresses of both slots (via load balancing and traffic management for both the nodes — slots)
- Update applications with zero downtime
- Swap back to a previous version of your app instantly, with zero downtime for users.
References
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
The overall reason to have deployment slots enabled is that it helps your team to run live testing on the production environment, and in case there are some problems on the production slot, it lets you roll back the swap without having to take your application down for maintenance.
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.
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.
Just getting used to VS2012 publishing of Cloud Services. At present I have a one instance webrole which contains a MVC3 application. I can publish it to Azure without issue, and it creates the Cloud Service>Web Role>VMs. Fine. Takes a little while.
However when I do a little code change how can I migrate just this code change without replacing all the VMs that implement the WebRole etc.
It seems that Code and infrastructure are inseparable, or have I misunderstood. Is there a way to just update the code bit?
Thanks.
When you roll out an update, you upload an entire package containing not only your code files, but also the configuration for the VM, such as # of instances, ports to open on the firewall, local resources to allocate, etc. These configuration settings are part of the code package - so there is more going on than just updating code files.
However, there are a couple of methods you can use to have more granular control over updates.
Use Web Deploy. One thing to keep in mind, is that any automatic service updates will restore your website to the last fully-deployed package, which may not be as up-to-date. You would only want to use this in staging, then do a full package update for production rollout.
Use an Azure Web Site instead, which allows continuous integration with your source control provider, and direct updates to the code.
Use an Iaas VM instead. These are basically the same as running your own custom server in the Azure cloud, and you have full control over the OS. However, you also have full responsibility for keeping the OS updated and secure.
You can also enable RDP to your Azure Web Role VM's. You will find all your code files there and IIS, but I wouldn't recommend updating your code this way for the same reasons listed in #1.
The code and infrastructure, in a cloud service, are actually separate. All you upload is a deployment package containing just your code and supporting libraries / files. You don't upload a vhd. Azure provides that for you, spinning up a vhd, and then accessing your code on a file folder on that vhd. Same process happens each time you scale out to more instances.
when you make a code change, you build a new deployment package and deploy that. If you do it as an in-place update (vs delete+redeploy), each role is updated on each instance (when you have multiple instances of a role, they're not all updated at the same time). You can even specify that you only want a single role within the deployment to be updated (helpful if, say, you have a worker role in addition to your web role, and want to leave all the worker role instances running).
when the code update happens, the VMs aren't replaced, but they are recycled, and when they start back up, they are running the updated code.
You can use WebDeploy with Cloud Services in production across multiple servers using the AzureWebFarm project (disclaimer: I maintain it).
Alternatively, you can also use the excellent Octopus Deploy deployment technology in conjunction with the AzureWebFarm.OctopusDeploy project (disclaimer: I maintain this one too).
To be honest though, if you just have a simple web app then I wouldn't both with cloud services - I'd just use Web Sites. Feel free to check out my blog post to see the situations which might force you to use cloud services though.
If you enable WebDeploy on the cloud service, you can use web deploy to publish the MVC application.
See http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx for details.
All of the above answers are correct and if you are trying to change your code for a production service you definitely want to do an in place upgrade as described. However, frequently during the dev/test phase or troubleshooting I want to make one small change and test it out quickly. To do this check out http://blogs.msdn.com/b/kwill/archive/2013/09/05/how-to-modify-a-running-azure-service.aspx which describes how to modify the code via RDP to the Azure VM.
Deploying apps to Windows Azure Websites feels incredibly more convenient compared to the initial WebRole option. Being able to push through Git, and get the app restarted in ~20s is a massive improvement over the 15min role redeploy.
Thus, I am considering using this option for what used to be hosted in WorkerRole as well. Indeed, it's possible to allocate a full VM to run WA website.
Are there any gotcha to be aware of when attempting this? Obviously, as the name suggests, WA websites are not intended for backoffice processing.
In an upcoming feature for Windows Azure Websites, the scenario you're referring to will be supported:
http://github.com/projectkudu/kudu/wiki/Web-jobs
The following will allow you to have 2 types of processes to run aside your website:
Triggered - Start your process on a scheduled (or manual) basis.
Continuous - Your process will always be on (if it goes, it brings it back up).
Regarding the differences between Azure Webrole and Azure Website, there's a different question:
What is the difference between an Azure Web Site and an Azure Web Role
Cloud Services gives you two different environments: staging and production. You can also use Continous deployment with Git, Tfs, Codeplex, Dropbox too. But if you don't need this two environments, you can go with websites.
Using a Virtual Machine, you'll be responsible for the operating system, runtime, data and also your app (obviously). Just be aware that you'll have to apply the service packs / security packs by yourself. If your app doesn't use 3rd party components I don't see a reason to use a VM for that.