Extend to the Cloud Using REST API and Workflows
Every conference I attend leaves me with the same mixed feelings: excitement about what I learned, disappointment at what I missed and a foggy feeling of information overload. If you missed my session at Commvault GO, Commvault’s inaugural customer conference, I’m guessing it was because you were stranded in an airport waiting for a missed connection. But regardless of the reason (which, why would there be any other reason?), here’s what you missed. See “Demos and Trials” up at the top of the page here? Those free trials that you can sign up for require communications across two clouds and an on-prem server, provisioning and permissioning. This is how we did it.
<side note> Did you know that the proper full singular form of “on-prem” is “on-premises?" Often abbreviated “on-prem,” it’s easy to mistakenly use on-premise, but it turns out that actually means something quite different, according to our copywriter. I'll stick with “on-prem” for now. ;) </side note>
Back to the topic at hand.
SaaS, IaaS, PaaS
Eventually everything will be offered as a service (XaaS).
They’re not just acronyms, they’re architectures behind business critical applications. In my case, a website that’s PaaS and a marketing automation platform that’s SaaS are two worlds apart. The only commonality is that they’re both considered “The Cloud,” which I’ve been told means “someone else’s computer.” A complete oversimplification of the cloud, it’s actually a pretty good way to think about the cloud for this conversation. If it’s someone else’s computer, do you think they’re going to let you execute arbitrary code on it? Not without some serious restrictions. Restrictions that usually come in the form of blocked ports and protocols, and inside of a sandbox. So where do you turn when you need to build integrations in the cloud and between clouds?
It’s not just what you needed after drifting trikes at GO Play on Wednesday night.
A decade ago, integration was a scary word that involved dollar signs and time. And most integrations of the past were built to support a single case with no future-proofing. Eventually companies started offering APIs for integration, but with each API came a different technology preference. No one wants to be forced to code in C++ just because that’s what the API was built on, so often times APIs were difficult to use and expensive to maintain. Fast forward a bit and we started to see web based APIs popping up. This was about the time of Web 2.0, when AJAX (remember when that was bigger than cloud!?) was the driving force. These started out as XML-RPC, which evolved into a slightly more structured SOAP.
While it opened up application developers’ options, SOAP was tolerated not loved. Eventually REST became the standard, mainly for its simplicity and open format. Today, RESTful APIs are the calling card of a Cloud era company.
Combine the Commvault REST API with its powerful workflow automation engine and you start to understand what a modern data platform looks like. It’s much more than backup. It’s bright, open and ready for you to put it to work building your future, today. If you were at GO, you hopefully got a glimpse of that future in our Hands-On Labs, or Data Cube Mini Theater. If you weren’t able to attend, use the comments here, or the contact us button at the top of the page to find out what you missed!