In our software development company, we're either working as consultants in corporate setups, as educators on courses or conferences or as project/product developers. We do most of our work using the Microsoft technology stack, and therefore we decided some time ago, that we would take the plunge, and establish development assets in the cloud using Azure. We already have experience using Amazon cloud services, so to compare the two products, the Azure adventure was needed also. Let me fill you in on our experiences so far.
Our initial and very simplistic setup was based on five subscriptions to Visual Studio Professional with MSDN (OVL licenses). We used to be a BizSpark partner but grew out of that (three year period), and had to buy into the Microsoft tool chain on ordinary market terms. Along with the MSDN subscriptions comes free Azure credits (350 DKK/month/subscription or approx. 50$), which has allowed us to experiment and gain some basic knowledge into the Azure world. More on the combined price tag later.
The overall setup looks like this.
(Besides the MSDN subscriptions we also run a Office 365 setup hosting all our email and office program needs)
We have a TeamCity (JetBrains) buildserver running on a small VM (Basic A1, 1.0 Core, 1.75 Gb) which is barely enough to keep us going. The estimated price tag on this baby is approx. 240 DKK/month (36$). This VM, along with our other VM’s are “classic” – Microsoft, in its wisdom, decided to differentiate VM’s created using a Service Management API (classic) from resources created by a Resource Manager (1,2). There are differences in how collected resources are treated, look to the references for further elaboration.
Another curiosity with respect to the different API’s is their visual appearance. Each has a client UI with totally different layout – why did Microsoft not just expand or evolve their first attempt?
Figure 1: "Old" Azure portal
Figure 2: "New" Azure portal
We try to adhere to the principles of not only Continous Integration but also Continuous Delivery (CD) and have supplemented our TeamCity build server with an “Octopus” deployment server (https://octopus.com/). This server is a very tiny VM (Basic A0, 0.25 Core, 0.75 Gb) and takes care of pushing the builds from the build server to our staging environment (mostly) web sites. For instance, we have one Azure QA web site (Web App) and an external ISP hosted LIVE web site. The CD server uses an SQL Server instance for storing configuration and releases. Notice, that we’ve chosen that DEV is the local developer machine. Our first integration point then, is the build service and the QA website. With the push of a button we’re able to release a tested QA build of choice. Builds from the build server are auto promoted if all tests are green.
We’re based on Git / Github with respect to our source code repositories. The Microsoft tools all play nicely along here and we’ve never looked back to ancient times with Subversion et al.
We would never consider going down the TFS path, so no experiences on its integration with Azure here, I’m afraid. Look to the references if you’re interested in how to leverage Azure with respect to TFS based builds (3). Then there’s the whole issue with Visual Studio Team Services, which is another Microsoft TFS initiative. But all, in all, we’ve always found the TFS setup too “corporate”.
Besides resources needed for actual development, we have set up a DokuWiki (https://www.dokuwiki.org) for ever-changing developer related documentation. This is just an Azure Web App, and it comes for free in the “Free” tier, being a non-outbound / non-production site). We administer the site using Remote IIS Manager and FileZilla (https://filezilla-project.org/).
So, with this relatively small company setup, how much does this cost us on a monthly basis?
MSDN (x5) is approx. 31.000 DKK/year / 12 = 2.583 DKK/month ($385/month)
Azure usage is approx. = 440 DKK/month ($65/month)
Azure credits = 350 DKK/month ($52/month)
Total(*) 2673 DKK/month (approx. $400/month)
(*) Total for five developers, excluding VAT.
This shall of course be taken with a very large grain of salt! .. our usage depends on how much development is going on, how many builds, how many deployments and so on. We’ve had 2 VM’s running around the (daytime) clock, with different loads, 1 VM (the build server) being the primary work horse. Now, you could argue that the Azure part in this equation is only minimal (some 90 DKK/month or 18 DKK/developer/month), but the only reason for us to board Azure was the MSDN prerequisites. Should we enter the Azure world on a non-credit basis the price tag starts to blur a bit. Try and figure the costs from the extremely overwhelming and confusing summery outlined for instance here (5,6).
The real cost of Azure however, is the learning curve associated with the mix of different tools you will have to master. We spent many hours trying to figure out infrastructure problems related to issues such as geo location of assets, different subscriptions or problems related to our VPN connection.
And with respect to geo location, note that you need to make sure to establish your SQL database resources in the same geo region as the using resources, otherwise you’ll pay extra for the intermediate traffic between the database and the backend (4).
Sort of conclusion
When we first set out, we were pretty naïve on how to use our individual MSDN licenses. We thought that the total Azure credits could just be pooled and used to the benefit of our company. We soon discovered that this is indeed not the case – credits are meant exclusively for the subscription on which it originates. We asked Microsoft about this, but they don’t seem likely to change this behavior (7). This means, that we need to carefully plan on which subscription we deploy which resources, to make the most of our credits. For a big company, the Azure credits are of course just peanuts, and this whole issue deserves no mentioning, but we think, as (current) representatives of companies less than 10 developers, that Microsoft could look into how to embrace companies like us. Remember, all companies start out small.
So, all in all, yes we’re sure - we see no other future than continuing to strengthen our Microsoft (as well as AWS) cloud efforts and make the most of our experiences to the benefit of our customers.