If you are a hardware vendor these days, you’re probably worried about staying relevant in an IT world where the future points to cloud. Public cloud vendors such as Amazon Web Services and Microsoft Azure are on-boarding customers at a fast pace and workloads are being moved out of traditional data centers. This trend is probably cause for alarm for many hardware vendors unless they are providing equipment to these public clouds directly.
The move to cloud is so prevalent in the IT world that product teams are trying to find ways to make their own products be cloud products. Products are being renamed with cloud in the product’s name. Rubrik’s own Internet page title is “The Cloud Data Management Company” which just screams at customers that it’s a cutting edge future looking company.
So, the question is, “Is Rubrik really a cloud solution like their page title suggests?” To answer that we should ask another question which is, “What are the characteristics of a cloud product?” This is a very difficult question to answer and leaves too much room for ambiguity. This lack of formal definition creates the opportunity for almost any product vendor to call their product “Cloud Ready.”
How about we investigate some commonly used characteristics for determining whether a product is a cloud product or not?
Can be Run from within a Public Cloud
If you can run a vendors product from within a public cloud, should that be the metric used for calling a product “Cloud Ready” or does this just mean it’s a virtual server? Many products, even if they are hardware solutions, really just run as software on commodity hardware. So porting that software to a virtual machine, virtual appliance or cloud instance is relatively easy to do. Should we consider every product that can be run as a virtual appliance a cloud product?
My take: It’s nice to be able to run a product directly within a public cloud but this alone does not make a product a true cloud solution.
Interactions with Public Clouds
This is a pretty interesting characteristic. Vendor solutions are now commonly leveraging public cloud resources to augment their own solutions. A pretty common one is using public cloud storage solutions like Amazon S3 or Glacier to store data. Storage solutions can add almost unlimited storage to their own product assuming they can withstand the latency of pushing data to a public cloud storage service.
My take: This seems like a pretty good characteristic to me. Making use of a public cloud resource to enhance another product makes it feel pretty cloudy to me.
APIs
If you’re building a product these days you had better make sure it has an application program interface (API). A common misconception is that “cloud” means that it has to be public cloud. The truth is private clouds are a viable option as well, but there needs to be some automated provisioning as part of the deployment and deprovisioning. Try automating anything when there isn’t an API available to execute commands against a product. It makes it very difficult if it’s possible at all.
My take: My thoughts on APIs as a characteristic of cloud is this: If you have an API, it doesn’t make it a cloud product, but if it doesn’t have an API, it is NOT a cloud solution. APIs are table stakes these days and if your product doesn’t have one, you’d be hard pressed to call it a cloud solution.
Have Some Level of Automation
This characteristic fits along with the APIs characteristic. Clouds need to be elastic and this elasticity needs to be really easy to manage. Deploying new services, removing old services, and removing the technical debt surrounding those operations should be an important consideration of a cloud solution.
My Take: Automation built into your vendor platform gives it a much more cloud like feel, but doesn’t necessarily make it a cloud product either.
What about Rubrik?
OK, so we defined some characteristics of cloud products, how does Rubrik stack up with our list?
First, the latest versions of the Rubrik code can be run as a virtual storage appliance within AWS. Second, Rubrik natively uses public cloud resources such as S3 for data archives and as of the 4.0 Atlas release, can instantiate workloads in EC2. Third, Rubrik has built the product with an API first mentality, meaning that everything you can do through the GUI, can be done through the API. In some cases you can do things through the API that can’t be done through the GUI. Lastly, Rubrik can be setup to automatically protect workloads based on a folder structure making adding new backups easy to manage for new deployments.
Rubrik was able to check off each of the characteristics that we laid out earlier in some form or another. Yeah, it’s a hardware appliance that generally lives in a data center some place just humming along backing up workloads, but it does have plenty of cloud characteristics.
When I see a hardware vendor calling themselves a cloud product I’m usually skeptical, but it does make sense if you can support some of the tenets of a cloud product. It seems like many vendors have one or two of the characteristics mentioned above and they’re calling themselves a cloud product, so since Rubrik has capabilities in each of these areas, I think it’s safe to let them use the cloud moniker.
What do you think?
This post is part of a Rubrik Tech Talk series. For more information on this topic, please see the rest of the series HERE. To learn more about Rubrik, please visit https://www.Rubrik.com/.
[…] Eric Shanks wrote in his Gestalt IT blogpost, “Rubrik’s own Internet page title is ‘The Cloud Data Management Company’ which just […]
Hi
What I understand Rubik can run inside AWS as appliance but and reported quit good but what about Azure are they any known major bugs to be aware of ??
Secondly I would like to see support for off siting to tape outside of cloud. (could not find any ) are there ways to do that. One can ask why ?? than read about when Azure was done for 7 days so off siting and disaster recovery plans outside of offered solutions could be a live line….