Bitmovin was built from the ground up with Multi-Cloud in mind. It can run on virtually any cloud!
From the first line of code, the Bitmovin Cloud Encoding Service was designed to be a true Multi-Cloud service, which means it can easily move from one cloud to another providing you with a very high level of control and flexibility! This helps you to remove vendor lock-in’s, offers you more flexibility and makes your application resilient to cloud outages and maintenance. (Download the Encoding Datasheet)
What is Multi-Cloud?
Multi-Cloud sounds like another buzzword, and on some levels it is, but let’s take a closer look. Multi-Cloud is simply a deployment strategy that enables your services and applications to run concurrently on different cloud providers such as AWS, Google or Azure. This is currently a big trend in the IT industry. In a recent survey from Dimensional Research, including more than 650 IT decision makers, the vast majority (77%) responded that they intended to implement Multi-Cloud architectures.
There are various reasons for the popularity of Multi-Cloud, but one of the most obvious and important ones is that this prevents a vendor lock-in. The ability to easily switch between clouds gives you a much better starting point when it comes to negotiating terms with your cloud provider, and avoids situations where you might get locked in with a single provider. Beside that it allows your IT infrastructure to be more flexible, scalable and resilient to cloud outages and maintenance.
3 Reasons Why Multi-Cloud Makes Sense
1. Advanced Cloud Capabilities
Nobody is perfect and it’s very unlikely that any one provider will ever be the best across all aspects of cloud infrastructure. Each cloud provider has advantages and disadvantages and they offer different services and features. For example, Google is particularly strong in Big Data and services like Google BigQuery work really well without specific setup when compared to AWS Redshift where you need to carefully configure resources like CPU and RAM. On the other hand AWS offers many more instance types in EC2 for specific workloads compared to Google Compute.
If your architecture is designed for Multi-Cloud usage you could use the specific features, services, locations and advantages of the different cloud providers
Taking a closer look at the datacenter locations of the different cloud providers also shows the differences as shown in the overview below. While Google has less locations, it still has compelling services but you will probably also need AWS and Azure if you want to deploy services and applications near to your customers. Even if datacenters from different cloud providers are in similar geographic locations, your users will experience different performance as all datacenters are connected differently. As a global cooperation you will need the performance and resources as near as possible to your customers and you will want to route different customers to different clouds and datacenters based on the performance that your users experience.
If your architecture is designed for Multi-Cloud usage you could use the specific features, services, locations and advantages of the different cloud providers. You could build your applications and services with the tools and services that fit best in the regions that are close to your customers and leverage unique cloud specific services when needed.
2. Redundancy and Disaster Recovery
Outages are a real problem and even AWS, Google and Azure have outages. For example, we have just seen an outage of the North Virginia region of AWS on June 9th 2016 and one major outage was on September 2015 which took several sites down including some big names such as; AirBnB, Netflix, Tinder, Reddit and IMDb. Of course this doesn’t happen every day (hopefully) but when it happens it’s usually a disaster for your IT department and a major problem for your business overall.
With a Multi-Cloud infrastructure this sort of downtime can be avoided by simply switching your load to another cloud without any impact on your users.
By switching load away from a failing region or service in a particular cloud, you can seamlessly avoid any downtime. The result is obviously a much better experience for your users and you can be sure that they certainly don’t care if your application or service is running on AWS, Google or Azure. They only care that your service is available and can be used when they need it.
3. Vendor Lock-In / Autonomy
A Multi-Cloud architecture will reduce your dependence on a single cloud provider and gives your more flexibility. Not being locked in with one cloud provider will help you to negotiate more favorable terms in case of service-level agreements, discounts and pricing. If AWS increases its pricing for a particular service that you are using heavily, you will have the option to switch to Google or negotiate on pricing with much more negotiation power.
Beside that it could always happen that cloud providers remove or disable services and/or change workflows that you are relying on, and again, in this case you will have the option to pick the next best offer at another cloud.
Bitmovin Multi-Cloud Video Encoding Service
Bitmovin was built from the ground up with Multi-Cloud in mind. Our services can virtually run on any cloud, making it somewhat unique in being a true Multi-Cloud encoding service. Nevertheless, the majority of our services run on AWS and Google simply because our customers use these clouds heavily. Having said that, we also have deployments on Azure and could easily deploy our services on any other cloud provider that offers Linux instances (which is pretty much everyone).
On June 9th, as AWS experienced a major outage, Bitmovin customers were seamlessly shifted across to the Google Cloud, avoiding any downtime.
Currently our enterprise customers can choose where their services should run and we also failover to other clouds if needed without any service interruption. On June 9th 2016 this is exactly what happened when the AWS North Virginia region had a major outage. We seamlessly shifted the load of our customers during that time to Google Cloud and afterwards back to the AWS North Virginia region when the outage has been resolved by AWS.
Needless to say that we also tightly integrate different cloud providers such as AWS, Google and Azure as inputs (where your video files come from) and outputs (where we transfer the encoded output to) for our Multi-Cloud Encoding Service. You could use AWS S3 with or without CloudFront in the same way as Google Cloud Storage with or without Fastly and you could easily switch between these storages if different projects or applications have different requirements.
In our new unified Bitmovin API that incorporates our encoding, player and analytics, our customers will be able to choose the cloud and region for every encoding through the API which gives you even more flexibility. This means you can build your own failover cases based on your needs and design specific disaster recovery plans.
Articles you might be interested in:
- How to build a Profitable VOD Service – Keeping the Lid on CDN and Storage Costs with Per-Title Encoding
- Per-Title Encoding Webinar: Netflix-Style Optimization for Quality and CDN Costs
