Shimel: So, how—how, you know, as you sit here today, how has StorPool changed in these years? Like, what are some of the new innovations and use cases that you guys are seeing that, you know, and you’ve had to build or change technology for?

Krosnov: Yeah. So, first, there is, in the last few years, there is this realization in terms of our kind of positioning and product is that StorPool is part of this wave of modern IT or new age IT. Meaning, it’s not an IT organization where the sys admin receives an order form and fulfills that, right? It’s an IT workflow organization in which there is a lot of kind of dynamicism and automation, right? So, there are systems talking to systems and not people talking to people.

And we’ve been very good at that from the very beginning, but now we realize it more and more. And alongside with that, kind of fairly new use cases for us are—so, we come from automated environments in which there are virtual machines and newer use cases for us are the same kind of automated environments in which there are containers and pods under Kubernetes and also fairly recently, automated environments which provision bare-metal physical servers.

Shimel: Yeah.

Krosnov: If you think of people that have idle—hundreds of servers which sit idle and they can dynamically provision these resource to be part of their application coasters in some way. And our product turns out to be pretty good for both of these newer use cases.

And the other thing that’s happening in terms of our positioning and the direction where the company is going is, we are—because of our longer history and the product is more proven, it has been more proven over time, we are managing to attract larger customers, right? So, there is this focus on larger IT organizations which have bigger pain points and have bigger problems to solve; so, this is the direction in the development of the product and the company, right?

Shimel: Sure. So, Boyan, one of the things we’ve seen here at DevOps.com and Container Journal is, first of all, people recognizing that it’s about the data. It’s not—the technology needs to make us be able to access the data, to see the data, to use the data, but it’s about the data.

Krosnov: Yeah. Mm-hmm.

Shimel: But the other thing is, you know, we have this thing called DataOps, right? I don’t know if you’ve ever heard that term.

Krosnov: Mm-hmm.

Shimel: And it kinda rides on top of DevOps or at least in our world, because we’re DevOps.com, we see it in conjunction. But really, the power we see is that a lot of organizations that are adopting DevOps, adopting automation and continuous type of delivery are also adopting DataOps and automation around data, data storage, data analysis. And so, I’m wondering if, at StorPool, if you’re seeing this connection between DevOps and people using product and data and how they’re using it.

Krosnov: Got it. So, the way we plug into the whole DevOps ecosystem is at the infrastructure layer. So, if you think of applications being built as applications or also known as a business logic layer on top and then in the middle, you have some form of a platform which could be, you know, a database application server, run times, things like that. And then at the bottom, you have infrastructure where our product plugs into this ecosystem at the infrastructure layer.

So, things like, for example, things like a Kafka or a Hadoop cluster or things like that, they said maybe you can think of them in the middle, in the platform layer, right? And if you deploy a, say, a Hadoop cluster, you could deploy that on top of bare metal servers, but you could also deploy that on top of a real storage system like StorPool, and there are some advantages to doing that, right? And the way we plug into that is through deployment automation and dynamic provisioning, right?

So, you could, you know, scale your data lake or whatever you wanna call it without having to physically touch hardware, right? And in order to do that, you need automation at the infrastructure layer, not just at the platform and application layer. And we plug into that in infrastructure automation.

Shimel: Absolutely. Very good. You know what? Boyan, I apologize, we should’ve said this up front—for people who want to get information about StorPool, just the website?

Krosnov: Yeah, the website is pretty good. I think we’ve spent a lot of—

Shimel: [Laughter] A lot of time on it—but it’s S-T-O-R-P-O-O-L, like Stor as in storage, no E.

Krosnov: Yeah. No E—exactly, yeah.

Shimel: Stor-P-O-O-L.com.

Krosnov: Mm-hmm.

Shimel: Okay.

Krosnov: That’s right.

Shimel: Now, the offering, is it kind of a SaaS model, or is it, you just buy the software? How—what’s the sort of go-to market, if you will?

Krosnov: Yeah. So, it is, like, a software-only model, meaning that, for most of our customers, we don’t ship hardware, right?

