What Cloud - Private, Public, Multi-cloud ?

Most of the cloud system context will fall in below category or its variants. Consider on Premise could be either the datacenter or private cloud.

1)   On Premise + Single Public Cloud Vendor

Enterprise with current existing IT systems trying to adopt and migrate to the cloud fall under this. some are in early stages of cloud exploration. These are legacy systems which are complex with minimal knowledge base. Most of the teams are new to cloud technologies.

2)   On Premises + Multi Public Cloud Vendor

These are enterprises where strategy is to be cloud vendor agonistic. based on their learnings from past where legacy tech such as mainframe etc. have put them on back foot in negotiations being dependents on single vendor.

3)   Multi/Single Cloud Vendor

These are organisations which are mostly new digital business that have originated post cloud ear and systems have been built for and in cloud right from the start. They do not have any datacenter owned by them and run fully in cloud.

What is right for you

You need to understand what category you fall in current state and what is your nirvana state. Some of the obvious decisions you have to make here 

• Co-Existence of On Premise and Cloud
• Private Cloud vs Public Cloud
• Multi Cloud - Vendor Agnostic

Co-existence of on premise and Cloud

This is most common as large systems takes time to migrate and even if you want to go to cloud completely, you will have a coexistence of both systems for a while. Second reason would be legal compliance and government regulation where companies high liabilities to risk data, overweight’s the advantage of cloud movement.

Some points worth considering

•  There is no wrong in having on premise systems if the reasons are justifiable and long-term vision is clear.
•  Carefully segment the business functionality across on-premise and cloud, try to be less chatty as possible across two.
• Data is foundation of coexisting system, where you keep your data, where you access it and what volumes of data you processing. Keep data close to application at least where volumes high and latency matters.
•  People challenges should be addressed upfront. Two things to address are skills and resistance to change. Both are easy to address if cascaded Top Down. Message should be clear that organisation is going to cloud and up skilling opportunity will be provided to the employees. Set a time frame and make it clear what’s coming post that. Sometime fear of change has to be overcome with bigger fears. 

Public Vs Private Cloud

Why would you need private cloud? Maybe you not able to host data on cloud for due to the legal and other challenges, you are still new to cloud and what to play with private cloud first before going to public. Identify and validate your reasons.

This is a decision you need to think as private cloud comes with its own challenges.

•  There are multiple foundation blocks (Security, high availability, obervablity etc) which public cloud provider takes care, while in private cloud you need to build and manage.
• You need to have an experienced cloud team to build and manage private cloud, if you just entering the cloud you might not have right skills and people, hire them.
• Understand the limitation of private cloud/platform you choose and purpose it within those limitations.
• While it’s good to re-skill existing employees, you cannot build and manage private cloud with people who have not done it before.
•  Then come communication between you on premise, public and private cloud, adding the complexity and it costs.

Consider the weightage and complexity of the having a private cloud over the ROI. Many public clouds provided platform for on-premise needs, evaluate those as though early in game, they have rich features and future roadmap.

Multi Cloud - Vendor Agnostic

This one is my personal favourite. Primary reason for its existence is Cost negotiation. Leaderships in past have burned their hands with single vendors where technologies were rigid and hard to migrate from one platform to other. However things have changed in cloud.

Some of the thoughts you will have while considering a multi cloud strategy

• Cost Negotiation
• Feature diversity allows you to use features across clouds providers, having said that still there is small set of services where you put most of your money in cloud, so focus on those.
• In case something goes wrong with one vendor ?
• Flexibility is powerful, however need to be rooted in your application architecture and design so applications can move across clouds, surely its not always lift and shift but depending on how you design could be easy or difficult.

What tradeoff comes with these when going multi cloud.

• Business spread across two platforms adds complexity with intra vendor communication.
• In trying to be vendor agnostic do not loose the advantages of using cloud native services. Many time is easy to use and manage services which is ready to use , no point reinventing the wheel.
• Cost of data movement between clouds is something you need to consider. Most of the vendor will not encourage cross vendor movements and you could hit technical limitations and high data movement charges.
• Managing process and business functions across the cloud become your responsibility and advantages you get with cloud provider managed services get limited. Basically, you are using cloud infrastructure and self-managing it. This needs a larger IT staff like pre cloud era, though the skills and role will be different but cost adds on. e.g. Building application observability across the multiple clouds 
• Initially you might get good deals and discounts, but in long term as margin reduces price differentiation would not be big advantage across vendors. It’s like e commerce boom time deals which stabilised over the time.

 In summary having a multi cloud strategy need to be well thought and identify the areas where it makes sense. Do not complex your system, management cost and organisation structure just to negotiate the initial discount and prices, you may end up paying more in long terms will sub optimised application architecture which would be hard to manage and fix.

Whatever strategy you pick thumb rule here is having clear vision of the final state and transition journey. Communicate that very clearly, you need a buy in and commitment from the people executing it. It takes time to evolve and know you are going in right direction, track closely, get the right people to do it for you, even fail fast could be a costly affair. Time is essence in this journey as things would change on rapid pace, once lagging behind, you will always be in catchup mode.