Eddy Ciliendo on Object Storage and the Mainframe
Reg Harbeck: Hi, I’m Reg Harbeck and today I am here with Eddy Ciliendo, who is the chief strategy officer at Model9. Welcome, Eddy.
Eddy Ciliendo: Hey Reg, glad to be here.
Reg: So I’d like to start by just kind of getting a sense—you’ve got a really interesting background that involves a lot more of the planet than just North America, and maybe if you could just sort of tell us about your journey of getting to where you are today to Model9, to the mainframe, and to North America.
Eddy: Yeah, yeah so I was born and raised in Switzerland—so again I’ve seen enough cold weather and snow for a lifetime—joined IBM in the late 90s, first in IBM’s education department and then pretty quickly went over to IBM’s mainframe division. You remember back in the late 90s/early 2000s, IBM had this first wave of "okay we have to modernize the mainframe." That’s when IBM brought out technologies like Linux running on the mainframe, I think in ’99, Java running on the mainframe with zAAP engines at the time. So that’s when I kind of joined the mainframe division as one of those young kids learning this strange dark art of z/OS.
Reg: So just basically when OS/390 became z/OS is when you sort of became a mainframer.
Eddy: Yup, pretty much, exactly right, yup, yup. I still remember we were doing sales brochures and system assurance for S/390 boxes, so yup.
Reg: Cool. So now was that when you came over to North America as well, did you say?
Eddy: No, that was a bit later. Again, I was a system engineer, learned from a lot of the old-timers, which was awesome. Really that is one of the experiences I think I still cherish to this day, just learning from people that have been there from the very beginning that started with the System/360. You know they put me through the whole brainwash of learning the principles of operation and all that good stuff, and how to analyze a dump and all those things I think that you probably don’t do anymore these days. So I did a lot of that stuff. I became an architect, had different architect roles, then left IBM for a little bit to join a larger insurance company where I became their head of mainframe. I always wanted to see how it is to run one of those large environments, be responsible for operation but also implement a lot of the advice that I’ve been giving out now. That was 2011, so for almost 15 years I was creating PowerPoint charts and all that good stuff. I wanted to see how difficult it is to implement some of those best practices in real life, like okay now how do you get young kids from college or straight from school to learn MVS or run z/OS? So did that for a couple of years, then I was rehired by IBM believe it or not in Singapore to run the mainframe business for the Asia Pacific region. Did that for a while and then was offered a worldwide job, became worldwide product manager for the IBM z hardware, and then left IBM after a couple of years to join Model9 at the beginning of last year.
Reg: Wow, okay. So basically you’ve had an opportunity to take all of that experience and really apply it as you learned your way into Model9, which would be a really different way of learning something from learning the mainframe and Model9 at the same time. Now I understand Model9 has sort of been around for a little while, but people might not know what it is they do. So maybe if you could give us sort of a picture of your journey of learning Model9 since you joined it.
Eddy: Yeah, well—and it’s funny because you say we’ve been around for a little while. I mean again, we were founded in 2016, and yeah that’s a couple of years, but in the mainframe world you do understand we haven’t been around for 40 years like the other big names in the mainframe software industry. So we’ve been around since 2016 with offices now pretty much all over the world. We have obviously a big development presence in Israel and Tel Aviv, where we have most of our developers. We have an office in New York, we have an office here in Raleigh, North Carolina, where I’m located, where we also have our mainframe test lab. Yeah, it’s funny. When Gil Peleg, our CEO, approached me whether I would like to join his team and join Model9, you know I at first thought what the heck? Object storage? I had never heard of object storage before, so what is that doing? Then as I looked into it a little bit more, I thought well how can storage attached by TCP/IP be faster? You know there is FICON and ESCON and that good stuff. So at first, I was—I really can’t believe it. I didn’t see any value in that story. And then as I was digging deeper into the company, digging deeper into the technology, you know it kind of dawned on me what the potential for that technology is for the mainframe.
Reg: So basically then I gather that Model9 was founded, as you say in 2016, with this idea of object storage and TCP/IP rather than the more traditional ways of connectivity and data storage and access on the mainframe. Maybe if you can give us a sense of sort of the founding principles of Model9 and what they’ve done since then.
Eddy: Yeah well, I think, and again people like Gil or Offer Baruch our CTO would probably be better to comment on that, but I think the initial you know, how Model9 came about was actually to look for a more cost-efficient storage alternative for some of the testing that they were doing at the time, and that’s how they discovered object storage and being able to attach object storage to z/OS. Because there wasn’t a native interface—there still isn’t a native interface for z/OS other than Model9. There’s now some tiering technology out there, but we’re still kind of the only offering that writes all data directly out to object storage. So that was kind of why the technology came about. It evolved now into the product or the products that we have today, where you can leverage object storage for backup/restore, or you can leverage it for cyber resiliency, or you can leverage it to expose mainframe data to cloud native applications or to data lakes for AI, artificial intelligence, and machine learning and that kind of stuff.
Reg: One of my hats that I wear as a computing security—I’m tempted to say nerd but certainly as somebody who has focused on it very much—and so when I think of storage that is accessible by the mainframe but accessible off the mainframe, I get pretty nervous just because of the need for control and security. But before I can even get there, I have to also admit that being a deep mainframe nerd, the term object storage is not part of my normal vocabulary. So maybe if you can kind of give us a mainframer’s primer on what the heck is model—I’m sorry—object storage?
Eddy: Yeah, I mean in it’s simplest—so you had the same reaction that I had when I heard about Model9 and object storage. It really wasn’t a concept to me. I think a couple of important things about object storage: First of all, it was designed as a repository for unstructured data, right? So stuff in a cloud like big picture images, audio, video, that kind of stuff as a very efficient means of storing unstructured data. Now obviously there’s other use cases in unstructured data that then extend it to AI or analytics use cases. I think that’s where object storage is now very popular. It then expanded into the cloud, obviously now with—I mean one of the big APIs for object storage is S3, a simple storage architecture that was kind of spearheaded by Amazon AWS I guess, so now it’s very prevalent in the cloud. So if you’re building a cloud native application today—and I think that’s also where object storage outside of just talking about Model9, but it’s where object storage becomes relevant for mainframers—is that it’s the de facto standard for cloud native applications. So if you build a cloud native application out there on whatever your preferred cloud stack is—again, I’ve been using AWS just for reference purposes—you build an EC2 instance, your default storage will be object storage, right? You’re not using block storage, block level storage or anything like that anymore, or NFS or anything like that. And that’s also where again—the whole concept of object storage, other than having a huge value proposition from a price performance point of view—but as you think about cloud native and the mainframe wanting to become more of a part of this hybrid cloud architecture, you know is [inaudible] container extensions and all that great technology that has been developed over the past couple of years, right? I think it’s very key that mainframers understand the concept of object storage, the importance of object storage, because again nobody is going to attach an ECKD device to a cloud native container.
Reg: Now there’s a few things that you’ve said that I’m going to dig deeper into once you mentioned containers, but before I get to containers, you talked about unstructured. Now of course mainframe is famous is for its structured data. I mean that’s one of the reasons the ESMs work so well is you can identify data and secure it at the field level because it is so highly structured. And so I’m wondering whether this object storage is something you would use for highly structured data as well, or if you’d mostly use it for rich multimedia and that sort of thing.
Eddy: I think in the context of cloud native it now also becomes this or has become a storage media for structured data, but if you think again about the use cases that I just outlined quickly for Model9, you know a backup—say something like a full volume dump—I mean that’s essentially a large blob of unstructured data like a big video or a big image or a big audio file, right? So yes, while the originating data is highly structured, what we then put in the cloud doesn’t have to be structured per se.
Reg: Okay so basically backing up—for an example, at a volume level—so you’ve got an off-site backup that’s available for an emergency or for access from an alternative platform. Now let’s talk about containers, because this is sort of one of these things that just landed on the mainframe. Like they’d be doing it elsewhere and suddenly, bam! Now not only are we doing containers through the hypervisor, we’re doing containers directly inside of zed/OS or z/OS. And so I’m thinking maybe if you can try to draw a picture to help people get up to speed both on the container state of the art on the mainframe and how you would use what you’re doing to really help that be more effective. Then I’m going to start digging into the weeds to how you talk to the mainframe, but go ahead.
Eddy: Yeah, so in all honesty I think there’s much better people to talk about the state of containers on the mainframe. I mean again the only thing that I would like to bring home is as you think about containerized applications and cloud native applications, just how important it becomes to also think about the underlying storage architecture. The whole idea of a containerized applications is that it is highly portable, which I think is a wonderful idea, right? It takes the concept of Java kind of to the next step, and I think there is going to be a lot of benefits for the mainframe because we’ve been talking about fit for purpose I think for decades now.
Reg: Yeah.
Eddy: You run your apps on the right platform, you know with the right quality of service or whatever, and I see containers as a huge potential for the mainframe. Now you developed the containerized applications and you realize hey, this containerized application needs super-fast I/O. It needs high security, or it has a really close affinity to your mainframe, whatever you’re running—your core bank and your airline reservation system. So let’s just port that container that could develop somewhere in the cloud and move it to the mainframe, but while doing so, again think about the underlying storage architecture, because your containerized application will very likely want to talk to an object storage-like architecture instead of block architecture.
Reg: So that’s one dimension of it. Now I’m thinking about—I mean you are saying you guys were founded with the idea of doing things more cost effectively and efficiently? I mean you know as a mainframer, I love ESCON, FICON, all these things that are such differentiators, and you are going straight to TCP/IP. Tell us about why is that a good idea.
Eddy: Yeah, and it’s funny. That was the other reaction that I had when I first learned about Model9—you know, why the heck? I mean how can you be faster than a virtual tape server that sits a couple of feet away from the mainframe in the same data center—again, ES attached by those extremely efficient fiber optic connections. But I think the important thing—well, I think there’s two important things to understand. So first of all, you have to talk about bandwidth, throughput, and latency. So from a latency perspective, TCP/IP, even in your data center, can’t even come close to FICON, right? FICON is so efficient, and so much development work has been put into FICON to reduce the overhead that TCP/IP comes with, right? I mean if you’re looking at low latency for very kind of chatty workloads, very I/O intensive workloads, again think about Db2 doing a million IOPs on your system. That’s nothing, and you want to connect via TCP/IP to TCP/IP storage, but if you think back about the use cases that I was mentioning, cyber resiliency. You want to create a large third data copy of your data, or again, backup/restore. You do a full volume dump or even an incremental backup of petabytes of data, or again you expose your mainframe data, and again you want to take the last ten years of customer interaction data and move it to a data lake for analytics. We’re always talking about really large data volumes and in that case, I mean it’s kind of like you push a large object through the pipes. Yes of course latency going to the cloud or even to object storage in your data center is going to be way more than FICON, but it’s only going to be bigger for that first transaction, right? After that transaction, you just start to push data out there and from a throughput perspective, it’s interesting. I mean TCP/IP has gone a long ways, right? I mean what do we now have, 25 GB OSAs? I don’t even know anymore. I think 100 GB OSAs for sure on the horizon, and I would wager a bet that we see 100 GB OSA way before we see 100 GB FICON—
Reg: Oh, interesting thought.
Eddy: And a lot of the data center infrastructure already supports 100 GB Ethernet today, so from a pipe size perspective, Ethernet has become pretty capable. But the same is true once you leave the data center, right? A lot of those hyperscalers, they provide you direct pipes from your data center to Google Cloud to Microsoft Azure to IBM’s cloud, obviously to AWS and those direct connection pipes, can be very, very large. I mean when we interact with customers it’s not uncommon to see customers that have multiple 10 GB links into public clouds. So from a throughput perspective, TCP/IP has gone a long ways, and now look at the receiving end of this chain. So we have the mainframe, we have TCP/IP, and then we have the object storage platform. I mean it sounds cool on marketing brochures, right? It has near limitless scale and yeah, you can make of it what you want but the scale of an AWS data center or a Google data center is something to respect, and the same is true for on-premise object storage platforms. There has been so much innovation over the past couple of years in that space. There are plenty of flash offerings that have an extremely parallel architecture that can ingest tens if not hundreds of gigabytes per second. So from a receiving end perspective, object storage is extremely capable.
Reg: So that’s interesting to talk about what we sometimes call the feeds and speeds, but of course the use cases are what really makes it relevant. Because you know obviously there are security issues, there’s availability issues, there’s the customer use. What are some of the ways you would use this that are really consistent with that whole mainframe way of doing things so scrupulously, so carefully, so effectively?
Eddy: Yeah, yeah, great question. So let’s talk about a couple of the use cases, right? I think that probably the simplest one is cyber resiliency, and don’t get me wrong. Cyber resiliency is a very difficult topic.
Reg: Oh yeah.
Eddy: But let’s only look at the niche of cyber resiliency with our product called Model9 Shield. The purpose of Model9 Shield is simply to create a third data copy of your data on object storage that can be on-premise or in the cloud, and then use an object storage capability called object lock, where you make the data immutable. So now you have an immutable copy of your data that is off the mainframe, potentially even off-premise—and I’ll come to an interesting customer example in just a second. I think the price performance of object storage is great, but it’s also just the simplicity. So we have one customer in northern/eastern Europe. It’s in a country that shares a border with Russia. That’s all I’m saying.
Reg: Ah, I can think of a country like that [laughs].
Eddy: They’re in the banking sector and when that whole situation in Ukraine started going south, they were obviously, as a neighboring country, they were very concerned about the situation, and they wanted to create a third data copy as a best practice. Now they wanted to create a third data copy not in their data center, not even in another data center in the country, but they wanted to create a third data copy outside of their country in a NATO member country.
Reg: Wow.
Eddy: And they were able to kind of achieve that architecture using Model9, using object storage—much simpler, much faster—because again, we don’t need to ship any hardware. You don’t need to install anything in your data center. We just connect to an object storage bucket and we move your data there. Obviously we encrypt it and we compress it, but first of all it’s a whole lot simpler than doing this on-prem stuff. And the use case, like what I just mentioned, you know that simply wouldn’t be possible with on-premise kind of infrastructure with traditional FICON unless you were one of the megabanks that can really afford—hey yes, I purchased another data center somewhere out of country. I put mainframes there, I put mainframe storage there, I put mainframe staff there. But I mean we’re talking about tens of millions of dollars of investment and probably a multiyear project.
Reg: Whereas this is something that had to happen really fast—
Eddy: Yeah, yeah, absolutely.
Reg: Because of the geopolitics involved. Really interesting. Okay so that’s one use case, and I can certainly see the value in having that that rescue ship of data just in case everything really goes south fast. How about another use case? Let’s talk about other perspectives that you can use this for.
Eddy: Yeah. I mean obviously once you have—and again I mean the example that I just mentioned is probably kind of on the extreme scale. Obviously we have other customers that do it more traditionally. They use an on-premise infrastructure to create their third data copy, too. But anyway I thought it’s kind of—it showcases kind of the capability and the value that the mainframe can gain from the technology. So I mean building on top of Model9 Shield, we do have another product called Model9 Manager that then takes this use case of copying data and extends it to full backup/restore, right? Model9 Shield, it’s kind of a one shot, you tell me you want to take a snapshot of your copy tonight or once a week, or whatever you need from a recovery point objective. Model9 Manager now goes the next step and implements all the backup policies that the mainframe is known for, like hierarchical storage, making sure you move your data into archives and you’re capable of recalling data from archives and all that good stuff, and kind of extending that cyber resiliency use case now into a full backup/restore use case where you can use object storage instead of your probably more complex and pricey on-premise tape or virtual tape infrastructure.
Reg: Now is this something you then would connect in with like database tools to do roll forwards and that sort of thing, or how does that all fit together?
Eddy: Yeah, yeah.
Reg: Okay, cool. Now so you’ve talked about two of your products. Maybe if you can just get a sense of some of the other products and use cases that you have as well.
Eddy: Yeah, so the last product use case that we have is what we called Model9 Gravity—you know, kind of a play on data gravity—and Model9 Gravity does two things very, very efficiently. We were talking about the speeds and feeds, and obviously the speeds and feeds are very important for Model9 Shield and Model9 Manager, because you want to make sure that you move your data as quickly and as efficiently to your backup location, but then also back in case you have to do a restore of a database or in case you have to restore and restart the full system. We’ve leveraging the same technology to move data from the mainframe to the cloud. So think of it like any data mover you have today—FTP, write, whatever ETL tool you come to think of—to move data from the mainframe somewhere else. So what we do is we move really large amounts of data very efficiently using our technology to object storage. If you think again about the discussion that we had at the beginning, okay so what is object storage used for? Well, it’s used for analytics and it’s used for anything out there that’s cloud native. So if you’re a large shop and you’re working on cloud native things, or again you have a data scientist department, which you very likely have, you know those data scientists and the cloud developers, they are very likely working with object storage, right? So the advantage of our solution is we’re not landing your stuff somewhere else—you land your stuff on Linux server, and then the Linux server has to bring it to object storage. We now have a direct interface between z/OS to move that data directly to object storage. So that’s kind of the first capability of Gravity, and then the second capability of Gravity is now as you move the data to that cloud native object storage, it’s still in mainframe formats, right? So the data scientists—they probably can’t do a whole lot with it, and your cloud applications probably also—they’re wondering about track cylinders and big Indian. Exactly like what’s going on here? So what the second part of what Gravity does is we have a part of Gravity that runs in a container, so it can run natively in the cloud or in a container in your data center on the VMware or whatever that then transforms the mainframe data into open systems format—you know, ASCII, UTF—and then put it into JSON or CSV5 or something like that. So that way your cloud applications or your AI teams with their AI algorithms stuff, they no longer have to go back to the mainframe team and ask hey, what’s that COBOL copybook structure again? Now they can work with that data just like they work with any other data.
Reg: Okay, cool. Now one of the things that been implicit with a number of the cases you’ve given is dealing with people who have a somewhat—more typical, I guess—education about IT. Obviously the mainframe people are always going to be out there and it’s still a bit of a specialized area, and as we look to the future of the mainframe there’s a number of different strategies, one of which is teach people mainframe, but another is speak to people where they’re already at. And I sense that that is a big part of how you guys can help the mainframe world move into the future is by being you know, compatible with how people are already doing stuff. Maybe you could talk a bit about that part of how you help people future proof their mainframes.
Eddy: Yeah, it’s a great point. I mean, I love the mainframe. I’ve always been a mainframer, so I want to make sure that this platform stays relevant for the next couple of decades—at least until I retire, right?
Reg: Yeah.
Eddy: So yeah, I think a couple of things here. First of all, again from a simplification point of view, I am now having more and more discussions with decision makers at large customer shops that tell me, hey look. We want to standardize our storage infrastructure to one or two storage technologies, and object storage is always one of them. Sometimes they will also talk about NFS, but object storage is always the first thing that comes up. So as you think about that, I think one of the advantages of using Model9 is now your mainframe can participate in that enterprise-wide strategy, right?
Reg: Right.
Eddy: You are no longer the odd kid. Again, it’s using ECKD and you know, track cylinders and FICON infrastructure. Now you’re just plugging into a corporate-wide object storage strategy, whether that is on-prem, hybrid, or in the cloud. From a strategy point of view, I think that is really helpful. And then the other thing—yeah, obviously once you can make the mainframe data more easily digestible for AI, for machine learning, for cloud native applications, I think that also make things a whole lot easier. And I think it’s all about, as I said before, not being the odd kid in the room. You just say hey, yup, we play nicely. Here’s your data. So I think that’s really where the mainframe can benefit a lot, and then there’s also all the innovation that is going on that otherwise would be kind of restricted for the mainframe. I mean again just from a hardware perspective as I said before, there’s so much crazy stuff going on in the object storage world that I feel the mainframe could really benefit from, but then there’s also all the other innovation. I mean I think most of the AI and data tools that are out there today, they’re all cloud native, so how do you get the data to those tools? Our Gravity product I believe is a cool answer to get it there in a very efficient manner.
Reg: Now of course, in addition to getting a new generation on the mainframe and all these other things—though there’s the fact as you pointed out, the mainframe is going to be around. I mean probably not just another 10-20 years—probably our great great grandkids will be working on something that is recognizably the mainframe. So as we take a look at that future and really try to not only predict it—but I like to say, pro-dict it—you know, chose how to contribute to that future. Maybe if you could share some thoughts about the future of the mainframe and how you folks are deliberately participating in creating that future.
Eddy: I think one thing that we’re doing clearly has to do, again, with storage abstraction. I think storage abstraction is important. The more we can leverage open technologies, the better for the mainframe, because you no longer need specialized skills, you no longer need specialized hardware or specialized infrastructure. I think that will help. Again, once you’re using object storage and an object storage platform, everybody that knows how to operate an object storage system can now help you operate your mainframe object storage system, right? So you no longer need specialized skills. I think that is a big advantage, but the other thing has to do with—you know, like you, I believe that the mainframe will be around for decades, but for certain workloads. I think there’s workloads where the cloud just makes more sense. I mean if you have a development test environment that you want to rapidly spin up and tear down, I think cloud probably makes more sense. If you need tomorrow—I don’t know—a thousand cores to do analytics on your data, I mean even though we have on/off Capacity on Demand on the mainframe, you probably would prefer to do it on the cloud for multiple reasons. So there are very valid reasons to use the cloud. I think that’s also why IBM is now pushing the whole notion of a hybrid cloud more and more, right? But in order to be relevant for the mainframe and stable enough for the mainframe, I think the mainframe is going to continue to do stuff that it does really well—like security, like transaction processing—but then interface with the other systems that are there today that will be there in the future, and interface as seamlessly as possible. You know I remember—and you probably, too—in my over two decades in the mainframe world, how often did somebody not want to work with me because we were being too complicated, because we said yeah, you can connect to the mainframe, but come back with your RACF profile and this and that and that. Then people just said you know what? I’m not going access your Db2 data, I’m going to go somewhere else or whatever. I think the easier we make it for the rest of the world to work with the mainframe, the healthier the mainframe will be, now and in the future.
Reg: Cool. Well thank you very much for this, Eddy. Any final thoughts you wanted to leave us with?
Eddy: Well it was a lot of fun talking to you, Reg. Again, if people are interested in Model9, please visit our website at Model9.io. But yeah, it was a lot of fun talking to you.
Reg: Well this has been a real pleasure Eddy, thank you. I’ll be back with another podcast next month but in the meantime check out the other content on TechChannel. You can also subscribe to their weekly newsletters, webinars, ebooks, solution directory and more on the subscription page. I’m Reg Harbeck.