In the last couple of years we've seen an explosive growth of microservices and related architectures. Docker and the containerization movement has revolutionized the way that developers deliver their applications to their customers. While we've seen a host of new container management services like: Swarm, DCOS, Kubernetes, Open Shift and similar platforms container management and distributed systems bring a host of new challenges to a development shop.

To start, the TheNewStack lists off some of the infrastructure and tooling that needs to be in place for a successful microservices shop: frameworks, consistent testing environments, logging, monitoring, auto scaling, service discovery, instant rollback, automatic versioning, failure resistance, and some self-service tools to provision resources.

One major challenge is service discovery. While your microservices system is relatively small, you can rely on developer knowledge and communication when it comes to coordinating between microservices. As your system grows this approach simply does not scale. Having a reliable way for developers to identify what services are available and their status is vital for rapid development and deployment.

If you're an open source shop you can rely on series of technologies like Consul, Zookeeper, or Eureka by Netflix. These platforms will solve some of the problems that developers might encounter but don't address the comprehensive system that you will need to make microservices work.

Another problem a developer will quickly run up against is local development. While the promise of microservices sound great when it comes to rapid delivery, developing microservices that integrate into a larger system is a challenge. When you start to have tens or hundreds of microservices being able to fit a new microservice into a cluster becomes daunting without a proper system in place.

Are you seeing a pattern here? In addition to writing code for an application, microservices architecture requires a great deal more tooling and support in order to successfully develop, deploy, and deliver a microservice. And each tool and microservice adds more complexity to an already complex system and stack of tools. Not to mention the training and educating that's required to get your developers and engineers up to speed. Microservices hold great promise but there are hidden costs and overhead to consider.

Complexity in Real World Examples

Here are a few examples of successful microservices systems:

Above is the Hailo cluster.

This is what microservices look like at Amazon.

And the now infamous Death Star Diagram at Netflix.

Take note of the complexity that's involved in these microservices systems and how each microservice communicates with the others.

While Netflix and Amazon have considerable development resources a smaller development shop will have to tackle many of the same problems on their own.

Microsoft and Open Source

Microsoft has pivoted in the last several years towards supporting the open source development community. They've opened sourced Visual Studio Code, .NET Core, Mono Project, and EntityFramework Core. Recently, they announced support for MS Sql on Linux, and a preview edition for Visual Studio for Mac. According to a report nearly one in three Azure virtual machines now are running Linux. This isn't your dad's Microsoft - when it comes to IDEs, documentation, and community Microsoft is leading the way with world class products and services. Which leads us to Azure Service Fabric.

Azure Service Fabric

I'm going to make a bold claim – Azure Service Fabric is the best thing since sliced bread for microservices. With ASF, Microsoft is eating its own dog food when it comes to developing and deploying microservices. Skype for Business, Intune, Azure Event Hubs, Azure Data Factory, Azure DocumentDB, Azure SQL Database, and Cortana are all built using the ASF platform. Additionally, ASF has: health monitoring, self-healing, supports stateful and stateless applications, high density of applications per virtual machine, rapid and independent deployment of each microservice, the ability to deploy different versions side by side with independent updates, fault analysis, and most importantly the ability to pull down the cluster for local development! With ASF, the cluster that you have on your local machine is the same cluster that you will deploy. They also have a Service Fabric Explorer that a developer can use to visualize what's going on with the local development cluster.

As a developer, I cannot stress how many problems ASF solves. If you want to develop microservices locally it can be difficult to ensure that the same cluster you have will be the same cluster you deploy. Not to mention ASF streamlines testing, managing, and deploying your applications. ASF takes care of the challenges of orchestration and development in one platform. If you don't want to develop in C#, ASF supports guest executables and Docker containers so you can program in the language of your choice.

With the rapid pace of technology and the dizzying array of tools and technologies that developers are expected to master, having a platform like ASF can make the transition to a microservices architecture far less painful. If you want to try out an ASF deployment, Azure has party clusters for experimentation. I invite you to check out Azure Service Fabric if you're considering a move into the brave new world of microservices.

Please note: I am not a Microsoft employee and the views and opinions expressed here are my own. If I've made an error or omission I'm happy to correct it.