Podcast Episode

Voices in Data Storage – Episode 31: A Conversation with Eyal David of Kaminario

:: ::
Enrico and Eyal David go beyond data storage to discuss embracing hybrid cloud strategies and new solutions to persistent issues.

Today's leading minds talk Data Storage with Host Enrico Signoretti

Guest

As CTO at Kaminario, Eyal David is responsible for charting Kaminario's technical vision and is the company's lead technology evangelist. Eyal joined Kaminario in 2009 as a developer then software team leader. He has also held the positions of VP of Product Management and VP of Business Development at Kaminario. Prior to Kaminario Eyal led the advanced algorithms group for a large enterprise. Eyal holds a B.Sc. in Mathematics, Computer Science and Physics from the Hebrew University in Jerusalem, and a M.Sc. in Computer Science from The Interdisciplinary Center, Herzliya.

Transcript

Enrico Signoretti: Welcome, everybody. This is GigaOm, Voices in Data Storage, and I am Enrico Signoretti, your host. Today, we will talk about something that is beyond data storage. A lot of organizations are embracing hybrid cloud strategies and they are looking for solutions that are totally different from the traditional storage array. The vision is more cloud-driven and they need new solutions to face these new challenges. To help me with this, I have invited Eyal David, CTO of Kaminario today. Hey, Eyal! How are you?

Eyal David: Hi, Enrico, thank you for having me. I’m well.

Kaminario is an upstart in the all-flash realm, but actually we will discover during the episode that they are changing and they are evolving into more of a cloud company, data company than it was in the past. Maybe we can start with a little bit of background about you, Eyal, and the company.

Thank you, Enrico. Yes, Kaminario has been around for about ten years. I’ve been with the company since its inception. I would say that over the last ten years, the company and its vision has evolved to mirror the changes we’ve seen in the market. As time goes by, it’s clear that the impact of cloud on modern deployment models and the expectations customers have [of] how they can transition to the cloud, is central to any IT strategy. We’ve been in the process of reshaping the company and addressing the major problems that companies see today in transitioning to the cloud.

Well in fact, I have to say that I’ve followed the company since the very beginning and the first product you launched was called K2. It was a record-breaking all-flash array at the time. Then you evolved a lot, not only with data services and functionalities, but actually a couple of years ago, you did a major change. You presented a new solution that was software-only.

Even more than that, the other day I was browsing your website and it’s incredible. In the home page of your website, there is no mention of ‘data storage,’ it’s data, applications, cloud, virtualization. All terms that, yes, some are connected with storage but none of it. Can you give me an idea what is happening?

Certainly what you’ve seen on the website is reflective of the changes in the market. Today’s challenges customers are facing [are] in building their hybrid cloud strategy around data mobility, performance application, refactoring and re-platforming. The ability to have true flexibility in deploying workloads where it makes sense from a business aspect, requires a completely different approach from traditional storage. As much as Kaminario started its way in storage, we now focus on data virtualization. Kaminario, in essence, allows customers to encapsulate business-critical data in what we call data pods and deliver extreme performance at scale, with competing cost efficiency across any type of cloud, private or public cloud.

It’s an interesting proposition. With all these companies doing this with all these companies implementing these hybrid cloud strategies now, they want to think more about data and not data storage. At the same time, they want a single platform that can span across different environments, so data mobility becomes a critical aspect of it, but also not just data mobility.

The other important aspect that I find in the field is that many enterprises, especially traditional enterprises, they want the same identical platform on different clouds, so that they can find something familiar. They don’t have to retrain their system administrator and they can migrate applications from one platform to the other, finding the same identical features.

I don’t know if your platform works this way or there is a difference but what do you find in the field from your customers and how does your platform help them to achieve this goal?

