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?
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.