Until the end of 2022, I had worked pretty much exclusively in the AWS cloud. But anyone who follows me on LinkedIn may have noticed that I recently started working as a Cloud Solution Architect at Microsoft. As old Amazon habits die hard, I wanted to document some of my Learn and Be Curious journey as I learn about Azure, in the hope that other people may find it useful or interesting.

One of the main differences I’ve noticed so far is the way the two companies think about, and position, their cloud offerings.

AWS cloud is a product and platform in and of itself, with IaaS, PaaS, and SaaS offerings across a huge range of technologies and capabilities. They see their main competitors as Microsoft Azure, and Google Cloud Platform (GCP). But Microsoft think about cloud differently. They have a simple model to illustrate the value of the Microsoft Cloud , which includes six key areas: Security, Infrastructure, Digital and App Innovation, Data and AI, Business Applications, and Modern Work.

Microsoft Cloud overview

Services in Azure largely covers Security, Infrastructure, Digital and App Innovation, and Data and AI, with a few outliers such as GitHub and Visual Studio. Business Applications consists of Dynamics 365 and Power Platform, and Modern Work includes Microsoft 365 (i.e. Office), Teams, Windows, and Viva. And across all six of these areas are the first-party integrations, allowing customers to use them together seamlessly.

AWS simply doesn’t have services to compete in some of these key areas, which means AWS customers would have to go to additional providers, and then also build or buy the integrations to make them work together. That’s often a non-trivial amount of work, so shouldn’t be underestimated.

I first started working with the AWS cloud back in early 2012, when I was working on a lift-and-shift migration from a managed datacentre into “the cloud” to try and reduce costs for my customer at the time. I learned a lot whilst configuring the AWS virtual machines (EC2 instances) to run the software we’d been running on VMware VMs up until that point. Back then, Amazon ECS and Kubernetes didn’t exist, containers were far from mainstream, and the cloud in general was immature and nascent.

Back in 2012, EC2 instances always ran in a public subnet (there were no VPCs), and the only way to secure them was via security groups. Instances didn’t have persistent storage, so you had to create EBS volumes and mount them into your instance at start-up. I used User Data scripts to customise the instances as they were launched, modifying and tweaking my base image for the exact software this EC2 instance was going to run (i.e. they were still mostly pets, and not cattle). And most importantly of all, I had to come to terms with “everything fails, all the time ”, and re-architect the solution around this fundamental belief. This meant running multiple copies of each server, across all Availability Zones in the AWS region we were running in. There were lots of things that had to change when suddenly, your IP addresses aren’t fixed, and you don’t even know how many instances of each server could be running at any given time.

But my first foray into cloud computing was a success. When my customer’s product launched to the public in mid-late 2012, they did so primarily by advertising on TV. They had the first ad slot in the first ad break of Britain’s Got Talent - at just after 9pm, this was considered the peak advertising slot at the time - and the advert directed interested customers to the product’s website, which duly crashed due to overwhelming levels of interest. But with autoscaling groups and a few quick configuration changes to quadruple the size of the instances we were using, we were back up and running in no time. This kind of agility just wouldn’t have been possible in a hosted datacentre - our website would have crashed, and we’d have been offline until interest had weened, by which time our customer’s product would have missed it’s chance to make a good first impression.

After spending a few years working with the AWS cloud as a customer, migrating various systems to the cloud lift-and-shift style, and building new systems in the cloud in a more “cloud native” manner, I decided I wanted to go and work for the makers of this amazing technology. In 2015 I passed the multiple rounds of phone screen and “loops”, and joined Amazon as a Solutions Architect. During my first few years I worked with customers across multiple industries, and across almost every service AWS had available at the time. But in early 2018 I started to switch my focus towards containers, and later that year became a Specialist Solutions Architect for container technologies, which I loved, and which I did until I left AWS at the end of 2022.

So, just over a decade later, there is a certain pleasantness that I find myself back at the beginning of my cloud journey - well, of a new cloud journey. After joining Microsoft at the beginning of this year, I am now exploring the Azure cloud, and I’m enjoying seeing how it compares to what I already know. But this time round is different, of course. I’ve spent the last 7 years working with some of the largest, most complex, and most interesting customers in the world, and diving deep on all sorts of containers and Kubernetes issues. I’m coming at the journey with a whole load of knowledge and expertise I didn’t have last time round. But I still feel like a newbie, just as I did 11 years ago when I opened the AWS console for the first time.

But I owe it to myself (and my future customers at Microsoft) to get a solid and broad grounding in Azure, as I did with AWS before joining Amazon , so I can help with with every aspect of their solution, as I was able to do at Amazon so often. And I’d like to share my journey, to show that even experienced technologists have to start somewhere when learning about new technologies, and in the hope that it may inspire or help others to learn too.

If you’re interested in following along on my journey, follow me or connect on LinkedIn for the next instalment!