Modern Data Protection Starts with the Right Architectural Foundation with HYCU

My name is Goran Garevski, CTO and co-founder of HYCU. So as Simon actually opened up, what are the challenges you try to solve, and how we approach this era of thousands of data silos, how to simplify it and make efficient data protection for the customers. One of the biggest challenges when you want to conquer the world is how to abstract, how to do it in an efficient way. 17,000 SaaS applications with a different type of data, different type of metadata, different type of configuration, different type of high availability and error functionality built by the vendor itself. How to abstract it and make it easy to use so that customers actually have a zero learning curve — this was the goal of our cloud platform.

What we learned actually in the past with our previous experiences is that we wanted to avoid the trap of the first architecture definition. I usually say for every company there's a DNA. Either they're coming from a storage background, from a monitoring background, from a developer background — usually the first DNA is visible in the architecture and everything they do later. You can see very few cases in the whole industry, back 30, 50 years, that people redesigned the whole thing and fine-tuned it to the new environment.

So the key for us were two goals. First is how to abstract the problem across different types of sources — classical data center file systems, containers, SaaS applications, databases, platform as a service. The abstraction means that what is, at least in our definition, nirvana in data protection: the same policy applied on a database as a service, on a SaaS service, on a VM, or on a file server. That's the abstraction we are looking for in order to address this problem, including 17,000 plus applications. The key here is the central intelligence for cross-cloud data protection management and standard functionality. No one has abstraction on the policy level so that you apply it to different sources.

Great question. You're abstracting all of the components of the policy. From the original design — and Simon mentioned the penicillin moment — they're very simple in each case, as they should be: RPO, RTO goal, retention, copies, archives, and then potentially a fine-tuning on the policy itself. If you look at the definition of the policy, you can pretty much apply it to anything. In case it's not applicable, of course users should be aware, but in 99% of cases you apply those simple properties of a policy to any type of source. This is our approach from the very beginning. If you recall, the application awareness for VM-hosted applications, file systems, and so on — that was the famous penicillin moment. Of course we started with infrastructure as a service, the classical things we need to cover: public clouds, the data center, and VM-hosted applications.

But the key was to add the future here, as Simon mentioned — tons of SaaS applications, different in nature, different in types of data, different in metadata. So for this, we actually extended our application or SaaS awareness model to also cover platform as a service, database as a service, and SaaS. But in order to address the 17,000 plus problem — which will become 20,000 or 50,000 in five years — you need the ecosystem. You cannot do it yourself. The original SaaS vendors, if they want to participate, or ISVs, or channel partners specialized in a specific SaaS application — the key is there must be a legal entity behind it to join the development program. There's a defined process: how we work together, how we certify, how we check for vulnerability and security, and how we publish it later in the marketplace.

So the key here is the ability to extend the platform, to abstract the functionality — how you protect not just SaaS but potentially any workload — and to apply it in an efficient way on top of it. We make it known ourselves by auto-discovering things. Originally in the VM-hosted world, but now even more in the much more complex world, which is the SaaS application and PaaS applications. Again, we stepped back and looked at who are usually the key sources for this kind of thing. We will discuss the discovery process later in more detail, but this is Okta and Azure AD, at the end of the day. Of course, as we go forward we will try to bring in more additional sources, but currently this is pretty much a stable situation in terms of having efficient discovery of the SaaS, PaaS, and IaaS workloads.

The key for us, and one of the key advantages — at least what we strongly believe against the competition — is that we do not lock your data. It's your storage, it's your data. We are providing a service that will protect your data, and we will store them on storage that you define, that you have, that you own at the end of the day. This is applicable to the platform itself. On top of it, clear to us is also the ability to automate, to orchestrate anything which is happening in the platform. This is the REST API, which is used also by our own user interface. Anything we do in the user interface can be done through the REST APIs too.

And the key addition here is the HYCU Marketplace. In order to properly address the problem, you can see HYCU has its own marketplace with all of the functionality required for a typical marketplace — content, tracking the consumption, publishing, updating, billing — either through us or through different partner marketplaces on top of it. Let's dive deeper into a couple of key components of our cloud platform and its extensibility.

But first, when you look at 17,000 plus SaaS sources, what is the challenge? This is not the same problem as we had in the past, where you can directly access the infrastructure, the storage, the hardware, and anything behind the application. We are talking about a black box. SaaS and PaaS are pretty much a black box, so you cannot do many miracles. You have an API, which usually limits access to the data. On top of it, any SaaS company has its own API throttling, network throttling, and limited bulk data APIs. When I say bulk data, I mean bulk data transfer in order to perform efficient backup and recovery operations. Not to mention the granular recovery, which is the most key feature for end users. The most wow effect we got from end users on our cloud is with discovery and granular recovery.

Why? Because every application has different types of objects, and this is a nightmare for a backup vendor to protect and recover. Not to mention more complex applications that have their own plugins and custom ISVs that add metadata and other things on top of what exists within the SaaS service. And of course configuration recovery, because there are always data, metadata, but also the configuration of a service or a sub-component of the service. So these are the challenges we faced when we approached the problem.