Yes, definitely. As we talk to customers, every organization today is somewhere on their cloud journey. They’re either planning for it they’re either in that process, they have done some transition into the cloud. Some have tried and not succeeded in moving some of their workloads to the cloud and are not able to benefit from the flexibility and scale of a public cloud deployment. This is where we come in. Usually, what we see is that when it comes to a core mission-critical application, that is where customers are most challenged to transition to a public cloud model.

It is often required of them, if they want to use native cloud resources, to go on a significant process of refactoring and re-platforming their applications to adhere to more cloud-like architectures. That is usually a lengthy process. We often see customers projecting two to three years of work, until they can actually leverage and deploy their mission-critical workloads in the cloud.

We offer a different proposition. We offer the ability to deploy the Kaminario data plane virtualization platform. That is the underlying technology driving the ability to move the data pods I mentioned earlier across multiple clouds, without compromising on the level of data services or performance at scale that is provided, where we can provide an order of magnitude better performance than the native cloud resources at a fraction of the cost.

We basically allow the customers to accelerate significantly their adoption of cloud infrastructure, by taking their mission-critical applications ‘as is’ without refactoring, and moving them to the cloud; in a sense, significantly reducing the risk they run in these cloud migration projects. That also gives them access to mobility between clouds. They can choose whatever public cloud provider makes sense for their workload at any given time. They can also combine that with workloads still deployed in their private cloud. This gives a uniform set of data services that deliver performance at scale, risk reduction, and a uniform experience across any type of cloud.

This is somewhat aligned with what I see. What I find is also that it’s very, very complicated to maintain a single level of performance in the cloud. When you are used to having an all-flash array on your premises, getting on an AWS or Azure, or the cloud that you choose, the same level of performance while keeping the same platform is very, very complicated, not just the peak performance, but most of the time, it’s about consistency.

Another problem that I see often is that, yes, we have a beautiful appliance but actually, the cloud is not really designed for traditional software architectures and traditional storage architecture. The way it manages failures is totally different. How do you approach these kinds of challenges?

These are definitely challenges that our customers are facing, as they want to move to the cloud. How can they achieve their performance SLAs with the native cloud resources? How do they now, potentially, need to take on [for] themselves data resiliency and data availability, where the cloud doesn’t give the same assurances as on-prem local resources used to do? In this case, we actually lean back on our mature stack of data services that delivers solutions to the problems you just mentioned.

As much as we over the last few years, we separated ourselves from the hardware, from a business model, from its inception, our technology has always separated software from hardware and capacity from compute. For this aggregation, between the ability to scale performance and the ability to scale capacity, it’s a perfect fit when trying to solve the issues you discussed in the cloud.

If a customer wants to take a high performance, mission-critical workload that they run on their private cloud and run it on the public cloud, we can give them access to a shared data resource that can scale performance infinitely, scale capacity as you go, as needed, without hitting any of the cloud limitations. Moreover, it is also significantly more cost efficient because these days, high performance native cloud resources are extremely costly. Leveraging our data virtualization platform, they gain access to this performance at scale at a significantly lower price point.

At the same time, we also give them access to dealing with resiliency and availability. By deploying our stack across multiple zones, multiple regions, or even multiple clouds, they can design to their needed resiliency level. Leveraging a uniform set of data services, they can choose to have cross-cloud, cross-region, and cross-zone resiliency in their applications, without the need to re-architect the actual workload layer.

Well yes, but another issue that I usually see is that by expanding this kind of architecture, so having something that runs on your premises, something that is on the cloud, maybe more than one cloud, there is another major problem that surfaces. It’s the fact that you need to control, monitor, maybe having some detailed information [about] what is really happening, especially to spot new trends, especially if you want to act on an issue, it becomes a real problem. Do you have something to deal with these kinds of problems?

