Thursday, 30 October 2014

Spiderman and Azure


I've been really impressed by Azure at the TechEd conference in Barcelona this week.  We are starting our Cloud journey in 2015 so it's been great to see how far things have moved on in the last year.

Because I'm a geek I signed up to the free Azure trial (http://azure.microsoft.com/en-us/pricing/free-trial/) and had a play around for an hour.

In 1 hour I created a load balanced pair of web servers and a geo-located SQL cluster (i.e. one node in Europe and the other in the US).

1 hour.

That's ridiculous.

I'm not sure we even have the technical skills to do something like that little lone the time it would take (literally months).

1 hour from a cold start with no real experience of doing it before.

So that's all very good.

However, earlier in the week the excelled David Chappell (http://www.davidchappell.com/) talked about the Cloud and how with great power comes great responsibility (like Mr Spiderman).  Couldn't agree more.

If its that easy to do and if you aren't careful, your company will be spinning up machines all over the shape and things will quickly get out of control.

Just because you can spin infrastructure quickly doesn't necessarily mean you should do...


One of way of getting around this might to be to put some kind of dashboard over the top of the Azure capabilities (I think System Centre can do something like this) which automates builds and adds in things like approvals.  I really don't like having to nanny individuals but the reality is that if you let people build servers and environments manually (as well as install applications) things will get out of sync pretty quickly.

And your credit card bill will be substantial (ooops I forgot to turn off those 100 test servers I built last year).


Automating Azure


I'm not speaking from a point of great experience so my thoughts on Microsoft's automation approach might be entirely misguided.  Apologies Microsoft is this is not the case but  I'm not convinced their automation approach for Azure is right.

I'm a big fan of idempotence, infrastructure as code and desired state.

I can talk about the above 3 for quite some time so I won't bore you here (if you aren't already!).

Microsoft's approach is heavily reliant on PowerShell for Azure automation jobs.  These jobs are basically script and therefore contain logic and without a very skilled developer they are not idempotant.  Moreover, its difficult to version control these scripts as it seems you enter the PowerShell code directly on the Azure portal (probably wrong here!).

Being a procedural script its difficult to see what the impact on script v1.1 has over script v1.0.

I would turn to Puppet but it doesn't have the maturity to hook into the vast Azure API.

So I'm going to be a little stuck with PowerShell for the time being.

PowerShell is very powerful but really I just want to define the state of an environment/server and let the software worry about how to get there (a la Puppet).

In order to make the migration from on-premise to Cloud (or use Cloud for DR) we also aren't just talking about VM's.  What about VLAN's, F5 load balancers and all the other stuff that makes up an application stack?

Puppet can define these and if I could potentially use the same manifests for on-premise and the cloud this would be very exciting.  The ability to abstract away implementation into a XML manifest is the dream.

I'm not sure if that's a deficiency in Puppet or Azure (or both).  Either way there is another opportunity for Microsoft here.

So please Mr (or Mrs) Microsoft extend Desired State Configuration so it can cover more than just servers and allow those same manifests to cover private-cloud and public-cloud.  It needs to be agnostic of whether you are using VMware, Hyper-V, F5, Alteon etc.

Write once, run everywhere.
   

No comments:

Post a comment