Yes, for the policy enforcement piece. Data movement, data protection, recovery — everything on top of it. We are providing pure data protection as a service on top.

That's available through backup and recovery functionality. Got it. We implement DR through the basic backup and recovery principles.

I can say the customers are very creative. So we proactively monitor behind the SaaS service but also through our telemetry in terms of what is happening, and try to guide them. We have a continued success — we are very fanatic about customer success. There's a proactive service that we monitor, but also daily continuous synchronization between the customer success team and the customer. Can we catch everything? No. But I think the NPS score tells itself.

You'll address the theoretical part in the following slides, and then you will see a demo for a couple of SaaS services.

So we support that, yes.

That's a hell of a challenge. Just having data movers — not so business challenge — the goal is to abstract the platform so that multiple partners can curve out efficient modules that will support different sources.

Right. Let's go first on the discovery process, because this is one of the wow effects. Simon was talking about the graph and the value there. Let me explain a couple of key challenges there. It's not so easy to discover a SaaS source or a PaaS source. Why? Because there's no central registry of all SaaS sources. Usually the CIOs don't even know about 20, 30 of the SaaS services within the company. The closest approximation or hint about SaaS services is from the IDP vendors — Okta, Azure AD. What we do there is collect data about how these services are configured, but that's far from enough. We have pre-built intelligence and information about SaaS applications and their built-in SaaS protection. It's very important to understand what are the HA or operational backup capabilities behind the service itself, because data protection is a multi-layered approach. You have operational stuff behind the SaaS service, then compliance stuff, and so on. The key is to inform the people, because this information is not available instantly. Sometimes you dig into different sources.

Key for us is to give it to the user so they understand what is the protection behind the SaaS service without any backup vendor approaching. Then we do advanced logic to identify, because there's a massive gap between the data provided by IDP vendors and the actual SaaS instance you need to protect or what the user has. There's advanced identification, filtering, and auto-mapping logic to remove the noise, because there are a lot of irrelevant things within the IDP event or catalog. And at the end, as you filter that, we are very proud also of our classification. We help you identify by grouping specific SaaS services into industry categories. For example, if you have Jira, it will be mapped into the engineering subsection of the graph or subtree. If you have HR, you'll have BambooHR part of the subtree there. We're trying to group and automate that discovery process so the CIOs or IT managers can see and have the quality information to understand what is happening in the environment.

And of course, ideally — because our graph is not just for services to be clear — we add the classical workloads, VMs, database as a service. This is a visualization of the whole cloud data environment, to propagate and provide the state of the whole environment about data protection and compliance. So this is ideally the single picture you need to see to understand if you're safe or not.

Yes. I see more and more people are beginning to understand the graph has different ways in which you can present that data. Absolutely. A lot of people also want to add value on the graph, potentially additional information. So a lot of interesting stuff in front of us. What I wanted to give you a clue also is what part of the typical backup application is done by the platform and what part is done by the module itself. Our goal was to minimize the effort the partner — or potentially the customer, if they do their own modules — needs to do in order to have an efficient data protection solution for a specific SaaS source. We managed to minimize the effort, putting the module to a bare-bones effort. Anything the development partner needs to do is tightly tied to the SaaS application itself — no additional layers, no architectural services. The beauty of the abstraction: policy management, storage management, managing the lifecycle of backup copies, retention — all of those tough and ugly things are done by the platform. The module itself focuses purely on the interaction with the SaaS service.

We can talk for the next five days on this topic. The key for us was to protect. Each platform has its own format of the data. It's extremely tough to migrate between one SaaS service and another, because there are a lot of things around. But for us, the first goal was to provide protection and give you the data. In the future, everything is possible. But first we need to protect the data and give you control of the data itself.

So we definitely have demos after this. Just to add on top of Simon's comments — each module, our cloud has a mechanism so each module self-describes the types of data, what can be recovered, and where it can be recovered. Which means it's not burnt into the platform but it's logic brought by the module itself, by the integration. If the module supports 100 types of recovery use cases, the platform will show them. That's the beauty of the extensibility.

I understand. The container services are actually managed by HYCU. We provide cross-cloud support. We are talking here about SaaS applications in nature. The computing platforms, container services, file systems — the core infrastructure as a service is covered by HYCU, and we provide multi-cloud operations there. Anything SaaS-related, anything PaaS, which is also very specific — it's done by the external partner.

Yes. And then anything SaaS-related, anything PaaS, which is also very specific, is done by the external partner.

If the module is done by the independent software vendor, they can define their own use cases. If the module is done by the original SaaS vendor, they define their use cases.

We review if this is a product that addresses the quality level and the restore use cases for a typical application. There must be minimal functionality — not just backup without restore. We have a review process where we review the use cases. There must be core value, minimal value, and then we go from there.

I think there are 17,000 applications to be covered. Anyone is welcome. It's absolutely end customers. The SaaS vendors are simply a means to expedite the source-by-source integration and development process. Our customer base are the end customers of those services.

In order to write a module, you need to be part of our development partner program and go through all of the checks. But you can dump the data if you want. You can use the REST API to customize additional workflows on top.