Yes, definitely. First, when running in a private cloud and when running with the public cloud, we integrate with the local orchestration and monitoring frameworks. At the same time, we have the Kaminario Clarity platform, which is the Kaminario AIOps, analytics, and machine-learning platform that collects ongoing telemetry from across the entire install base, regardless if it’s deployed in a private or public cloud. Delivering for us and for our customers a very strong suite of reporting tools, predictive analytics, and preventative analytics capabilities to spot trends, spot potential future failures, direct resource management, optimize resource deployment, and maintain the SLAs they need and protect their costs from going through the roof.

I see, but again, let me play the devil’s advocate here and talk about the complexity also...from a financial point of view. It’s not unusual now to find solutions from major vendors that have some components on the cloud and some components on premises. Actually, it’s very complicated to migrate these workloads for several reasons. One is just finance. I made a huge investment on premises; now I’m moving some of my stuff into the cloud and I have to buy new licenses or subscriptions or whatever. It’s not really convenient at the end of the day.

We’ve definitely addressed that issue as well because you are correct: a cloud migration project is complex, not only from a development perspective but also from an operational perspective, and certainly from a financing and cost perspective. We’ve gone to great lengths to simplify that process. We’ve covered how we simplify it from a development and operational perspective, by allowing customers to avoid expensive and complex refactoring of the application.

From a financial and business perspective, leveraging our ability to deliver a subscription-based software license that is tied to the ongoing usage of the customers, we actually completely decouple the licenses from the underlying infrastructure where our stack is deployed, which means that customers can enjoy full mobility of their licenses between any underlying infrastructure.

If a customer actually is going through some form of consolidation for their private cloud, and at the same time also, moving some workloads to the public cloud, they don’t actually have to waste all that investment. We leverage commodity components on-prem and we leverage “commodity components in the cloud” to deliver the robust set of data services that we provide.

The software license to run our stack is actually 100% mobile, so there’s 100% investment protection for somebody going through a consolidation and migration process with us. As they move data to the cloud, they can leverage the same set of licenses that they were leveraging on the private cloud to do that, without any need to rebuy anything.

This is very nice. You give your customers the ability to buy the license or the subscription once and then move it according to the needs of, not the day, but of the needs that they have during the evolution of the infrastructure.

Yes, I would say an additional aspect of improving the financials of such a solution is that both in a private cloud and in a public cloud, through our analytics platforms, we give the customers access to ongoing infrastructure optimization. If we would see a Kaminario data pod running on a public cloud is underutilizing its performance capabilities, we would recommend to the customer: “Why don’t you shut down a few of the performance components of this data pod; reduce your cost without compromising your SLAs?” If the need arises and the workload requires additional performance, we can immediately spin-up new compute elements, increase the performance in a linear fashion on the spot, and then maintain the updated SLA. In the meantime, you can reduce your cost significantly on an ongoing basis.

Yes, this sounds interesting not only to enterprises but also to other kinds of organizations, MSPs for example, or service providers in general that can borrow some resources from other clouds for example or resellers.

I’m pretty curious now to know a little bit more about your customers. Is it 100% enterprises? Do you sell to other markets?

Definitely. We focus on the large SaaS providers, usually focusing on data-intensive applications. At the same time, we also work closely with the managed service providers that deliver services to these types of companies. It is a common use case for us to work with a managed service provider that aggregates services to multiple enterprises.

With our data plane virtualization platform, they can themselves achieve a significantly more cost efficient model for their operations. They can run some parts of the infrastructure on-prem, some parts of it in the cloud, and they can very quickly adapt to the changing needs of their customers and spin-up new customers because they’re not tied to physical resources. If they have a new customer coming in, they can spin them up in the cloud in a matter of minutes.

I see. This leads me to another couple of questions actually. One is you mentioned SaaS providers. These guys are moving very quickly to new forms of virtualization or application development and deployment, meaning with these containers and Kubernetes. Do you have a strategy for Kubernetes?

Yes, of course. As deployment models move to cloud-like architectures and at the same time, adopt containerized workloads, usually driven by a Kubernetes orchestration, they’re still faced with similar challenges when trying to deliver resiliency and performance at scale. This is where our data plane virtualization platform can come into play. We can provide that persistent backend to any type of containerized deployment, either in a private cloud or a public cloud.

