Business · Cloud · Data

Rubrik continues their quest to protect the enterprise

Screen Shot 2018-04-23 at 9.56.47 AM

Data protection is all the rage right now. With data moving beyond the corporate data center to multiple locations including cloud, the complexity has increased significantly. What is Data Protection? It generally covers a combination of backup, restore, disaster recovery (DR) and business continuity (BC). While not new, most enterprises have struggled for decades to effectively backup their systems in a way that ensures that a) the data is protected, b) can be restored if needed and c) can be restored in a timely fashion when needed. Put a different way: BC/DR is still one of most poorly managed parts of an IT operation. Add cloud to this and one can see where the wheels start to fall off.

The irony is that, while not new, enterprises struggle to effectively balance the needs of DR/BC in a meaningful way. The reasons for this are longer than this blog will permit. This is an industry screaming for disruption. Enter Rubrik.


A couple of weeks back, I caught up with the Rubrik team at Tech Field Day’s Cloud Field Day 3. Rubrik came into the market a few years back and has continued their drive to solve this old, but growing problem.

Unlike traditional solutions, Rubrik takes a modern approach to their architecture. Everything that Rubrik does calls an API. By using this API-centric architecture, Rubrik provides modularity and flexibility to their approach. API-centric architectures are a must in a cloud-based world.

At Cloud Field Day, the Rubrik team went through their new SaaS-based solution called Polaris. Knowing that enterprise data is increasingly being spread across multiple data centers and cloud providers, they need a cohesive way to visually manage their data. Polaris is a SaaS-based solution that does just that. Polaris becomes the overarching management platform in which to effectively manage the growing complexity.


There are two dynamics that are driving these changes: 1) the explosion in data growth and 2) the need to effective management data. As applications and their data move to a myriad of different solutions, so does the need to effectively manage the underlying data.

An increase in compliance and regulatory requirements are just adding further complexity to data management. As the complexity grows, so does the need for systemic automation. No longer are we able to simply throw more resources at the problem. It is time to turn the problem on its head and leverage new approaches.


During the discussion, Rubrik’s Chief Technologist Chris Wahl made a very key observation that everyone in IT painfully understands: Data protection is not important…until it is. To many enterprises, the concept of data protection is seen as an insurance policy that you hopefully will not need. However, in today’s world of increasingly regulated and highly complicated architectures with data spreading out at scale, the risks are simply too great to ignore.

While data protection may have been less important in the past, today it is critical.


If the story about Rubrik were to stop with just backup and recovery, it would still be impressive. However, Rubrik is venturing into the complexity that comes with integration into other systems and processes. One of the first areas is their integration with ServiceNow. Rubrik integrates with ServiceNow by ingesting CMDB data into the system. By doing so, it provides a cohesive look at the underlying components that Rubrik has visibility into.

Looking into the crystal ball, one can start to see how Rubrik is fully understanding that backup and recovery is just the start. The real opportunity comes from full integration into business processes. However, in order to do that, integrations like ServiceNow are needed. Expect to see more as Rubrik continues their quest to provide a solid foundation to the enterprise when they need it most.


Can cloud finally help enterprises with DR/BC?


Disaster Recovery (DR) and Business Continuity (BC) are collectively, using IT lingo, called DR/BC. Both terms go back to the earliest days of computing. Even though neither term is new, neither are done really well. DR/BC is one of the biggest risks for a company and most do not realize it until failure strikes. So, what is DR/BC and what can be done to change this posture?


First, let’s break it down. What is DR & BC? They are interrelated, but very different in nature. In essence, they cover a spectrum of solutions when failure strikes. DR typically covers the period of failure and return to operations. BC covers the continuity of business operations during a failure. While that seems pretty straight forward, the complexity comes in when you consider dependencies and costs.

Dependencies cover a range of items from physical circuits to inter-related applications and just about everything in-between. One may ask: Why not just create redundancy in all of the dependencies. That is easier said than done. IT is already a complex beast. Think of it like a ball of yarn. Now add a second ball of yarn that is identical in every way. The very introduction of a second ball means that the first ball is no longer unique. And the cost would be exorbitant. To many, DR/BC is often see like an insurance policy. What is the risk and likelihood of failure? How does this compare against the costs? Again, not a trivial matter; hence the failure of most to enact good DR/BC plans.


