Azure turned 13 earlier this year – yes, it’s a teenager. As a proud member of the extended Azure family, Dootrix’s head of DevOps, Mark Vallins, looks back to its beginnings and wonders where Azure goes from here.

The origins of Azure

If you’d asked almost anyone connected with it where the newborn Azure of 2010 would be 13 years in, I doubt they would have quite predicted what we have now.

In the great scheme of things, 13 years is nothing; but in cloud-development terms, it’s aeons. Cloud as we know it today can trace its origins back to the early noughties when Amazon decided it needed a solution to its own software challenges – problems of global reach and scale that almost no other business in the world faced.

In 2006 Amazon Web Services, seeing other, smaller providers emerge, and sensing a commercial opportunity, started offering cloud storage to the public. Microsoft, which had started working on a similar solution the previous year, announced Azure in 2008 and it became publicly available in the spring of 2010.

Back then we were starting to break the link between storage and hardware. Up until that point, you largely either had your servers on-premises or you rented or stored servers in a data centre. With the advent of AWS and Azure, enterprises started to think about this more in terms of the amount of compute, storage, memory and CPU capacity they paid for, rather than where and on whose servers it was hosted. This, of course, meant that one could also outsource maintenance, with the added advantage that if one of the provider’s servers went down your data would simply be migrated elsewhere and everything would carry on as normal. It also made elastic compute capacity a realistic option in a way it hadn’t been before.

Azure – a natural enterprise solution

Though Microsoft came to this market a little behind AWS, it also had a significant advantage; while start-ups gravitated towards Amazon, enterprises moved towards Azure. Partly this reflected the near ubiquity of Microsoft in the enterprise market; Azure offered the possibility of a seamless shift. Given that one of the main points of friction inhibiting the move to the cloud back then were concerns about security, the fact that Microsoft provided the authentication and authorization layer, via a single sign-on, across Office 365 and on-premises services, really helped build confidence.

The next milestone came in March 2014, with the launch of Azure Resource Manager (ARM) coinciding with the rebrand of the platform from Windows Azure to Microsoft Azure. ARM gave developers a unified way of managing all the services they might want to use on Azure; rather than building applications and deploying all the tools they wished to use on infrastructure with physical limits, ARM allowed developers to define infrastructure in terms of code. This in turn opened the way to a DevOps approach, because it allowed application development and deployment to cloud infrastructure as part of a seamless process.

As a result, if you needed to change your infrastructure, for instance to scale it up, you could change your config, push it back and things would change automatically as a result – the automation element that really brought the power and flexibility of the cloud to bear. Being able to script and automate infrastructure, both on Azure and other platforms, opened the way for the emergence of DevOps culture.

Azure spearheads Cloud Native

Where we are now is, at least in retrospect, a logical extension of these trends. The original offering was essentially infrastructure as a service. What we’re seeing now is something far more dynamic, namely platform as a service. It’s the culmination of massive amounts of storage and compute that have made using processes like machine learning practical in a way that it wasn’t before. And it’s all being simplified in such a way that rather than having to build something, it’s possible to send a simple query and get a simple result back.

Ten years ago, complex Enterprise-Architecture-type jobs – where we not only had to design the software, but spec-out all the hardware and define how that hardware was going to be redundant as well – would have been hugely costly and quite impractical. But now we are able to lay out for clients all the moving parts available in Azure, the building blocks of the solution they need, and show them how to put them together to solve their challenges. With this simplified tooling, you don’t need to develop everything from scratch.

Azure: where will it take us next?

But what I suspect most people are interested in is not how we got here, but where Azure might go in the next five years. I’ll be completely frank, it’s extremely hard to predict beyond the level of informed, creative guesswork.

It could run the gamut from finding ourselves five years down the line and realising nothing’s changed, to discovering that everything’s changed. In terms of day-to-day development, over the last five years, I don’t think what we do has moved significantly, but during the next five I expect us to get more abstract in our thinking. There’s a gradual movement towards tools like Power platform and less emphasis on going straight to the code.

I can imagine situations where we’re working with clients and saying to them ‘OK, what are your challenges? Let’s go and see what tools and services there are to address those,’ and surveying what’s already available alongside looking for opportunities to innovate and develop solutions based on the tools that emerge in the Azure ecosystem. Our role could increasingly be one of guiding partners in how to use these services, as well as offering governance and architectural ownership.

It may become a little like taking a trusted friend out shopping. Just because you can afford something doesn’t mean you should buy it; there are questions about whether it’s a good match for your needs, whether you’ll get use out of it, whether it represents good value for money.

And while I’m wary of making firm predictions simply because the rate at which this environment is changing is so fast, I can be pretty confident in saying that the future will see our choices multiply. And because you can have too much choice, finding a partner to help you navigate that embarrassment of riches will be an essential element of Azure development