Tag: AWS

It’s snowing here on New Year’s Eve 2017 as I sit here in Northern Virginia, reflecting on the multitude of things that crammed themselves into the past 364 days. Turning the lens to Rubrik, I thought about all the features, enhancements and team members we added this year, and I wanted to take a moment to highlight my favorites. I think they’re pretty spectacular, while also being merely a few peaks that crested this year’s clouds.

#1: Cloud Cluster for AWS and Azure (BrikOS 3.2)

Rubrik Cloud Cluster was the culmination of a dream. It is the feature that truly transformed vision into reality. Rubrik’s tagline is “Cloud Data Management”, but to me, it felt shallow…nominal when that was limited to cloud archive (“CloudOut”) for long-term retention. Cloud Cluster changed everything.

It brought the same beautiful software stack to a highly flexible cloud platform (two, in fact: AWS and Azure), made protection of cloud-native applications possible, cloud mobility real, and terrestrial-free ascendance tangible.

Like the AWS and Azure clouds in which it runs, Rubrik Cloud Cluster is a subscription-based model with a low entry threshold, granular scale-out expansion (1TB at a time), and lean resource design. Contrary to industry collateral, “cloud” isn’t free, so the architecture choices we make should be conservative in their approach. We can’t afford to just lift-and-shift our resource demands and expect customers to pay the price for that laziness. That’s just one of the reasons I like Rubrik Cloud Cluster.

#2: The Ranger Team (January ’17)

2017 was an year of immense growth across all teams in Rubrik, but one team in particular was born near the beginning. The Rangers. At least one New Hire Bootcamp misunderstood the name to mean Park Rangers which brought more than a few laughs and groans on our part (especially in light of the mountains, river, and font, Smokey the Bear-style, in the PowerPoint slide). The true alignment and tribute is to the Army Rangers.

The Ranger team members are the blasting caps to the dynamite of Rubrik’s API-first architecture. They unlock the incredible potential of a platform entirely exposed via RESTful APIs.

Customers and partners are all over the spectrum on their DevOps journeys, but most have initiatives at some level of the organization to eliminate repetitive processes, introduce self-service capabilities, and enable cloud mobility. Rangers leverage languages like Python, Ruby, and PowerShell* to streamline workflows, aggregate analytics, and tie Rubrik into other ecosystem products.

Here are just a few examples of Ranger projects in 2017:

(*with some internal debate as to whether this is actually a language… :)


Sometime in 2016, I moved my blog (this one) to an AWS EC2 instance (t2.micro) running Amazon Linux. It seemed like a good idea at the time, since my prior hosting (Gandi.net) was shutting down their US-based datacenter. I had to move it somewhere, and running it on my own server for ~$10/mo had the added “benefit” of a dedicated host to tinker with. I think I was bored when I made that decision or I would have chosen something with less risk/overhead.

In the intervening months, I found myself returning to a time when server/application “health” was achieved by routinely rebooting the server running it. Apparently a t2.micro isn’t really enough for even a lightweight blog and LAMP setup like mine, because every few weeks, I’d refresh it to find the database connection failing (out of memory, maybe?). So I’d hit the AWS Console and reboot the instance (because it never happened when I had free time). That brought it back to life for another few weeks before it’d crash again. And so 2017 went.

The Christmas season presented me with a bit of time to finally escape this relatively expensive sub-par experience, so I finally executed on my plan to move my domain to Google Domains and my hosting to Namecheap. Fill in “Namecheap” with almost any generic hosting provider using cPanel, and you’ll be able to apply the steps below. There are other ways to do this (some surely easier), but this is the path I took. Feel free to chime in with others!

Step 1: Pre-move housekeeping

Just like moving apartments or houses, the shift can be easier if you get rid of junk you don’t need before you shovel it to your new home. In WordPress land, that can be achieved by:

  • Deleting unused themes
  • Deleting retired or unused plugins
  • Pruning your media library–especially unattached items

With the bit bucket full and your WP site lean, let’s move to Step 2.


With Virtualization Field Day 5 (VFD5) coming up this week, it seems appropriate timing for an update on Rubrik in action. For a refresh on what Rubrik is, check out Mike Preston’s #VFD5 Preview – Rubrik. I’ll be using some of what he shared as launching points for elaboration and on-the-ground validation.

Share Nothing – Do Everything

rubrik_systemI believe that this is both the most important and likely the most overlooked characteristic of Rubrik and its architecture. It is crucial because it defines how users manage the solution, build redundancy in and around it, and assess performance needs. I also believe it is overlooked because it is like the foundation of a great building–most of it is under the surface and behind the scenes, enabling prominent edifices like Time Machine-like simplicity.

One way that I can describe it is “multi-master management and operations”, though it falls short because Rubrik has no slaves. Every node is the master. Some data protection solutions have redundant storage nodes which all depend on a single control node. If issues arise with control, the plethora of storage behind it is helpless except to sit and maintain integrity. With Rubrik, all nodes have command authority to manage, support, and execute across the infrastructure.

Storage Technology Virtualization