We knew multi-cloud was coming, and now that Microsoft and Google have a viable product in the infrastructure as a service (IaaS) space, multi-cloud may be in your future.
If you consume software-as-a-service, you most likely are already “multi-cloud”. In this article, my focus will be on Infrastructure as a Service (IaaS) and I’ll examine the value of multi-cloud, the considerations, and address what I think are myths.
Value
There is value in considering multi-cloud. Here are a few.
- If you are a big company, one of the things that being multi-cloud can bring is the “champion and challenger” model from a sourcing perspective. Sourcing managers hate soul source deals because they put the company at a disadvantage when it comes to negotiating better deals.
- Sometimes you need access to features and technologies that you can’t get with your current provider. This is an obvious one but requires the technologists to really address the differentiation and question the ROI.
- Multi-cloud can bring complete and total redundancy. For example, I’m told that Netflix is ready to deliver out of the Azure cloud if the binary-spew really hits the fan. Google definitely touted this after the AWS S3 outage on the east coast.
Myths
Vendors want you to believe that being multi-cloud is easy and everyone should be multi-cloud. I mentioned some of this in my coverage of Google’s cloud conference article. Providers and pundits may have sold you on running everything in containers so you can burst your workloads or move them easily between clouds to get the lowest cost of the day. This sounds great but I don’t think it’s that easy. Here’s a few reasons why:
- Applications rarely live in isolation, they have data attached to them. At this point in time, no architect would recommend you move the application without the data. Moving an entire application takes planning and a lot of work.
- Dependency impacts will need to be evaluated. Many applications depend on other services. If you have micro-services within your dependency chain, you have a whole new set of things to think about.
- Your architects will need to consider how you integrate all of your solutions.
- Applications will need to be tested in both environments from both behavior as well as performance and how various failure-modes are handled. In addition, security is handled different in each cloud as well as how you configure services like load balancing.
- Any cloud automation scripts you have most likely won’t be portable.
- You need to consider all of the cloud provider setup & operational costs outlined below.
The costs of multi-cloud
Just getting to the first IaaS cloud can be expensive. If you are part of large corporation, you’ve probably invested in network, training, tooling, and spent a lot of effort on all of the vendor management items to get you to your first cloud. Before you could start moving workloads, your security team needed to learn how to secure it, your identity and access management team may have had to setup beachhead services to support applications there, and your operations team needs to learn how to monitor and manage the governance of onboarding accounts as well as how you would handle billing.
Below is a list of example costs that you need to overcome with a strong ROI for each cloud you want to engage with. Take a look at each area and the staffing to support it. If you can do it with existing staff, that’s great, but don’t kid yourself, it’s more work to setup, manage, and operate each cloud.
- Vendor management. This obviously is the first step of engaging the vendor and starting the work on getting them on-boarded into your process. This is also one of those on-going operational tasks that you will need to own.
- Contract management. Depending on your company, this can be a lot of work to initiate, negotiate and finalize and maintain if you have SLA provisions.
- Security assessment and remediation plans. This is where the work begins with your security team.
- Building a reference architecture to use to ensure security compliance.
- Building re-usable templates for using new APIs and tools for infrastructure as code. If you are already in the cloud, you’ll need to retool for the next cloud and adopt different APIs, tools, and adapt to their approach to security and monitoring.
- Development of tooling that allows automated testing and monitoring of security.
- Establish secure redundant network connectivity.
- Possibly establish beachhead services like LDAP, and single sign-on services.
- Account management needs to be setup. How are you going to manage and govern accounts in the new cloud. This will be one of those things you want to stay ahead of.
- Cloud operations, which at a minimum, can help manage your costs at an enterprise level and help find opportunities to continually lower costs.
- Consider the cost to integrate with the company’s CMDB solution. Remember, just because you have services in the cloud doesn’t mean you break with managing your portfolio of services and exactly how they are deployed. If you use AWS, this step can be fairly straightforward by integrating into the AWS billing DB, using AWS config, or purchasing a plug-in from your CMDB vendor to do this for you.
- Every new cloud means you fragment your talent development... Said another way, you can be an expert on one cloud but going multi-cloud fragments your time. Operation and dev teams can just deal with this fact or you deploy dedicated teams to be the experts on each platform. As the complexity goes up, the latter is your path to sanity.
If you think multi-cloud is in your future, you’ll need to code that into your requirements and resulting architecture. For example, if you want to leverage AWS Lambda for serverless computing, remember that it works different at Google. Also, if you use Google Cloud Spanner, think about compatibility with database stacks from AWS. Take a second look at your integration strategy and ensure your tools will work in the future state architecture.
The right number of clouds really depends on how much leverage you need, what the variation in services are that drive your decision and the ROI that tells the story to the CFO. Being multi-cloud it’s more complicated than the pointy-haired boss thinks, and in some ways it can be as difficult as it was when you moved from your on-premise data center to the cloud.
Reference & Other Relevant Info
- How to keep multicloud complexity under control by David Linthicum
-- Chris Claborne
(AKA Christian Claborne)
No comments:
Post a Comment