Shimel: Right. Well, it’s software-defined storage.

Krosnov: Yeah. There are very few exceptions where someone would come to us and they would say, “You know, you guys do software, but I would also like to buy the servers from you because it gives me a bit more assurance into what I’m getting,” right? And we can serve that use case, too, but it’s kind of a rarer use case.

And so, what we provide is software and the services you need around that to run that software. So, things like monitoring and, say, deploying it, operating it—like, all the support and services you need around that. That software is installed in our customers’ infrastructure—that means, on their servers in their data center. It’s most kind of typical use cases would be private cloud environments, which may be in a proper designed extent, or they may be—they’re private cloud environments, most of them.

So, this is how the whole flow looks like. The team that builds and operates infrastructure for this large IT organization, they need to build infrastructure that consists of compute networking and storage, right? They look at different storage vendors and our product kind of fits very well in this environment of, you know, private cloud, automated, continuous, DevOps, modern IT automation kind of environment.

So, say they select our product. They would buy servers from their preferred server vendor, or they would compete different servers’ vendors in a process. These servers would be installed in a data center and connected to their network and they would get a license for the StorPool software as well as supporting services from us—say, deploying it, training them, upgrading, et cetera, right?

And this is how kind of the model works. We—in this space, we compete with different types of products. It’s not just software-defined storage, there is also kind of the traditional SAN or all-flash array vendors, right? And, increasingly—so, all-flash array vendors are quite popular, by the way, in this area, in private cloud infrastructure, right?

Shimel: Sure.

Krosnov: And—but a software-defined approach is a lot more strongly associated with automation and continuous improvement and kind of these newer ways of working, of doing IT. So, that’s one of our strong advantages, there.

Shimel: Understood. Excellent. Alright. Boyan, I think we’re running out of time, here.

Krosnov: Oh.

Shimel: We can give the webinar—I told you, the time goes quick. Once we start talking technology and the companies, the time goes quick. You know what, maybe we could have you on or we could do some other feature on DevOps about it. Is there anything we missed that you want to touch on?

Krosnov: Just, I have a talking point, here. So, there is this—for example, there is this concept of persistence and persistent storage versus—

Shimel: Okay, sure. Let’s talk about it.

Krosnov: Yeah. So, what we’re doing in Kubernetes and pods and containers, right, is we provide persistent volumes for containers, right? And it’s—if you think about it, it’s nothing new. So the same kind of thing was needed for virtual machines before that. So, you had the choice of a virtual machine with local storage or let’s give that virtual machine a virtual disk which would survive if a particular physical host died, right? And that would be called persistent storage.

And the same thing is now happening in containers, you know? It used to be containers are stateless and you don’t need persistence, and over time, people have realized that, at some level in your stock, you need persistence and actually, every service needs some form of persistence. It’s kind of extremely rare that you would have a completely stateless service which wouldn’t need persistence, right?

So, what we did there was, we implemented a Kubernetes CSI driver, and that provides persistent storage for Kubernetes pods, for persistent volumes, right? And these are used—so, what are they used for? They’re used for things like transactional databases so, you know, MySQL, PopSQL, and they’re also used in these batch processing applications, you know, where you take a large amount of data and you transform it and output a concise index of that data that you can then query and you can think of one part that outputs the—does a lot of calculation and produces an index, and that needs persistence to ________ the index, and another part that queries the index and that may need very low latency and that’s very performance-oriented—the second part. The first part is more of a batch processing, and it’s okay if it takes a long time, but the second part, the part that processes online queries, is usually very performance and latency sensitive and, you know, that’s where we play quite well.

Shimel: Sure. Excellent. Alright. Boyan, we’re gonna end this discussion, but maybe we can have you back on and we can continue. This whole—the whole data space is really heating up and everything around it as, again, as I mentioned, people are recognizing that. It really is about the data. All of the technology we built around it is about data and so, we need to kind of focus there.

But anyway, Boyan Krosnov, StorPool, has been our guest here. This is Alan Shimel. You’ve just listened to another DevOps Chat.