Azure is more than cloud infrastructure - a look at Microsoft’s Application Platform

Despite its seeming maturity and inclusion in the general lexicon, the cloud remains maddeningly hard to define, much less circumscribe. Like its atmospheric analog, cloud services are dynamic, indistinct and ephemeral and although accepted definitions and product categories exist, they don’t capture the subtle distinctions between various services.

One area where the lines are especially fuzzy is the difference between infrastructure and platform services. It’s an important distinction since IaaS is becoming a fungible commodity while higher level application services are the way cloud vendors produce customer stiction, if not outright lock-in.

Thus, it’s not surprising that the two most popular cloud services, AWS and Microsoft Azure, are building contrasting versions of a cloud-based infrastructure and service substructure for enterprise applications. Yet they’re coming at it from completely different directions: AWS building from IaaS up the platform stack, Azure starting with platform services only to later expose basic IaaS capabilities.

Our need for clarity means that most people still consider AWS to be IaaS even though its set of services now includes machine learning analytical models, an IoT SDK and backend services, media transcoders and all manner of databases and data analytics systems. Conversely, Microsoft Azure was originally developed as a cloud platform for Windows application developers complete with .NET and SQL services and app synchronization using Microsoft Live. Azure has since evolved to include standard IaaS compute, storage and network service to compete with AWS, however it’s most valuable as a PaaS for applications.

Azure’s essence or soul became apparent after attending a Microsoft workshop unveiling the Azure Stack private cloud (see my coverage here). Microsoft doesn’t position Azure as a way to replace IT infrastructure, but rather as a framework for rethinking enterprise architecture and application design through the lens of targeted, cloud-based (often, micro-) services. Understanding what this means and entails requires looking past the individual virtualized components to the overall Azure platform.

First, one must abandon traditional mental models of IT. As Phil Wainwright pointed out here last year, “The IT industry seems compelled to reinterpret cloud computing as a remake of how things have always been done in the past. And yet it never works out that way.”

Exploiting Azure, whether as a public, private or hybrid service demands unlearning old habits of client-server or mainframe design with monolithic applications and big-bang software releases and adopting a cloud-first scheme implemented using an agile, DevOps methodology that facilitates faster response to digital business plans.

Cloud native apps

Azure, like AWS and Google Cloud, are built for cloud-native applications, which differ from traditional IT systems by being inherently distributed, resilient and scalable, where APIs to micro-services and asynchronous message buses replace persistent connections to network sockets and file shares. Azure consists of a growing portfolio of application, data, analytics, messaging, monitoring, security and developer services that can be integrated like building blocks into arbitrarily complex applications. Yet like IaaS, these higher level components are managed by Microsoft, provisioned and priced as no-contract, usage-based services, consumed and interconnected using APIs and the Azure Service Fabric and deployable on either shared (public Azure) or private (Azure Stack) infrastructure.

Unlike AWS or other virtualization platforms, Azure was designed up front as a PaaS. As Mike Schutz, Microsoft’s General Manager, Cloud Platform Product Marketing told Stuart Lachlan last year, “Microsoft is taking and managing that underlying stack from the app down instead of from the operating system down. So from an operating standpoint, we believe we have a more mature offering in Platform-as-a-Service and because of the footprint that we have with developers today.”

Designing for Azure

Microsoft’s paradigm for Azure apps is the Cloud Platform Integration Framework (CPIF), a set of design patterns that provide a lightweight structure for solving a variety of business problems using distributed, often stateless cloud services. There are 24 application patterns for such things as loading data on demand from a cached data store or building a load-leveling message queue, along with general guidance for architectural decisions about 10 concepts including autoscaling, data caching, replication and synchronization and application instrumentation. Each pattern contains the details application architects and developers will need when designing for Azure including the list of Azure Services required to use the pattern, architectural diagrams and dependencies, and interfaces.

The keys to exploiting Azure PaaS are understanding the range of services available and creatively stitching them together to solve application problems. For example, traditional Web apps should be stateless and autoscaling with static content cached on a CDN; however unlike the typical IaaS, most of these details are handled automatically by the Azure Web Apps Service.

Likewise, given the wide range of storage options in Azure, including object, blob, relational database, column store and cache, it’s important to identify the best fit for the job. Many of Microsoft’s application patterns deal with the subtleties of managing communications, queues, user identity or telemetry in a distributed system. Again, these are much easier to solve by using an available Azure service rather than incorporating code into the core application.

My take - the meaning for business

Azure PaaS, like other cloud application platforms, represents a new way of designing, operating and funding IT and business services. While it promises to improve the performance, scalability and reliability of new product delivery, Azure and other PaaS clearly pose an acute risk of lock-in. Of course, this is nothing new. Application services are the reason Windows servers and IBM mainframes became ubiquitous and persistent within most organizations.

As companies rearchitect IT and move to the cloud, executives must carefully consider the long-term implications of their application platform decisions. The choice of Azure, Salesforce, AWS, CloudFoundry or another cloud platform will have as much to do with the business relationships and prior experiences as technical merit.

The lessons from the consumerization of IT and rise of cloud services are that users, whether individuals or business units, demand rapid, continuous innovation of digital products, reliable, predictable performance and integration with existing systems and data sources. I consider Azure PaaS to be a viable choice for meeting these objectives, but not the necessarily the best one for every organization and then, only for those willing to learn and adopt new ways of system design.

Image credit - Man fix server network in data center room © cookiecutter - Fotolia.com.