Azure Dev Spaces has hit public preview, so El Reg took it for a spin

Or, if you will, an arthritic stagger around the park

Azure Dev Spaces is one of those technologies that looks great in demonstrations, but can end up being infuriating when introduced to real life.

Shown off at this year's Build conference and subsequently released in private preview, the toys were released to public preview this week, and The Register was keen to get its talons on it to enjoy some real-time container code debugging.

Suffice to say, it has not gone well. Though this is a public preview, quite a bit of work is needed to make it stable enough for production purposes.

Dev Space Delights

Azure Dev Spaces is aimed fairly and squarely at persuading developers that they should be targeting Microsoft's Azure Kubernetes Service (AKS) in their container development. Redmond reckons that if developers take their first tentative steps in the familiar Visual Studio environment (although others can be used), with the tools they are used to, they won't look back.

Intrepid Reg reporter does the breakpoint fandango in Azure Dev Spaces

The theory is that once Dev Spaces is enabled in your chosen environment (Visual Studio 2017 in the case of El Reg), code gets synced to the cloud. It is then built and deployed as a container into AKS. The neat trick is that you can still edit and debug code as though it was running locally, and don't need to spray your local workstation with all manner of Docker and Kubernetes components.

The concept is certainly appealing and deals with common workflow problems encountered by developers, particularly in the arena of end-to-end testing. The Register likes to do a bit of code-monkeying from time to time, and we decided to take the thing for a spin.

Putting the oh no in Visual Studio

From the outset you'll find a few limitations. You'll need Kubernetes 1.9.6 or later, and you'll need to make sure your cluster is running in one of a limited list of Azure regions. If the thought of setting up this stuff alarms you, probably best to stop reading now.

Microsoft does provide a helpful guide, which is festooned with errors. This is possibly because it looks like it was written against an earlier version of AKS that doesn't match the current feature set, such is the rapid release cadence adopted by Redmond of late.

Having spent too many years typing in BASIC listings from computer magazines in the '80s and debugging due to the inevitable printing typos, your humble El Reg hack sees this as more an opportunity for learning than something to be too distressed about.

Once configured correctly, the integration is impressively seamless, in Visual Studio 2017 at least. Directing the build toward Azure Dev Spaces pops up a dialog from which the developer can select the previously created cluster and – hey presto – the project gets sprayed with the scaffolding needed to make it container-happy.

At least, that is the theory. The process is slow. Very, very slow. And if you try to interrupt it to get on with something else, bad things can happen and leave the project in a state where rolling back to the last-known decent checkpoint is easier than trying to unpick the work done by Azure Dev Spaces.

Patience is a virtue, possess it if you can

Patience is its own reward, and once Azure Dev Spaces has done its stuff, the project can be run pretty much as normal, with the code spinning up in the container.

But again it is slow. The initial build and deploy is coffee-break material, even for the "Hello World!"-like example we put together. And if that build and deploy gets interrupted... well, it isn't good news for the cluster. We saw our first cluster crash and burn (or rather "left in a failed state") to the point where we simply deleted and recreated it rather than continue trying to resurrect the poor thing.

Again, patience is the key, and if left to its own devices for far longer than one would expect if running locally, Azure Dev Spaces does indeed work as advertised. Code running in the container can be stepped into and debugged – invaluable for end-to-end testing. Performance, however, can best be described as glacial.

Balan Subramanian's Azure DevEx product team has been tasked with "creating delightful experiences on Azure for all kinds of developers". The experience of Dev Spaces has, alas, not been delightful for this developer. It is sluggish, a little fragile, and needs to be configured just so.

However, this is still preview technology with clearly a way to go before it hits the big time. For developers used to a visual way of debugging and happy in the world of Visual Studio, Azure Dev Spaces will indeed provide a familiar wrapper around the potentially alien environment of containerisation. Just not quite yet. ®

Serverless Computing London in November will give you the state of play on serverless and function as a service, and explain how to put them to work in your business. Full details, and ticket information, at the website here.