The “wrong” and the “right” way to adopt the Cloud
Some organisations have had the Public Cloud imposed on them by a well-meaning CEO who has either attended a conference where their peers have been bragging about their cloud success, or they have read about it in an in-flight magazine on a trip from Melbourne to Paris.
They return to the office and call in the CIO or Director of IT and ask the dreaded question “so what are we doing with this Cloud thing?”
If we go back 2 or 3 years it is likely the answer was “nothing” even though they were likely using a SaaS application like Salesforce or Office365 and there was surely some shadow IT.
The pressure to get the cloud going has resulted in some organisations making common errors with adopting the cloud.
This post will explore the do’s and don’ts and ways to fix these issues if you’ve already made them.
Don’t treat the Public Cloud like just another Data Centre
Architecting your Public Cloud deployment in the same way you have always done your on-premises Data Centre and lifting and shifting your Virtual Machines, may be a good way to “get some cloud” quickly, but it will not give you any of the benefits of the Public Cloud and will likely cost 3 times as much.
This will result in bill shock and a lot of negativity towards your cloud projects.
Start with the end-user and the business outcome
Don’t just look at each service/application as a hardware stack or “Gandalf”(or whatever other name you have given your servers), think about the business outcome it achieves and who actually uses it, then look to see if there is a Cloud Native service or SaaS Application that can achieve this outcome.
This will mean that you actually get the benefit of the Public Cloud. If not consider whether the service should even move to the Cloud.
Use Cost calculation tools
There are many great tools out there like Cloud Health and Cloud Physics that can-do cost comparisons and workload sizing for you across on-premises, Azure and AWS.
Use these tools to determine what should go where and to appropriately size your cloud instances. You shouldn’t be sizing like for like with on-premises infrastructure.
The normal practice on-premises is to super-size for the extreme use case that “might happen one day”.
In the cloud you can scale as you need and if you architect your application correctly you can auto-scale up and down as needed.
Don’t assume that security and redundancy are built in
Unfortunately, there are some clients that assume that security and resiliency is the cloud vendors problem.
It’s a shared responsibility model.
The cloud vendors provide the tools, platforms, scale and sites and it is our responsibility to architect and implement to our business requirements and implement the appropriate; security controls, availability zones and geo- redundancy, governance and data protection.
Invest in education and training your team
Speed kills in this case. Overconfidence because “we have been doing infrastructure for 20 years” will result in design errors and pain.
Learning the Cloud is more complex than learning the latest version of Windows or VMware.
Investing in training and certifying your team will pay off in spades in terms of your outcomes and staff loyalty.
Don’t build when you can buy
While hand crafting an application with all the bells and whistles may give a Developer a short-term win- as well as make it harder for you to move them on down the track because they’re the only person who understands how that thing is built.
Review your code base to see if you can buy an off the shelf application or use a cloud native service, it will give you better short term outcomes as well as make it easier to manage in the long term.