Why Operations-as-a-Service is the Future with Azure

FOCUS ON OUTCOMES BY USING NEW CLOUD PLATFORM TECHNOLOGIES

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.

 

IN AN AGE OF CONTINUAL EVOLUTION, DEVELOPER EXPERIENCE IS KEY

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.

 

 

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.

SIMPLIFYING CLOUD-NATIVE APPLICATION DEVELOPMENT WITH AZURE FUNCTIONS AND COSMOS DB

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 FOR SERVERLESS APPLICATIONS

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).

 

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).

 

COSMOS DB FOR SERVERLESS DATA STORAGE AND QUERYING

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.