It’s now been ten years since Microsoft announced its Azure cloud service. A decade is a long time in computing terms, so I took a trip back on the Internet Archive’s Wayback machine to see what Azure was like shortly after launch.
Back then, Microsoft was treating Azure as a platform as a service play, offering cloud-hosted services where you could build your applications. Live Services integrated with devices, SQL Services handled your data, and .Net Services hosted stateless applications, along with planned integrations for SharePoint and for Dynamics.
Azure at launch
There was a lot then that’s still familiar today. Many underlying technologies have since emerged in their own right and become key Azure development tools. Under the hood were now-familiar concepts, like worker processes and a managed service fabric. It wasn’t as flexible as building apps on Windows or Linux, but it was a roadmap to a world where software deployment was as simple as hitting the Publish button in your IDE.
Pushback from an industry that wasn’t ready for a stateless, serverless application development model meant that Azure had to take a step back and aim for parity with its main competition, Amazon Web Services. AWS had quickly gained market share with its focus on functional services that supported virtual infrastructure.
Built using Microsoft’s Hyper-V virtualization technology under the hood, infrastructure as a service (IaaS) was a logical transition for Azure, and over the last decade it’s focused on a similar model to AWS’s, rolling out services that can be accessed from apps running in virtual machines in virtual networks.
However, that original Azure vision was still there, powering its web services, and its back-end-as-a-service tools.
Azure today
But the industry was evolving too, and over the last few years Azure has begun to move back to its original vision. The result is a modern Azure is closer to that original platform than you might think. Yes, it’s still got a significant infrastructure component, but as its services framework was built out over the years, Azure has slowly focused back on the idea of cloud as platform.
The biggest driver for that is the importance of distributed systems development to the cloud. Although you may have access to near unlimited compute capability, it’s still a set of discrete servers. For all that Intel’s architecture has added more cores and support for multiprocessing systems, the commercial cloud remains a scale-out architecture rather than scale-up. You can use one of Azure’s massive G series machines for large projects, but at well over $80,000 dollars a year it’s not a model that supports the type of continuous operation that a cloud-native application requires.
Scale-out is an architectural approach that matches the capabilities of cloud hardware, the endless racks of Open Compute servers that fill the halls of data centers scattered around the world. You can then replicate architectures between sites, letting you build in redundancy and geographic routing if necessary. It’s also a model that maps neatly to microservices, breaking applications into component parts that can be independently scaled as necessary.
Microsoft has taken a big bet on cloud-native microservices in Azure. You only have to look at its investments in Kubernetes tools and in rearchitecting Windows Server to support containers. Building on its infrastructure investments, it can use those new container-optimized releases to handle rapid scaling and deployment. With preconfigured servers ready for container deployments, rolling out new functionality and additional capacity becomes a lot faster; there’s no need to wait for an OS deployment because all that’s needed to support an application or a service is bundled in the container alongside your code.
Services that date back to the original Azure release, like Azure Service Fabric, have graduated from behind the scenes to become customer-facing tools with a stronger microservices focus, and with improved support for both containers and VM-based solutions. Developers are building complex applications that mix technologies, and Azure has evolved to support these newer architectures.
Azure tomorrow
So what of the future? If the past of Azure has become its present, where will it go next?
One of the advantages of a hyperscale cloud platform is that it can support many development models. There will always be lift-and-shift migrations from on-premises applications, and there will always be born-in-the-cloud new application development. What’s going to be needed are ways of migrating from hard to scale monoliths to distributed applications.
Distributed application design patterns can help break down these monoliths, using models like the sidecar and the adapter to move functionality away from the core of an application to new microservices that slowly take over functionality while allowing the old application to continue running. As Service Fabric continues to evolve, it’s likely to be come the host for these patterns, managing Kubernetes orchestration for sidecar and adapter containers, while continuing to manage virtual machines.
There’s also scope for further development of other approaches to distributed computing, building on the work done by the Project Orleans team. With support for distributed transactions in the latest build, it can now support much more complex applications. Global scale might not be needed for everyone, but tools like this can help developers use multiple parallel microservices to handle complex loads, firing up virtual actors as necessary to handle secure delivery of data to central services.
Modern applications are at heart distributed applications, reflecting the architecture of public clouds and the limitations of their underlying hardware. Without major changes in server architecture, we’re not going to see much change. What we will see is cloud providers like Microsoft providing more and better tools to support distributed applications, educating developers on how to build and run them, along with tools to help migrate existing code to new ways of working.
Azure is in a good place to do this. Its own developers have spent a decade building and running distributed services, and it’s time for those lessons to be delivered to the wider community. As tools improve, services like Azure Service Fabric Mesh simplify the way they’re delivered, with the new Learn platform wrapping self-paced training around the platform.
Microsoft may have been skating well ahead of the puck when it launched Azure all those years ago. The field of play has moved on, and it’s time for it to not only head to where developers are going, but to also start encouraging them to build new, ambitious apps that can take advantage of global scale distributed systems. Yes, it’s a challenge, but it’s one where Microsoft needs to step up to the mark.