+44 (0)115 933 8474 hello@n4stack.co.uk

Key Points


  • As technology decision-makers or architects we need to understand the trajectory of modern cloud tools/platforms so we can make investment decisions
  • Some of the cloud technology offerings have deep complexity and need a significant investment – they are not suitable for many organisations
  • Why we should choose approaches and platforms based partly on the developer experience (DevEx) offered by the platform


The speed of evolution in cloud technologies is so rapid that organisations building software systems need to think carefully before adopting technologies that are even just 2-3 years old. Organisations that move to new, operations-as-a-service technologies with established cloud providers are finding they have additional capacity to focus on business outcomes because they no longer need to deal with the underlying platform runtime operational details. In this context, I regularly recommend to technology decision makers that they look at the emerging cloud technologies – such as Serverless and Containers-as-a-Service – and plot a course to meet the trajectory in 12-18 months’ time to avoid the risk of being stuck with outdated approaches. In this post, we will focus on the Azure platform, but many of the points apply to other platforms as well, such as AWS, Google Cloud, and Aliyun.



When I co-authored the book Continuous Delivery with Windows and .NET (O’Reilly, 2016), we didn’t include much about Azure because some of the developer tooling for Azure was somewhat lacking; however, in the 3 years since writing the book, the Azure team has done hugely impressive work both with the Azure features & services and also with the auxiliary tooling (version control, builds, logging, etc). I think it’s fair to say that the Developer Experience (DevEx) around Azure is now probably the best of any of the cloud platforms today. For me, the richness of the Azure software development ecosystem feels really engaging. DevEx – how it feels to develop using a platform – matters hugely when the platforms and technologies around them are changing so rapidly because the applications on the platform will be under continual development, and any drag or friction in using the platform will cause delays or even loss of revenue for the teams doing the development. In this context, choosing a cloud platform with good DevEx means your teams will have more time to focus on the real business problems rather than fighting with poor documentation or clunky tooling.


Developers Guide to Azure


A good example of the Azure focus on DevEx is the Developer’s Guide to Azure (PDF), a great resource for software developers starting out with or returning to Azure for application development. It provides a clear, concise overview of the key Azure services and features, with links to online documentation and quick start demo applications.



I have been working with teams using Kubernetes since early 2017 and it’s clear to me that although Kubernetes is a very powerful infrastructure abstraction, it is also very complicated. In fact, I’d say that Kubernetes is too complicated for most medium-sized organisations to run themselves. Increasingly, organisations are turning to managed Kubernetes “Containers-as-a-Service” offerings such as Azure Kubernetes Service (AKS) to avoid having to build and operate the underlying Kubernetes plumbing.

Part of the problem with Kubernetes is the effort required to get a containerised application fabric up and running for development purposes. A promising feature from Microsoft to help accelerate application development in AKS is Azure Dev Spaces, which handles the behind-the-scenes complexity of deploying code to a Kubernetes environment to allow remote debugging from an IDE. Through some clever hooks in Visual Studio (and other IDEs) and the use of the open source Draft framework, Azure Dev Spaces lets you set a breakpoint in code on your local machine and step into the code running in a container on Azure – pretty neat:



Debugging a containerised web app using Azure Dev Spaces in Visual Studio – source: https://blogs.msdn.microsoft.com/visualstudio/2018/07/09/announcing-the-public-preview-of-azure-dev-spaces/


Azure Dev Spaces is a good example of where Microsoft is leading the field in cloud platforms by focusing on the developer experience (DevEx), in this case for containerised applications. Being able to use the debugger in the IDE to step into lines of code running in AKS brings the feeling of local application development to the Kubernetes world, making things much easier for developers.


A big advantage of cloud platforms over traditional hosted infrastructure is that the operation of the infrastructure is handled by the cloud provider: operations-as-a-service. This allows organisations to focus more on core differentiating business outcomes rather than underlying “plumbing”. The cloud platform model with the lowest operational overhead is Serverless or Functions-as-a-Service (FaaS), where any strong sense of underlying servers has been removed: we simply deploy code and the code runs.



Azure Functions is the Microsoft offering in the Serverless/FaaS space. When coupled with other low-overhead services (such as Azure Service Bus, Azure Event Hub, or Azure Cognitive Services), Azure Functions enables developers to create highly-scalable, nimble applications that respond to a wide range of events and process data in a cost-effective and trackable way. Microsoft supports a good DevEx for Azure Functions through the Azure Functions Core Tools which enable local development in Visual Studio (other local development options are available, too).


Azure Functions

Visual Studio has full support for local development of Azure Functions.

Source: https://docs.microsoft.com/en-us/azure/azure-functions/functions-develop-vs


The code in Azure Functions is called when a defined trigger is fired; this could be an HTTP call, a timer, a queue, a service bus, or several other things. The rich set of triggers for Azure Functions provides a excellent event-driven programming model that encourages us to adopt the well-respected Reactive Systems approach of responsive, resilient, elastic, message-driven applications. With the underlying code execution engine managed by Azure, we are free to focus on core business outcomes and even “price per feature” because Azure Functions are essentially billed per function execution (with memory footprint factored in).



With the modern range of “NoSQL” database options like column store, document-oriented, and graph that enable specialised data storage and querying do we really want to run 3 or 4 different database technologies in our single application? Of course not. This is where Azure Cosmos DB comes in. Cosmos DB is a multi-model + multi-API database that effectively acts as a document-oriented database, a graph database, and a column-store database all at the same time, with intelligent indexing happening behind the scenes. It also helps that Cosmos DB has seamless support for globally-distributed data, allowing rapid access from anywhere in the world along with very high availability. There is a Cosmos DB Emulator for local development and an official Cosmos DB Docker image to help developers test out Cosmos DB before paying for storage and throughput in Azure. When choosing Cosmos DB, we do not need to make an up-front choice about graph data or document-oriented or column-store: we can simply use the “flavour” of API that best suits the needs of our application or feature. Even better, all the operational aspects of running a high-performing, globally-distributed database are taken care of for us by Azure. This greatly simplifies application development and allows us to focus on the business logic without worrying about the low-level data persistence.


Organisations that adopt modern operations-as-a-service technologies like Serverless have more time to focus on business outcomes compared to companies running their own infrastructures. Technologies like Azure Functions and Azure Cosmos DB provide a compelling developer experience for organisations looking to develop new software rapidly, taking advantage of the cloud platform to minimise operational overhead.

Matthew Skelton

Matthew Skelton

Head of Consulting @ Conflux

Matthew is a guest writer here at N4Stack and has been building, deploying, and operating commercial software systems since 1998.

He specialises in Continuous Delivery, operability, and organisation design for software in manufacturing, ecommerce, and online services, including cloud, IoT, and embedded software.

Find out more about Matthew here.

Share This