In the past, there was, fundamentally, only one way to provide DR/ BC. Today, there are two fundamental methods when considering DR/BC; application-based and infrastructure based.

Infrastructure-based DR/BC is more common in enterprises, especially with legacy enterprise applications. This method is well understood and heavily leverages redundancy among hardware infrastructure components. For example, redundant storage arrays, clusters of compute infrastructure, redundant power supplies, etc. The application takes a stance where it assumes that the infrastructure resources are always there and available. There is often little to no intelligence within the application to protect against infrastructure failure.

Application-based DR/BC is less common in enterprise applications. It is, however, very common in cloud-native applications. Why? Cloud based infrastructure is often based on commodity hardware with little to no redundancy. Cloud native applications, unlike their legacy relatives, have the benefit of leveraging a totally new architecture from the ground up.

While infrastructure-based methods may be more common, application-based methods are more resilient. Why? Even with the most sophisticated Tier IV data center, brand-name systems, storage sub-systems and network topologies, the fact is that infrastructure still fails. Sure, it has gotten better over time. On the other hand, application-based methods do not assume that infrastructure is always there. As such, the applications themselves contain sophistication to ‘heal’ themselves without impacting the user experience. A whole data center (or a component within) can fail and not impact the user experience of the application.

Getting an application from one architecture to the other is not trivial. In addition, the underlying infrastructure must change with the re-architecture of the application. Running an application with self-healing properties on redundant infrastructure would be a waste in most cases. It would serve as redundancy of redundancy.


Cloud-based solutions provide a number of clever benefits for enterprises. First, there is flexibility in the underlying infrastructure options. Need redundant infrastructure one day and non-redundant the next? No problem. There are options for that. Trying to manage these shifts within the enterprise data center is both complicated and expensive. Not to mention it provides little direct business value to manage internally.

Cloud also provides a location for DR/BC that is physically separate from the corporate data center and reduces the overall cost. Only use it when you need. Which means you only pay for what you need and when you need it. Solutions from companies like CloudVelox help enterprises with this migration. (Full Disclosure: I serve as an advisor to CloudVelox)

Regardless if whether you use a third-party solution or do it yourself, cloud provides a significant opportunity for enterprises to finally engage meaningful DR/BC plans. It is not a trivial matter to shift from existing infrastructure-based applications to an architecture that supports application-based intelligence. Cloud can still provide benefits to infrastructure-based applications without the complexity and expense of the alternatives.

Business · CIO

Outages happen. How prepared are you for the next one?

Significant outages hit several major firms today including United Airlines, New York Stock Exchange (NYSE) and the Wall Street Journal. And that was just this morning alone. While many suggest a correlation between the three, I will leave that to the experts.

The point is, outages happen. How prepared you are and how you respond to the next outage is what matters.

DR/ BC: Not new and still broken

The bottom line is that disaster recovery and business continuity is not new and is still broken. IT organizations have cobbled together solutions for decades with limited success. There are shining lights but often they are startups based on an entirely different culture.

Are you only using backups? How do you know you’re backing up the right information? Is that enough? Generally, the answers are less flattering than most would want.

Redundancy doesn’t cut it either. Organizations continue to build redundancy into systems to the point of over complicating systems. And complication leads to greater risk of missing a step along the way

Today, backups and redundancy is not enough. Building to increase the number of 9’s of uptime is not the answer either. Organizations need to go beyond that.

Time to streamline

There are a number of ways this problem can be resolved. DR/ BC is a must but not using traditional means. Investment is needed, and there are clever solutions available today. This is more than just a technology problem. It involves process, organization and culture. Think about DevOps. Think about how to streamline.


Remember: The more the complicated the system, the longer to troubleshoot. And the greater the risk to both the company and its customers. How prepared are you for the next outage?