Questions about developing for azure

Question

We currently have a .Net MVC web app with a SQL server back-end database and two web services that perform periodically some computing tasks in the database.

I am thinking of packaging this app for the cloud, where a client would "instantiate" it as a whole package. This process would allocate automatically the pieces needed to run the whole thing, i.e. the site, the database and the other two services.

I've been reading quite a bit about azure and I am having a very hard time getting my head around the whole azure development, testing and deployment process, then upgrading and applying changes to existing deployments. I am used to having control of all the pieces. First I like to have everything local on my workstation. We use git and we have our own self managed repository. I find it weird to have a dev environment on a remote cloud computer. I think source code is one of the most valuable assets of a company along with the data (the data more so).

In the current environment we build the apps manually (I know it's far from being ideal, we will automate this process and I am not worried about it for now) and we deploy by simply copying the new version of top of the old one. We also do backups, recompile database stored procedures and apply scripts that massage data, change tables structures or add indexes and so on. There is some downtime allocated while the upgrades are done. Before we deploy to production we deploy to the integration and test environments.

How does all this translate to an azure architecture?

Here is my mental model:

• Development and integration are done locally.
• The software is packaged locally as a SAAS and uploaded to the cloud. I assume the cloud will take a manifest that includes all the resources the app needs and will allocate them when the app is created the first time in the cloud. This process will have to be tested in the cloud by us.
• As for upgrades, the upgrades would have to be applied by the client to existing deployments. I guess another option would be to create a new instance and migrate the data from the old one. I see the upgrades as packages that can be dropped onto existing deployments and they would perform certain tasks, much like a setup software that performs an upgrade on an older version. The upgrades would have be tested as well in the cloud.

I kind of assumed that the app can have some minor downtime. I realize that other apps might not have this luxury, but I don't want to go there now.

Anyway, is this doable in the azure world? Should anything be done differently? And how would one charge in this model?

Thanks

An update: I was thinking more about it and I guess another model would be to build a monolithic app that would allow users to sign up for the service (much like an email app) and it would allocate resources accordingly. I guess in this case the charging model is easier. The downside is that the app would have to be designed to be multi-tenant and it would have its own set of challenges. I am still fuzzy about how the whole development->test->production cycle would work in this case.

Answer 1

Part of the problem with Azure is that there are often several ways to achieve the same result - in the case of a web site your options range from App Services to Virtual Machines.

Your solution is probably best deployed as an App Service - basically what was once called an Azure Web Site and what sound like two Web Jobs along with an SQL Database.

In order to keep the model simple (i.e. consistent with your current usage) you can have as many of these as you want (within reason) and there's scope for scaling within Azure App services and SQL Servers (elastic database pools).

There are several deployment models - detailed here: Deploy your app to Azure App Service and similarly you can connect to Azure SQL server instances in the same way as any other to do the manipulation you need. So basically you can do the same thing you do now i.e. copy the files using FTP or something a bit more creative along the same lines (OneDrive/Dropbox). You'll probably end up with web deploy. You absolutely do not have to use git deploy (in fact you probably don't want to...)

I haven't been playing enough to be confident, but you can group azure resources - I'd guess this could be done on a per customer and for test and qa instances.

If it were me... I'd think about the build / deploy process - automate, start to use a build server, have the build server generate packages for deployment, promote those packages through test and integration and then deploy as suits to your client instances. Similarly look at automating the schema changes - fundamentally this means automating running the scripts and ensuring that you run them in the right sequence and once each only (this is basically a solved problem, there are tools...)

In all of this automation is you friend - automation == repeatability and (mostly) takes stress away. Tools like AppVeyor (a build server) and Octopus deploy (a deployment tool) understand Azure and will help.