Devs: This is another fine Mesh you've got us into, Microsoft

Or: How I learned to stop worrying about infrastructure and love the cloud

From the department of "things punted to public preview before they're totally ready" comes Azure Service Fabric Mesh.

Microsoft emitted Azure Service Fabric at the end of March 2016, aimed at managing stateful and stateless microservices over hundreds of servers in the Azure cloud. Redmond proudly stated that the technology was behind the likes of Dynamics 365, Skype for Business and Azure SQL Server Database and began opening up the code on GitHub a year later.

The challenge that faces those developing for the service is thinking about the infrastructure running in the background while also considering the needs of scaling and distributed computing.

Enter Azure Service Fabric Mesh, which has hit Public Preview after a few months of privacy following Build 2018.

Microsoft reckoned that all a developer needs to do to take advantage of the Mesh is to package up their application into a handy container and fling it at the service via the Azure Command Line Interface.

The new Microsoft has been equally happy with a Windows or Linux container, and in fact recommends the use of Linux (in this instance Alpine) in the compulsory "Hello World" example, due to it being lighter in weight than the Server 2016 or 2019 equivalent.

The theory is that the application manifest deployed with the container describes any scaling and network requirements. The Service Fabric Mesh then takes care of everything, dealing with hardware and software failures, scaling, distribution and so on.

So far so good.

Great for devs who can't get enough of hunting down dependancies

Microsoft has also trumpeted a "great developer experience", which is where the wheels come off a little bit. The good news is that it should be relatively simple to migrate applications to the platform with minimal changes. The bad news is that getting the likes of Visual Studio to the point where deploying and publishing is possible is currently a little problematic due to the preview nature of the technology.

The Register broke out our copy of Visual Studio, still traumatised from its Azure Dev Spaces experience, and proceeded to plug through the dependencies to actually make the thing work. Docker is obviously needed for the containerised apps along with a local Service Fabric Cluster for debugging. Fighting through the forest of broken links that are par for the course as far as preview software is concerned, the experience could hardly be called "great".

However, once configured, running up a containerised application locally (in this case, a Windows container) is impressively rapid, with all the debugging tools beloved by VS users present and correct. While Azure Dev Space-like debugging isn't available, hitting the publish button does, after a bit of a wait, indeed shunt the application up to Azure where it can begin its new Meshy life.

Microsoft will be keen for developers to take the preview for a test drive, although it has been at pains to point out that it is very much not ready for production. El Reg would certainly agree with that, and also urge caution before devs spray any sort of production development environment with preview SDKs and add-ons for Visual Studio.

The Preview Mesh service itself is also free, although limited. The largest container is restricted to 4 cores and 16 GB, while there is a maximum of five applications permitted. Other restrictions mean it is possible to kick the tyres for sure, but not really sufficient for serious work. Being limited to only three Azure regions (US West, US East and Europe West) isn’t ideal either.

There is great potential here, and those who are making the move into a containerised Azure world will find much to like (certainly if already working in the existing Azure Service Fabric.)

However, while Azure Service Fabric Mesh is designed to take away the grief of infrastructure planning, Microsoft must also persuade developers that giving up that control won’t cause more pain further down the line. ®