I’m writing this during registration at the Microsoft Cloud Roadshow at the Excel centre in London at the end of February 2016.
I have been working on an Azure based project for 15 months and I am well aware that some of the concepts that the project was based on all those months ago are feeling decidedly old. It has become obvious to me that when working with Azure, one the major challenges has been keeping up to date. Microsoft are fully bought into regular incremental delivery which is a positive, because you can rely on getting new features quickly but as a technology consultant you have your work cut out trying to understand how the leverage new features and also keeping a handle on product renaming and repositioning. I get limited opportunity for training so I am hoping that the next two days can bring me up to speed.
The rest of this post is going to cover the key highlights for me.
The key message from the keynote was that Cloud transformation is happening: businesses can lead on this or be dragged. If you are not transforming, you’ll find that in time you’ll struggle to be competitive. Cloud transformation comes in three stages:
- Efficiency – The Cloud allows you to deliver value early or test your assumptions with your customers allowing faster feedback. Its pay as you go model keeps costs under control and avoids hardware sitting underutilised in your data centre.
- Agility – Services can be spun up on demand, utilised and removed with ease. You don’t have to worry about getting your sizing maths right up front, you can change later. Azure provides a number of sophisticated rule based elastic scale controls that allows you to flex your environment dynamically and manage your costs all within well-defined constraints.
- Differentiation – The Cloud allows for business models that are not possible or cost effective with traditional architectures. The canonical example used throughout the sessions was IoT.
Something I hadn’t thought about was the way in which organisations start with the Cloud. One way is to start with SaaS services such as Office 365 and Salesforce. The other way is through virtualisation and hosting infrastructure in the Cloud rather than on premise. Once your transformation has started you start using high level services and may end up moving development onto the Cloud.
Microservices – Containers and Service Fabric
One session was focused on Azure Service Fabric. Apparently Azure Service Fabric underpins many other Azure services, including pretty heavy one such as Azure SQL DB. Service fabric provides a means for hosting lightweight services that can the stateful or stateless. It also provides support for the Actor model. Under the hood VMs are added to a cluster which Service Fabric manages. Service Fabric controls which host the service runs on and deals with reliability and failover automatically.
The presenter gave a demo of a simple stateful service incrementing a counter. All the code did was increment a number stored in a special data type, a reliable collection. As the service was incrementing the counter on screen, the speaker ripped nodes out of the fabric. As nodes came out the counter stopped briefly and then continued on another node seamlessly without losing state.
The take away here, this was all for free. There was very little Azure configuration required and no need for anything like SQL Server. This is really something to consider when building Microservices on the Microsoft stack.
Other sessions covered Azure’s support for Docker containers. Whilst Microsoft have a good story of Docker containers running on Azure it still seems their strategy isn’t coherent. All they really have is an alternative for Linux shops running Docker. But why would a Linux shop move to Azure for that capability?
I think there is a long way to go before Microsoft developers really get containers. Containers are something that has lived in the Linux ecosystem for some time whereas there is nothing really equivalent in the Microsoft space. Maybe there will be more traction behind this once Windows Server 2016 provides native container support.
Microsoft uses the diagram above to differentiate the various ways of hosting Microservices. Service Fabric provides lots of productivity but limited control, whereas hosting Docker on your own VMs or using the Windows Container Service (basically containers for Windows 2016) provides lots of control but at the cost of limited productivity.
It is pretty clear that Azure Websites are the preferred way to host websites, mobile and API applications on Azure. The “legacy” option of Web Role Cloud Services didn’t get a look in. Officially Azure Websites provide greater productivity and Web Roles provide more control but I would struggle to provide a strong case to use anything other than Azure Websites.
The stand out features for me is the concept of web site slots which amongst other things provide a target for deployments. For example, you could have testing, staging and production slots on the same website. Swapping staging to production is straight forwards and it is possible to have “sticky” configuration which ensures that production still points at the production database whilst still allowing any configuration necessary to support new features to move into production. It is possible to split traffic between slots. You might do this for a form of A-B testing, splitting traffic between staging and production allows new features in staging to be tested with real customers.
The announcement that Microsoft was procuring Xamarin emerged during the running of the roadshows, and surprisingly there was not a spotlight on it, but I think this is a key strategic move for Microsoft. Up to this point Microsoft did not have a coherent strategy when it came to cross platform mobile development.
However, for the best performance and experience you need to build native applications. In the past, to do this you are either limited to targeting Windows Phone or building Universal applications or you leave Microsoft’s development stack and using more specialised tools. Xamarin plugs this gap and provides a means to have a single project which contains all the common code and provides for light weight satellite projects which contains all the specialised code for each target device .
Azure DevTest Labs
The final thing I wanted to draw out was Azure DevTest Labs.
This was touched on as part of a session on DevOps and Visual Studio Team Services (VSTS) tooling. This looked very powerful. It effectively allows developers and testers to spin up preconfigured development and test labs hosted on Azure. It can be hooked into a VSTS release pipeline allowing environments to be provisioned as part of the release cycle. Administrators create templates that define the environment, server and software configuration. Resources and costs can be managed by enforcing quotas and policies and the VMs can be configured to auto shutdown when they are not being used. This was in preview at the time of publishing but it represents an interesting addition to Microsoft’s DevOps story.