{"id":53904,"date":"2018-09-19T09:00:44","date_gmt":"2018-09-19T08:00:44","guid":{"rendered":"http:\/\/content.n4stack.io\/?p=53904"},"modified":"2018-09-19T14:30:42","modified_gmt":"2018-09-19T13:30:42","slug":"azure-operations-as-a-service","status":"publish","type":"post","link":"http:\/\/content.n4stack.io\/2018\/09\/19\/azure-operations-as-a-service\/","title":{"rendered":"Why Operations-as-a-Service is the Future with Azure"},"content":{"rendered":"
[et_pb_section bb_built=”1″ _builder_version=”3.12.2″ background_color=”#e5e5e5″ custom_padding=”0|0px|0|0px|false|false” next_background_color=”#ffffff”][et_pb_row custom_padding=”0|0px|27px|0px|false|false” _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.12.2″ text_font_size=”17.5px”]<\/p>\n
<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.0.47″ prev_background_color=”#e5e5e5″ next_background_color=”#e5e5e5″][et_pb_row _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.12.2″ header_3_text_color=”#e05206″]<\/p>\n
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<\/a> 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\u2019 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<\/a>, Google Cloud<\/a>, and Aliyun<\/a>.<\/p>\n <\/p>\n When I co-authored the book Continuous Delivery with Windows and .NET<\/em><\/a> (O\u2019Reilly, 2016), we didn\u2019t 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\u2019s 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.<\/p>\n <\/p>\n <\/p>\n <\/p>\n A good example of the Azure focus on DevEx is the Developer\u2019s Guide to Azure (PDF)<\/a>, 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.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.12.2″ background_color=”#e5e5e5″ custom_padding=”0|0px|0|0px|false|false” prev_background_color=”#ffffff” next_background_color=”#ffffff”][et_pb_row custom_padding=”0|0px|27px|0px|false|false” _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.12.2″ header_3_text_color=”#e05206″]<\/p>\n <\/p>\n I have been working with teams using Kubernetes since early 2017 and it\u2019s clear to me that although Kubernetes is a very powerful infrastructure abstraction, it is also very complicated. In fact, I\u2019d say that Kubernetes is too<\/em> complicated for most medium-sized organisations to run themselves. Increasingly, organisations are turning to managed Kubernetes \u201cContainers-as-a-Service\u201d offerings such as Azure Kubernetes Service (AKS)<\/a> to avoid having to build and operate the underlying Kubernetes plumbing.<\/p>\n 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<\/a>, which handles the behind-the-scenes complexity of deploying code to a Kubernetes environment to allow remote debugging from an IDE<\/a>. Through some clever hooks in Visual Studio (and other IDEs) and the use of the open source Draft framework<\/a>, 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:<\/p>\n <\/p>\n <\/p>\n Debugging a containerised web app using Azure Dev Spaces in Visual Studio – source: <\/em>https:\/\/blogs.msdn.microsoft.com\/visualstudio\/2018\/07\/09\/announcing-the-public-preview-of-azure-dev-spaces\/<\/em><\/a><\/p>\n <\/p>\n 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.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.0.47″ prev_background_color=”#e5e5e5″ next_background_color=”#e5e5e5″][et_pb_row _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.12.2″ header_text_color=”#e05206″ header_3_text_color=”#e05206″]<\/p>\n 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 \u201cplumbing\u201d. 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.<\/p>\n <\/p>\n Azure Functions<\/a> 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<\/a> which enable local development in Visual Studio (other local development options are available, too).<\/p>\n <\/p>\n <\/p>\n Visual Studio has full support for local development of Azure Functions. <\/em><\/p>\n Source: <\/em>https:\/\/docs.microsoft.com\/en-us\/azure\/azure-functions\/functions-develop-vs<\/em><\/a><\/p>\n <\/p>\n 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<\/a> 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 \u201cprice per feature\u201d because Azure Functions are essentially billed per function execution<\/a> (with memory footprint factored in).<\/p>\n <\/p>\n With the modern range of \u201cNoSQL\u201d 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<\/a> comes in. Cosmos DB is a multi-model + multi-API<\/em> 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<\/a> for local development and an official Cosmos DB Docker image<\/a> 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 \u201cflavour\u201d 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.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.12.2″ background_color=”#e5e5e5″ custom_padding=”0|0px|0|0px|false|false” prev_background_color=”#ffffff” next_background_color=”#ffffff”][et_pb_row custom_padding=”0|0px|38px|0px|false|false” _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.12.2″ header_3_text_color=”#e05206″]<\/p>\n 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.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.0.47″ prev_background_color=”#e5e5e5″][et_pb_row _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″][et_pb_team_member name=”Matthew Skelton” position=”Head of Consulting @ Conflux” image_url=”http:\/\/content.n4stack.io\/wp-content\/uploads\/2018\/09\/Matthew-Skelton.png” twitter_url=”https:\/\/twitter.com\/matthewpskelton” _builder_version=”3.12.2″]<\/p>\n Matthew is a guest writer here at N4Stack and has been building, deploying, and operating commercial software systems since 1998.<\/p>\n He specialises in Continuous Delivery, operability, and organisation design for software in manufacturing, ecommerce, and online services, including cloud, IoT, and embedded software.<\/p>\n<\/h2>\n
IN AN AGE OF CONTINUAL EVOLUTION, DEVELOPER EXPERIENCE IS KEY<\/h3>\n
<\/h3>\n
MAKING KUBERNETES EASIER TO USE WITH AKS AND AZURE DEV SPACES<\/h3>\n
SIMPLIFYING CLOUD-NATIVE APPLICATION DEVELOPMENT WITH AZURE FUNCTIONS AND COSMOS DB<\/h3>\n
<\/h2>\n
AZURE FUNCTIONS FOR SERVERLESS APPLICATIONS<\/h3>\n
<\/h2>\n
COSMOS DB FOR SERVERLESS DATA STORAGE AND QUERYING<\/h3>\n
<\/h3>\n
<\/h3>\n
SUMMARY<\/h3>\n