Earlier this year at the Google Cloud Next event, Google announced the launch of its new managed service offering for multi-cloud environments, Google Cloud Anthos.
The benefits of public cloud, like cost savings and higher levels of productivity, are often presented as an “all or nothing” choice to enterprises. However, with this offering, Google is acknowledging that multi-cloud environments are the reality as organizations see the value of expanding their cloud platform portfolios. Anthos is Google’s answer to the challenges enterprises face when adopting cloud solutions alongside their on-prem environments. It aims to enable customers to evolve into a hybrid and multi-cloud environment to take advantage of scalability, flexibility, and global reach. In the theory of “write once, run anywhere”, Anthos also promises to give developers the ability to build once and run apps anywhere on their multi-cloud environments.
Anthos embraces open-source technology
Google Cloud Anthos is based on the Cloud Services Platform that Google introduced last year. Google’s vision is to integrate the family of cloud services together.
Anthos is generally available on both Google Cloud Platform (GCP) with Google Kubernetes Engine (GKE) and data centers with GKE On-Prem. So how does Google aim to deliver on the multi-cloud promise? It embraces open-source technology standards to let you build, manage and run modern hybrid applications on existing on-prem environments or in public cloud. Moreover, Anthos offers a flexible way to shift workloads from third-party clouds, such as Amazon Web Services (AWS) and Microsoft Azure to GCP and vice-versa. This allows users not to worry about getting locked-in to a provider.
As a 100% software solution, Anthos gives businesses operational consistency by running quickly on any existing hardware. Anthos leverages open APIs, giving developers the freedom to modernize. And, it automatically updates with the latest feature updates and security patches, because is based on GKE.
Rapid cloud transformation from Anthos
Google also introduced Migrate for Anthos at Cloud Next, which automates the process of migrating virtual machines (VM) to a container in GKE, regardless of whether the VM is set up on-prem or in the cloud lets users convert workloads directly into containers in GKE. Migrate for Anthos makes the workload portability less difficult both technically and in terms of developer skills when migrating.
Though most digital transformations are a mix of different strategies, for the workloads that will benefit the most, containers, migrating with Anthos will deliver a fast, smooth path to modernization according to Migrate for Anthos Beta.
Streamlining multi-cloud management with Anthos
Another piece of the offering is Anthos Config Management, which lets users streamline confirmation so they can create multi-cluster policies out of the box, set and enforce secure role-based access controls, resource quotas, and create namespaces. The capability to automate policy and security also works with their open-source independent service for microservices, Istio.
The management platform also lets users create common configurations for all administrative policies that apply to their Kubernetes clusters both on-prem and cloud. Users can define and enforce configurations globally, validate configurations with the built-in validator that reviews every line of code before it gets to the repository, and actively monitors them.
Expanded Services for Anthos
Google Cloud is expanding its Anthos platform with Anthos Service Mesh and Cloud Run for Anthos serverless capabilities, announced last week and currently in beta.
The first is Anthos Service Mesh, which is built on Istio APIs, is designed to connect, secure, monitor and manage microservice running in containerized environments, all through a single administrative dashboard that tracks the application’s traffic. This new service is aimed to improve the developer experience by making it easier to manage and troubleshoot the complexities of the multi-cloud environment.
Another update Google introduced was Cloud Run for Anthos. This managed service for serverless computing allows users to easily run stateless workloads on a fully managed Anthos environment without having to manage those cloud resources. It only charges for access when the application needs resources. Cloud Run for Anthos can run workloads on Google Cloud on on-premises and is limited to Google’s Cloud Platform (GCP) only.
Both AWS and Azure have hybrid cloud offerings but are not the same, mostly for one single reason.
AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility, in the same operating idea as Anthos, using the same AWS APIs, tools, and infrastructure across on-prem and the AWS cloud to deliver a seamless and consistent for an AWS hybrid experience.
As an extension of Azure to consistently build and run hybrid applications across their cloud and on-prem environments, Azure Stack delivers a solution for workloads wherever they reside and gives them access to connect to Azure Stack for cloud services.
As you can see, the main difference is that both AWS Outposts and Azure Stack are limited to combining on-premises infrastructure and the respective cloud provider itself, with no support for other cloud providers, unlike Anthos. Google Cloud Anthos manages hybrid multi-cloud environments, not just hybrid cloud environments, making it a unique offering for multi-cloud environment users.
AWS offers a number of discount options for their cloud resources, of which one of the more interesting is AWS spot instances. Spot instances offer an alluring discount for spare capacity – but of course, this purchasing option can’t be used the same way as on demand infrastructure. Here are seven things you should know about AWS spot instances, which may help you decide whether or not you should be using them.
1. What Spot Instances Are
AWS spot instances are not a specific type of instance – rather, this is the name of a purchasing option that allows users to take advantage of spare capacity at a low price, with the possibility that it could be reclaimed for other workloads with just a two minute notice. If the price goes above your maximum set price, your workload will also be interrupted.
This means that workloads need to be specifically designed for fault tolerance, though AWS claims that spot instances are interrupted less than 5% of the time. With spot instance hibernation, interrupted instances need not be terminated. Rather, they can be essentially paused, with the memory saved to the root EBS volume, then reloaded when the machine is resumed.
2. Best Practice: Spot Fleets
Spot Fleets are collections of instances, including Spot Instances and optionally On Demand instances. When provisioning a spot fleet, you can set a target capacity for the fleet, and the request will be fulfilled if there is available capacity.
AWS recommends Spot Fleets as a best practice. One reason is that you can use fleets to request multiple instance types simultaneously – which not only increases the likelihood that your request is filled, but can mitigate cost risks by setting a maximum cost per hour for the whole fleet rather than a specific spot pool (group of instances with the same instance type, operating system, availability zone, and network platform).
3. When to Use AWS Spot Instances
Since Spot Instances are interruptible, you’ll need to limit your usage of them to fault-tolerant workloads.
Time critical workloads should have instances be automatically replaced, either by restarting workloads on a new instance, or for production websites, send users to a different instance using a load balancer.
Common use cases for spot instances include:
- Batch processing
- Web services
- CI/CD development
- Hadoop data processing
- Image rendering
- Big data analytics
- Machine learning
- Video transcoding
- Massively parallel computations
AWS recently announced that spot instances will now be available in US GovCloud regions, putting them available in 21 regions and 66 availability zones. They’re only available for EC2 instances.
If you’ve read any older (pre-fall-2017) articles about Spot Instances, you’ll see a lot of talk about bidding strategies and spikes in pricing. AWS seems to have listened to customers’ complaints that this system was confusing, and in response, they changed the pricing mechanism in November 2017. Now, spot instance prices do still adjust based on trends, but these trends are longer term and gradual. There is no bidding function. Instead, you pay the spot price that’s in effect for the current hour, with the option to set a maximum price you are willing to pay.
6. Savings Potential
To compare current savings over on demand pricing, you’ll want to visit AWS’s spot instance advisor. A quick check shows savings largely in the 70-80% range for Linux OS and in the 40-50% range for Windows OS, with a few instance types showing anomalies at 0% savings.
For longer-running systems, reserved instances or on demand instances with on/off schedules may be better, so you should evaluate the savings rate for all three based on the workload.
When determining whether this amount of savings will be worthwhile, remember to consider any labor costs of building and maintaining your application to tolerate interruptions.
7. How AWS’s Option Compares to Other Clouds
It’s always worth considering how the major cloud providers approach similar offerings. Comparable to AWS spot instances, Microsoft Azure has low priority VMs while Google Cloud offers preemptible VMs. As the names of both of these offerings highlight, they, too, are interruptible instances offered at a discount.
There are a few main differences to highlight. Both Azure and Google offer fixed discounting structures, offering clarity and predictability on pricing. Google’s offering is a bit more flexible, with no limitations on the instance types. On the other hand, Azure users report issues with scaling to large numbers of VMs, with many VM types having limited availability. You also must launch in Batch/Scale Sets, with no option for an individual VM.
Should You Adopt an AWS Spot Instance Strategy?
Whether you adopt an AWS spot instance-focused strategy depends on your workloads, your application, and your expertise. But if you can address the issues of fault tolerance, then most likely, yes: the savings from spot instances will be worth your while.
After reviewing the fiscal earnings report for 2019 and the most recent quarterly report from June for the ‘big three’ cloud providers, we thought it was time to take a closer look at the Alibaba Cloud market share. Looking at the numbers, it’s obvious that AWS is still number one overall, but other cloud service providers are not trailing far behind.
Alibaba is at the top of the market in Asia, and dominating in China with cloud revenue up 66% year-over-year. While Alibaba is in the top 5 CSPs worldwide, they still have a lot of plans for the future to maintain this growth and continue to move up. Here’s the deal with Ali Cloud and why it should not be overlooked in 2019.
Note: a version of this post was originally published in May 2018. It has been completely rewritten and updated for 2019.
Alibaba Cloud at a Glance
Following Amazon’s AWS, Google Cloud, and Microsoft Azure, AliCloud is making headlines of its own after they released their latest quarterly revenue and full fiscal year 2019 reports:
To see how much the Alibaba Cloud has grown, here are the 2018 headlines we gathered last year:
Here’s what Alibaba’s 2019 annual reports tell us:
- Cloud computing revenue grew 66% YoY in the most recent June quarter to $1.134 billion.
- For 2019, Alibaba’s annual cloud revenue reached $3.68 billion for the full fiscal year, an 84% increase from last year.
- In comparison, AWS growth was at 45 percent for the same period, and Azure was a surprising 64% YoY – the lowest it’s been in years.
- However, Alibaba’s cloud revenue can’t quite compare with the $30 billion and $33.7 billion generated for 2019 by AWS and Microsoft Azure, respectively.
- Alibaba Cloud, or Aliyun as some call it, accounts for 7% of Alibaba revenue. For comparison to the other big cloud + retail giant, AWS accounts for 13% of Amazon revenue.
- According to IDC, Alibaba Cloud has grown by 76% annually to hit $1.51 Billion in revenue.
Ali Cloud’s Market Presence
Alibaba is growing its market presence, not only with a firm hold over Asia, but also securing a spot as one of the top 5 cloud providers worldwide. Synergy Research Group reported Q2 2019 cloud market share numbers: Amazon 33%, Microsoft 13%, Google 8%, IBM 6%, and Alibaba 5%. Although Alibaba ranks lowest among the top five, they show consistently steady, upward growth, and land only a hair shy of catching up to IBM at 6 percent.
While AWS has a third of the total market share, Alibaba is holding onto a whopping 47.3% of China’s cloud computing market share. Out of all the China cloud providers, Alibaba is clearly in the lead with the biggest market share. According to Canalys findings, the closest competitor Alibaba Cloud has is Tencent Cloud who holds 15.4% of the China cloud market share. AWS comes in third holding 8.8% of the cloud market share in China.
So far this year, they have opened a second data center in Japan, as well as Indonesia. With the two data centers in Japan, AliCloud will offer 50+ services, such as elastic computing, image search, database, networking, disaster recovery, and storage services. These services can cater to key sectors.
Not only is Alibaba Cloud expanding their cloud footprint in the Asia-Pacific, but they have also recently expanded their reach to offer services in Brazil. They are focused on the bigger picture and continuing to increase their presence in the global marketplace. The company is growing at a rapid rate thanks to an increase in average revenue per customer. Alibaba is currently operating at a global scale in 55 availability zones across 19 regions around the world.
Not only is Alibaba expanding the number of data centers, but they also launched over 300 new cloud services during the June 2019 quarter. These include products and features that are related to core cloud offerings, security, AI applications, and data intelligence. On top of that, Alibaba also caught attention when it was named Salesforce’s exclusive provider in China. In an effort to expand their SaaS offerings, Alibaba cloud announced their SaaS Accelerator program. The goal of the SaaS Accelerator is to enable a seamless integration of SaaS offerings for vendors running on Alibaba Cloud.
We have seen that they are the public cloud provider that has shown the most YoY growth and Aliyun is proving that they are a force to be reckoned with and are showing no signs of slowing down anytime soon.
What People Are Saying
John Dinsdale, chief analyst and research director at Synergy Research Group, says “While not all cloud providers have released their Q4 numbers yet, it is quite evident that Alibaba growth has once again outpaced overall market growth”
Daniel Zhang, CEO of Alibaba Group, says “Our growth is driven by the power of Alibaba’s cloud and data technology that helps expedite the digital transformation of millions of enterprises.”
“The growth, evolution, and operating margin profile of Alibaba’s cloud services are following, and should continue to follow, the same path. At present, AWS represents only about 1/9th of Amazon revenue but generates over 60% of its operating profit. There is little reason to believe that Alibaba’s cloud business will somehow veer off trajectory and be different,” said John Freeman, equity analyst at CFRA Research.
“Alibaba’s advanced, secure infrastructure and knowledge of these markets will empower our global customers with a solution that meets local business needs,” said Salesforce, Alibaba’s newest strategic partner.
Alibaba Cloud Market Share – 2019 and Beyond:
So as we continue to see Alibaba cloud market share growth, could they be the next big cloud provider in 2019? Will they jump into the ‘big three’ or will it become a ‘big five,’ including IBM market share? What we know for sure is that we can expect more growth, and that’s a good thing for all of us because growth drives competition, innovation, and better offerings for all. The cloud market is constantly changing, so while we continue looking at AWS, Azure, Google, and IBM in the next year, we’ll also be keeping an eye on Alibaba Cloud to see what they bring to the table.
It’s unlikely that Alibaba will be keeping up with AWS, Azure or GCP in the United States anytime in the near future. We’ll keep up with the changes in the cloud market to see if this changes.
When evaluating public cloud providers, whether to choose the best for your environment or simply to try to decipher the disparity in market share, it can be easy to get hung up on the differences. AWS, Microsoft Azure, and Google Cloud each have their own service catalog, pricing and purchasing variations, and flavor. But do these differences actually matter?
What’s Actually Different Between Cloud Providers?
Let’s take a look at some of the differences between the various cloud providers.
First up is terminology. At first glance, it may seem like the cloud providers each have a unique spread of offerings, but many of these products and services are quite similar once you get the names aligned. Here are a few examples:
Obviously, this is not a sign of substantive differences in offerings – and just goes to show that the providers are often more similar than it might appear at first glance.
Though we are able to align comparable products across AWS, Azure, and Google Cloud, there are of course differences between these offerings. In fact, with the number of products and services available today (we’ve counted 176 from AWS alone), comparing each is beyond the scope of this single blog post.
For our purposes, we can compare what is still the core product for cloud service providers: compute. Compute products make up about ⅔ of most companies’ cloud bills, so the similarities and differences here will account for the core of most users’ cloud experiences.
Here’s a brief comparison of the compute option features across cloud providers:
Of course, if you plan to make heavy use of a particular service, such as Function-as-a-Service/serverless, you’ll want to do a detailed comparison of those offerings on their own.
That covers functionality. How do the prices compare? One way to do this is by selecting a particular resource type, finding comparable versions across the cloud providers, and comparing prices. Here’s an example of a few instances’ costs as of this writing (all are Linux OS):
For more accurate results, pull up each cloud provider’s price list. Of course, not all instance types will be as easy to compare across providers – especially once you get outside the core compute offerings into options that are more variable, more configurable, and perhaps even charged differently (in fact, AWS and Google actually charge per second).
Note that AWS and Azure list distinct prices for instance types with the Windows OS, while Google Cloud adds a per-core license charge, on top of the base instance cost.
The table above represents the default On Demand pricing options. However, each provider offers a variety of methods to reduce these base costs, which we’ll look at in the Purchasing Options section below.
Comparisons of the myriad purchasing options are worth several blog posts on their own, so we’ll keep it high level here. These are the most commonly used – and discussed – options to lower costs from the listed On Demand prices for AWS, Microsoft Azure, and Google Cloud.
Each of the major cloud providers offers a way for customers to purchase compute capacity in advance in exchange for a discount: AWS Reserved Instances, Azure Reserved Virtual Machine Instances, and Google Committed Use discounts. There are a few interesting variations, for example, AWS offers an option to purchase “Convertible Reserved Instances”, which allow reservations to be exchanged across families, operating systems, and instance sizes. On the other hand, Azure offers similar flexibility in their core Reserved VM option. Google Cloud’s program is somewhat more flexible regarding resources, as customers must only select a number of vCPUs and memory, rather than a specific instance size and type.
What about if you change your mind? AWS users have the option to resell their reservations on a marketplace if they decide they’re no longer needed, while Azure users will pay a penalty to cancel, and Google users cannot cancel.
Spot and Preemptible Instances
Another discounting mechanism is the idea of spot instances in AWS, low-priority VMs in Azure, and preemptible VMs, as they’re called on Google. These options allow users to purchase unused capacity for a steep discount. The cost of this discount is that these instances can be interrupted (or perhaps Azure puts it best with their “evicted” term) in favor of higher priority demand – i.e. someone who paid more. For this reason, this pricing structure is best used for fault-tolerant applications and short-lived processes, such as financial modeling, rendering, testing, etc. While there are variations in the exact mechanisms for purchasing and using these instance types across clouds, they have similar discount amounts and use cases.
Sustained Use Discounts
Google Cloud Platform offers another cost-saving option that doesn’t have a direct equivalent in AWS or Azure: Sustained Use Discounts. This is an automatic, built-in discount for compute capacity, giving you a larger percentage off the more you run the instance. Be aware that the GCP prices listed can be somewhat misleading, as a sustained use discount is already built in, assuming full-month usage – but it is nice to see the cloud provider looking after its customers and requiring no extra cost or work for this discount.
A last sort of “purchasing option” is related to contract agreements. With all three major cloud providers, enterprise contracts are available. Typically, these are aimed at enterprise customers, and encourage large companies to commit to specific levels of usage and spend in exchange for an across-the-board discount – for example, AWS EDPs, Azure Enterprise Agreements. As these are not published options and will depend on the size of your infrastructure, your relationship with the cloud provider, etc., it’s hard to say what impact this will have on your bill and how it will compare between clouds.
Revenue & Market Share
As of earlier this year, AWS still dominates public cloud market share at 47%, while Azure and Google trail at 22% and 7% respectively. AWS quarterly sales are at least $7.7 billion – while Microsoft and Google avoid reporting specific numbers for public cloud but instead lump it in with other services, making revenue impossible to compare (other than an assumption that, yes, AWS is beating them.) Both report growth and their market share seems to be on the rise as well.
Does this matter? In some ways, yes. There’s a positive feedback loop in which larger enterprises will be more inclined to go with the solution that is serving the most large enterprises. And, AWS’s many-year head start and market advantage have let it develop more, and more innovative, offerings at a rapid pace. But ultimately we do not find the market picture to have any impact on functionality or availability.
It’s worth mentioning that you may also need to consider whether or not your organization competes with the cloud provider’s other lines of business. For example, many retailers specifically choose to avoid using AWS because they compete directly with Amazon. However, for most organizations, this is not an important factor to consider.
There’s also just the pure perception of the differences between cloud providers. Many folks perceive Azure as a bit stodgy, while Google Cloud seems slick but perhaps less performant than AWS.
Some appreciate AWS and Azure’s enterprise support and find Google Cloud lacking here, but this is changing as Google onboards more large customers and focuses on enterprise compatibility.
There are also perceptions regarding ease of use, but actually, we find these to be most affected by the platform you’re used to using. Ultimately, whatever you’re most familiar with is going to be the easiest – and any can be learned.
Do the Differences Matter?
On some of the factors we went through above, the cloud providers do have variations. But on many variables, the providers and their offerings are so similar as to be equivalent. If there’s a particular area that’s especially important to your business (such as serverless, or integration with Microsoft applications), you may find that it becomes the deciding factor.
And… that’s okay! The fact of the matter is, you’re likely to be using multiple clouds soon, if you’re not already – so you will have access to the advantages of each provider. Additionally, applications and data are now more portable than ever due to containers.
So, prepare yourself and your environment for a multi-cloud reality. Build your applications to avoid vendor lock-in. Use cloud-agnostic tools where possible to take advantage of the benefits of abstraction layers.
Even if you’re only considering one cloud at the moment, these choices will benefit you in the long run. And remember: if your company is telling you to use a specific cloud provider, or an obscure requirement drives you to one in particular – don’t worry. The differences don’t matter that much.
Many DevOps folks are inclined to use Hashicorp’s Terraform on AWS to manage infrastructure as code. This can have some Schroedinger-esque qualities to it, in that it can simplify your cloud management while also adding a layer of complexity to your toolset. If you’re already using Terraform, or are planning to start implementing infrastructure as code, then use these tips for better management of AWS deployments.
1. Use Terraform AND CloudFormation
This might come as a surprise, but not everyone wants to be involved in the holy war between Terraform and CloudFormation – and many have team members who use both tools. If this rings true for you, there’s no need to give up on CloudFormation. You can make use of the aws_cloudformation_stack resource type in Terraform. By using this, you can incorporate existing CloudFormation templates in your Terraform configurations, or you can make use of any potential features that aren’t available in Terraform. The “parameters” and “outputs” of the resource let you have a bidirectional communication between the two tools as well.
2. Run “terraform plan” early and often
One of the best things about infrastructure as code is that you can know what’s going to happen before it happens. Using the “terraform plan” command to get an output of any AWS infrastructure changes that would happen from the existing terraform configuration can help you plan, communicate, and document everything that happens during your change windows. Making a habit of getting the plan after even minor code changes can save you a bunch of headache from errors or misunderstood edits.
3. Be careful using Autoscaling Groups with Terraform
AWS Autoscaling Groups are a great idea on paper, but can cause headaches (and often at the worst possible times) in practice due to either scaling too much or not enough. The biggest key for this is that you need to not only build out your ASG in Terraform, but also define the scaling policies, scaling boundaries, and know how to handle graceful termination and data storage. You also need to know what it looks like if Terraform expects one setup, but you’ve parked your resources for cost savings or suspended any ASG processes. This can be a challenge when you try to test your scaling policies, or if you don’t use ASGs the same way in development environments.
4. Adopt a “microservices” architecture with your configurations
Splitting your Terraform configuration into multiple files might seem like you’re just adding complexity, but this “microservices” approach can really help with management in large organizations. By making heavy use of output variables, you can coordinate configurations as needed, or you can keep things isolated for risk mitigation in case a configuration doesn’t do what you intended. Separate files also helps you keep track of what’s changing and where for audit logging purposes.
5. Create reusable modules specific to your organization
Along a similar line to number 4 above, creating smaller configurations can help you reuse code for different projects or teams. Reusable modules that are specific to what you do as a company can help accelerate deployment in the future, and can help with non-production workloads when developers want an AWS environment that is as close to production as possible.
Using Terraform on AWS can be a fantastic tool for defining your cloud infrastructure in an easily-deployable way, but can be daunting if you are trying to just get started or scale out to fit a larger enterprise. Use these tips to help save some frustration while making full use of the power of AWS!
One of the key drivers to a multi-cloud strategy is the fear of vendor lock-in. “Vendor lock-in” means that a customer is dependent on a particular vendor for products and services, and unable to use another vendor without substantial switching costs or operational impact. The vendor lock-in problem in cloud computing is the situation where customers are dependent (i.e. locked-in) on a single cloud service provider (CSP) technology implementation and cannot easily move to a different vendor without substantial costs or technical incompatibilities.
Vendor Lock-in: Public Cloud vs. Traditional Infrastructure
Before the cloud, IT was running in dedicated on-premises environments, requiring long-term capital investments and an array of software license commitments and never ending hardware refresh contracts. Based on that experience, it is understandable that a customer would be concerned about lock-in. Many large IT vendors like Oracle, IBM, HP, and Cisco would “lock” customers into 3-5-10 year Enterprise License Agreements (ELAs) or All You Can Eat (AYCE) hardware and software license agreements, promising huge discounts and greater buying power – but only for their products, of course. I used to sell these multi-year contracts. There is a common ground for sure, as the customer was locked-in to the vendor for years. But that was then and this is now. Is vendor lock-in really a concern for public cloud users?
Isn’t the point of cloud to provide organizations the agility to speed innovation and save costs by quickly scaling their infrastructure up and down? I mean, we get it – your servers, data, networking, user management, and much more are in the hands of one company, so the dependence on your CSP is huge. And if something goes wrong, it can be very detrimental to your business – your IT is in the cloud, and if you’re like us, your entire business is developed, built and run in the cloud. Most likely, some or all of your organization’s IT infrastructure where you are developing, building and running applications to power your business and generate revenue, is now off-premise, in the cloud. But although “lock-in” sounds scary, you are not stuck in the same way that you were with traditional hardware and software purchases.
Can You Really Get “Locked In” to Public Cloud?
Let’s talk about the realities of today’s public cloud-based world. Here are a couple of reasons why vendor lock-in isn’t as widespread a problem as you might think:
- No Long-Term Commitments: Customers can adopt the cloud on their own terms. AWS, Azure, and Google Clouds are designed so customers only use the services when they see value, and they are free to use the technology of their choice. Pay-as-you-go pricing provides customers with the ability to shut down their environment, export their data and virtual machines (VMs), and walk away without ever incurring another expense. Customers are billed monthly without any required long-term commitments or contracts regardless of spend or support tier.
- Customer Choice: Today’s cloud customers have alternatives to proprietary tools with advances in open source software technologies, along with a range of ‘as-a-service’ capabilities that can remake traditional IT — IaaS, PaaS, and even SaaS. A wide range of solutions that support industry standards allow customers to choose what they want to invest in and architect for application portability from the beginning, if they so choose.
- Moving Into and Out of a CSP: Generally speaking, cloud services are built to support both migration into and out of their platforms, and CSPs and the industry at large provide many tools and documented techniques to make it easy to do both. Many cloud service providers offer tools to help move data between networks and technology partners. Customers can securely move information in and out of the cloud regardless of where that information is going: cloud-to-cloud or cloud-to-data center.
How to Mitigate Risk with a Multi-Cloud Strategy
Now the cloud is not without risk, and when we talk to customers the primary vendor lock-in concerns we hear are related to moving to another cloud service provider IF something goes awry. You hope that this never has to happen, but it’s a possibility. The general risks include:
- Data transfer risk – it is not easy to move your data from CSP to another.
- Application transfer risk – If you build an application on one CSP that leverages many of its offerings, the reconfiguration of this application to run natively on another provider can be an extremely expensive and difficult process
- Infrastructure transfer risk – Every major CSP does things a little bit differently.
- Human knowledge risk – simply put, AWS is not the same as Azure which is not the same as GCP, and your IT team has likely gained a lot of institutional knowledge about that provider’s tools and configurations.
To minimize the risk of vendor lock-in, your applications should be built or migrated to be as flexible and loosely coupled as possible. Cloud application components should be loosely linked with the application components that interact with them. And, adopt a multi-cloud strategy.
How Much Should You Worry About Vendor Lock-In?
Many companies are familiar with vendor lock-in from dealing with traditional enterprise companies mentioned above – you begin to use a service only to realize too late what the terms of that relationship brings with it in regards to cost and additional features and services. The same is not entirely true with selecting a cloud service provider like AWS, Azure, or Google Cloud. It’s difficult to avoid some form of dependence as you use the new capabilities and native tools of a given cloud platform. In our own case, we use AWS and we can’t just wake up tomorrow and use Azure or Google Cloud. However, it’s quite possible to set your business up to maintain enough freedom and mitigate risk, so you can feel good about your flexibility.
So how much should enterprises worry about vendor lock-in in public cloud? IMHO: they shouldn’t.