I’m Stephane, and I work as a cloud architect at ShareGate and its parent company, GSoft. Over the past couple of years, I’ve been in charge of defining, executing, overseeing and optimizing our corporate cloud journey.
At GSoft, we’ve been using Azure for over 7 years. By sharing the path we took, the mistakes we made, and the lessons we learned along the way, I hope to help others who are currently going through those same steps.
What does a typical cloud journey look like?
I really like this diagram from 451 Research’s Cloud Transformation Journey report. From my experience, it’s a pretty accurate depiction of the typical transition organizations go through, and it matches GSoft’s path to becoming a cloud-first company.
According to the report, businesses tend to go through four major phases when moving toward a cloud-first approach. This journey can span several years, and some phases can be longer than others.
To give you an idea, the timeline for GSoft’s cloud transformation looks roughly like this:
- Great Expectations: 2012 – 2013
- Wuthering Heights: 2014 – 2016
- War and Peace: 2016 – 2018
- Brave New World: 2018 and beyond
Great Expectations: Getting started in the cloud
As a long-time Microsoft partner, it made sense for GSoft to think of Azure when we started looking at different cloud providers.
GSoft’s story with Azure starts in 2012, around the time Microsoft Azure launched its infrastructure as a service (IaaS) offering.
Like many organizations, our first steps in the cloud were all about experimenting and exploring different ways to reap the promised benefits of cloud computing, such as:
- On-demand availability
- Fast provisioning
- Lower cost
This exploratory phase matches what 451 Research calls Great Expectations: there was a lot of excitement about the cloud and its promise, and the more we experimented, the more confident we became in the Azure platform. At the same time, more and more businesses started to migrate workloads to Azure, and the number of available services exploded.
Wuthering Heights: Moving from proof of concept to cloud native
We started using Azure for things other than proof of concept in 2013, marking the beginning of what 451 Research refers to as the Wurthering Heights stage. Over the next few years, our Azure resource consumption – and costs – exploded.
2014 marked a major milestone in our cloud journey: we launched a new SaaS, Officevibe, and hosted it in Azure. We also moved our service clients’ development environments to the cloud in 2014, followed by their production environments a year later.
Another turning point occurred in 2016, when the decision was made to migrate all remaining on-prem workloads to the cloud. The company took a stance that might sound familiar to some: from then on, all new workloads were to be cloud native.
War and Peace: The need for cloud governance
I started working at GSoft in August 2016 as the company’s first-ever full-time “cloud guy”. My main goals were to:
- Improve our overall service offering by leveraging the cloud
- Assist our in-house product development teams in transitioning to a cloud-first mindset
- Put some order in the organization’s cloud environment – and maintain that order
Our developers had been using Microsoft Azure to the best of their knowledge for several years by the time I came on board, and it was serving them well as a whole.
However, as more and more projects and environments cropped up, in addition to a constant stream of people moving between departments and teams, things ended up a bit out of control in terms of resource and cost management.
It took us several months to get things back in order, and we managed to do it without disrupting day-to-day business operations.
One of the reasons it took that long was, simply, that it wasn’t my main focus; I was spending at least half of my time consulting with clients and dev teams.
We were aware that good cloud governance was crucial, but many of the initiatives involved in achieving that were treated as side projects, which we were entirely comfortable with. It’s important to take things at your own pace!
Here are some of the steps we took to restore order in our Azure environment during my first year and a half as cloud architect at GSoft:
- Switching to a new subscription model
- Migrating resources for the new subscription model
- Migrating from Classic to Azure Resource Manager (ARM)
- Establishing a naming convention
- Implementing resource tagging
- Infrastructure as Code (IaC)
- Ensuring that all non-production environments were hosted in Canada
- Using departments in our Enterprise Agreement Azure Policy
Implementing most of these measures went flawlessly. Some didn’t turn out as expected, of course, and others we found either too rigid or too difficult to sustain over time. Many were a first attempt; the teams and I were learning in the process.
Looking back, I am very happy with what we achieved during this War and Peace stage of our cloud adoption journey. Knowing what I know now, would I have done some things differently? For sure. But isn’t what gaining experience is? Execute, validate, learn, iterate… and then rinse and repeat.
In future articles, we’ll get into the details of some these attempts to take back control, and I’ll share what worked, what didn’t, and what it taught us.
Interested in a particular topic? Let us know in the comments!