Q&A
Cloud Adoption and Cloud Migrations are NOT the Same
Understanding the distinction between the two is crucial for organizations' cloud transformation.
Cloud adoption and cloud migration are often conflated, but understanding the distinction (and explaining it to the higher-ups) is crucial for organizations embarking on a cloud journey.
Aidan Finn, an Azure MVP and principal consultant at Innofactor Norway, delves into the nuances between these two concepts and explores the challenges and best practices for a successful cloud journey during a one-on-one interview with Redmond.
He'll also be sharing his tips and expertise during his anticipated TechMentor session, "Your Azure Migration Project Is Doomed To FAIL," this August on the Microsoft campus in Redmond, Wash. Time is running out to make your plans to join us at this year's TechMentor, so register today!
Redmond: How big of an issue is cloud repatriation? Is it common enough to be considered a "trend?" And what's the biggest reason, in your experience, that organizations leave the cloud?
Finn: Where I see Cloud Repatriation a lot is in the headlines. It's the latest flying jet car, "Linux is replacing Windows as the desktop OS", or "VDI for everyone" headline to generate clicks and keep the advertisers happy.
Why is this topic generating clicks? Is it just because it's controversial? Is it funny for some people? No, it's because there often is a level of frustration when organizations have attempted a cloud journey. The topic resonates and they wonder if it's a future path that they will have to take.
What's the biggest or most common mistake that organizations make in the planning stage of their cloud migration journey? (Or is it "not planning at all?")
There is one common denominator with all failing journeys: the organizations have not had suitable leadership. Despite years of recognition by influencers and commentators, IT is still seen as a cost center that "the nerds" do in the basement. Just don't bother leadership with it!
A cloud journey must be a digital transformation to succeed in mid/large organizations. There will you find developers and operators throughout the many divisions and departments that expect self-service and agility in order to meet business challenges in the flexible way that they know that the cloud can offer.
Digital transformation requires changes to the delivery of IT services throughout all parts of that delivery -- including outside of the IT department. An engagement that does not start with understanding the motivations of the business with involved sponsorship from board-level leaders will eventually fail. A "migration" might succeed, but adoption will fail.
What are the security and compliance bases that organizations absolutely need to cover during their migration?
I think that the most common observation I see is a lack of defined standards. There is a lot of security and compliance by gut, even in highly regulated markets such as the European Union. For example, one country in the EU has had a "we cannot use the Cloud because of the law." It turns out that "the law" did not exist and was a myth that was so widely propagated that it was more effective than an actual law could have been!
When I start to probe about what security/feature requirements are necessary I often get blank faces followed by "we require patching and antiviruses." Sometimes they equate using a brand name as being secure, rather than understanding what that set of products is doing, how to use them, or if they will be of any use in the cloud or not.
This failure originates in leadership. There is not involvement or direction other than "make us more X." Without direction or supervision, a little work is done and it might be the wrong work. So you won't find a defined security standard that covers more than malware scanning. Information storage or transmission standards are not defined. Policies regarding backup or disaster recovery are not even though about, beyond "back it up."
"Some organizations will opt to purchase a third-party solution. That can work -- but keep in mind that it just automates what you could be doing and that the subscription cost might eat up any savings you find. "
Aidan Finn
Organizations often move to the cloud expecting to save money, only to end up having unexpected costs. Do you have any advice for managing costs, from migration to the aftermath?
It's false that the cloud will be cheaper for everyone. It can be in some ways, but in most cases, the cloud will cost more so one had better realize the advantages of it beyond than just being a different place to run some virtual machines.
Microsoft Azure has a number of mechanisms that one can use to save costs. One cannot just rely on alerts from Microsoft Advisor (but that is a good start) to figure out how to use those mechanisms.
Some organizations will opt to purchase a third-party solution. That can work -- but keep in mind that it just automates what you could be doing and that the subscription cost might eat up any savings you find. Others might hire consultants from the same company that sells them their Azure licensing -- I've seen this and it makes me laugh. Would you hire a wolf that is stalking your herd to advise you on guarding that very same herd?
Work is the best recommendation. Learn how the resource types are metered. Do your best to estimate the mid-big ticket items during design and size appropriately. PaaS is not always cheaper -- sometimes compute is more affordable. But the indirect costs of compute (backup, patching, security, operations and so on) can be significant too. After a deployment, reassess the design. Do you need that premium storage? Is any of the compute over-specified? Are you committing to this for one or three years? If so, reservations and hybrid use benefit licensing can reduce costs significantly.
We love disaster stories. What's the worst Azure migration project that you've seen (without naming names) and what caused it? Looking back, do you think there was any way it could have been salvaged?
The story always starts the same. "We're going to the cloud because the IT manager said so."
We put in a lot of work getting a secured and well-managed infrastructure into place for this customer with their unique customizations. The whole time, this was a technology project with no involvement from anyone outside of central IT. Security poked their head in quickly and were happy that there was a firewall and some antivirus. We did the usual handover -- from high-level briefings to technical deep dives where you can hear the brain strokes happening over Teams when the new owners finally realize how much their jobs will be changing.
Then we go our separate ways. The customer decided that they wanted to run things themselves and that we were no longer required. So we went off and worked on other projects. Two years later, my colleague informed me that he just spent the morning with that company. A team of developers pinged him to say that they loved what we'd built but they hated how it was run -- like a traditional locked down IT. Could we build our platform again, but just for them so they could run it in an agile way?
This is not a unique story. I've seen it a few times. You try to tell the customer how things are eventually going to play out, but they won't listen because they are "different."This was the first one of these scenarios that we have seen play out a few times -- always with larger organizations that believe that their size makes them smarter than everyone else.
I now can tell from first contact whether the cloud adoption will succeed or not. That failure might happen 18-24 months after our build/migration project is finished. IT can control the migration because it consists of assets that they control. But when it comes to new projects where cloud adoption, architecture and cooperation are required, the necessary changes to the organization have not happened and there will come a point where other departments refuse to deal with "IT's cloud".