Also, with the added benefit of providing cross-cloud mobility for containerized workloads, maintaining this uniform set of APIs and data services. Containerized workloads can now enjoy a higher performance SLA, improved resiliency and durability, and also cross-cloud mobility.

Interesting. At the same time, on the other side of the spectrum, when we talk about this data platform that spun across clouds and on premises locations, it’s a software at the end of the day. There is a hardware component that you need to run your software on the premises. Do you have a hardware compatibility list or best practices to help the customers building their infrastructure, depending on their needs, the number of IOps they expect and so on?

Yes. Kaminario works to qualify and certify the underlying stack where our platform runs on. Our customers can gain access to a certified stack through our partners for on-prem deployment or through the marketplace on the public cloud providers, to deploy the needed underlying cloud resources. We do all the testing and qualification and configuration and the customers can get it delivered as a qualified solution; they do not need to build it on their own. That is a strong expectation when you’re dealing with mission-critical applications and data.

Yes, indeed, it’s a very clever way to operate. That leads to another question. It’s about the size of the customer that you can serve. This is the kind of question that I ask almost every time to all the vendors. I’m curious just to understand where your solution can be applied: very large organizations, every type of organization, all these small organizations? It would be awesome if you could give me an idea of the smallest possible installation and the biggest one that you can get from Kaminario.

As we discussed earlier, the Kaminario platform can deliver its data services in a decoupled way from a data capacity and data performance perspective. Our solutions can scale from the low tens and hundreds of terabytes to the multi-petabyte scale and tens of petabytes. From a performance perspective, from a few hundred of thousands of IOps to multi-million IOps configurations. It all depends on the level of performance at scale that is needed and the performance density that a specific workload requires. We actually give that ultimate agility to our customers based on their workloads.

The IP we’ve developed and built over the years allows us to deliver this consistent performance at scale, which is a key requirement for these types of applications. Applications that want to deliver real-time analytics, transaction processing, for their core workloads, require performance at scale but more importantly, persistent performance at scale.

How are your customers distributed across the world?

We have presence in North America, Europe, Israel, and [are] building our business in the Far East.

Is your business based on a channel model or on direct sales?

We work in a combined model, both with channels and with a direct sales force for a certain part of our customers. Especially working with the larger customers on their hybrid cloud strategies, you see a lot of variance if they’re working directly with the vendors or through a solution provider.

How many customers do you have?

We have thousands of deployments in mission-critical environments, which is the core of our install base.

I think this conversation was very good and we got a very, very nice profile about Kaminario, especially if we think about the alignment of this company with the trends in the market. I’m also curious to know a little bit more about the future. What can we expect from Kaminario in the next 12/18 months?

First of all, thank you for having me. It’s always fun having a conversation, Enrico. Looking into the future, I think we will continue to follow the market trend of giving a cloud-like experience to any deployment location or deployment model. The Kaminario data plane virtualization platform will continue to deliver improved orchestration capabilities, specifically focusing on workload mobility and resource management, and how you deliver the improved uniform, seamless experience across any type of cloud. As time goes by, data management and data orchestration becomes a key factor in any cloud strategy and we’re building the foundations to deliver on that need.

Yes that sounds very cool. Maybe we can keep the channel open here. If you have a Twitter handle that we can share with our listeners, maybe we can continue the conversation online, if somebody has questions. You can also share the website link for Kaminario, so if somebody wants to read more about the solution, maybe ask for a demo, they can go there.

Yes, Enrico, definitely. You can find us on Twitter on @kaminarioflash and our website is www.kaminario.com. You’re welcome to come in, browse and reach out if you have any questions.

Yeah, thank you very much for the time you dedicated to me today. If anybody wants to contact me on Twitter, you can find me on @esignoretti or on gigaom.com. Bye-bye!

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.