(upbeat music) >> From around the globe, it's theCUBE with digital coverage of Postgres vision 2021 brought to you by EDB. >> Hello everybody. Welcome back to Postgres Vision 21. My name is Dave Vellante and we're super excited to have Josh Berkus on. He's joining us, he's a leader in the Kubernetes community, extremely well-versed in containerized applications, application development, containerizing databases all things Open-source, CUBE alum, Josh Berkus welcome back to theCUBE. Great to see you again. >> Thank you. I'm glad to be here. >> Just recently, you're coming off KuberCon, we heard some of the themes from that event. There was a lot of focus on inclusion and diversity, which of course, you know, that's the Open-source ethos and a lot of discussion around designing security in, the whole conversation about shift left. That's great to see larger companies giving back, to obviously a lot of the pressure over the years on the big companies that there's a one-way street, they're actually giving back, making some investments. So we love to see that. And just Open-source continues to be the main spring of innovation. I got to say, I got to call-out and a recent Red Hat survey the state of the enterprise Open-source in 2021, 90% of technology leaders said that they're adopting Open-source and made a joke that the other 10% they're doing it they just don't know it. But so what were some of your takeaways from the event and some of the trends you're seeing but specifically as it relates to containers. >> So, I mean, you're right, one thing is this sort of return to security, the security topic again because we've had like a couple of things happen. One was, when we initially got, started doing containers or platform with Docker and with early Kubernetes and that sort of thing we got a lot of container image scan, right? So you have like Clare and Docker has a scanning thing and Amazon and Azure have their own scanning things. And people felt that was kind of good enough for a while but then we both had the solar winds hack. And the thing is like, in the meantime, we've gone from a stage where people were mostly using Kubernetes in dev to people using Kubernetes in production. And there's a lot of extra security issues and vulnerabilities that come up in an actual production environment that people just didn't necessarily think about before. And so now we're looking at adding more pieces to the security stack and making those more standard for everyone who uses Kubernetes. And I've had the chance to work with the StackRox folks since they became part of Red Hat. So it's been very exciting to look at the whole thing and look at things like container supply chain because the solar winds showed us obviously, it's not enough to necessarily just trust the vendor. You need to trust their whole supply chain. And it helps to be able to examine that supply chain. >> Yeah, it's very scary when you look at that you're absolutely right. Multiple components of malware coming into an organization through the supply chain cell forming, different signatures. And so it's great to see the community spending time on that and an emphasis on that. Now I got to cut right to the chase here, in 2018, you wrote a two-part blog series it's called Should I run Postgres in Kubernetes? Obviously it's highly relevant for this community. So I want to talk about your perspective, well, first of all, the thing I love about you is you're tactical and you can go deep, but at the same time, you can speak to a business audience. >> Thanks. >> You're welcome and thank you for writing this and communicating the way you do, but talk about when it makes sense and when it doesn't, I mean, that's kind of... My big three takeaways on the pros were simplify, simplify, simplify, especially if you're running application components and other services on Kubernetes but give us the update three years later, why should you, why shouldn't? >> You know let's actually, why don't we zoom out to an even bigger picture? Which is just honestly like every new platform that we've got, right? So when virtualization and VMware became a thing we had the same sort of decisions about when do I move my database to this, when AWS and the public cloud became a thing. I could have like, like if I had written that 12 years ago I could have written it about AWS and it would have had a lot of the same decision tree 'cause what it really sort of comes down to is the more commodifiable a particular database instance is the better candidate it is to move to an advanced infrastructure platform, and the most advanced, currently being Kubernetes. To the extent that you can describe this particular database, what it does, who needs to use it, what's in it in and a simple one pager then that's probably a really good candidate for hosting on Kubernetes. Whereas if you have a database where it's like, Hey, the entire company uses it and it's so complicated we can't describe it's inputs and outputs. That's possibly the last thing in your company that you're going to migrate to Kubernetes, because both in terms of there's less gain to be made there, because the real advantage of moving stuff to Kubernetes is your ability to automate things. The whole way I got into Kubernetes in the first place was I started out way down the line not using containers at all. I was just looking to solve the problem of how do we automate Postgres high availability. That's what I was looking for. And it started out with something I built using SaltStack called handy rep, that Casey and I built. And mostly that was a problem discovery exercise, we discovered what the hard problems were there. And then we moved from that, and then we moved from that to Docker because containers offered an encapsulation strategy because one of the problems you run into when automating high availability is the database actually down or not. And so the first thing that containers offered us was not packaging, what people usually talk about but instead of encapsulation, right, because it's a lot easier to determine is the container running or not, than is the database down or not? Because an actual Postgres database has multiple components and multiple processes that make it up. And some of those can be down without the others being down which can then make you think a database is down that's not actually shut down. And being able to put that in a container, it gives me more of a binary up or down. And then from there, I got into, okay, well but I need to automate a lot of other components. I need to automate the storage and everything else. And that led to Kubernetes. And so if you look at it in terms of deciding when you're going to migrate the database to Kubernetes you look at, can I take advantage of that automation? Is this something that my application workflow and my team organization allows me to do? And if the answer is yes, particularly, if you're in a company that's doing the full dev ops thing where you have a unified development and infra team that owns the entire stack then those people are going to be a really good candidate for moving that stack to Kubernetes. >> Got it. Okay, so let me ask you, in database especially in critical apps, your recovery's everything, when something goes wrong, you got to recover. So if I understand it correctly, just in reading and listening to you, if you've got Kubernetes expertise and you're building applications in that environment then the application components are in there. And am I inferring correctly that you're going to be able to automate and facilitate high quality recovery with certainty? >> Yeah, there's a bunch of infrastructure involved, and this is why, what enterprises do is they move things like the web front-end to Kubernetes first and is what they should do, right? That is absolutely the right order of things to do because the minute that you're looking at bringing databases in, you're now looking at your whole storage infrastructure. So that direct attack storage that was attached physically to one machine is not going to work once you've moved to a container-based cloud. You suddenly need a way to be able to attach that storage to any of the nodes in your cluster so that you can move the database around and you can have fail-over. But once you build those things up, you can't. I mean, some of the stuff that I've done, I work in the office of the CTO now at Red Hat. So I'm not in production support. So the only Postgres instance I'm supporting are ones for some Open-source projects we support like the Python project. And in those cases, it's not a high criticality database, but I'm not support, I'm not on call on the weekend. I want something where it doesn't require need to be on call in order for it to stay up. And so putting that on open shift with the Patroni fail-over driver was the answer for that. And it has failed over in the Red Hat IT team contacts me and says, "Hey, we need to move those servers. And then we'll just add a node to the cluster and delete the old node and it'll do the right thing." And I don't have to worry about it, which is really what you're going for there. >> The other thing I took away from your writing was that you suggested that a lot of the successes in areas where the Postgres databases were rather small and there were a lots of them. And so to the extent that you can automate that you're going to save yourself a lot of problems. Whereas in the flip side if you're running extremely large databases or there may be performance constraint that might be an area to be a little bit more circumspect. >> Yeah and that's absolutely true because like the other side of this, like I've worked with the dev ops people and the people who are on Heroku and that sort of thing that have one database per application, right. And those people are great candidates for migrating. But then I've also worked with the people who have a one big database for the company, where the database is three terabytes in size, it powers their reporting system and their customer's system and the web portal and everything else in one database. That's the one that's really going to be a hard call and that you might in fact, never physically migrate to Kubernetes because even if it's on Kubernetes you are going to mess with the hardware policy to give it its own dedicated machine. So in that case, what I would honestly tend to do is there's a feature in Kubernetes called service catalog that allows you to expose an external service within Kubernetes as if it were a Kubernetes service. And that's what I tend to do with those kinds of databases because it's, there's not a huge advantage in actually physically moving the database to a container. There's a bunch of steps involved and going via service catalog is a lot easier. >> But essentially you're you're speaking the same language in that example that you just gave. >> Yeah. >> Now, the other thing you pointed out at the time that you wrote this article is there's a lot of pre 1.0 kind of alpha in the Kubernetes stack and it might be prudent to if, not putting your HIPAA compliant, since it evolved. >> Yeah, if I was to update two things in the article I guess that would be one of them the other one I'll get to in a minute. So the first one is that, Kubernetes has progressed along that maturity timeline. Like we recently added the production readiness reviews as part of our feature review process. We've really improved tested adherence, so that we're not releasing with known broken tests, and a bunch of other things to make it more stable. But part of it depends on who I'm talking to because there's still degrees here. So if I'm talking to the context of the world of software then Kubernetes has reached the point of maturity that it is as stable as anything else. And if you use a release, you can assume that any sort of major issues have been worked out. The one difference with it and some other platforms people may have used is it's still young enough that backwards compatibility can be an issue. As in Kubernetes releases now three times a year, we've stepped down from four and within three releases you can find yourself needing to change API calls which means needing to refactor parts of your application. So if you compare that with some other things, like a JVM platform, when's the last time you had a major API change with a JVM platform. But you know the Kubernetes is only six years old, so that's part of that. The other thing is the question is I'm talking to the Postgres community, right? Which is within Postgres, people run the daily Postgres snapshot in production. I would not do that with Kubernetes, I would wait for release. So there's still kind of a difference there if people are coming from the Postgres community, right. Is we're used to this really extreme level of stability that we have with Postgres and Kubernetes as a much younger project isn't quite there yet. >> So that's a process, a change that you would have to be aware of if you want to take the benefits of containers with Postgres, you just have to really understand that and make that process part of your change management. >> The other thing I would say has changed is there are new opportunities in running your data warehouse, your big data databases on Kubernetes. A number of platforms, the one I'm most familiar with is Citus, because I worked with those folks that have taken advantage of Kubernetes as a deployment and management platform for their database, their big data database infrastructure, which makes sense because if you look at a lot of modern data analysis and data mining platforms that are built on top of Postgres part of how they do their work is they actually run a bunch of little Postgres instances that they federate together. And then Kubernetes becomes the tool that allows you to manage all of those little Postgres instances. So that's the sort of exception to the, should I migrate this really big database? That can be a yes, if you are migrating it to a big data platform that supports Kubernetes, then it can be a huge advantage. >> Obviously you've got the practitioner knowledge and you were working in the community. I'm wondering if you can share just thinking about sort of the motivation to move to a container environment if you're one of the Postgres folks in the audience could you share any, either anecdotal or other data on business impact, benchmarks that you've seen, some of the things that you've seen some positives there? >> If you actually look at my history when you talk about performance is one, right? And if you actually look at my history, I actually did, and for that matter of some of the folks from Percona and some of our other folks in the database field did a bunch of benchmarks of running Postgres in MySQL, on Kubernetes versus running it not on Kubernetes. And one of the advantages of containers over VMS is that there isn't any intrinsic, there's not any intrinsic sort of layer gap or virtualization that modifies your performance. In other words, if a container is using storage that's present on the node where the container is running it is using that storage through Linux. And therefore the performance is, with some caveats, performance is going to be identical to if you were running that on the host system. Now, where performance differences creep in is that you might not be able to use the same kind of storage. In that Kubernetes and containers systems in general are organized around the idea that no service is using a majority of the resources on the system, so again, if you're planning on user running a larger Postgres database that really needs all the RAM that a system has you're going to have to do a lot of tinkering with Kubernetes configuration to get the same performance, you would have a running it on a dedicated hardware now. >> Okay, but fundamentally you're saying that overhead is less with caveats, like you said, you just mentioned in the story, right? >> Yeah, well, the overhead is not any different from if you were running under the host system. So a really good example of that was, if you go back to on my lightning talking in, (indistinct) Austin, I think. I showed running a benchmark with Postgres on an AWS instance using EBS storage, both not in Kubernetes and in Kubernetes. And there was no perceptible performance difference between the two of them because it was all metered by how fast was EBS for me. >> Right, and I said less, but I should've been more specific less than say you would expect with virtualization. >> Right, and then it just comes down to a business decision, which is that if you're already on some sort of cloud storage or network storage, and again you have databases that can share hardware systems then you shouldn't really expect substantial performance differences by moving to Kubernetes. That's something that you can eliminate inside of words, but if you're going in the process going to be migrating from direct attached storage to network storage then you are going to see a performance difference but that's caused by the change in storage. Or if you're going to be moving from systems that are not shared to systems that aren't shared again you're going to see a difference from them, but it wouldn't be any different than if you did that without Kubernetes containers being involved. >> If you're using any world-class shared storage device from whatever name of big vendor, you're going to accommodate if you're racking and stacking your own flash drives or worse yet spinning disk drives that's in direct attached, that's maybe a different story, so, okay. That's good. Where would you advise people to get started with Postgres and Kubernetes? >> The nice thing is there are a number of advanced systems now, and advanced systems that are supported by the various Postgres vendors. And that can actually be a great place to get started because the systems are Open-source so you can try them out. This is, as far as I know, they're Open-source you can try them out but then if you decide you like them, you can get support. And so that would include Crunchy data. Enterprise DB has a system, and honestly, I have to admit less familiar with than the ones that Crunchy runs. StackRox is another one out of Europe that has their own system for running cloud native Postgres. And there's one I'm forgetting, and what a lot of these have to do with is taking advantage of the automation. 'Cause you can obviously can put Postgres and container play around, right? But your whole point of moving to Kubernetes in general is going to be take advantage of the automation, so you want to look at the various automation platforms and you can go ahead and do that and the one I'm most familiar with because I develop it as Patroni, is the component for automating Postgres. You do Patroni plus you do operators, it's another word that comes in here. But if you're looking at this as a business you're probably going to want something that supported or that at least there's a potential to buy support and a bunch of the different companies in the Postgres space package up these components for you into a platform. Like I know the Crunchy platform uses Patroni plus some proxy stuff, plus PG back rest plus a couple of other things to give you a sort of full automation platform for running Postgres on Kubernetes. >> Awesome, last question. Where are we in the whole container adoption, we started out kind of you've mentioned this stateless and now you're building stateful applications but still you look at the, we look at spending data with our data partners ETR and containers and container orchestration. It's it's right up there with RPA, with cloud, with AI just in terms of the attention and resource that's going in. So it's exploding. It feels like it's still early days. There's a lot of legs left, what do you see? >> Yeah, well, a lot of it is, I mean you're talking about migrating IT infrastructure, right? So where we are with Kubernetes is we have the early adopters, right? We have all the people who were at the point of building their new infrastructure when Kubernetes came out, right. And people who had major unsolved problems which is a big reason for adopting a new platform was just was no old platform for you. and so we sort of have those people and those people are already on Kubernetes and running their stuff there. And so now we're looking at the really long path of people who are not in one of those camps moving, right. And in a lot of cases, that's a matter of coinciding with other reasons why they have to look at an upgrade because even if, whether it's the gradual replacement of old applications by new ones, where you gradually all the legacy applications get offline and the new applications run in Kubernetes or sometimes it's a, "Hey we're waiting for replacement cycle." We're waiting for, we already had plans to move from on-prem to public cloud, and so we're going to move from on-prem to public cloud on Kubernetes, to make it part of the migration. And that'll be years. I still like, I have fingers into other areas, like I still know a lot of people in the nonprofit space and a lot of nonprofits just got around to adopting virtualization, right? Like they're not even at public cloud yet. I don't even talk to them about Kubernetes. There's this huge long tail in terms of adoption. The nice thing is we don't show any signs of stopping, is that one of the things that we kind of learned from earlier stuff particularly learned from our friends at OpenStack was to really really focus on the APIs, to look at who Kubernetes more as the hub of a system of an infrastructure idea with potentially unbounded growth. If you have a new concept that comes in like service mesh, service mesh is not a successor to Kubernetes. It's not an alternative to Kubernetes. It is a thing you layer on top of Kubernetes because we didn't make it exclusive. >> Right. Great, great example going back to OpenStack and thank you for bringing that in because there's lessons learned. And so Josh, we've got to leave it there. Thanks so much for coming back in theCUBE, great conversation, you're awesome. >> Okay, good to talk to you. >> All right, and thank you for watching everybody, keep it right there for more content from Postgres Vision 21. My name is Dave Vellante, you're watching theCUBE. (upbeat music)

(upbeat music) >> From around the globe, it's theCUBE! With digital coverage of Postgres Vision 2021, brought to you by EDB. >> Welcome back to Postgres Vision 21, where theCUBE is covering the innovations in open source trends in this new age of application development and how to leverage open source database technologies to create world-class platforms that are cost-effective and also scale. My name is Dave Vellante, and with me is Roberto Giordano, who is the End User Computing, Corporate, and Database Services Manager at Borsa Italiana, the Italian Stock Exchange. Roberto, great to have you. Thanks for coming on. >> Thanks Dave, and thanks to the interview friend for the invitation. >> Okay, and we're going to dig in to the great customer story here. First, Roberto, tell us a little bit more about Borsa Italiana and your role at the organization. >> Absolutely. Well, as you mentioned, Borsa is the Italian Stock Exchange. We used to be part of the London Stock Exchange, but last month we left that group, and we joined another group called Euronext, so we are now part of another group, I would say. And right now within Euronext, Euronext provide the biggest liquidity pool in Europe, just to mention something. And basically we provide the market infrastructure to our customers across Europe and the whole world. So probably if it happens for you to buy a little of, I don't know, Ferrari for instance, probably use our infrastructure. >> So I wonder if you could talk about the key drivers in the exchange business in Italy. I don't know how closely you follow what's going on in the United States, but it's crypto madness, there's the Reddit army driving up stocks that have big short positions, and of course the regulators have to look at that, and there's a big debate going on. Well, I don't know what's it like in Italy, but what are the key drivers that are really informing the priorities for your technology strategy? >> Well, you mentioned, for instance, the stereotypical cases that are a little bit of laterally to the global markets and also to our markets as a it professional running market infrastructure is our first the goal to provide an infrastructure that is reliable and be with the lowest possible latency. So we are very focused on performance and reliability just to mention the two main drivers within our systems. >> Well, and you have end-user computing in your title and we're going to get into the database discussion, but I presumably with with COVID you had to pivot and that that piece of your job was escalated in 2020, I would imagine. And you mentioned latency which is a key factor in obviously in database access but that must've been a big challenge last year. >> Well, it was really a challenge, but basically we move just within a weekend, the wall organization working remotely. And it has been like this since February, 2020. Think about the challenge of moving almost 1000 people that used to come to the office every day to start to work remotely. And as within my team of the end user computing this was really a challenge but it was a good one at the end. We, we, we succeeded and everything work. It's fine from our perspective, no news is is a good news, you know, because normally when something doesn't work, we are on newspapers. So if you didn't heard about us it means that everything worked out just fine. >> Yeah. It's amazing, Roberto. We both in the technology business that you'll be you're a practitioner observer, but I mean if you're in the tech business most companies actually pivoted quite well. You're have always been a digital business, different. I mean, if you're a Ferrari and making cars and you can't get semiconductors, but but most technology companies actually made the transition you know, quite amazingly, let's get into the, the case study a bit of it. I wonder if you could paint a picture of your organization's infrastructure and applications what it looks like and and particularly your database infrastructure what does that look like? >> Well, we are a multi-vendor shop. So we would like to pick the right technology for for the right service. This means that my database services teams currently manage several different technology where possible that plays a big role in, in, in our portfolio. And because we, we, we currently support both the open source, fully open source version of Postgres, but also the EDB distribution in particular we prefer to use EDB distribution where we did specific functionalities that just EDB provide. And we, when we need a first class level of support that EDB in recent year was able to provide to us. >> When you say full functioning, are you talking about things like acid compliance, two phase commits? I mean, all these enterprise capabilities, is that right? Or maybe you could be >> Just too much just to mention one, for instance we recently migrated our wire intrasite availability solution using the ADB fail-over manager. That is an additional component that just it'll be provide. >> Yeah. Okay. So, so par recovery obviously is, is and so that's a solution that you to get from the EDB distro as opposed to having to build it yourself with open source tooling. >> Yeah, correct. Well, basically sterically, we used to rely on OSTP clustering from, from, from that perspective. But over the years we found that even if it's a technology that works fine, it has been around for four decades. And so on. We faced some challenges internally because within my team we don't own also the operative system layers. So we want a solution that was 100% within our control and perimeter. So just few months ago we asked the EDB EDB folks if they can provide something. And after a couple of meetings also with their pre-sales engineers, we found the the right solution for us. So we launched long story short, just a quick proof of concept to a tissue test together, again using the ADB consultancy. And, and then we, beginning of this year, we, we went live with the first mission critical service using this brand new technology, well brand new technology for us. You know, it'd be created a few years ago >> And I do have some follow-up questions but I want to understand what catalyzed the, you know what was the motivation for going with an open source database? I mean, you're, you're a great example because you have your multi-vendor so you have experienced with all of it, the full spectrum. What was it about open source database generally EDB specifically that triggered the, the choice? >> Well thanks for the question. It is, this is one of the, or one of the questions that I always, like. I think what really drove us was the right combination between easy to use, so simplicity and also good value for money. So we like to pick the right database technology for the right kind of service slash budget that the survey says and, and the open source solution for a specific service. It, it, it's, it's our, you know, first, first, first choice. So we are not going to say a company that use just one technology. We like to take the best of breed that the market can offer. In some cases, the open source and Postgres in particular is, is our choice. How involved was >> The line of business in this both the decision and the implementation? Was it kind of invisible to them, or this was really more of a technology decision based on the your interpretation of the requirements I'm interested in who was involved and how you actually got it done? >> Well, I, I think this decision was transplant for, for, for, for the business at the end of the day don't really have that kind of visibility. You know, they just provide requirements in particular in terms of performance and rehabil area, the reliability. And so, so this this is something they are not really involved about. And obviously if they, if we are in opposition to save a little bit of money everybody's at the, even the business >> No. So what did you have to do? So that makes sense to me, I figured that was the case. Who would, who were the stakeholders on your team? I mean, what kind of technical resources did you require an implementation resources? What take us through what the project if you will look like, wh how did you do it? >> Well, it's a combination of database expertise. I got the pleasure to run a team that is paid by very, very senior, very, very skilled database services professional that are able to support more than one more than what the county and also are very open to innovation and changes. Plus obviously we need also the development teams the relevant development teams on board, when you when you run this kind of transformations and it looks like also, they liked the idea to use PostgreSQL for for this specific service I got in mind. So it, it, it was quite, quite easy, not be discussion. You know. >> What was the, what was the elapsed time from from when you said, okay, we're in, you know signed the agreement we're going here you made the decision to actually getting into production. >> Well, as I mentioned, we, we, we were on we're on services and application that are really focused on high availability and performance. So generally speaking, we are not a peak organization. Also we run a business that is highly regulated. So as you know, as you can imagine we are an organization that don't have a lot of appetite for risk, you know, so generally speaking in order to run this kind of transformation is a matter of several months, I will say six nine months to have something delivered in that space. >> Okay. Well, that's, I mean, that's reasonable. I mean, if you could do it inside of a year that's I think quite good especially in the highly regulated industry. And then you mentioned kind of the fail over the high availability Cape Cape capabilities. Were there other specific EDB tools that that you utilize to sort of address the objectives? >> Yeah, absolutely. We were in particular, we used Postgres enterprise, AKA Pam. Okay. And very recently we were involved within ADB about per se specifically developing one functionality that, that that we needed back in the day. I think together with Bart these are the free EDB specific tools that, that we, that that we use right now. >> And, and I'm, I'm interested in, I want to get to the business impact and I know it's early days for you but the real motivation was to save money and simplify. I would actually, I would imagine your developers were happy because they get to use modern tooling and open source. But, but really though if your industry is bottom line, right, I mean that's really what the, the business case was all about. But I wonder if you could add some color there in terms of the business impact that you expect. And then, I mean I don't know how much visibility you have now but anything you can share with us. >> Well, thinking about the EFM implementation that the business impact the, was that in case of a failure or the DBA team that a services team is it is able to provide a solution that is within our 100% within our perimeter. So this means that we are fully accountable for it. So in a nutshell, when you run a service, the less people the less teams you have to involve the more control you can deliver. And in some, again, very critical services that is a great value. >> Okay. So, and, and where do you want to take this? I mean, how do you see w what's your, if you're thinking about your Postgres and, and generally an EDB you know, roadmap, where do you want it to go? >> Well, I stay to, to trends within within the organization, the, the, the, the the first one is about migrating more existing services to open source solution for database is going to be, is going to be prosperous. And other trends that I see within my organization is about designing applications, not really to be, to to use PostgreSQL as the base, as it does a base layer. I think both trends are more or less surroundings at the same state right now. >> Yeah. A lot of the audience members at Postgres vision 21 is just like you they they're managing day-to-day infrastructure. They're there they're expert practitioners. What advice would you give to somebody that is thinking about, you know taking this journey, maybe if you had to do something over again maybe what would you do differently? How can you help your peers here? >> Well, I think in particular, if you are going to say a big organization that runs a highly regulated business in some cases, you are a little bit afraid of open source because there is this, I can say general consideration about the lack of enterprise level support. I would like to say that it is just about the past because they're around bunch of companies like EDB that are we're a hundred percent capable of providing enterprise level of support, even on, on, on even on the open source distribution of Paul's presser. Obviously Dan is you're going to go with their specific distribution. The level of support is going to be even more accurate but as we know, it could be currently is they across say main contributor of the pollsters community. And I think is, is that an insurance for every organization? >> Your advice is don't be afraid. >> Yeah. My advice is done is absolutely, don't be, don't be afraid. And if, if, if I can, if we can mention about also about, you know, the cloud called technologies this is also another, another topic where if possible I would like to suggest to not being afraid EDB as every every I would say organization within the it industry is really pushing for it. And I think for a very, for, for a lot of cases not all of them, but a lot of cases, there is a great value about the design services application to be cloud native or migrating existing application into the cloud. >> Okay. But, but being a highly regulated industry and being a, you know, very much aware of the the narrative around open source, et cetera, you, you must've had just a little piece of your mind saying, okay I have to manage this risk. So there's anything specifically you did with managing the risks that you would advise? Was it, was it or is it really just about good change management? >> I think it was mainly about a good change management when you got, you know the relevant stakeholders that you need on board and we are, everybody's going the same direction. That basically is about executing. >> Excellent. Well, Roberto, I really appreciate your time and your knowledge that you share with the audience. So thanks so much for coming on the cube. >> Thank you, Dave. It was a great pleasure. >> And thank you for watching the cubes continuous coverage of Postgres vision 21. We'll be right back. (upbeat music)

>> For years, the database market was steady, and steadily boring. As virtualization went mainstream, organizations began to rethink their database strategies and ask questions like, "should I run Postgres and VMware?" Now implicit in that question was another drill down question. In other words, can VMware itself handle my critical applications and is PostGres the right solution to optimize my infrastructure estate. Now history has shown that was both a safe and good bet for organizations looking to leverage open source innovation and lower their costs. At the same time, new workloads were emerging that were pushing the boundaries of existing relational database technologies, that were designed primarily for transactional workloads. So-called systems of engagement and systems of analytics we're growing at rates much faster than traditional OLTP workloads. Once again, people ask the question, should I think about running these new workloads on Postgres? Now the answer came from the community response that saw the need to extend the open source platform to handle these emerging workloads. The database market suddenly got really interesting as these new applications emerged. Multiple data sources were combined and analyzed to interpret sentiment from social media and get consumers to buy something before they moved to another website, triangulate data to fight fraud, predict weather patterns, and short drug provenance, and dozens of other use cases. Then when cloud went mainstream, similar questions were asked about Postgres. And once again, the open source community responded to accommodate and extend the platform for the cloud. And now Kubernetes is all the rage. When should I run Postgres and Kubernetes, similar theme right? Open source, community, innovation, lowering license costs, minimizing lock-in, maximizing optionality, avoiding too much database sprawl, confidence to support new workloads. These are the factors that customers tell us they use generally to choose a database, and PostGrest specifically. In reality, it's usually pretty obvious what the right strategic fit is for a platform, but buyers want to make sure they have headroom for innovation. They do want to push the envelope on new data types while at the same time managing their risks. And that's where Postgres and the Postgres community in my view has thrived. It's become the ideal solution for what I call the fat middle of workloads, that are increasingly diverse but require a cost effective and stable approach that can scale. These are some of the themes we heard in the morning keynotes from Suzette Kent, former federal CIO who laid down her knowledge on transformation, leadership, and technology modernization. And then EDB CEO Ed Boyajian gave his annual keynote address and talked about the power of data. Data, as we know is growing at a mind-bending exponential rate. It'll make the 2010s look meager by comparison. My big takeaway from his talk really were around using technology to extract value more quickly. I think this is going to become the new new metric in the industry, which basically is every industry is a data-oriented platform now. Yes, software is eating the world, data is eating software. In other words, the new KPI is how long does it take to go from idea to monetization. That is are going to become critical in my opinion, over this next decade. Ed made what I thought was a critical point, and that is you really can't easily define the future. Industries are transforming right before our eyes. And his premise was that you have to pick a data platform that can evolve in unpredictable times. Now, as I pointed out earlier, the Postgres community has stepped up to changing environments for decades. And that really was a point Boyajian hit on pretty hard. Replatforming is happening and he made a convincing argument that Postgres and EDB will be part of that future, with a significant investment in advancing Postgres with hundreds of engineers on the task. He talked about three growth vectors. First, growth in new workloads. He made the claim that around 50% of new EDB customers are deploying new applications. Second, he talked about legacy migrations as another driver, and third was cloud, both traditional compute in the cloud, but also managed services and DBaaS, database as a service. Of course, he also talked about, and there's been a lot of discussion at Vision 2021 about Kubernetes and developers. Big push there. Let me give you my thoughts on that. First, the Kubernetes community is really focused on security and has made a lot of progress in the past 24 months. I think the second point there is developers, they want simplification, and Kubernetes brings that to a greater degree. And it's maturing with more production-ready capabilities. It just some basic, blocking and tackling, like not releasing with an unstable code, (laughs) but it's still early days and the community has some work to do on things like backwards compatibility, for example. And the release cadence of Kubernetes, it's still pretty frequent, which means you got to update scripts and APIs and the like. Remember, Postgres practitioners, they're used to very high levels of stability. So you got to be a little bit careful there. You got to go experiment because you want to take advantage of containers and benefits within Postgres, but you got to make sure you have the right change management in place and you got the resources to be on top of that. The bottom line is Kubernetes is still a toddler, but it's growing up fast. And I have no doubt it will become a staple of the Postgres stack. I'll end where I started, and that's the market. It's gone from stayed and uninteresting years ago to one that one of the most dynamic sectors of IT infrastructure software. And Ed Boyajian talked about the total available market, the TAM, and the valuations that we're seeing today. The market's enormous. I mean, if you just think about traditional database, it's probably 60 to $70 billion, but when you add in all the data and data clouds and decentralized data architectures and eventually edge computing, the market is potentially hundreds of billions of dollars in value for data platforms. So the last thing I'll say about Vision 21 is there's some great content here that spans both the business discussion and also deep practitioner material. And it's useful, has very useful how to's that both educate and inspire. So sit back and enjoy the show. This is Dave Vellante, and you're watching The Cube's continuous coverage of Postgres Vision 21 brought to you by EDB. Thanks for watching.

>> Narrator: From around the globe. It's theCUBE with digital coverage of Postgres vision 2021 brought to you by EDB. >> Welcome back to Postgres Vision 21. My name is Dave Vellante. We're thrilled to welcome Carl Olofsen to theCUBE. Carl is a research vice president at IDC focused on data management. The long-time database analyst is the technologist and market observer. Carl, good to see you again. >> Thanks Dave. Glad to be here. >> All right. Let's let's get into it. Let's talk about, let's go right to the, to the source the open source database space. You know, how, what changes have you seen over the last couple of years in that marketplace? >> Well, this is a dynamic area and it's continuing to evolve. When we first saw the initial open source products like mysQl and PostgreSQL on the early days they were very limited in terms of functionality. They were espoused largely by sort of true believers. You know, people who said everything should be open source. And we saw that mainly they were being used for what I would call rather prosaic database applications. But as time has gone by they both of these products improve. Now there's one key difference, of course, which is a mySQL is company owned open source. So the IP belongs to Oracle corporation. Whereas PostgreSQL is community open source, which means that the IP belongs to the PostgreSQL community. And that can have a big difference in terms of things like licensing and so forth, which really matters now that we're coming into the cloud space because as open-source products moving into the cloud space the revenue model is based on subscriptions. And of course they are always based on subscription to open source cause you don't charge for the license. So what you charge for its support, but in the cloud what you can do is you can set up a database service, excuse me, a database service and then you charge for that service. And if it's open source or it's not open source that actually doesn't matter to the user. If you see what that I mean because they still are paying a subscription fee for a service and they get the service. The main difference between the two types is that if you're a commercial provider of PostgreSQL like enterprise DB, you don't have control over where it goes and you don't have control over the IP and how people use it in different ways. Whereas Oracle owns mySQL so they have a lot more control and they can do things to it on their own. They don't have to consult the community. Now there's also, non-relational open source including MongoDB. And as you may be aware, MongoDB has changed their license. So that it's not possible for third party to offer Mongo DB as a complete managed database service without paying a license fee to MongoDB for that. And that's because they own the IP too. And we're going to see a lot more of this sort of thing. I have conversations with open source all the time and they are getting a little concerned that it has become possible for somebody to simply take their technology, make a lot of money off that. And no money goes back to the community. No money goes back to the IRS. It's a company it's just stays with the supplier. So I think, you know it'll be interesting to see how all this is over time. >> So you're suggesting that the Postgres model then is, is I guess I'll use the word cleaner. And so that feels like it's a it's a benefit or is it a two-edged sword kind of thing? I mean, you were saying before, you know a company controls the IP so they could do things without having to go to the community. So maybe they can do things faster. But at the other hand like you said, you get handcuffed. You think you're going to be able to get a, you know a managed service, but then all of a sudden you're not and the rules change midstream saying it, am I correct? That Postgres, the model is cleaner for the customer? >> Well, you know, I mean, a lot of my friends who are in the open source community don't even consider company owned open source to be true open source because the IP is controlled by a company, not by a community. >> Dave: Right >> So from that perspective certainly Postgres SQL is considered, I don't know if you want to use the word cleaner or more pure or something along those lines, but also because of that the nature of community open source it can be used in many different ways. And so we see Postgres popping up all over the place sometimes partially and sometimes altogether, in other words, a service, a cloud service, we'll take a piece of Postgres and stick it on top of their own technology and offer it. And the reason they do that is they know there are a lot of developers out there who already know how to code for Postgres. So they are immediately first-class users of the service that they're offering. >> So, talk a little bit more about what you're seeing. You just mentioned a lot of different use cases. That's interesting. I didn't realize that was, that was happening. The, what are you seeing in terms of adoption in let's say the last 18, 24 months specific to Postgres? >> Yeah, we're seeing a fair amount of adoption in especially in the middle market. And of course there is rapid adoption in the tech sector. Now, why would that be? Well it's because they have armies of technologists. Who know how to program this stuff. You know, when you, you know, a lot of them will use PostgreSQL without a contract without a support contract, they'll just support themselves. And they can do that because they have the technicians who are capable of doing it. Most regular businesses can't do that. They don't have the staff so they need that support contract. And so that's where a company like enterpriseDB comes. I mentioned them only because they're the leading supplier Postgres to all their other suppliers. >> I was talking to Josh Burgers, red hat and he was, you know, he had just come off a Cubacon and he was explaining kind of what's happening in that community. Big focus of course on security and the whole, you know, so-called shift left. We were having a good discussion about, you know when does it make sense to use, you know Postgres in a container environment should you use Postgres and Kubernetes and he sort of suggested that things have rapidly evolved. There's still, you know, considerations but what are you seeing in terms of the adoption of microservices architectures containers, generally Kubernetes how has that affected the use of things like postsgres? >> So those are all different things or need to be kind of custody. >> Pick your favorite. >> They're related then. So microservices, the microservice concept is that you take an application break it up into little pieces and each one becomes a microservice that's invoked through an API. And then you have this whole structure API system that you use to drive the application and they run. They typically, they run in containers usually Kubernetes govern containers but the reason you do this and this is basically a efficiency because especially in the cloud, you want only to pay for what you use. So when you're running a microservice based application. Applications have lots of little pieces when something needs to be done, microservice fires up it does the thing that needs to be done. It goes away. You only pay for that fraction of a second that the microservice is running. Whereas in a conventional application you load this big heavyweight application. It does stop. It sets some weights with things and does more stuff and sits and waits for things. And you pay for compute for that entire period. So it's much more cost effective to use a microservices application. The thing is that microservice, the concept of microservices is based on the idea that the code is stateless but database code isn't stateless cause it has its attraction to the database which is the ultimate kind of like stateful environment right? So it's a tricky business. Most database technologies that are claimed to be container-based actually run in containers the way they run in servers. In other words, they're not microservice-based they do run in containers. And the reason they're doing that is for portability so that you can deploy them anywhere and you can move them around. But you know deploying a microservice based database is, well, it's it's a big technical project. I mean, that is hard to do. >> Right and so talk about, I mean again we're talking to Josh it was clear that that Kubernetes has evolved, you know quite rapidly at the same time there were cautions. In other words, he would say I think suggested things like, you know, there were known at one point, there were known, you know flaws and known bugs that ship the code that's been been remediated or moderated in terms of that practice but still there's there's considerations just in terms of the frequency of updates. I think he gave the example of when was the last time you know, JVM got, you know, overhauled. And so what kind of considerations should customers think about when considering them, they want the Kubernetes they want the flexibility and the agility but at the same time, if they're going to put it production, they've got to be careful, right? >> Yeah, I think you need to make sure you're using you're using functions that are well-established, you know you wouldn't want to put something into production that's new. They say, oh, here's a new, here's a new operation. Let's try that. And then, you know, you get in trouble. So you want to deal conservative that way you know, Kubernetes is open-source so and the updates and the testing and all that follows a rather slow formal process, you know from the time that the submission comes in to the time that it goes out, whereas you mentioned JVMs JV, but it was owned by Oracle. And so JVMs are managed like products. Now there's a whole sort of legal thing I don't want to get into it as to whether it's legal. They claim it's not libero third parties to build JVMs without paying a licensing. I don't want to talk about that, but it's based on a very state that has a very stable base, you know whereas this area of Kubernetes and govern containers is still rapidly evolving but this is like any technology, right? I mean, when you, if you're going to commit your enterprise to functions that run on an emerging technology then you are accepting some risk. You know, that there's no question about it. >> So we talked about the cloud earlier and the whole trend toward managed services. I mean, how does that specifically apply to Postgres? You can kind of imagine like a sidecar, a little bit of Postgres mixed in with, you know, other services. So what do you see and what do you, what's your telescope say in terms of the the Postgres adoption cloud? How do you see that progressing? >> I think there's a lot of potential. There's a lot of potential there. I think we are nowhere near the option that it should be able to achieve. I say that because for one thing, even though we analyze the future at IDC, that doesn't mean we actually know the future. So I can't say what its adoption will be but I can say that there's a lot of potential there. There's a tremendous number of Postgres developers out there. So there's a huge potential for adoption. And especially in cloud adoption, the main thing that would help that is independent. And I know that enterpriseDB has one independent a managed cloud service. So I think they do. >> Yeah I think so. >> But you know, why do I say that? I say that because alternatives these days there are some small companies that maybe they'll survive and maybe they won't, but that, you know, do you want to get involved with them or the cloud platform providers, but if you use their Postgres you're locked into that cloud platform. You know, if you use Amazon, go press on RDS, right? You're not, you become quickly locked in because you're starting using all the AWS tools that surround it to build and manage your application. And then you can't move. If you see what I mean. >> Dave: Yeah . >> They have have an RDS labor Aurora, and this is actually one of the things that it's really just a thin layer of Postgres interaction code underneath Aurora is their own product. so that's an even deeper level of commitment. >> So what has to happen for, so obviously cloud, you know, big trend. So the Postgres community then adopts the code base for the cloud. Obviously EDB has, you know hundreds of developers contributing to that, but so what does that mean to be able to run in the cloud? Is that making it cloud native? Is that extensions? Is it, you know, what technically has to occur and what has occurred and how mature is it? >> Well, so smaller user organizations are able to migrate fairly quickly cloud because most of their applications are you know, commercially purchased. They're like factories applications. When they move to the cloud, they get the SAS one and often the SAS equivalent runs on Postgres. So that's just fine. Larger enterprises are a real mess. If you've ever been in a large enterprise data center you know what I'm talking about? It's just, there's just servers and storage everywhere. There's, all these applications, databases connections. They are not moving to the cloud anytime soon. But what they are doing is setting up things like private cloud environments and applying in there. And this is a place where if you're thinking about moving to something like a Postgres you know most of these enterprises use the big commercial databases. Oracle SQLserver DB two and so forth. If you're thinking of moving from that to a a PostgreSQL development say, then the smart thing to do would be first to do all your work in the private cloud where you'd have complete control over the environment. It also makes sense still to have a commercial support contract from a vendor that you trust, because I've said this again, unless you are, you know, Cisco or somebody, you know, some super tech company that's got all the technicians you need to do the work. You really don't want to take on that level of risk. If you see that, I mean. Another advantage to working with a supplier, a support supplier, especially if you have a close, intimate relationship is they will speed your security patches on a regular basis which is really important these days, because data security is as you know, a growing concern all over the place. >> So let's stay on the skillsets for a minute. Where do you see the gaps within enterprises? What kind of expertise you mentioned, you know support contracts, what are the types of things that a customer should look for in terms of the the expertise to apply to supporting Postgres databases? >> Well, obviously you want them to do the basics that any software company does, right? You want them to provide you with regular updates and binary form that you can load and, you know test and run. You want to have the you know, 24 hour hotline you know, telephone support, all that kind of thing. I think it's also important to have a solid ability on the part of the vendor that you're working with to provide you with advice and counseling as you, especially, if you're migrating from another technology, help your people convert from what they were using to what they're going to be using. So those are all aspects that I would look for in a vendor for supporting a product like PostgreSQL. >> When you think about the migration to the cloud, you know of course Amazon talks a lot about cloud migration. They have a lot of tooling associated with that. >> Carl: Right. >> But when you step back and look at it it did to a point earlier, I mean a lot of the hardcore mission, critical stuff isn't going to move it, hasn't moved, but a lot of the fat middle, you know, is, are good candidates for it. >> Carl: Right. >> How do you think about that? And how do you look at that? I mean, obviously Oracle is trying to shove everything into OCI and they're, you know, they're all in because they realized that could make a lot of money doing that. But what do you, what are the sort of parameters that we should think about when considering that kind of migration, moving a legacy database into the cloud? >> Well, it has to be done piecemeal. You're not going to be able to do it all at once. You know, if you have hundreds of applications, you're not just you don't even want to, you know, it's a good time to take you into it. And what you've got running, ask yourself are these applications really serving the business interests today and will they in the future or is this a good time to maybe consider something else? Even if you have a packaged application, there might be one that is more aligned with your future goals. So it's important to do that. Look at your data integration, try to simplify it. You know, most data integration that most companies has done piecemeal project by project. They don't reference each other. So you have this chaos of ETL jobs and transformation rules and things like that that are just, you know, even difficult to manage. Now, just forget about any kind of migration or transformation considerations, just trying to run it now is becoming increasingly difficult. You know, maybe you want to change your strategy for doing data integration. Maybe you want to consolidate you want to put more data in one database. I'm not an advocate of the idea that you can put all application data in one database by the way, we know from bitter experience that doesn't work, but we can be rational about the kinds of databases that we use and how they sit together. >> Well, I mean, you've been following this for a long time and you saw the sort of rise and fall of the big data meme. And you know, this idea that you can shove everything into a single place, have a single version of the truth. It's like, it's just never seemed to happen. >> Carl: Right. >> So, you know, Postgres has been around a long time. It's evolved. I mean, I remember when, you know, VMware's ascendancy and people are like, okay, should I, you know should I virtualize my Postgres database is your, you know similar conversations that we were having earlier about Kubernetes. You've seen the move to the cloud. We're going to have this conversation about the edge at some point in time. So what's your outlook for Postgres, the Postgres community and, you know database market overall? >> Well, I really think the future for database growth is in the cloud. That's what all the data we're looking at and the case that's what our recent surveys indicate. As I said before, the rate of change depends on the size of the enterprise. Smaller advices are moving rapidly, large enterprises much more slowly and cautiously for the very simple reason that it's a very complex proposition. And also in some cases, they're wondering if they can move certain data or will they be violating your some sort of regulatory constraint or contractual issue. So they need to deal with those things too. That's why the private cloud is the perfect place to get started and get technology all lined up storing your data center is still under your control no legal issues there, but you can start, you know converting your applications to micro-service architected applications running in containers. You can start replacing your database servers with ones that can run in a container environment and maybe in the future, maybe hope that in the future, some of those will actually also be able to run as microservices. I don't think it's impossible but it just involves programming the database server in a very different way than we've done in the past. But you do those things. You can do those things under your own control over time in your own dataset. And then you reach a point where you want to take the elements of your application environment and say, what pieces of this, can I move to the cloud without creating disruption and issues regarding things like data egress and latency from cloud to data center and that kind of thing. And prepare for that. And then you're doing the step wise and then you start converting in a stepwise manner. I think ultimately it just makes so much sense to be in the cloud that the cloud vendors have economies of scale. They can deploy large numbers of servers and storage systems to satisfy the needs of large numbers of customers and create, you know great considerable savings. Some of which of course becomes their profit which is what's due to them. And some of that comes back to the users. So that's what I expect. We're going to see. And oh gosh, I would say that starting from about three years from now the larger enterprises start making their move and then you'll really start to see changes in the numbers in terms of cloud and cloud revenue. >> Great stuff, Carl, thank you for that. So any cool research you're working on lately, how you're spending your your work time, anything you want to plug? >> Well, working a lot on just as these questions, you know cloud migration is a hot topic, another which is really sort of off the subject. And what we've been talking about is graph database which I've been doing a fair amount of research into. I think that's going to be really important in the coming years and really, you know working with my colleagues in a project called the future of intelligence which looks at all the different related elements not just database, data integration but artificial intelligence, data communications and so on and so forth and how they come together to create a more intelligent enterprise. And that's a major initiative that I see. It's one of the, we call the future of initiatives. >> Great, Carls, thanks so much for coming back to theCUBE. It's great to have you, man. I appreciate it. >> Well, I enjoyed it. Now I have to do it again sometime. >> All right you got it. All right thank you everybody for watching theCUBEs. Continuous coverage of Postgres vision 21. This is Dave Vellante keep it right there. (upbeat music)

(upbeat music) >> From around the globe, it's theCUBE with digital coverage of Postgres Vision 2021 brought to you by EDB. >> Well, hi everybody John Walls here on theCUBE and we're now welcoming Jeremy Wilmot who is the chief product officer at ACI Worldwide part of the Postgres movement, you might say or certainly benefiting from the great value that Postgres is providing a number of enterprises across the globe. Jeremy good to see you today and first off, congratulations you are the first guest I've talked to maybe in a year and a half in their office. So good for you. >> Thanks (chuckles) John that's very kind of you John and great to see you and thanks for having me here. Yeah, it's great to be in the office, it really is. I'm here in Miami in South Florida and getting some sort of normalcy back is great for all of us and I'm certainly enjoying it. So thank you before (indistinct) has been. >> I'm sure you are, yeah, congratulations on that front. First off, let's talk about ACI Worldwide for the folks in our audience who aren't familiar with the payments, your role in terms of that payment ecosystem. Tell us a little bit about ACI Worldwide. >> Sure, well, primarily we're a software company. That's ACI, we started 1975 in Omaha, Nebraska built the first debit card system and ATM system for first National Bank of Omaha and over the last 45 years, we've globalized ourselves, we have, we are delivering mission-critical real-time payment systems across the world to banks to merchants to billers, we help them meet the payment needs of their consumers and their corporates. So we process, manage digital payments, we power omni-commerce and e-commerce payments, we present and process bill payments, we manage fraud, we manage the risk all within that and as I said on a global basis 13 of the G20 countries with a leading DDA account or current account payment processing software in those countries and have been for many years. >> So, as the CPO then quite obviously in the financial space your plate is quite full these days in terms of providing for your client base. How would you characterize maybe the evolution in terms of product development that you've been through in the financial world here over the past say, three to five years, where were you back then to where you are now and what role has Postgres played in that journey? >> Sure, yeah. So, specific to the Postgres part of the ecosystem, previously five-plus years ago our previous database solution was complex, it was expensive, it was hard to change and maintain and we leveraged multiple pieces of software from multiple vendors as a result of that. So at that time we looked for an alternative that was simpler and better and we went through a very comprehensive due diligence process, we explored both open source and license models of database to support our solution and when we looked at all of the options we determined that 2ndQuadrant Postgres was the one that provided the most comprehensive solution we were looking for. It had the right mix of capabilities and performance at the right total cost of ownership that we were looking for. And in the payments world as you can imagine, you've got to to be 24/7 365. And we also required a lower cost of ownership than we had before. But we also wanted a greater flexibility and time to market that we could pass on to our customers. And then the last thing I'd say that we were looking for was a multi-deployment capability. And what I mean by that is that we would be able to use this new platform, Postgres platform in our own data centers in our own private cloud, but we could also deploy it in the public cloud, whether we would run it or whether our customers would run it. We wanted that ability to mix and match between these different deployment options. >> So you've talked about a lot of key elements here attributes in terms of availability, accessibility reliability, security obviously. Walk us through those in terms of why you think 2ndQuadrant was addressing your needs in those particular areas or any others for that matter but what it was that checked the box specifically about what Postgres was offering you as opposed to what these other possible solutions and services were that you were looking at. >> Yeah, I think, we're very focused on being able to identify what our customers need and when they're offering services to consumers and to their corporates what is it that they require that's going to enable them to win and compete. And payments industry has a lot of cost pressures within it. It has regulation, it has consumer convenience and the whole movement of digitalization that puts a lot of downward pressure on the cost space. And those who are going to win in the payment space need to be able to address that. So, that is relevant for our banks, for our merchants, for the billers. They all come under very similar regulatory pressure and market pressure and as a result, the ability to reduce dramatically in a very significant way, the total cost of ownership upon which the payment software was going to be operating that was one of the key elements that was very important to us as we made that decision. The second one I think was to enable us to be able to do what we are good at and what our customers expect us to do. And that in turn enables them to focus on their core competencies. We're a software company, we own our own IP we manage our own software for the needs of the 24/7 365 payment requirements and therefore the merchant or the biller or the bank can really focus in on the digital experience for their customers, focusing on their core competencies and what they need to do to win. That was a second key factor for us. I think the third one for us was as well speed to market. Speed to market for ourselves and being competitive to the alternative to ACI, but also more importantly a speed to market for our customers. And there are, the payment world is highly regulated requires significant certification in order to launch new services that's often the long pole in the tent. So we want to be able to get to that point as quickly as possible. And being able to have a public cloud deployment open systems capabilities that would really allow us to pass on that speed to market to those customers. So for example, an acquirer, a payment acquirer moving into a new geographical country they want to compete in they can (indistinct) on their competitors by launching minimum viable products in six to nine months that is five years ago, that could have been a 24 to 30 months endeavor for them to take on. So I, those were important considerations for us as we were choosing a longterm partner for the Postgres world and the public cloud world. >> Obviously, so you've talked a lot about your relationship with your clients and I know you have a really keen awareness of the need to ensure that trust, to ensure that reliability to ensure the collaboration. How about your relationship on the other side with EDB and in terms of all those elements so how has that evolved over a period of time and what kind of service and what kind of value do you think are you deriving from that relationship now? >> So with EDB, first of all, our journey started with 2ndQuadrant and now EDB. And we were specifically looking at the, one area was at the Bi-Directional Replication BDR that we were wanting to support with our solutions particularly in the public cloud. And that was going to enable us to replace multiple pieces of software from multiple vendors. And so we were to create that solution that was right for ACI, it was right for our customers from a functionality and agility and a cost perspective. So technologically with the non-functional requirements and the reliability, availability, serviceability aspects that we were looking for that was in partnership with 2ndQuadrant and EDB, that was a key element. I think the second piece of it is we worked really well with 2ndQuadrant EDB in terms of partnering to meet the needs of the market. It's great to have the right technology in place but then you need your partners really to be able to work with you tactically real-time in order to win in the market and make it work. And I found that they'd been a great partner for us to be able to do that and to be able to react quickly, do the right thing and really enable us to be a great partner to our customers as we deliver real-time payments, as we deliver the acquiring capabilities, as we deliver a modernization for the big banks that we work with as well. >> Now, before I let you go, I'm going to give you a two-part question here. That's always one way to squeeze a little more info (laughing) to the guest. First off advice. You've been through this transformation obviously you're very happy with all that has transpired, so your advice to others who are considering this journey. And then secondly, what can they and you do you think expect in terms of future challenges, opportunities how we might want to frame that with Postgres? Like, where are we going from here, basically? So, two parts, advice and then where do you think this is headed? >> So advice, I certainly learnings from us versus advice is number one, be very thorough in the due diligence that you do and be very clear on what you want and what are your goals that you're looking for. So from an AGI perspective, we were clear that total cost of ownership in terms of the stack that we were going to be providing to our customers. That was very important, number one number two, nonfunctional requirements. So I've talked about the mission criticality of payments 24/7 365. That was a key second piece. And then the third one, ease of deployment. I talked about that, multi-cloud deployment that we were looking for. So we were clear what we wanted and we we took our time from a due diligence point of view. It's a multi-year decision being made so it's not something specifically I think we want to rush into. In terms of looking forward and where do we go from here? Performance is critical so further up performance enhancements, ability for rapid failover availability, near 100% availability that we're looking for five-nines and above, working together with Postgres in order to make those failovers more seamless because they will happen, particularly in the real-time payments world, where we're now seeing billions of transactions happening in a week and soon that will be in a day, they will need to be able to deal with. And for all of this to happen in a public cloud environment, we, I think all understand a lot of the benefits of public cloud and we need to be able to provide this failover availability capability in the public cloud but also in a hybrid cloud environments we're in a multi-cloud environment, so we need to keep working that and make that happen that will make Postgres a payment-grade infrastructure that could power the world's real-time payments and we would love to be able to do that into the future. >> Well, Jeremy thanks for the insights, we appreciate that and once again, congratulations on getting back in that office. I know it's probably a pretty welcomed addition to your regimen now. >> Yeah, John, thank you very much and thanks to everyone who's dialed in for this and John I look forward to welcoming you in the office soon. >> Very good sir, I look forward to that as well. I'll take you up on that in Miami for sure. John Walls here on theCUBE talking with Jeremy Wilmot is the chief product officer at ACI Worldwide. part of our Postgres Vision 2021 coverage. (upbeat music)

(upbeat music) >> From around the globe, it's theCUBE with digital coverage of Postgres Vision 2021 brought to you by EDB. >> Well, hi everybody John Walls here on theCUBE and we're now welcoming Jeremy Wilmot who is the chief product officer at ACI Worldwide part of the Postgres movement, you might say or certainly benefiting from the great value that Postgres is providing a number of enterprises across the globe. Jeremy good to see you today and first off, congratulations you are the first guest I've talked to maybe in a year and a half in their office. So good for you. >> Thanks (chuckles) John that's very kind of you John and great to see you and thanks for having me here. Yeah, it's great to be in the office, it really is. I'm here in Miami in South Florida and getting some sort of normalcy back is great for all of us and I'm certainly enjoying it. So thank you before (indistinct) has been. >> I'm sure you are, yeah, congratulations on that front. First off, let's talk about ACI Worldwide for the folks in our audience who aren't familiar with the payments, your role in terms of that payment ecosystem. Tell us a little bit about ACI Worldwide. >> Sure, well, primarily we're a software company. That's ACI, we started 1975 in Omaha, Nebraska built the first debit card system and ATM system for first National Bank of Omaha and over the last 45 years, we've globalized ourselves, we have, we are delivering mission-critical real-time payment systems across the world to banks to merchants to billers, we help them meet the payment needs of their consumers and their corporates. So we process, manage digital payments, we power omni-commerce and e-commerce payments, we present and process bill payments, we manage fraud, we manage the risk all within that and as I said on a global basis 13 of the G20 countries with a leading DDA account or current account payment processing software in those countries and have been for many years. >> So, as the CPO then quite obviously in the financial space your plate is quite full these days in terms of providing for your client base. How would you characterize maybe the evolution in terms of product development that you've been through in the financial world here over the past say, three to five years, where were you back then to where you are now and what role has Postgres played in that journey? >> Sure, yeah. So, specific to the Postgres part of the ecosystem, previously five-plus years ago our previous database solution was complex, it was expensive, it was hard to change and maintain and we leveraged multiple pieces of software from multiple vendors as a result of that. So at that time we looked for an alternative that was simpler and better and we went through a very comprehensive due diligence process, we explored both open source and license models of database to support our solution and when we looked at all of the options we determined that 2ndQuadrant Postgres was the one that provided the most comprehensive solution we were looking for. It had the right mix of capabilities and performance at the right total cost of ownership that we were looking for. And in the payments world as you can imagine, you've got to to be 24/7 365. And we also required a lower cost of ownership than we had before. But we also wanted a greater flexibility and time to market that we could pass on to our customers. And then the last thing I'd say that we were looking for was a multi-deployment capability. And what I mean by that is that we would be able to use this new platform, Postgres platform in our own data centers in our own private cloud, but we could also deploy it in the public cloud, whether we would run it or whether our customers would run it. We wanted that ability to mix and match between these different deployment options. >> So you've talked about a lot of key elements here attributes in terms of availability, accessibility reliability, security obviously. Walk us through those in terms of why you think 2ndQuadrant was addressing your needs in those particular areas or any others for that matter but what it was that checked the box specifically about what Postgres was offering you as opposed to what these other possible solutions and services were that you were looking at. >> Yeah, I think, we're very focused on being able to identify what our customers need and when they're offering services to consumers and to their corporates what is it that they require that's going to enable them to win and compete. And payments industry has a lot of cost pressures within it. It has regulation, it has consumer convenience and the whole movement of digitalization that puts a lot of downward pressure on the cost space. And those who are going to win in the payment space need to be able to address that. So, that is relevant for our banks, for our merchants, for the billers. They all come under very similar regulatory pressure and market pressure and as a result, the ability to reduce dramatically in a very significant way, the total cost of ownership upon which the payment software was going to be operating that was one of the key elements that was very important to us as we made that decision. The second one I think was to enable us to be able to do what we are good at and what our customers expect us to do. And that in turn enables them to focus on their core competencies. We're a software company, we own our own IP we manage our own software for the needs of the 24/7 365 payment requirements and therefore the merchant or the biller or the bank can really focus in on the digital experience for their customers, focusing on their core competencies and what they need to do to win. That was a second key factor for us. I think the third one for us was as well speed to market. Speed to market for ourselves and being competitive to the alternative to ACI, but also more importantly a speed to market for our customers. And there are, the payment world is highly regulated requires significant certification in order to launch new services that's often the long pole in the tent. So we want to be able to get to that point as quickly as possible. And being able to have a public cloud deployment open systems capabilities that would really allow us to pass on that speed to market to those customers. So for example, an acquirer, a payment acquirer moving into a new geographical country they want to compete in they can (indistinct) on their competitors by launching minimum viable products in six to nine months that is five years ago, that could have been a 24 to 30 months endeavor for them to take on. So I, those were important considerations for us as we were choosing a longterm partner for the Postgres world and the public cloud world. >> Obviously, so you've talked a lot about your relationship with your clients and I know you have a really keen awareness of the need to ensure that trust, to ensure that reliability to ensure the collaboration. How about your relationship on the other side with EDB and in terms of all those elements so how has that evolved over a period of time and what kind of service and what kind of value do you think are you deriving from that relationship now? >> So with EDB, first of all, our journey started with 2ndQuadrant and now EDB. And we were specifically looking at the, one area was at the Bi-Directional Replication BDR that we were wanting to support with our solutions particularly in the public cloud. And that was going to enable us to replace multiple pieces of software from multiple vendors. And so we were to create that solution that was right for ACI, it was right for our customers from a functionality and agility and a cost perspective. So technologically with the non-functional requirements and the reliability, availability, serviceability aspects that we were looking for that was in partnership with 2ndQuadrant and EDB, that was a key element. I think the second piece of it is we worked really well with 2ndQuadrant EDB in terms of partnering to meet the needs of the market. It's great to have the right technology in place but then you need your partners really to be able to work with you tactically real-time in order to win in the market and make it work. And I found that they'd been a great partner for us to be able to do that and to be able to react quickly, do the right thing and really enable us to be a great partner to our customers as we deliver real-time payments, as we deliver the acquiring capabilities, as we deliver a modernization for the big banks that we work with as well. >> Now, before I let you go, I'm going to give you a two-part question here. That's always one way to squeeze a little more info (laughing) to the guest. First off advice. You've been through this transformation obviously you're very happy with all that has transpired, so your advice to others who are considering this journey. And then secondly, what can they and you do you think expect in terms of future challenges, opportunities how we might want to frame that with Postgres? Like, where are we going from here, basically? So, two parts, advice and then where do you think this is headed? >> So advice, I certainly learnings from us versus advice is number one, be very thorough in the due diligence that you do and be very clear on what you want and what are your goals that you're looking for. So from an AGI perspective, we were clear that total cost of ownership in terms of the stack that we were going to be providing to our customers. That was very important, number one number two, nonfunctional requirements. So I've talked about the mission criticality of payments 24/7 365. That was a key second piece. And then the third one, ease of deployment. I talked about that, multi-cloud deployment that we were looking for. So we were clear what we wanted and we we took our time from a due diligence point of view. It's a multi-year decision being made so it's not something specifically I think we want to rush into. In terms of looking forward and where do we go from here? Performance is critical so further up performance enhancements, ability for rapid failover availability, near 100% availability that we're looking for five-nines and above, working together with Postgres in order to make those failovers more seamless because they will happen, particularly in the real-time payments world, where we're now seeing billions of transactions happening in a week and soon that will be in a day, they will need to be able to deal with. And for all of this to happen in a public cloud environment, we, I think all understand a lot of the benefits of public cloud and we need to be able to provide this failover availability capability in the public cloud but also in a hybrid cloud environments we're in a multi-cloud environment, so we need to keep working that and make that happen that will make Postgres a payment-grade infrastructure that could power the world's real-time payments and we would love to be able to do that into the future. >> Well, Jeremy thanks for the insights, we appreciate that and once again, congratulations on getting back in that office. I know it's probably a pretty welcomed addition to your regimen now. >> Yeah, John, thank you very much and thanks to everyone who's dialed in for this and John I look forward to welcoming you in the office soon. >> Very good sir, I look forward to that as well. I'll take you up on that in Miami for sure. John Walls here on theCUBE talking with Jeremy Wilmot is the chief product officer at ACI Worldwide. part of our Postgres Vision 2021 coverage. (upbeat music)

(upbeat music) >> Narrator: From around the globe, it's theCUBE, with digital coverage of Postgres Vision 2021, brought to you by EDB. >> Well, good day, everybody. John Walls here on theCUBE, and continuing our CUBE conversation as part of Postgres Vision 2021, sponsored by EDB, with EDB Chief Technology Officer, Mr. Mark Linster. Mark, good morning to you. How are you doing today? >> I'm doing very fine, very good, sir. >> Excellent. Excellent. Glad you could join us. And we appreciate the time, chance, to look at what's going on in this world of data, which, as you know, continues to evolve quite rapidly. So let's just take that 30,000-foot perspective here to begin with here, and let's talk about data, and management, and what Postgres is doing in terms of accelerating all these innovative techniques, and solutions, and services that we're seeing these days. >> Yeah, so I think it's really... It's a fantastic confluence of factors that we've seen in Postgres, or are seeing in Postgres today, where Postgres has really, really matured over the last couple of years, where things like high availability, parallel processing, use of very high core counts, et cetera, have come together with the drive towards digital transformation, the enormous amounts of data that businesses are dealing with today, so, and then the third factor's really the embracing of open source, right? I mean, Linux has shown the way, and has shown that this is really, really possible. And now we're seeing Postgres as, I think, the next big open source innovation, after Linux, achieving the same type of transformation. So it's really, it's a maturing, it's an acceptance, and the big drive towards dealing with a lot more data as part of digital transformation. >> You know, part of that acceptance that you talk about is about kind of accepting the fact that you have a legacy system that maybe, if you're not going to completely overhaul, you still have to integrate, right? You've got to compliment and start this kind of migration. So in your perspective, or from your perspective, what kind of progress is Postgres allowing in the mindset of CTOs among your client base, or whatever, that their legacy systems can function in this new environment, that all is not lost, and while there is some, perhaps, catching up to do, or some patching you have to do here and there, that it's not as arduous, or not as complex, as might appear to be on the face. >> Well, I think there's, the maturing of Postgres that has really really opened this up, right? Where we're seeing that Postgres can handle these workloads, right? And at the same time, there's a growing number of success cases where companies across all industries, financial services, insurance, manufacturing, retail are using Postgres. So, so you're no longer, you're no longer the first leader who's taken a higher risk, right? Like, five or 10 years ago, Postgres knowledge was not readily available. So if you want Postgres, it was really hard to find somebody who could support you, right? Or find an employee that you could hire who would be the Postgres expert. That's no longer the case. There's plenty of books about Postgres. There's lots of conferences about Postgres. It's a big meetup topic. So, getting know how and getting acceptance amongst your team to use Postgres has become a lot easier, right? At the same time, over 90% of all enterprises today use open source in one way or the other. Which basically means they have open source policies. They have ways to bring open source into the development stream. So that makes it possible, right? Whereas before it was really hard, you had to have an individual who would be evangelized to go, get open source, et cetera, now open source is something that almost everybody is using. You know, from government to financing services, open sources use all over the place, right? So, so now you have something that really matured, right? There's a lot of references out there and then you have the policies that make it possible, right? You have the success stories and now all the pieces have come together to deal with this onslaught of data, right? And then maybe the last thing that that really plays a big role is the cloud. Postgres runs everywhere, right? I mean, it runs from an Arduino to Amazon. Everywhere. And so, which basically means if you want to drive agile business transformation, you call Postgres because you don't have to decide today where it's going to run. You're not locking into a vendor. You're not locking into a limited support system. You can run this thing anywhere. It'll run on your laptop. It'll run on every cloud in the world. You can have it managed, you can have it hosted. You can add have every flavor you want and there's lots of good Postgres support companies out there. So all of these factors together is really what makes us so interesting, right? >> Kubernetes and this marriage, this complimentary, you know relationship right now with Kubernetes, what has that done? You think in terms of providing additional services or at least providing perhaps a new approach or new philosophies, new concepts in terms of database management? >> Well, it's maybe the most the most surprising thing or surprising from the outside. Probably not from the inside, but you think that that Postgres this now 25 year old, database twenty-five year old open source project would be kind of like completely, you know, incompatible with Kubernetes, with containers. But what really happens is Postgres in containers today is the number one database, after Engine X. It is the number two software that is being deployed in containers. So it's really become the workhorse of the whole microservices transformation, right? A 25 year old software, well, it has a very small footprint. It has a lot of interesting features like GIS, document processing, now graph capabilities, common table expressions all those things that are really like cool for developers. And that's probably what leads it to be the number one database in containers. So it's absolutely compatible with Kubernetes. And the whole transformation towards microservices is is like, you know, there's nothing better out there. It runs everywhere and has the most innovative technologies in it. And that's what we're seeing. Also, you go to the annual stack overflow survey of developers, right? It's been consistently number one or number two most loved and most used database, right? So, so what's amazing is that it's this relatively old technology that is, you know, beating everybody else in this digital transformation and then the adoption by developers. >> Just like old dog new tricks, right? It's still winning, right? >> Yeah, yeah, and, and, you know, the elephant is the symbol and this elephant does dance. >> Still dancing that's right. You know, and this is kind of a loaded question but there are a lot of databases out there, a lot of options, obviously from your perspective, you know, Postgres is winning, right? And, and, and from the size of the marketplace it is certainly leading RA leader. In your opinion, you know, what, what is this confluence of factors that have influenced this, this market position if you will, of Postgres or market acceptance of Postgres? >> It's, I mean, it's the, it's a maturing of the core. As I said before, that the transaction rates et cetera, Postgres can handle, are growing every year and are growing dramatic, right? So that's one thing. And then you have it, that Postgres is really, I think, the most reliable and relational database out there as what is my opinion, I'm biased, I guess. And, and it's, it's super quality code but then you add to that the innovation drive. I mean, it was the first one out there with good JSONB support, right? And now it's brought in JSON Path as as part of the new SQL standard. So now you can address JSON data inside your database and the same way you do it inside your browser. And that's pretty cool for developers. Then you combine that with PostGIS, right, which is, I think the most advanced GIS system out there in database. Now, now you got relations, asset compliant, GIS and document. You may say what's so cool about that. Well, what's cool about it is I can do absolutely reliable asset compliant transactions. I can have a fantastic personalization engine through JSONB, and then all my applications need to know where is the transaction? Where is the next store? How far away I'm a form of the parking spot? Right? So now I got a really really nice recipe to put the applications of the future together. You add onto that movements toward supporting graph and supporting other capabilities inside the database. So now you got, you got capability, you've got reliability and you got fantastic innovation. I mean, there's nothing better out there. >> Let's hit the security angle here, 'cause you talked about the asset test, and certainly, you know, those, that criteria is being met. No question about that, whether it's isolation, durability, consistency, whatever, but, but security, I don't have to tell you what a growing concern this is. It's already paramount, but we're seeing every day write stories about, about intrusions and and invasions, if you will. So in terms of providing that layer of security that everybody's looking for right now, you know, this this ultra impenetrable force, if you will, what in your mind, what's Postgres allowing for, in that respect in terms of security, peace of mind, and maybe a little additional comfort that everybody in your space is looking for these? >> So, so look at, look at security with a database like, like multiple layers, right? There's not just, you don't do security only one place. It's like when you go into a bank branch, right? I mean, they do lock the door, they have a camera, there is a gate in front of the safe, there's a safe door. And inside the safe, there is still, again safety deposit boxes with individual locks. The same applies to Postgres, right? Where let's say we start at the heart of it where we can secure and protect tables and data. We're using access control lists and groups and usernames, et cetera. Right? So that's, that's at the heart of it. But then outside of that, we can encrypt the data when on disk or when it's in transit on disk. Most people use the Linux disc encryption systems but there's also good partners out there, like like more metric or others that we work with, that that provide security on disk. And then you go out from there and then you have the securing of the database itself again through the log-ins and the groups. You go out from there and now you have the securing of the hosts that the database is sitting on. Then you'll look at securing the data on the networks through SSL and certificates, et cetera. So that basically there's a multi-layer security model layer that positions Postgres extremely well. And then maybe the last thing is to say it certainly integrates very well with ELDAP, active directory, Kerberos, all the usual suspects that you would use to secure technology inside the enterprise or in an open network, like where people work from home, et cetera. >> You talked about the history about this 25 year old technology, you know, founded back at Cal Berkeley, you know, probably almost some 30 years ago and certainly has evolved. And, and as you have pointed out now as a very mature technology, what do you see though in terms of growth from here? Like, where does it go from here in the next 18 months, 24 months, what what do you think is that next barrier, that challenge that that you think the technology and this open source community wants to take on? >> Well, I think there's there's the continuous effort of making it faster, right? That always happens, right? Every database wants to be faster do more transactions per second, et cetera. And there's a lot of work that has been done there. I mean, just in the last couple of years, Postgres performance has increased by over 50%. Right? So, so transactions per second and that kind of scalability that is going to continue to be, to be a focus, right? And then the other one is leading the implementation of the SQL standards, right? So there'd be the most advanced database, the most innovative database, because, remember for many years now, Postgres has come up with a new release on an annual basis. Other database vendors are now catching up to that, but Postgres has done that for years. So innovation has always been at the heart of it. So we started with JSONB, Key value pair came even before that, PostGis has been around for a long time, graph extensions are going to be the next thing, ingestion of time series data is going to, is going to happen. So there's going to be an ongoing stream of innovations happening. But one thing that I can say is because Postgres is a pure open source project. There's not a hard roadmap, like where it's going to go but where it's going to go is always driven by what people want to have, right? There is no product management department. There's no, there's no great visionary that says, "Oh, this is where we're going to go." No, no. What's going to happen is what people want to have, right? If companies or contributors want to have a certain feature because they need it, well, that's how it's going to happen. And that's really been at the heart of this since Mike Stonebraker, who's an advisor to EDB today, invented it. And then, you know, the open source project got created. This has always been the movement to only focus on things that people actually want to have because if nobody wants to have it, we're just not going to build it because nobody wants it. Right? So when you asked me for the roadmap I believe it's going to be, you know, faster, obviously, always faster, right? Everybody wants faster. And then there's going to be innovation features like making the document stored even better, graph ingestion of large time series, et cetera. That's really what I believe is going to drive it forward. >> Wow. Yeah, the market has spoken and as you point out the market will continue to speak and, and drive that bus. So Mark, thank you for the time today. We certainly appreciate that. And wish EDB continued success at Postgres vision 2021. And thanks for the time. >> Thanks John, it was a pleasure. >> You bet. Mark Linster, joining us, the CTO at EDB. I'm John Walls, you've been watching theCUBE. (upbeat music)

(upbeat music) >> From around the globe, it's theCUBE. With digital coverage of Postgres Vision 2021 brought to you by EDB. >> Well, good day, everybody. John Walls here on theCUBE. We continue our coverage here at Postgres Vision in 2021. Talking today with Andy Harris, who is the Chief Technology Officer at Osirium, a leader in the Privileged Access Management Space, and Andy, good day to you. Thanks for joining us here on theCUBE. >> Good morning to you and good afternoon, yes. >> That's right. Joining us from overseas over in England, we're on this side of the big pond, but nonetheless, we're joined by the power of Zoom. So again, thanks for the time. Andy, for those who aren't familiar who are watching about Osirium, share a little bit about your various service levels of what you provide, the kind of solutions you provide, and how you've achieved a great success in this space. >> Okay. I know these things, mine will be boring. So I'll just put a little slide up now, which is the minimum I think I can get away with which is that we're all about managing privilege. So that's privileged at the endpoint, Privileged Access Management, and Privileged Process Automation. So wherever a CIS admin has to do something on a machine that needs privilege, we like to be involved. Obviously, we like to be able to delegate all the way down to the business functions with Privileged Process Automation and with the EDB or the BDR part of that functionality in EDB that really fits in to our Privileged Access Management. So what I'll do just to take you away from our product. So I'll just quickly show you a slide of the architecture, which is as simple as we have these nodes. If you like the running ADB BDR and they can perform log-ins to a target device using privileged credentials, which we control when we might be really long up to about 128 characters. >> So Andy, if you would, I think you had put together a little show and tell you a demonstration for how when these systems are perhaps under siege if you will. That there are ways in which obviously you've developed to counter this and to be able to continue secure communications, which in the privilege assets world as you know is paramount. >> Yes, indeed. So I'll show you another slide, which gives you a kind of a overview of everything that's going on and you're going to see a little demonstration of two nodes here that has the BDL technology on and they can make these logins, and we have these characters, Bob and Allison. I've just noticed how it marks in department turn Alice to Allison. they should really be Alice because you get Bob, Alice, Carol, Dave, which are the standard encryption users. And what we're going to do is we're going to demonstrate that you can have breaks in the network. So I'm just sharing the network breaks slide. I'm showing the second network break slide. And then we have this function that we've built which we're going to demonstrate for you today, which is called evil beatings. And what it does is whilst there is a politician in the network, we are going to refresh many thousands of times the credentials on the target device. And then we're going to heal the break in the network and then prove that everything is still working. So right now, I'm going to zoom over to my live connection, terminal connections to the machine. And I'm going to run this command here, which is Python EV3. And I'm going to put a hundred cycles in it which is going to do around about 10,000 password refreshes. Okay. And I'm then going to go over to Chrome, and I should have a system here waiting for me. And in this system, you'll see that I've got the device demo and I've got this come online, SSH. And if I click on this I've got a live connection to this machine. Even whilst I have a huge number of queued up and I'll just show you the queued out connections through the admin interface. The system is working extremely hard at the moment. And in fact, if I show you this slide here, you can see that I have all of these queued credential resets and that is giving our system an awful lot of grief. Yeah. I can go back to the device connection and it is all here still top. Why not? And as you can see, it is all working perfectly. And if I was a user of EDB, I think this has to be one of the demonstrations I'd be interested in because it's one of the first things that we did when we dropped that functionality into our products. We wanted to know how well it would work under extreme conditions because you don't think of extreme conditions as normal working, but whenever you have 10 nodes in different countries, there will always be a network break somewhere and someone will always need to be refreshing passwords a ridiculous rates of knots. So Andy let's talk about this kind of the notion that you're providing here, this about accountability and visibility, audit-ability, all these insights that you're providing through this kind of demonstration you've given us how critical is that today, especially when we know there are so many possible intrusions and so many opportunities with legacy systems and new apps and all of this. I mean talking about those three pillars, if you will, the importance of that and what we just saw in terms of providing that peace of mind that everybody wants in their system. >> That's a cracking question. I'm going to enjoy that question. Legacy systems, that's a really good question. If you, we have NHS, which is our national health service and we have hospitals and you have hospitals every country has hospitals. And the equipment that they use like the MRI scanners, the electro-microscope, some of the blood analysis machines, the systems in those costs multiple Gillions of dollars or should use dollars euros, dollars, pounds and the operating systems running those systems, the lifetime of that piece of equipment is much much longer than the lifetime of an operating system. So we glibly throw around this idea of legacy systems and to a hospital that's a system that's a mere five years old and has got to be delivering for another 15 years. But in reality, all of this stuff gets, acquires vulnerabilities because our adversaries the people that want to do organizations bad things ransomware and all the rest of it they are spending all that time learning about the vulnerabilities of old systems. So the beauty of what we do is being able to take those old legacy systems and put a zero trust safety shell around them, and then use extremely long credentials which can't be cracked. And then we make sure that those credentials don't go anywhere near any workstations. But what they do do, is they're inside that ADB database encrypted with a master encryption key, and they make that jump just inside the zero trust boundary so that Bob and Alice outside can get administration connections inside for them to work. So what we're doing is providing safety for those legacy systems. We are also providing an environment for old apps to run in as well. So we have something called a map server which I didn't think you'd asked us that question. I'd have to find you some slides or presentations, which we want to do. We have a map server, which is effectively a very protected window server, and you can put your old applications on them and you can let them age gracefully and carry on running. Dot net 3.5 and all of those old things. And we can map your connection into the older application and then map those connections out. But in terms of the other aspects of it is the hospital stay open 24 hours a day banks run 24 hours a day and they need to be managed from anywhere. We're in a global pandemic, people are working from home. That means that people are working from laptops and all sorts of things that haven't been provisioned by centrality and could all have all sorts of threats and problems to them. And being able to access any time is really important. And because we are changing the credentials on these machines on a regular basis, you cannot lose one. It's absolutely critical. You cannot go around losing Windows active directory domain credentials it just can't be done. And if you have a situation where you've just updated a password and you've had a failure one of those 10 nodes has the correct set of credentials. And when the system heals, you have to work out which one of the 10 it is and the one that did it last must be the one that updates all the other 10 nodes. And I think the important thing is as Osirium we have the responsibility for doing the updates and we have the responsibility for tracking all those things. But we hand the responsibility of making sure that all the other 10 nodes are up to date which just drop it into bi-directional replication and it just happens. And you've seen it happen. I mean, might be just for the fun of it, We'll go back to that demonstration Chrome, and you can see we're still connected to that machine. That's all still running fine but we could go off to our management thing, refresh it and you see that everything there is successful. I can go to a second machine and I can make a second connection to that device. Yet, in the meantime that password has been changed, Oh, I mean, I wouldn't like to tell you how many times it's been changed. I need to be on a slightly different device. I was going to do a reveal password for you, I'll make another connection but the passwords will be typically, do a top on that just to create some more load. But the passwords will typically be... I'll come back to me. They'll typically be 128 characters long. >> Andy, if I could, I mean, 'cause I think you're really showing this very complex set of challenges that you have these days, right? In terms of providing access to multiple devices across, in multiple networking challenges, when you talk to your prospective clients about the kind of how this security perimeters changed, it's very different now than it was four or five years ago. What are the key points that you want them to take away from your discussion about how they have to think about security and access especially in this day and age when we've even seen here in the States. Some very serious intrusions that I think certainly get everybody's attention. >> That's a great question again. They're all... The way that I would answer that question would definitely depend on the continent that I was talking to. But my favorite answer will be a European answer, so I'll give you a European answer. One of the things that you're doing when you come along and provide Privileged Access Management to a traditional IT team, is your taking away the sysadmins right now, before privilege access, they will know the passwords. They will be keeping the passwords in a password vault or something like this. So they own the passwords, they own the credentials. And when you come along with a product like privilege access management you're taking over management of those credentials and you're protecting those systems from a whole wide range of threats. And one of those threats is from the system administrators themselves. And they understand that. So what I would say, it's an interesting question. 'Cause I'm like, I'm thinking I've got two ways of answering I can answer as if I'm talking to management or as if I'm talking to the people who are actually going to use the products and I feel more aligned with the, I feel more aligned with the actual users. >> Yeah, I think let's just, we'll focus on that and I'll let you know, we just have a moment or two left. So if you could maybe boil it down for me a little bit. >> Boiling it down, I would say now look here CIS admins. It's really important that you get your job done but you need to understand that those privileged accounts that you're using on those systems are absolute gold dust if they get into the hands of your adversaries and you need protections income away from those adversaries, but we trust you and we are going to get you the access to your machines as fast as possible. So we're a little bit like a nightclub bouncer but we're like the Heineken of nightclub bounces. When you arrive, we know it's you and we're going to get you to your favorite machine logged on as domain admin, as fast as possible. And while you're there, we're going to cut that session recording of you. And just keep you safe and on the right side. >> All right, I'm going to enjoy my night in the nightclub. Now I can sleep easy tonight knowing that Andy Harris and Osirium are on the case. Thanks, Andy. Andy Harris speaking with us. So the Chief Technology Officer from Osirium as part of our Postgres vision, 2021, coverage here on theCUBE. (upbeat music) >> From theCUBE studios in Palo Alto, in Boston connecting with thought leaders all around the world. This is theCUBE conversation.

(upbeat music) >> From around the globe, it's theCUBE! With digital coverage of Postgres Vision 2021, brought to you by EDB. >> Welcome back to Postgres Vision 21, where theCUBE is covering the innovations in open source trends in this new age of application development and how to leverage open source database technologies to create world-class platforms that are cost-effective and also scale. My name is Dave Vellante, and with me is Roberto Giordano, who is the End User Computing, Corporate, and Database Services Manager at Borsa Italiana, the Italian Stock Exchange. Roberto, great to have you. Thanks for coming on. >> Thanks Dave, and thanks to the interview friend for the invitation. >> Okay, and we're going to dig in to the great customer story here. First, Roberto, tell us a little bit more about Borsa Italiana and your role at the organization. >> Absolutely. Well, as you mentioned, Borsa is the Italian Stock Exchange. We used to be part of the London Stock Exchange, but last month we left that group, and we joined another group called Euronext, so we are now part of another group, I would say. And right now within Euronext, Euronext provide the biggest liquidity pool in Europe, just to mention something. And basically we provide the market infrastructure to our customers across Europe and the whole world. So probably if it happens for you to buy a little of, I don't know, Ferrari for instance, probably use our infrastructure. >> So I wonder if you could talk about the key drivers in the exchange business in Italy. I don't know how closely you follow what's going on in the United States, but it's crypto madness, there's the Reddit army driving up stocks that have big short positions, and of course the regulators have to look at that, and there's a big debate going on. Well, I don't know what's it like in Italy, but what are the key drivers that are really informing the priorities for your technology strategy? >> Well, you mentioned, for instance, the stereotypical cases that are a little bit of laterally to the global markets and also to our markets as a it professional running market infrastructure is our first the goal to provide an infrastructure that is reliable and be with the lowest possible latency. So we are very focused on performance and reliability just to mention the two main drivers within our systems. >> Well, and you have end-user computing in your title and we're going to get into the database discussion, but I presumably with with COVID you had to pivot and that that piece of your job was escalated in 2020, I would imagine. And you mentioned latency which is a key factor in obviously in database access but that must've been a big challenge last year. >> Well, it was really a challenge, but basically we move just within a weekend, the wall organization working remotely. And it has been like this since February, 2020. Think about the challenge of moving almost 1000 people that used to come to the office every day to start to work remotely. And as within my team of the end user computing this was really a challenge but it was a good one at the end. We, we, we succeeded and everything work. It's fine from our perspective, no news is is a good news, you know, because normally when something doesn't work, we are on newspapers. So if you didn't heard about us it means that everything worked out just fine. >> Yeah. It's amazing, Roberto. We both in the technology business that you'll be you're a practitioner observer, but I mean if you're in the tech business most companies actually pivoted quite well. You're have always been a digital business, different. I mean, if you're a Ferrari and making cars and you can't get semiconductors, but but most technology companies actually made the transition you know, quite amazingly, let's get into the, the case study a bit of it. I wonder if you could paint a picture of your organization's infrastructure and applications what it looks like and and particularly your database infrastructure what does that look like? >> Well, we are a multi-vendor shop. So we would like to pick the right technology for for the right service. This means that my database services teams currently manage several different technology where possible that plays a big role in, in, in our portfolio. And because we, we, we currently support both the open source, fully open source version of PostgreSQL, but also the EDB distribution in particular we prefer to use DDB distribution where we did specific functionalities that just EDB provide. And we, when we need a first class level of support that ADB in in recent year was able to provide to us. >> When you say full functioning, are you talking about things like acid compliance, two phase commits? I mean, all these enterprise capabilities, is that right? Or maybe you could be >> Just too much just to mention one, for instance we recently migrated our wire intrasite availability solution using the ADB fail-over manager. That is an additional component that just it'll be provide. >> Yeah. Okay. So, so par recovery obviously is, is and so that's a solution that you to get from the EDB distro as opposed to having to build it yourself with open source tooling. >> Yeah, correct. Well, basically sterically, we used to rely on OSTP clustering from, from, from that perspective. But over the years we found that even if it's a technology that works fine, it has been around for four decades. And so on. We faced some challenges internally because within my team we don't own also the operative system layers. So we want a solution that was 100% within our control and perimeter. So just few months ago we asked the EDB EDB folks if they can provide something. And after a couple of meetings also with their pre-sales engineers, we found the the right solution for us. So we launched long story short, just a quick proof of concept to a tissue test together, again using the ADB consultancy. And, and then we, beginning of this year, we, we went live with the first mission critical service using this brand new technology, well brand new technology for us. You know, it'd be created a few years ago >> And I do have some follow-up questions but I want to understand what catalyzed the, you know what was the motivation for going with an open source database? I mean, you're, you're a great example because you have your multi-vendor so you have experienced with all of it, the full spectrum. What was it about open source database generally EDB specifically that triggered the, the choice? >> Well thanks for the question. It is, this is one of the, or one of the questions that I always, like. I think what really drove us was the right combination between easy to use, so simplicity and also good value for money. So we like to pick the right database technology for the right kind of service slash budget that the survey says and, and the open source solution for a specific service. It, it, it's, it's our, you know, first, first, first choice. So we are not going to say a company that use just one technology. We like to take the best of breed that the market can offer. In some cases, the open source and Pasquesi in particular is, is our choice. How involved was >> The line of business in this both the decision and the implementation? Was it kind of invisible to them, or this was really more of a technology decision based on the your interpretation of the requirements I'm interested in who was involved and how you actually got it done? >> Well, I, I think this decision was transplant for, for, for, for the business at the end of the day don't really have that kind of visibility. You know, they just provide requirements in particular in terms of performance and rehabil area, the reliability. And so, so this this is something they are not really involved about. And obviously if they, if we are in opposition to save a little bit of money everybody's at the, even the business >> No. So what did you have to do? So that makes sense to me, I figured that was the case. Who would, who were the stakeholders on your team? I mean, what kind of technical resources did you require an implementation resources? What take us through what the project if you will look like, wh how did you do it? >> Well, it's a combination of database expertise. I got the pleasure to run a team that is paid by very, very senior, very, very skilled database services professional that are able to support more than one more than what the county and also are very open to innovation and changes. Plus obviously we need also the development teams the relevant development teams on board, when you when you run this kind of transformations and it looks like also, they liked the idea to use PostgreSQL for for this specific service I got in mind. So it, it, it was quite, quite easy, not be discussion. You know. >> What was the, what was the elapsed time from from when you said, okay, we're in, you know signed the agreement we're going here you made the decision to actually getting into production. >> Well, as I mentioned, we, we, we were on we're on services and application that are really focused on high availability and performance. So generally speaking, we are not a peak organization. Also we run a business that is highly regulated. So as you know, as you can imagine we are an organization that don't have a lot of appetite for risk, you know, so generally speaking in order to run this kind of transformation is a matter of several months, I will say six nine months to have something delivered in that space. >> Okay. Well, that's, I mean, that's reasonable. I mean, if you could do it inside of a year that's I think quite good especially in the highly regulated industry. And then you mentioned kind of the fail over the high availability Cape Cape capabilities. Were there other specific EDB tools that that you utilize to sort of address the objectives? >> Yeah, absolutely. We were in particular, we used Postgres enterprise, AKA Pam. Okay. And very recently we were involved within ADB about per se specifically developing one functionality that, that that we needed back in the day. I think together with Bart these are the free EDB specific tools that, that we, that that we use right now. >> And, and I'm, I'm interested in, I want to get to the business impact and I know it's early days for you but the real motivation was to save money and simplify. I would actually, I would imagine your developers were happy because they get to use modern tooling and open source. But, but really though if your industry is bottom line, right, I mean that's really what the, the business case was all about. But I wonder if you could add some color there in terms of the business impact that you expect. And then, I mean I don't know how much visibility you have now but anything you can share with us. >> Well, thinking about the EFM implementation that the business impact the, was that in case of a failure or the DBA team that a services team is it is able to provide a solution that is within our 100% within our perimeter. So this means that we are fully accountable for it. So in a nutshell, when you run a service, the less people the less teams you have to involve the more control you can deliver. And in some, again, very critical services that is a great value. >> Okay. So, and, and where do you want to take this? I mean, how do you see w what's your, if you're thinking about your Postgres and, and generally an EDB you know, roadmap, where do you want it to go? >> Well, I stay to, to trends within within the organization, the, the, the, the the first one is about migrating more existing services to open source solution for database is going to be, is going to be prosperous. And other trends that I see within my organization is about designing applications, not really to be, to to use PostgreSQL as the base, as it does a base layer. I think both trends are more or less surroundings at the same state right now. >> Yeah. A lot of the audience members at Postgres vision 21 is just like you they they're managing day-to-day infrastructure. They're there they're expert practitioners. What advice would you give to somebody that is thinking about, you know taking this journey, maybe if you had to do something over again maybe what would you do differently? How can you help your peers here? >> Well, I think in particular, if you are going to say a big organization that runs a highly regulated business in some cases, you are a little bit afraid of open source because there is this, I can say general consideration about the lack of enterprise level support. I would like to say that it is just about the past because they're around bunch of companies like EDB that are we're a hundred percent capable of providing enterprise level of support, even on, on, on even on the open source distribution of Paul's presser. Obviously Dan is you're going to go with their specific distribution. The level of support is going to be even more accurate but as we know, it could be currently is they across say main contributor of the pollsters community. And I think is, is that an insurance for every organization? >> Your advice is don't be afraid. >> Yeah. My advice is done is absolutely, don't be, don't be afraid. And if, if, if I can, if we can mention about also about, you know, the cloud called technologies this is also another, another topic where if possible I would like to suggest to not being afraid EDB as every every I would say organization within the it industry is really pushing for it. And I think for a very, for, for a lot of cases not all of them, but a lot of cases, there is a great value about the design services application to be cloud native or migrating existing application into the cloud. >> Okay. But, but being a highly regulated industry and being a, you know, very much aware of the the narrative around open source, et cetera, you, you must've had just a little piece of your mind saying, okay I have to manage this risk. So there's anything specifically you did with managing the risks that you would advise? Was it, was it or is it really just about good change management? >> I think it was mainly about a good change management when you got, you know the relevant stakeholders that you need on board and we are, everybody's going the same direction. That basically is about executing. >> Excellent. Well, Roberto, I really appreciate your time and your knowledge that you share with the audience. So thanks so much for coming on the cube. >> Thank you, Dave. It was a great pleasure. >> And thank you for watching the cubes continuous coverage of Postgres vision 21. We'll be right back. (upbeat music)

>> Ed Boyajian, the CEO of Enterprise DB. Ed, what are some of the more exciting things that people can expect from Postgres Vision 2021. Who should attend and why? >> Yeah, so really key things that we're going to be covering. Because of our focus on the enterprise, we're going to to talk a lot about how Postgres is used and deployed at scale in the enterprise. As we've seen, developers are playing such a prominent role now in the decision-making for technologies, especially database. So we're going to talk a lot about application development with Postgres. We're going to spend time. Of course, it's a technology conference. There's a lot coming on the horizon with Postgres and work that EDB is doing. So we're going to talk about emerging technologies and what's ahead. And then, you know, a lot of outsiders don't understand the nature and power of the Postgres community. And so we're going to put some cycles into sharing a little more depth and insight about what happens in the community and why that is powerful and what makes it great. >> Postgres Vision '21 is June 22nd and 23rd. Go to Enterprise DB.com and register. The Cube's going to be there. We hope you will be too. Ed, thanks for coming on the Cube and previewing the event. >> Thanks, Dave. >> And thank you, we'll see you at Vision '21.

(upbeat music) >> From around the globe, it's the CUBE with digital coverage of Postgres Vision 2021. Brought to you by EDB. >> Hello everyone, this is Dave Vellante for the CUBE. We're covering Postgres Vision 2021, the Virtual CUBE edition. Welcome to our conversation with the CEO, Ed Boyajian, the CEO of Enterprise DB. And we're going to talk about what's happening in open source and database and the future of tech. Ed, Welcome. >> Hi Dave, good to be here. >> Hey, several years ago at Postgres Vision event you put forth the premise that the industry was approaching a threshold moment, and digital transformation was the linchpin of that shift. Now, Ed, while you were correct, and I have no doubt the audience agreed, most people went back to their offices after that event and they returned to their hyper-focus of their day-to-day jobs. Yeah, maybe a few accelerated their digital initiatives but generally, pre COVID, we moved at a pretty incremental pace and then the big bang hit. And if you weren't digital business, you were out of business. So, that single event created the most rapid change that we've ever seen in the tech industry by far, nothing really compares. So, the question is, why is Postgres specifically and EDB generally the right fit for this new world? >> Yeah, I think, look a couple of things are happening Dave. You know, right along the bigger picture of digital transformation, we are seeing the database market in transformation. And, and I think the things that are driving that shift are the things that are resulting the success of Postgres and the success of EDB. I think first and foremost, we're seeing a dramatic re-platforming. And just like we saw in the world of Linux where I was at, Red Hat during that shift where people were moving from Unix-based systems to X86 systems, we're seeing that similar re-platforming happening whether that's from traditional infrastructures to cloud-based infrastructures or container-based infrastructures, it's a great opportunity for databases to be changed out. Postgres wins in that context because it's so easily deployed anywhere. I think the second thing that's changing is we're seeing a broad expansion of developers across the enterprise. They don't just live in IT anymore. And I think as developers take on more power and control, they're just defining the agenda. And it's another place where Postgres shines. It's been a priority of EDB's to make Postgres easier and that's coming to life. And I think the last stack overflow developer survey suggested that, I think they survey 65,000 developers, the second most loved and the second most used database by developers is Postgres. And so I think there again, Postgres shines in a moment of change. And then I think the third is kind of obvious. It's always an elephant in the room, no pun intended, but it's this relentless nagging burden of the expenses of the incumbent proprietary databases and the need. And we especially saw this in COVID. To start to change that, more dramatically change that economic equation, here again, Postgres shines. >> You know, I want to ask you, I'm going to jump ahead to the future for a second, because you're talking about the re-platforming and with your Red Hat shops I kind of want to pick your brain on this because you're right. You saw that with Red Hat and you're kind of seeing it again when you think about open shift and where it's going, my question is related to re-platforming around new types of workloads, new processing models at the edge, I mean, you've seen an explosion of processing power GPU's, NPUs, accelerators, DSPs and it appears that there this is happening at a very low cost. I'm inferring that you're saying Postgres can take advantage of that trend as well, that that broader re-platforming trend to the edge, is that correct? >> It is. And, and I think, you know this is the this has been one of the I think the most interesting things with Postgres. Now I've been here almost 13 years. So if you put that in some perspective, I've watched and participated in leading transformation in the category. You know, we've been squarely focused on Postgres so we've got 300 engineers who worry about making Postgres better. And as you look across that landscape a time, not only as Postgres gotten more performance and more scalable, it's also proven to be the right database choice in the world of not just legacy migrations but new application development. And I think that stack overflow developer survey is a good indicator of how developers feel about Postgres, but, you know over that timeframe, I think if you went back to 2008 when I joined EDB, Postgres was was considered a really good general purpose database. And today I think Postgres is a great general purpose database. General purpose isn't sexy in the market, broadly speaking but Postgres capabilities across workloads in every area is really robust. And let me just spend a second on it. We look at our customer base as deploying and what we think of as systems of record, which are the traditional ERP type apps, you know where there's a single source of truth. You might think of ERP apps there. We look at our customers deploying and systems of engagement, and those are apps that you might think of in the context of social media style apps or websites that are backed by a database. And the third area is systems of analytics where you would typically think of data warehouse style applications, interestingly, Postgres performs well. And our customers report using us across that whole landscape of application areas. And I think that is one of Postgres' hidden superpowers, is that ability to reach into each area of requirement on the workload side. >> Yeah. And as I was alluding to before. That, that itself is evolving as you now inject AI into the equation AI inferencing. And it's just a very exciting times ahead. There's no, there's no database, you know 20 years ago it was kind of boring. Now it's just exploding. I want to come back to that, the notion of of Postgres that maybe talk about other database models. I mean, you've mentioned that you've evolved from this, you know, system of record. You can take a system engagement on structured data, et cetera, Jason it's-. So how should we think about Postgres in relation to other databases and specifically other business models of companies that provide database services? Why is Postgres attractive? Where is it winning? >> Yeah, I think a couple of places. So, I mean, for first and foremost, Postgres, you know at its core, Postgres is a SQL relational database a trend in asset compliance, equal relational database. And that is inherently a strength of Postgres but it's also a multi-model database. Which means we handle a lot of other, you know database requirements, whether that's geospatial or, or JSON for documents or, or time series, things like that. And, so Postgres extensibility is one of its inherent strengths. And that's kind of been built in from the beginning of Postgres. So not surprisingly people use Postgres across a number of workloads because at the end of the day, there's still value in having a database that's able to do more. There are a lot of important specialty databases and I think they will remain important specialty databases, but Postgres thrives in its ability to crossover in that way. And I think that is, you know one of the different key differentiators in in how we've seen the market and the business develop. And, and that's the breadth of of workloads that Postgres succeeds in. But, but our growth if you kind of ventured it across vectors we see growth happening, you know, in a few dimensions. First, we see growth happening in new applications. About half of our customers have come to us today for new, new Postgres users are deploying us on new applications. The others are our second area migrating away from some existing legacy incumbent. Often Oracle, not always. The third area of growth we see is in cloud where we're Postgres is deployed very prolifically both in the traditional cloud platforms like EC2, but then again also in the database as a service environment and then the fourth area growth we're seeing now is around container deployment, Kubernetes deployment. >> Well, you mean Oracle's prominent because it's just, it's, it's, it's a big install base and it's expensive and people, you know they got to look at that. I mean, It's funny. I do a lot of TCO work and mostly, you know usually TCO is about labor costs when it comes to Oracle it's about license costs and maintenance costs. And so to the extent that you can reduce that at least for a portion of your state, you're going to, you're going to drop right to the bottom line. But, but, I want to ask you about the kind of that spectrum that you think about the prevailing models for database you've got on the one hand, you've got the right tool for the right job approach. You know, it might be 10 or 12 data stores in the cloud. On the other hand, you've got kind of a converged approach. You know, Oracle is going that direction, clearly Postgres, with its open source innovation, is going that direction. And it seems to me yet that at scale that's a more, the latter is the more cost-effective model. How do you think about that? >> Well, you know, I think at the end of the day you kind of have to look at it. I mean, the, the business side of my brain looks at that as an addressable market question, right? And you heard me talk about three broad categories of workloads and, you know, people define workloads in different buckets, but that's how we do it. But if you look at just a system of record in the system of engagement market I think that's what would be traditionally viewed as the database market. And there that's, you know, let's just say for the sake of arguments, a 45 to $50 billion market. The third, the systems of analysis that market's an $18 billion market. And, and, you know, as we talk about that so all in it's still between 60 and $70 billion market. And I think what happens, there's so much heat and light poured on the valuation multiples of some of the specialty players that the market gets confused. But the reality is our customers don't get confused. I mean, if you look at those specialty players take that $48 billion market. I mean, add up Mongo, Reds, Cockroach, Neo, all of those. I mean, hugely valued companies all unicorn companies, but combined they add up to a billion bucks. Don't get me wrong, that's important revenue and meaningful in the workloads they support, but it's not, it doesn't define the full transformation of this category. Look at the systems of analysis again, another great, great market example. I mean, if you add up the consolidation of the Hadoop vendors, add in there, snowflake you're still talking to, you know $1.5 billion in revenue in an $18 billion market. So while those are all important technologies the question is in this transformation move did the database market fully transformed yet. And my view is, no, it didn't, we're in the first maybe second inning of a $65 billion transformation. And I think this is where Postgres will ultimately shine. I think this is how Postgres wins, because at the end of the day, the, the nature of the workloads fits with Postgres and the future tech that we're building in Postgres will serve that broader set of needs. I think more effectively. >> Well, and I love these tam expansion discussions because I think you're right on. And I think it comes back to the data and we all we all talk about the data growth, the data exposure and we see the IDC numbers. Well, you ain't seen nothing yet. And so at data by its very nature is distributed. That's why I get so excited about these new platform models. And I want to tie it back to developers and open source because to me, that is the linchpin of innovation in the next decade. It has been, I would even say for the last decade we've seen it, but it's gaining momentum. So, so in thinking about innovation and specifically Postgres in open source, you know, what can you share with us in terms of how we should think about your advantage and again where people are glomming, leaning in to that advantage? >> Yeah. So, I mean, I think, I think you bring up a really important topic for us as a company, Postgres, we think is an incredibly powerful community and, and when you step away from it, again, I, now you remember, I told you, I'd been at, I was at Red Hat before now here at EDB. And there's a common thread that runs through those two experiences. In, in both experiences the companies are attached and prominent alongside a strong, independent open-source community. And I think the notion of an independent community is really important to understand around Postgres. There are hundreds and thousands of people contributing to Postgres. Now EDB plays a big role in that about, you know approaching a third of the contributions in the last release, released 13 of Postgres came from EDB. Now you might look at that and say, gee, that sounds like a lot, but if you step away from it, you know at about 30% of those contributions, most of the contributions come from a universe around EDB and that's inherently healthy for the community's ability to innovate and accelerate. And I think that while we play a strong role there you can imagine that having, and there are other great companies that are contributing to Postgres. I think having those companies participating and contributing gets the best the best ideas to the front in innovation. So I think the inherent nature Postgres community makes it strong and healthy. I mean, and then contrast that to some of the other prominent high value open-source companies. Companies and the communities are intimately intertwined. They're one in the same. They're actually not independent open source communities. And I think that they're therein lies one of, one of the inherent weaknesses in those. But, Postgres thrives because, you know we bring all those ideas from EDB. We bring a commercial contingent with us and all the things we hope, we emphasize and focus on, in growth and Postgres. Whether that's in the areas of scalability, manageability, all hot topics, of course security, all of those areas. And then, you know, performance as always. All of those areas are informed to us by enterprise customers deploying Postgres at scale. And I think that's the heart of what makes a successful independent project. >> Common editorial powers of, of that ecosystem. They, they they're they're multiplicative as opposed to the, the resources of one. I want to talk about Postgres Vision 2021 sort of set up that a little bit. The theme this year is 'The Future is You'. What do you mean by that? >> So, if you think about what we just said, posts, the category is in Tran-, the database categories in transformation. And we know that many of our people are interested in Postgres are early in their journey. They're early in their experience. And so we want to focus this year's Postgres Vision on them. That we understand, as a company who's been committed to Postgres, as long as we have. And with the understanding we have of the technology and best practices, we want to share that view, those insights with, with those who are coming to Postgres. Some for the first time, some who are experienced. >> Postgres Vision 21 is June 22nd and 23rd go to enterprisedb.com and register. The CUBE's going to be there. We hope you will be too. Ed, thanks for coming to the CUBE and previewing the event. >> Thanks, Dave. >> And thank you. We'll see you at Vision 21. (upbeat music)

(upbeat techno music) >> From around the globe, it's theCUBE. With digital coverage of Postgres Vision 2021. Brought to you by EBD. >> Hello everyone, this is David Vellante, for the CUBE. And we're here covering Postgres Vision 2021. The virtual version, thCUBE virtual, if you will. And welcome to our power-panel. Now in this session, we'll dig into database modernization. We want to better understand how and why customers are tapping open source to drive innovation. But at the same time, they've got to deliver the resiliency and enterprise capabilities that they're used to that are now necessary to support today's digital business requirements. And with me are three experts on these matters. Abdul Sheik, is Global CTO and President of Cintra. Young Il Cho, aka Charlie, is High Availability Cluster Sales Manager, at Daone CNS. And Alan Villalobos, is the Director of Development Partnerships, at IBM. Gentlemen, welcome to theCUBE. >> Thank you, Dave, nice to be here. >> Thank you, Dave. >> All right, let's talk trends and frame the problem. Abdul, I want to start with you? Cintra you're all about this topic. Accelerating innovation using EDB Postgres helping customers move to modern platforms. And doing so, you got to do it cost-effectively but what's driving these moves? What are the problems that you're seeing at the organizations that you serve? >> Oh, so let me quickly introduce, Abdul Sheik, CTO. I'll quickly introduce Cintra. So we are a multicloud and database architecture MSP. And we've been around for 25 plus years. Headquartered in New York and the UK. But as a global organization, we're serving our SMB customers as well as large enterprise customers. And the trends we're seeing certainly in this day and age is transformation and modernization. And what that means is, customers looking to get out of the legacy platforms, get out of the legacy data centers and really move towards a modern strategy with a lower cost base, while still retaining resiliency and freedom. Ultimately, in terms of where they're going. The key words that really I see driving this, number one is choice. They've been historically locked into vendors. With limited choice with a high cost base. So choice, freedom to choose in terms of what database technologies they apply to which workloads and certainly EDB and the work that has been done to closely marry what enterprise RD platforms offer with EDBs in a work that they've done in terms of filling those gaps and addressing where the resiliency monitoring performance and security requirements are, are certainly are required from an enterprise customer perspective. Choice is driving the move that we see and choice towards a lower cost platform that can be deployed anywhere. Both on-prem modernization customers are looking to retain on premise platforms or moving into any multi clouds whether it's an infrastructure cloud play or a platform cloud play. And certainly with EDBs offering in terms of, you know the latest cloud native offerings also very interesting. And lastly, aside from just cost and the freedom to choose where they deploy those platforms the SLA, the service level model where is the resiliency requirement where the which system is going to bronze, silver, gold? Which ones are the tier one revenue platform revenue generating platforms which are the lower, lower utility platforms. So a combination of choice, a combination of freedom to deploy anywhere and while still maintaining the resiliency and the service levels that the customers need to deliver to their businesses >> Abdul that was a beautiful setup. And, and we've got so much to talk about here because customers want to move from point A to point B but getting there and they, they need help. It's sometimes not trivial. So Charlie Daone is a consultancy. You've got a strong technical capabilities. What are you seeing in this space? You know, what are the major trends? Why are organizations considering that move? And what are some of the considerations there? >> Well, like in other country in South Korea or so our a lot of customers, banking's a manufacturing distributor. They are 90, over 90%. They are all are using Oracle DB and a rack system. But as the previous presenters pointed out, a lot of customers that are sick of the Oracle and they have to undergo the huge cost of a maintenance costs. They want to move away from this cost stress. And secondly, they can think about they're providing service to customer on their cloud base which is a private or the public. So we cannot imagine running on database, Oracle database running on the cloud the system that's not matches on this cloud. And first and second, and finally the customer what they want is the cost and they want to move away from the Oracle locking. They cannot be just a slave at Oracle for a long time and the premium for the new cloud the service for the customer. >> Great. Thank you for that. Oh, go ahead. Yeah. Did you have something else to add Charlie go ahead and please. >> No that's all. >> Okay, great. Yeah, Allen, welcome to theCUBE. You know, it's very interesting to us. IBM, you, you, of course, you're a big player in database. You have a lot of expertise here. And you partner with EDB, you're offering Postgres to customers, you know, what are you seeing? Charlie was talking about Oracle and RAC. I mean, the, the, the thing there is obviously, we talked about the maintenance costs but there's also a lot of high availability capabilities. That's something that IBM really understands well. Do you see this as largely a cloud migration trend? Is it more modernization? Interested in what's IBM's perspective on this? >> I think modernization is the right word. The points that the previous panelists brought up or are on point, right? You know, lower TCO or lower costs in general but that of agility and then availability for developers and data scientists as well. And then of course, you know, hybrid cloud, right? You know, you want to be able to deploy on prem or in the cloud, or both in a mixture of all of that. And I think, I think what ties it together is the customers are looking for insights, right? And, you know, especially in larger organizations there's a myriad of data sources that they're already working with. And, you know, we, you know we want to be able to play in that space. We want to give an offering that is based on Postgres and open source and be able to further what they're strong at at and kind of, you know on top of that, you know, a layer of, of of need that we see is, is seamless data governance across all of those different stores. >> All right, I'm going to go right to the heart of the hard problem here. So if, I mean, I want to, it's just that I want to get from point A to point B, I want to save money. I want to modernize, but if I'm the canary in the coal mine at the customer, I'm saying guys, migration scares me. How do I do that? What are the considerations? And what do I need to know that I don't know. So Abdul, maybe you could walk us through what are some of the concerns that customers have? How do you help mitigate those? Whether it's other application dependencies, you know freezing code, you know, getting, again from that point A to point B without risking my existing business processes how do you handle that? >> Yeah, certainly I think a customer needs to understand what the journey looks like to begin with. So we've actually developed our own methodology that we call Rocket Cloud, which is also part of our cloud modernization strategy that builds in and database modernization strategy built into it starts with an assessment in terms of current state discovery. Not all customers totally understand where they are today. So understanding where the database state is, you know where the risks lie what are the criticality of the various databases? What technologies are used, where we have RAC or we don't have RAC but we have data God, where we have encryption. And so on. That gives the customer a very good insight in terms of the current state, both commercially and technically that's a key point to understand how they're licensed today and what costs could be freed up to free the journey to effectively fund the journey. It's a big, big topic, but once we do that, we get an idea and we've actually developed a tool called rapid discovery. That's able to discover a largest stake without knowing the database list. We just put the scripts at the database servers themselves and it tells us exactly which databases are suited to be you know, effectively migrated to Postgres with in terms of the feature function usage in terms of how heavy they are, would store procedures in the database amount of business logic use of technologies like RAC data guard and how they convert over to to Postgres specifically. That ultimately gives us the ability to give that customer an assessment and that assessment in a short sharp few weeks and get the customer view of all of my hundreds of databases. Here are the subset of candidates for Postgres and specifically than we do the schemer advisor tool the actual assessment tool from EDB, which gives us a sense of how well the schema gets converted and how best to then also look at the stored procedure conversion as well. That gives the customer a full view of their architecture mapping their specific candidate databases and then a cost analysis in terms of what that migration looks like and how we migrate. We also run and maintain those platforms once we're on EDB. >> Thank you for that again, very clear but so you're not replacing, doing an organ transplant. You may, you're you're, you know, this is not I don't mean this as a pejorative, but you're kind of cherry picking those workloads that are appropriate for EDB and then moving those and then maybe, maybe through attrition or, you know over time, sun-setting those other, those other core pieces. >> Exactly. >> Charlie, let me ask you, so we talked about RAC, real application clusters, data guard. These are, you know kind of high profile Oracle capabilities. Can you, can you really replicate the kind of resiliency at lower costs with open source, with EDB Postgres and how do you do that? >> It's my turn? >> yes, please. >> Quite technically, again, I go on in depths and technically the RAC, RAC system is so-called is the best you know, best the tool to protect data and especially in the Unix system, but apart from the RAC by the some nice data replication solution we just stream the application and log shipping and something and then monitor Pam and, and EFM solution which is enterprise failover manager. So even though it be compared to Apple the Apple RAC versus with EDB solution, we can definitely say that RAC is more stable one, but after migration, whatever, we can overcome the, you know, drawbacks of the HA cluster system by providing the EDB tools. So whatever the customer feel that after a successful migration, utilizing the EDB high availability failable solution they can make of themselves at home. So that's, that's how we approach it with the customers. >> So, Alan, again, to me, IBM is fascinating here with your level of involvement because you're the, you guys are sort of historically the master of proprietary the mainframes, VCM, CICF, EB2, all that stuff. And then, you know IBM was the first I remember Steve Mills actually announced we're going to invest a billion dollars in open source with Linux. And that was a major industry milestone. And of course, the, the acquisition of red hat. So you've got now this open source mindset this open source culture. So we, you know, as it's all about recovery in, in database and enterprise database and all the acid properties in two phase commits, and we're talking about, you know the things that Charlie just talked about. So what's your perspective here? IBM knows a lot about this. How do you help customers get there? >> Yeah, well, I mean the main, the main thrust right now IBM has a offering called IBM cloud Pak for data which from here, which runs EDB, right? EDB, Postgres runs on top of cloud Pak for Data But the, you know I think going back to Abdul's points about, you know migrating whatever's needed and whatever can be migrated to Postgres and maybe migrating other things other places, we have data virtualization and autoSQL, right? So once you have migrated those parts of your database or those schemes that can be, having, you know a single point where you can query across them and by the way, being able to query across them you know, before, during and after migration as well. Right? So we're kind of have that seamless experience of layer of SQL. And now with autoSQL of spark SQL as well, as you're, as you're migrating and after is, I'd say, you know, key to this. >> What, what's the typical migration look like? I know I'm sorry, but it's a consultant question but thinking about the, you know, the average, in terms of timeframe, what are the teams look like? You know who are the stakeholders that I need to get involved? If I'm a customer to really make this a success? maybe Abdul, you could talk about that and Charlie and Alan can chime in. >> Well, I think, well, number one you knew the exact sponsors bought into it in terms of the business case, supporting the business case an architect has got a big picture understanding not only database technology but also infrastructure that they're coming from as well as the target cloud platforms and how you ensure that the infrastructure can deliver the performance. So the architect role is important, of course the core DBA that lives within the scope of the database understands the schema of the data model the business logic itself, and the application on it. That's key specifically around the application certification testing connectivity and the migration of the code. And specifically in terms of timeline just to touch on that quickly. I mean, in our experience so far and we're seeing the momentum really really take off the last 18 months, a small project with limited business logic within the database itself can we migrate it in a couple of months but typically with all the testing and rigor around that you typically say three months timeline a medium-sized complexity projects, a six month timeline and a large complex project could be anything from nine months and beyond, but it really comes down to how heavy the database is with business logic and the database and how much effort it will take to re-engineer effectively migrate that PLC code, business logic into EDB given the compatibility level between Oracle and EDB it's relatively certainly an easier path than any other target platform in terms of options. Yeah. Not perspective. That's certainly looks like the composition of a team and timeline >> Charlie or Alan, anything you guys would add. >> Yeah. So, so I think all those personas make sense. I think you might, on the consumer side of the consumer the consumer of the data side the data scientists often we see, you know during migrations and then obviously the dev ops, I think or any operations, right, have to be heavily involved. And then lastly, you know, you see more and more data steward role or data steward type persona, CDO office type type person coming in there make sure that, you know, whatever data governance that is already in place or wants to be in place after the migration is also part of the conversation. >> Why EDB? You know, there's a lot of databases out there you know, it's funny, I always say like, you know, 10, 15 years ago databases were kind of sort of a boring market, right? It was like, okay, you're going to work or whatever. And now it's exploded. You got open source databases, you got, you know not only sequel databases, you got graph databases you know, you get cloud databases, it's going crazy. Why EDB? You wonder if you guys could address that? >> Allan why don't you go first this time? I'll compliment your answers. >> Yeah. I mean, again, I think it goes back to, to the, the I guess varying needs and, and enterprises. Right. And I think that's, what's driven this explosion in databases, whether it's a document store like you're saying, or, or new types of RDBMS, the needs that we talked about at the beginning, like lower TCO, and the push to open source. But you know, the fact of the matter is that that yes, there is a myriad, an ecosystem of databases, pretty much any organization. And so, yeah, we want to tap into that. And why EDB? EDB has done a great job of taking Postgres and making it enterprise ready, you know, that's what they're, they're good at and that, you know fits very nicely with the IBM story obviously. And, and so, you know, and they've they've worked with us as well. They have an operator on, on the runs on red hat OpenShift. So that makes it portable as well but also part of the IBM cloud Pak for data story. And, and yeah, you know, we want to break down those silos. We realized that that need is there for all of these, you know, there's this ecosystem of databases. And so, you know, we're, we see our role as being that platform, whether it's red hat OpenShift, or IBM cloud Pak for data that, that unifies, and kind of gives you that single pane of glass across all of those sources. >> And Charlie, you're obviously all in, you've got EDB in your background. Why EDB for you? >> Before talking about EDB you asked about the previous question about how the migration was different from Oracle to EDB. We had a couple of success story in Korea telecom and some banking area, and it was easier. So EDB provide MTK tool as a people know but it was an appropriate, like a 90%. So we are the channel partner of the EDB for four years. So what we have done was to hire the Oracle expert. So we train Oracle export as as EDB expert at the same time so that they can approach customer and make it easy. So you have no worry about that. Just migrating EDB, Oracle to EDB. There is a no issue. Those telltales include all the tasks, you know Stratus test and trainee, and a POC that we there. So by investing that Oracle expert that we could overcome and persuade the customer to adopt EDB. So, why EDB? Simply I can say there, is there any database they can finally replaced Oracle in the world? Why is the, it's the interoperability between Oracle to EDB as the many experts pointed out there is no other DBE. They can, you know, 90, 90% in compatibility and intercooperability with EDB. That's why, of course, there's the somewhat, you know budget issues or maintenance issue cost the issue escape from Oracle lock-in. But I think the the number one reason was the interoperability and the compatibility with database itself, Oracle database. That was a reason, I guess >> Great Abdul we've talked about, we all know the, as is, you've got a high maintenance costs. You got a lot of tuning, and it's just a lot of complexity. What about the 2B maybe you could share with us sort of the outcome some of the outcomes you've seen what the business impact has been of some of these migrations? >> Sure. I mean, I'll give you a very simple example then just the idea of running Oracle on prem a lot of customer systems teams, for example will drive a virtualization VMware strategy. We know some of the challenges of running Oracle MBM where from a license perspective. So giving the business the ability where I want to go customer in the financial services market in New York, heavy virtualization strategy the ability for them to move away from Oracle on, you know expensive hardware on to Postgres EDB on virtualization just leverage existing skillsets, leveraging existing investment in terms of infrastructure, and also give them portability in AWS. The other clouds, you know, in terms of a migration. More from a business perspective as well, I would say about some of the Allan's points in terms of just freeing up the ability for data scientists and data consumers, to, you know, to consume some of that data from an Postgres perspective more accessibility spinning up environments quicker less latency in terms of the agility is another key word in terms of the tangible differences, the business, lower cost agility, and the freedom to deploy anywhere at the end of the day. Choices, I think the key word that we could come back to and knowing that we can do that to Charlie's point specifically around maintaining service levels. And as architects, we support some of the big, big names out there in terms of airlines, online, cosmetic retailers, financial services, trading applications, hedge funds, and they all want one thing as architect: for us to deliver that resiliency and stand behind them. And as the MSP we're accountable to ensure those systems are up and running and performing. So knowing that the EDB is provided the compatibility but also plugged the specific requirements around performance management, security availability that's fundamentally been key. >> [Dave I mean, having done a lot of TCO studies in this area, it's, it's it Oracle's different. You know, normally the biggest component of TCO is labor with Oracle. The biggest component of TCO is licensed and maintenance costs. So if you can virtualize and reduce those costs and of course, of course the Oracle will fight you and say we won't support it in a VMware environment. Of course, you know, they will, but, but you got to really, you got to battle. But, so here's my last question. So if I'm a customer in that state that you described you know, a lot of sort of Oracle sprawl a lot of databases out there, high maintenance costs, the whole lock-in thing. I got to choices. I, you know, a lot of choices out there. One is EDB. You guys have convinced me that you've got the expertise If I can partner with firms like yours, it's safer route. Okay, cool. My other choice is Oracle is going to, The Oracle sales reps is going to get me in a headlock and talk about exit data and how their Oracle cloud, and how it's, they've invested a lot there. And they have, and, I can pay by the drink all this sort of modern sort of discussion, you know, Oracle act like they invented it late to the game. And then here we are. So, so help me. What's the pitch as to, well, that's kind of compelling. It's maybe the safe bet they're there. They're working with my CIO, whatever. Why should I go with the open source route versus that route? It sounds kind of attractive to me, help me understand that each of you maybe take me through that. Abdul, why don't you start. >> Yeah. I'd say, you know, Oracle's being the defacto for so many years that people have just assumed and defaulted saying, high availability, RAC, DR. Data guard, you know, and I'll apply to any database need that I have. And at the end of the day customers have a three tier database requirement: the lowest, less critical, bronze level databases that really don't need RAC or a high availability, silver tier that are departmental solutions. That means some level of resiliency. And then you've got your gold revenue producing brand impact databases that are they're down. And certainly they won. You see no reason why the bronze and silver databases can be targeted towards EDB. Admittedly, we have some of our largest customers are running platforms, are running $5 million an hour e-commerce platform or airlines running large e-commerce platforms. And exit data certainly has a place. RAC has a place in those, in those scenarios. Were not saying that the EDB is a solution for everything in all scenarios, but apply the technology where it's appropriate where it's required and, you know, generally wherever Oracle has being the defacto and it's being applied across the estate, that's fundamentally what's changed. It doesn't have to be the only answer you have multiple choices now. EDB provides us with the ability to probably address, you know more than 50% of the databases' state, and comfortably cope with that and just apply that more expensive kind of gold tier one cost-based but also capability, you know from the highest requirements of performance and availability where it's appropriate. >> Yeah. Very pragmatic approach. Abdul, thank you for that. And Charlie. Charlie, what's your perspective? Give us your closing thoughts. >> Well, it has been, Oracle has been dominating in Asia in South Korea has market or over many years. So customers got tired of this, continuous spending money for the maintenance costs and there is no discount. There is no negotiation. So they want to move away from expensive stuff. And they were looking for a flexible platform with the easygoing and the high speed and performance open source database like a possibly as career. And now the EDB cannot replace a hundred percent of existing legacy worker, but 10%, 20% 50% as time goes on the trend that will continue. And it will be reaching some high point or replacing the existing Oracle system. And it can, it can also leading to good business chance to a channel partner and EDB steps and other related business in open source. >> Great. Thank you, Charlie and Allen, bring us home here. Give us your follow up >> I think my, co- panelists hit the nail on the head, right? It's a menu, right? That's as things become more diverse and as people make more choices and as everybody wants more agility, you have to provide, I mean, and so that, that's where that's coming in and I liked the way that Andul I kind of split it into gold silver and bronze. Yeah. And I think that that's where, we're going, right? I mean you should ask your developers right? Are your developers like pining to start up a new instance of Oracle every time you're starting a new project? Probably not reach for their Postgres right? And so, because of that, that's where this is coming from and that's not going to change. And, and yeah, that that ecosystem is going to continue to, to thrive. And there'll be lots of different flavors in the growing open source ecosystem. >> Yeah. I mean, open source absolutely is the underpinning you know, the, the bedrock of innovation, these days. Gentlemen, great power panel. Thanks so much for bringing your perspectives and best of luck in the future. >> Thank you, next time we'll try and match our backgrounds >> Next time. Well, we'll up our game. Okay. And thank you for watching everybody. This is Dave Volante for theCUBE. Stay tuned for more great coverage. Postgres vision, 21. Be right back. (upbeat techno music)

>>Ed. Biology in the ceo of enterprise DB ed. What are some of the more exciting things that people can expect from postgres Vision 2021 who should attend and why? >>Yeah. So really um key things that we're going to be covering were because of our focus on the enterprise. We're gonna we're gonna talk a lot about how Postgres is used and deployed at scale in the enterprise. As we've seen, developers are playing such a prominent role now in the decision making for technologies, especially database. So we're going to talk a lot about application development with Postgres. We're going to spend time, of course, it's a technology conference, there's a lot coming on the horizon with Postgres and work that Ebs doing. So we're going to talk about emerging technologies and what's ahead and then, you know, a lot of outsiders don't understand the nature and power of the postgres community. And so we're gonna put some cycles into sharing a little more depth than insight about what happens in the community and why that is powerful and what makes it great. >>Postgres Vision 21 is june 22nd and 23rd go to Enterprise db dot com and register the cube is gonna be there. We hope you will be too. Ed, thanks for coming on the Cuban previewing the event. >>Thanks Dave. >>Thank you. We'll see you at Vision 21.

>>Good afternoon everybody. I'm John Walls and welcome back to our coverage here on the cube of AWS Reinvent 22. We are bringing you another segment with the Global Startup Program, which is part of the AWS Start Showcase, and it's a pleasure to welcome two new guests here to the showcase. First, immediately to my right Han w lre. Good to see you Han. Good to see you. The leader of the Enterprise Solutions Architecture at aws. And on the far right, Rolin Lee, who is the co-founder and CEO of Heim Doll Data. Roland, good to see you. Great >>To be here. >>All right, good. Thanks for joining us. Well first off, for those at home, I may not be familiar with Heim Doll. What do you do? Why are you here? But I'll let you take it from there. >>Well, we're one of the sponsors here at AWS and great to be here. We offer a data access layer in the form of a proxy, and what it does is it provides complete visibility and the capability to enhance the interaction between the application and one's current database. And as a result, you'll, the customer will improve database scale, database security and availability. And all these features don't require any application changes. So that's sort of our marketing pitch, if you will, all these types of features to improve the experience of managing a database without any application >>Changes. And, and where's the cloud come into play then, for you then, where, where did it come into play for you? >>So we started out actually helping out customers on premise, and a lot of enterprise customers are moving over to the cloud, and it was just a natural progression to do that. And so aws, which is a key part of ours, partners with us to help solve customer problems, especially on the database side, as the application being application performance tends to have issues between the interaction between the application database and we're solving that issue. >>Right. Sohan, I mean, Roan just touched on it about OnPrem, right? There's still some kickers and screamers out there that, that don't, haven't bought in or, or they're about to, but you're about to get 'em. I, I'm sure. But talk about that, that conversion or that transition, if you would, from going OnPrem into a hybrid environment or to into the, the bigger cloud environment and and how difficult that is sometimes. Yes. Maybe to get people to, to make that kind of a leap. >>Well, I would say that a lot of customers are wanting to focus more on product innovation experimentation, and also in terms of having to manage servers and patching, you know, it's to take away from that initiative that they're trying to do. So with aws, we provide undifferentiated heavy lifting so that they can focus on product innovation. And one of the areas talking about Heim is that from the database side, we do provide Amazon rds, which is database and also Aurora, to give them that lift so they don't have to worry about patching servers and setting up provisioning servers as well. >>Right. So Roland, can you get the idea across to people very simply, let us take care of the, the hard stuff and, and that will free you up to do your product innovations, to do your experimentations to, to really free up your team, basically to do the fun stuff and, and let us sweat over the, the, the details basically. Right? >>Exactly. Our, our motto is not only why build when, when you can buy. So a lot of it has to do with offering the, the value in terms of price and the features such as it's gonna benefit a team. Large companies like amazon.com, Google, they have huge teams that can build data access layers and proxies. And what we're trying to do here is commercialize those cuz those are built in house and it's not readily available for customers to use. And you'd need some type of interface between the application and the database. And we provide that sort of why build when you can buy. >>Well, I was gonna say why h right? I mean what's your special sauce? Because everybody's got something, obviously a market differentiator that you're bringing into place here. So you started to touch on a little bit there for me, but, but dive a little deeper there. I mean, what, what is it that, that you're bringing to the table with AWS that you think puts you above the crowd? >>Well, lemme give you a use case here. In typical events like let's say Black Friday where there's a surge traffic that can overwhelm the database, the Heim doll data access layer database proxy provides an auto scaling distributed architecture such that it can absorb those surges and traffic and help scale the database while keeping the data fresh and up to date. And so basically traffic based on season time of day, we can, we can adjust automatically and all these types of features that we offer, most notably automated query caching, ReadWrite split for asset compliance don't require any code changes, which typically requires the application developer to make those changes. So we're saving months, maybe years of development and maintenance. >>Yeah, a lot of gray hairs too, right? Yeah, you're, you're solving a lot of problems there. What about database trends in just in general Hunt, if you will. I mean, this is your space, right? I mean, what we're hearing about from Heindel, you know, in terms of solutions they're providing, but what are you seeing just from the macro level in terms of what people are doing and thinking about the database and how it relates to the cloud? Right. >>And some of the things that we're seeing is that we're seeing an explosion of data, relevant data that customers need to be able to consume and also process as well. So with the explosion of data, there's also, we see customers trying to modernize their application as well through microservices, which does change the design patterns of like the applications we call the access data patterns as well. So again, going back to that, a differentiated heavy lifting, we do have something called purpose built databases, right? It's the right tool for the right purpose. And so it depends on what their like rpo, rto their access to data pattern. Is it a base, is it an acid? So we want to be able to provide them the options to build and also innovate. So with that, that's why we have the Amazon rds, the also the, we also have Redshift, we also have Aurora and et cetera. The Rediff is more of the BI side, but usually when you ingest the data, you have some level of processing to get more insight. So with that, that's why customers are moving more of towards the managed service so that they can give that lift and then focusing on that product and innovation. Yeah. >>Have we kind of caught up or are we catching up to this just the tsunami of data to begin with, right? Because I mean, that was it, you know, what, seven, eight years ago when, when that data became kind of, or becoming king and, and reams and reams and reams and all, you know, can't handle it, right? And, and are we now able to manage that process and manage that flow and get the right data into the right hands at the right time? We're doing better with that. >>I would say that it, it definitely has grown in size of the amount of data that we're ingesting. And so with the scalability and agility of the cloud, we're able to, I would say, adapt to the rapid changes and ingestions of the data. So, so that's why we have things like Aurora servers to have that or auto scale so they can do like MySQL or Postgres and then they can still, like what you know, I'm trying to do is basically don't have to co do like any code changes. It would be a data migration. They still use the same underlying database on also mechanisms, but here we're providing them at scale on the cloud. >>Yeah. Our proxies, they must have for all databases. I mean, is that, is that essential these days? >>Well, good question John. I would say yes. And this is often built in house, as I mentioned, for large companies, they do build some type of data access layer or proxy and, or some utilize some orm, some object relational map to do it. And what again, what we're trying to do is offer this, put this out into the market commercially speaking, such that it can be readily used for, for all the customers to use rather than building it from scratch all the time. >>You know what I didn't ask you was Roy, how does AWS come into play for you then? And, and as in the startup mode, the focus that they've had in startups in general, but in you in particular, I mean, talk about that partnership or that relationship and the value that you're extracting from that. >>The ad AWS partnership has been absolutely wonderful. The collaboration, they have one of the best managed service databases. The value that it that adds in terms of the durability, the manageability, what the Heim doll data does is it compliments Amazon rds, Amazon Redshift very well in the sense that we're not replacing the database. What we're doing is we are allowing the customer to get the most out of the managed service database, whether it be Redshift or Aurora Serverless, rds, all without code changes. And or the analogy that I would give John is a car, a race car may be very fast, but it takes a driver to get to those fast speeds. We're the driver, the Hyundai proxy provides that intelligence so that you can get the most out of that database engine. >>And, and Hfi would then touch on, first off AWS and the emphasis that you have put on startups and are obviously, you know, kind of putting your money where your mouth is, right? With, with the way you've encouraged and nurtured that environment. And they would be about Heim doll in general about where you see this going or what you would like to have, where you want to take this in the next say 12 months, 18 months. >>I think it's more of a better together story of how we can basically coil with our partners, right? And, and basically focusing on helping our customers drive that innovation and be collaboration. So as Heim, as a independent service vendor isv, most customers can leverage that through a marketplace where basically it integrates very nicely with aws. So that gives 'em that lift and it goes back to the undifferentiated heavy lifting on the Hein proxy side, if you will, because then you have this proxy in the middle where then it helps them with their SQL performance. And I've seen use cases where customers were, have some legacy system that they may not have time to modernize the application. So they use this as a lift to keep, keep going as they try to modernize. But also I've seen customers who use are trying to use it as a, a way to give that performance lift because they may have a third party software that they cannot change the code by putting this in there that helps optimize their lines of business or whatever that is, and maybe can be online store or whatever. So I would say it was a better together type of story. >>Yeah. Which is, there's gotta be a song in there somewhere. So peek around the corner and if you wanna be headlights here right now in terms of 12, 18 months, I mean, what, you know, what what next to solve, right? You've already taken, you've slayed a few dragons along the way, but there are others I'm sure is it always happens in innovation in this space. Just when you solve a problem you've just dealt or you have to deal with others that pop up as maybe unintended consequences or at least a new challenge. So what would that be in your world right now? What, what do you see, you know, occupying your sleepless nights here for the next year or so? >>Well, for, for HOMEDALE data, it's all about improving database performance and scale. And those workloads change. We have O ltp, we have OLA with artificial intelligence ml. There's different type of traffic profiles and we're focused on improving those data profiles. It could be unstructured structured. Right now we're focused on structured data, which is relational databases, but there's a lot of opportunity to improve the performance of data. >>Well, you're driving the car, you got a good navigator. I think the GPS is working. So keep up the good work and thank you for sharing the time today. Thank you. Thank you, joy. Do appreciate it. All right, you are watching the cube. We continue our coverage here from AWS Reinvent 22, the Cube, of course, the leader in high tech coverage.

>>Hey everyone. Welcome to Las Vegas. The Cube is here, live at the Venetian Expo Center for AWS Reinvent 2022. Amazing attendance. This is day one of our coverage. Lisa Martin here with Day Ante. David is great to see so many people back. We're gonna be talk, we've been having great conversations already. We have a wall to wall coverage for the next three and a half days. When we talk to companies, customers, every company has to be a data company. And one of the things I think we learned in the pandemic is that access to real time data and real time analytics, no longer a nice to have that is a differentiator and a competitive all >>About data. I mean, you know, I love the topic and it's, it's got so many dimensions and such texture, can't get enough of data. >>I know we have a great guest joining us. One of our alumni is back, Evan Kaplan, the CEO of Influx Data. Evan, thank you so much for joining us. Welcome back to the Cube. >>Thanks for having me. It's great to be here. So here >>We are, day one. I was telling you before we went live, we're nice and fresh hosts. Talk to us about what's new at Influxed since the last time we saw you at Reinvent. >>That's great. So first of all, we should acknowledge what's going on here. This is pretty exciting. Yeah, that does really feel like, I know there was a show last year, but this feels like the first post Covid shows a lot of energy, a lot of attention despite a difficult economy. In terms of, you know, you guys were commenting in the lead into Big data. I think, you know, if we were to talk about Big Data five, six years ago, what would we be talking about? We'd been talking about Hadoop, we were talking about Cloudera, we were talking about Hortonworks, we were talking about Big Data Lakes, data stores. I think what's happened is, is this this interesting dynamic of, let's call it if you will, the, the secularization of data in which it breaks into different fields, different, almost a taxonomy. You've got this set of search data, you've got this observability data, you've got graph data, you've got document data and what you're seeing in the market and now you have time series data. >>And what you're seeing in the market is this incredible capability by developers as well and mostly open source dynamic driving this, this incredible capability of developers to assemble data platforms that aren't unicellular, that aren't just built on Hado or Oracle or Postgres or MySQL, but in fact represent different data types. So for us, what we care about his time series, we care about anything that happens in time, where time can be the primary measurement, which if you think about it, is a huge proportion of real data. Cuz when you think about what drives ai, you think about what happened, what happened, what happened, what happened, what's going to happen. That's the functional thing. But what happened is always defined by a period, a measurement, a time. And so what's new for us is we've developed this new open source engine called IOx. And so it's basically a refresh of the whole database, a kilo database that uses Apache Arrow, par K and data fusion and turns it into a super powerful real time analytics platform. It was already pretty real time before, but it's increasingly now and it adds SQL capability and infinite cardinality. And so it handles bigger data sets, but importantly, not just bigger but faster, faster data. So that's primarily what we're talking about to show. >>So how does that affect where you can play in the marketplace? Is it, I mean, how does it affect your total available market? Your great question. Your, your customer opportunities. >>I think it's, it's really an interesting market in that you've got all of these different approaches to database. Whether you take data warehouses from Snowflake or, or arguably data bricks also. And you take these individual database companies like Mongo Influx, Neo Forge, elastic, and people like that. I think the commonality you see across the volume is, is many of 'em, if not all of them, are based on some sort of open source dynamic. So I think that is an in an untractable trend that will continue for on. But in terms of the broader, the broader database market, our total expand, total available tam, lots of these things are coming together in interesting ways. And so the, the, the wave that will ride that we wanna ride, because it's all big data and it's all increasingly fast data and it's all machine learning and AI is really around that measurement issue. That instrumentation the idea that if you're gonna build any sophisticated system, it starts with instrumentation and the journey is defined by instrumentation. So we view ourselves as that instrumentation tooling for understanding complex systems. And how, >>I have to follow quick follow up. Why did you say arguably data bricks? I mean open source ethos? >>Well, I was saying arguably data bricks cuz Spark, I mean it's a great company and it's based on Spark, but there's quite a gap between Spark and what Data Bricks is today. And in some ways data bricks from the outside looking in looks a lot like Snowflake to me looks a lot like a really sophisticated data warehouse with a lot of post-processing capabilities >>And, and with an open source less >>Than a >>Core database. Yeah. Right, right, right. Yeah, I totally agree. Okay, thank you for that >>Part that that was not arguably like they're, they're not a good company or >>No, no. They got great momentum and I'm just curious. Absolutely. You know, so, >>So talk a little bit about IOx and, and what it is enabling you guys to achieve from a competitive advantage perspective. The key differentiators give us that scoop. >>So if you think about, so our old storage engine was called tsm, also open sourced, right? And IOx is open sourced and the old storage engine was really built around this time series measurements, particularly metrics, lots of metrics and handling those at scale and making it super easy for developers to use. But, but our old data engine only supported either a custom graphical UI that you'd build yourself on top of it or a dashboarding tool like Grafana or Chronograph or things like that. With IOCs. Two or three interventions were important. One is we now support, we'll support things like Tableau, Microsoft, bi, and so you're taking that same data that was available for instrumentation and now you're using it for business intelligence also. So that became super important and it kind of answers your question about the expanded market expands the market. The second thing is, when you're dealing with time series data, you're dealing with this concept of cardinality, which is, and I don't know if you're familiar with it, but the idea that that it's a multiplication of measurements in a table. And so the more measurements you want over the more series you have, you have this really expanding exponential set that can choke a database off. And the way we've designed IIS to handle what we call infinite cardinality, where you don't even have to think about that design point of view. And then lastly, it's just query performance is dramatically better. And so it's pretty exciting. >>So the unlimited cardinality, basically you could identify relationships between data and different databases. Is that right? Between >>The same database but different measurements, different tables, yeah. Yeah. Right. Yeah, yeah. So you can handle, so you could say, I wanna look at the way, the way the noise levels are performed in this room according to 400 different locations on 25 different days, over seven months of the year. And that each one is a measurement. Each one adds to cardinality. And you can say, I wanna search on Tuesdays in December, what the noise level is at 2:21 PM and you get a very quick response. That kind of instrumentation is critical to smarter systems. How are >>You able to process that data at at, in a performance level that doesn't bring the database to its knees? What's the secret sauce behind that? >>It's AUM database. It's built on Parque and Apache Arrow. But it's, but to say it's nice to say without a much longer conversation, it's an architecture that's really built for pulling that kind of data. If you know the data is time series and you're looking for a time measurement, you already have the ability to optimize pretty dramatically. >>So it's, it's that purpose built aspect of it. It's the >>Purpose built aspect. You couldn't take Postgres and do the same >>Thing. Right? Because a lot of vendors say, oh yeah, we have time series now. Yeah. Right. So yeah. Yeah. Right. >>And they >>Do. Yeah. But >>It's not, it's not, the founding of the company came because Paul Dicks was working on Wall Street building time series databases on H base, on MyQ, on other platforms and realize every time we do it, we have to rewrite the code. We build a bunch of application logic to handle all these. We're talking about, we have customers that are adding hundreds of millions to billions of points a second. So you're talking about an ingest level. You know, you think about all those data points, you're talking about ingest level that just doesn't, you know, it just databases aren't designed for that. Right? And so it's not just us, our competitors also build good time series databases. And so the category is really emergent. Yeah, >>Sure. Talk about a favorite customer story they think really articulates the value of what Influx is doing, especially with IOx. >>Yeah, sure. And I love this, I love this story because you know, Tesla may not be in favor because of the latest Elon Musker aids, but, but, but so we've had about a four year relationship with Tesla where they built their power wall technology around recording that, seeing your device, seeing the stuff, seeing the charging on your car. It's all captured in influx databases that are reporting from power walls and mega power packs all over the world. And they report to a central place at, at, at Tesla's headquarters and it reports out to your phone and so you can see it. And what's really cool about this to me is I've got two Tesla cars and I've got a Tesla solar roof tiles. So I watch this date all the time. So it's a great customer story. And actually if you go on our website, you can see I did an hour interview with the engineer that designed the system cuz the system is super impressive and I just think it's really cool. Plus it's, you know, it's all the good green stuff that we really appreciate supporting sustainability, right? Yeah. >>Right, right. Talk about from a, what's in it for me as a customer, what you guys have done, the change to IOCs, what, what are some of the key features of it and the key values in it for customers like Tesla, like other industry customers as well? >>Well, so it's relatively new. It just arrived in our cloud product. So Tesla's not using it today. We have a first set of customers starting to use it. We, the, it's in open source. So it's a very popular project in the open source world. But the key issues are, are really the stuff that we've kind of covered here, which is that a broad SQL environment. So accessing all those SQL developers, the same people who code against Snowflake's data warehouse or data bricks or Postgres, can now can code that data against influx, open up the BI market. It's the cardinality, it's the performance. It's really an architecture. It's the next gen. We've been doing this for six years, it's the next generation of everything. We've seen how you make time series be super performing. And that's only relevant because more and more things are becoming real time as we develop smarter and smarter systems. The journey is pretty clear. You instrument the system, you, you let it run, you watch for anomalies, you correct those anomalies, you re instrument the system. You do that 4 billion times, you have a self-driving car, you do that 55 times, you have a better podcast that is, that is handling its audio better, right? So everything is on that journey of getting smarter and smarter. So >>You guys, you guys the big committers to IOCs, right? Yes. And how, talk about how you support the, develop the surrounding developer community, how you get that flywheel effect going >>First. I mean it's actually actually a really kind of, let's call it, it's more art than science. Yeah. First of all, you you, you come up with an architecture that really resonates for developers. And Paul Ds our founder, really is a developer's developer. And so he started talking about this in the community about an architecture that uses Apache Arrow Parque, which is, you know, the standard now becoming for file formats that uses Apache Arrow for directing queries and things like that and uses data fusion and said what this thing needs is a Columbia database that sits behind all of this stuff and integrates it. And he started talking about it two years ago and then he started publishing in IOCs that commits in the, in GitHub commits. And slowly, but over time in Hacker News and other, and other people go, oh yeah, this is fundamentally right. >>It addresses the problems that people have with things like click cows or plain databases or Coast and they go, okay, this is the right architecture at the right time. Not different than original influx, not different than what Elastic hit on, not different than what Confluent with Kafka hit on and their time is you build an audience of people who are committed to understanding this kind of stuff and they become committers and they become the core. Yeah. And you build out from it. And so super. And so we chose to have an MIT open source license. Yeah. It's not some secondary license competitors can use it and, and competitors can use it against us. Yeah. >>One of the things I know that Influx data talks about is the time to awesome, which I love that, but what does that mean? What is the time to Awesome. Yeah. For developer, >>It comes from that original story where, where Paul would have to write six months of application logic and stuff to build a time series based applications. And so Paul's notion was, and this was based on the original Mongo, which was very successful because it was very easy to use relative to most databases. So Paul developed this commitment, this idea that I quickly joined on, which was, hey, it should be relatively quickly for a developer to build something of import to solve a problem, it should be able to happen very quickly. So it's got a schemaless background so you don't have to know the schema beforehand. It does some things that make it really easy to feel powerful as a developer quickly. And if you think about that journey, if you feel powerful with a tool quickly, then you'll go deeper and deeper and deeper and pretty soon you're taking that tool with you wherever you go, it becomes the tool of choice as you go to that next job or you go to that next application. And so that's a fundamental way we think about it. To be honest with you, we haven't always delivered perfectly on that. It's generally in our dna. So we do pretty well, but I always feel like we can do better. >>So if you were to put a bumper sticker on one of your Teslas about influx data, what would it >>Say? By the way, I'm not rich. It just happened to be that we have two Teslas and we have for a while, we just committed to that. The, the, so ask the question again. Sorry. >>Bumper sticker on influx data. What would it say? How, how would I >>Understand it be time to Awesome. It would be that that phrase his time to Awesome. Right. >>Love that. >>Yeah, I'd love it. >>Excellent time to. Awesome. Evan, thank you so much for joining David, the >>Program. It's really fun. Great thing >>On Evan. Great to, you're on. Haven't Well, great to have you back talking about what you guys are doing and helping organizations like Tesla and others really transform their businesses, which is all about business transformation these days. We appreciate your insights. >>That's great. Thank >>You for our guest and Dave Ante. I'm Lisa Martin, you're watching The Cube, the leader in emerging and enterprise tech coverage. We'll be right back with our next guest.

(soft electronic music) >> Okay, we're back with Tim Yocum who is the Director of Engineering at InfluxData. Tim, welcome, good to see you. >> Good to see you, thanks for having me. >> You're really welcome. Listen, we've been covering opensource software on theCUBE for more than a decade and we've kind of watched the innovation from the big data ecosystem, the cloud is being built out on opensource, mobile, social platforms, key databases, and of course, InfluxDB. And InfluxData has been a big consumer and crontributor of opensource software. So my question to you is where have you seen the biggest bang for the buck from opensource software? >> So yeah, you know, Influx really, we thrive at the intersection of commercial services and opensource software, so OSS keeps us on the cutting edge. We benefit from OSS in delivering our own service from our core storage engine technologies to web services, templating engines. Our team stays lean and focused because we build on proven tools. We really build on the shoulders of giants. And like you've mentioned, even better, we contribute a lot back to the projects that we use, as well as our own product InfluxDB. >> But I got to ask you, Tim, because one of the challenge that we've seen, in particular, you saw this in the heyday of Hadoop, the innovations come so fast and furious, and as a software company, you got to place bets, you got to commit people, and sometimes those bets can be risky and not pay off. So how have you managed this challenge? >> Oh, it moves fast, yeah. That's a benefit, though, because the community moves so quickly that today's hot technology can be tomorrow's dinosaur. And what we tend to do is we fail fast and fail often; we try a lot of things. You know, you look at Kubernetes, for example. That ecosystem is driven by thousands of intelligent developers, engineers, builders. They're adding value every day, so we have to really keep up with that. And as the stack changes, we try different technologies, we try different methods. And at the end of the day, we come up with a better platform as a result of just the constant change in the environment. It is a challenge for us, but it's something that we just do every day. >> So we have a survey partner down in New York City called Enterprise Technology Research, ETR, and they do these quarterly surveys of about 1500 CIOs, IT practitioners, and they really have a good pulse on what's happening with spending. And the data shows that containers generally, but specifically Kubernetes, is one of the areas that is kind of, it's been off the charts and seen the most significant adoption and velocity particularly along with cloud, but really, Kubernetes is just, you know, still up and to the right consistently, even with the macro headwinds and all of the other stuff that we're sick of talking about. So what do you do with Kubernetes in the platform? >> Yeah, it's really central to our ability to run the product. When we first started out, we were just on AWS and the way we were running was a little bit like containers junior. Now we're running Kubernetes everywhere at AWS, Azure, Google cloud. It allows us to have a consistent experience across three different cloud providers and we can manage that in code. So our developers can focus on delivering services not trying to learn the intricacies of Amazon, Azure, and Google, and figure out how to deliver services on those three clouds with all of their differences. >> Just a followup on that, is it now, so I presume it sounds like there's a PaaS layer there to allow you guys to have a consistent experience across clouds and out to the edge, wherever. Is that correct? >> Yeah, so we've basically built more or less platform engineering is this the new, hot phrase. Kubernetes has made a lot of things easy for us because we've built a platform that our developers can lean on and they only have to learn one way of deploying their application, managing their application. And so that just gets all of the underlying infrastructure out of the way and lets them focus on delivering Influx cloud. >> And I know I'm taking a little bit of a tangent, but is that, I'll call it a PaaS layer, if I can use that term, are there specific attributes to InfluxDB or is it kind of just generally off-the-shelf PaaS? Is there any purpose built capability there that is value-add or is it pretty much generic? >> So we really build, we look at things with a build versus buy, through a build versus buy lens. Some things we want to leverage, cloud provider services, for instance, POSTGRES databases for metadata, perhaps. Get that off of our plate, let someone else run that. We're going to deploy a platform that our engineers can deliver on, that has consistency, that is all generated from code. that we can, as an SRE group, as an OPS team, that we can manage with very few people, really, and we can stamp out clusters across multiple regions in no time. >> So sometimes you build, sometimes you buy it. How do you make those decisions and what does that mean for the platform and for customers? >> Yeah, so what we're doing is, it's like everybody else will do. We're looking for trade-offs that make sense. We really want to protect our customers' data, so we look for services that support our own software with the most up-time reliability and durability we can get. Some things are just going to be easier to have a cloud provider take care of on our behalf. We make that transparent for our own team and of course, for our customers; you don't even see that. But we don't want to try to reinvent the wheel, like I had mentioned with SQL datasource for metadata, perhaps. Let's build on top of what of these three large cloud providers have already perfected and we can then focus on our platform engineering and we can help our developers then focus on the InfluxData software, the Influx cloud software. >> So take it to the customer level. What does it mean for them, what's the value that they're going to get out of all these innovations that we've been talking about today, and what can they expect in the future? >> So first of all, people who use the OSS product are really going to be at home on our cloud platform. You can run it on your desktop machine, on a single server, what have you, but then you want to scale up. We have some 270 terabytes of data across over four billion series keys that people have stored, so there's a proven ability to scale. Now in terms of the opensource software and how we've developed the platform, you're getting highly available, high cardinality time-series platform. We manage it and really, as I had mentioned earlier, we can keep up with the state of the art. We keep reinventing, we keep deploying things in realtime. We deploy to our platform every day, repeatedly, all the time. And it's that continuous deployment that allow us to continue testing things in flight, rolling things out that change, new features, better ways of doing deployments, safer ways of doing deployments. All of that happens behind the scenes and like we had mentioned earllier, Kubernetes, I mean, that allows us to get that done. We couldn't do it without having that platform as a base layer for us to then put our software on. So we iterate quickly. When you're on the Influx cloud platform, you really are able to take advantage of new features immediately. We roll things out every day and as those things go into production, you have the ability to use them. And so in the then, we want you to focus on getting actual insights from your data instead of running infrastructure, you know, let us do that for you. >> That makes sense. Are the innovations that we're talking about in the evolution of InfluxDB, do you see that as sort of a natural evolution for existing customers? Is it, I'm sure the answer is both, but is it opening up new territory for customers? Can you add some color to that? >> Yeah, it really is. It's a little bit of both. Any engineer will say, "Well it depends." So cloud-native technologies are really the hot thing, IoT, industrial IoT especially. People want to just shove tons of data out there and be able to do queries immediately and they don't want to manage infrastructure. What we've started to see are people that use the cloud service as their datastore backbone and then they use edge computing with our OSS product to ingest data from say, multiple production lines, and down-sample that data, send the rest of that data off to Influx cloud where the heavy processing takes place. So really, us being in all the different clouds and iterating on that, and being in all sorts of different regions, allows for people to really get out of the business of trying to manage that big data, have us take care of that. And, of course, as we change the platform, endusers benefit from that immediately. >> And so obviously you've taken away a lot of the heavy lifting for the infrastructure. Would you say the same things about security, especially as you go out to IoT at the edge? How should we be thinking about the value that you bring from a security perspective? >> We take security super seriously. It's built into our DNA. We do a lot of work to ensure that our platform is secure, that the data that we store is kept private. It's, of course, always a concern, you see in the news all the time, companies being compromised. That's something that you can have an entire team working on which we do, to make sure that the data that you have, whether it's in transit, whether it's at rest is always kept secure, is only viewable by you. You look at things like software bill of materials, if you're running this yourself, you have to go vet all sorts of different pieces of software and we do that, you know, as we use new tools. That's something, that's just part of our jobs to make sure that the platform that we're running has fully vetted software. And you know, with opensource especially, that's a lot of work, and so it's definitely new territory. Supply chain attacks are definitely happening at a higher clip that they used to but that is really just part of a day in the life for folks like us that are building platforms. >> And that's key, especially when you start getting into the, you know, that we talk about IoT and the operations technologies, the engineers running that infrastrucutre. You know, historically, as you know, Tim, they would air gap everything; that's how they kept it safe. But that's not feasible anymore. Everything's-- >> Can't do that. >> connected now, right? And so you've got to have a partner that is, again, take away that heavy lifting to R&D so you can focus on some of the other activities. All right, give us the last word and the key takeaways from your perspective. >> Well, you know, from my perspective, I see it as a two-lane approach, with Influx, with any time-series data. You've got a lot of stuff that you're going to run on-prem. What you had mentioned, air gapping? Sure, there's plenty of need for that. But at the end of the day, people that don't want to run big datacenters, people that want to entrust their data to a company that's got a full platform set up for them that they can build on, send that data over to the cloud. The cloud is not going away. I think a more hybrid approach is where the future lives and that's what we're prepared for. >> Tim, really appreciate you coming to the program. Great stuff, good to see you. >> Thanks very much, appreciate it. >> Okay in a moment, I'll be back to wrap up today's session. You're watching theCUBE. (soft electronic music)

>>This past May, The Cube in collaboration with Influx data shared with you the latest innovations in Time series databases. We talked at length about why a purpose built time series database for many use cases, was a superior alternative to general purpose databases trying to do the same thing. Now, you may, you may remember the time series data is any data that's stamped in time, and if it's stamped, it can be analyzed historically. And when we introduced the concept to the community, we talked about how in theory, those time slices could be taken, you know, every hour, every minute, every second, you know, down to the millisecond and how the world was moving toward realtime or near realtime data analysis to support physical infrastructure like sensors and other devices and IOT equipment. A time series databases have had to evolve to efficiently support realtime data in emerging use cases in iot T and other use cases. >>And to do that, new architectural innovations have to be brought to bear. As is often the case, open source software is the linchpin to those innovations. Hello and welcome to Evolving Influx DB into the smart Data platform, made possible by influx data and produced by the Cube. My name is Dave Valante and I'll be your host today. Now in this program we're going to dig pretty deep into what's happening with Time series data generally, and specifically how Influx DB is evolving to support new workloads and demands and data, and specifically around data analytics use cases in real time. Now, first we're gonna hear from Brian Gilmore, who is the director of IOT and emerging technologies at Influx Data. And we're gonna talk about the continued evolution of Influx DB and the new capabilities enabled by open source generally and specific tools. And in this program you're gonna hear a lot about things like Rust, implementation of Apache Arrow, the use of par k and tooling such as data fusion, which powering a new engine for Influx db. >>Now, these innovations, they evolve the idea of time series analysis by dramatically increasing the granularity of time series data by compressing the historical time slices, if you will, from, for example, minutes down to milliseconds. And at the same time, enabling real time analytics with an architecture that can process data much faster and much more efficiently. Now, after Brian, we're gonna hear from Anna East Dos Georgio, who is a developer advocate at In Flux Data. And we're gonna get into the why of these open source capabilities and how they contribute to the evolution of the Influx DB platform. And then we're gonna close the program with Tim Yokum, he's the director of engineering at Influx Data, and he's gonna explain how the Influx DB community actually evolved the data engine in mid-flight and which decisions went into the innovations that are coming to the market. Thank you for being here. We hope you enjoy the program. Let's get started. Okay, we're kicking things off with Brian Gilmore. He's the director of i t and emerging Technology at Influx State of Bryan. Welcome to the program. Thanks for coming on. >>Thanks Dave. Great to be here. I appreciate the time. >>Hey, explain why Influx db, you know, needs a new engine. Was there something wrong with the current engine? What's going on there? >>No, no, not at all. I mean, I think it's, for us, it's been about staying ahead of the market. I think, you know, if we think about what our customers are coming to us sort of with now, you know, related to requests like sql, you know, query support, things like that, we have to figure out a way to, to execute those for them in a way that will scale long term. And then we also, we wanna make sure we're innovating, we're sort of staying ahead of the market as well and sort of anticipating those future needs. So, you know, this is really a, a transparent change for our customers. I mean, I think we'll be adding new capabilities over time that sort of leverage this new engine, but you know, initially the customers who are using us are gonna see just great improvements in performance, you know, especially those that are working at the top end of the, of the workload scale, you know, the massive data volumes and things like that. >>Yeah, and we're gonna get into that today and the architecture and the like, but what was the catalyst for the enhancements? I mean, when and how did this all come about? >>Well, I mean, like three years ago we were primarily on premises, right? I mean, I think we had our open source, we had an enterprise product, you know, and, and sort of shifting that technology, especially the open source code base to a service basis where we were hosting it through, you know, multiple cloud providers. That was, that was, that was a long journey I guess, you know, phase one was, you know, we wanted to host enterprise for our customers, so we sort of created a service that we just managed and ran our enterprise product for them. You know, phase two of this cloud effort was to, to optimize for like multi-tenant, multi-cloud, be able to, to host it in a truly like sass manner where we could use, you know, some type of customer activity or consumption as the, the pricing vector, you know, And, and that was sort of the birth of the, of the real first influx DB cloud, you know, which has been really successful. >>We've seen, I think like 60,000 people sign up and we've got tons and tons of, of both enterprises as well as like new companies, developers, and of course a lot of home hobbyists and enthusiasts who are using out on a, on a daily basis, you know, and having that sort of big pool of, of very diverse and very customers to chat with as they're using the product, as they're giving us feedback, et cetera, has has, you know, pointed us in a really good direction in terms of making sure we're continuously improving that and then also making these big leaps as we're doing with this, with this new engine. >>Right. So you've called it a transparent change for customers, so I'm presuming it's non-disruptive, but I really wanna understand how much of a pivot this is and what, what does it take to make that shift from, you know, time series, you know, specialist to real time analytics and being able to support both? >>Yeah, I mean, it's much more of an evolution, I think, than like a shift or a pivot. You know, time series data is always gonna be fundamental and sort of the basis of the solutions that we offer our customers, and then also the ones that they're building on the sort of raw APIs of our platform themselves. You know, the time series market is one that we've worked diligently to lead. I mean, I think when it comes to like metrics, especially like sensor data and app and infrastructure metrics, if we're being honest though, I think our, our user base is well aware that the way we were architected was much more towards those sort of like backwards looking historical type analytics, which are key for troubleshooting and making sure you don't, you know, run into the same problem twice. But, you know, we had to ask ourselves like, what can we do to like better handle those queries from a performance and a, and a, you know, a time to response on the queries, and can we get that to the point where the results sets are coming back so quickly from the time of query that we can like limit that window down to minutes and then seconds. >>And now with this new engine, we're really starting to talk about a query window that could be like returning results in, in, you know, milliseconds of time since it hit the, the, the ingest queue. And that's, that's really getting to the point where as your data is available, you can use it and you can query it, you can visualize it, and you can do all those sort of magical things with it, you know? And I think getting all of that to a place where we're saying like, yes to the customer on, you know, all of the, the real time queries, the, the multiple language query support, but, you know, it was hard, but we're now at a spot where we can start introducing that to, you know, a a limited number of customers, strategic customers and strategic availability zones to start. But you know, everybody over time. >>So you're basically going from what happened to in, you can still do that obviously, but to what's happening now in the moment? >>Yeah, yeah. I mean if you think about time, it's always sort of past, right? I mean, like in the moment right now, whether you're talking about like a millisecond ago or a minute ago, you know, that's, that's pretty much right now, I think for most people, especially in these use cases where you have other sort of components of latency induced by the, by the underlying data collection, the architecture, the infrastructure, the, you know, the, the devices and you know, the sort of highly distributed nature of all of this. So yeah, I mean, getting, getting a customer or a user to be able to use the data as soon as it is available is what we're after here. >>I always thought, you know, real, I always thought of real time as before you lose the customer, but now in this context, maybe it's before the machine blows up. >>Yeah, it's, it's, I mean it is operationally or operational real time is different, you know, and that's one of the things that really triggered us to know that we were, we were heading in the right direction, is just how many sort of operational customers we have. You know, everything from like aerospace and defense. We've got companies monitoring satellites, we've got tons of industrial users, users using us as a processes storing on the plant floor, you know, and, and if we can satisfy their sort of demands for like real time historical perspective, that's awesome. I think what we're gonna do here is we're gonna start to like edge into the real time that they're used to in terms of, you know, the millisecond response times that they expect of their control systems, certainly not their, their historians and databases. >>I, is this available, these innovations to influx DB cloud customers only who can access this capability? >>Yeah. I mean commercially and today, yes. You know, I think we want to emphasize that's a, for now our goal is to get our latest and greatest and our best to everybody over time. Of course. You know, one of the things we had to do here was like we double down on sort of our, our commitment to open source and availability. So like anybody today can take a look at the, the libraries in on our GitHub and, you know, can ex inspect it and even can try to, you know, implement or execute some of it themselves in their own infrastructure. You know, we are, we're committed to bringing our sort of latest and greatest to our cloud customers first for a couple of reasons. Number one, you know, there are big workloads and they have high expectations of us. I think number two, it also gives us the opportunity to monitor a little bit more closely how it's working, how they're using it, like how the system itself is performing. >>And so just, you know, being careful, maybe a little cautious in terms of, of, of how big we go with this right away, just sort of both limits, you know, the risk of, of, you know, any issues that can come with new software rollouts. We haven't seen anything so far, but also it does give us the opportunity to have like meaningful conversations with a small group of users who are using the products, but once we get through that and they give us two thumbs up on it, it'll be like, open the gates and let everybody in. It's gonna be exciting time for the whole ecosystem. >>Yeah, that makes a lot of sense. And you can do some experimentation and, you know, using the cloud resources. Let's dig into some of the architectural and technical innovations that are gonna help deliver on this vision. What, what should we know there? >>Well, I mean, I think foundationally we built the, the new core on Rust. You know, this is a new very sort of popular systems language, you know, it's extremely efficient, but it's also built for speed and memory safety, which goes back to that us being able to like deliver it in a way that is, you know, something we can inspect very closely, but then also rely on the fact that it's going to behave well. And if it does find error conditions, I mean we, we've loved working with Go and, you know, a lot of our libraries will continue to, to be sort of implemented in Go, but you know, when it came to this particular new engine, you know, that power performance and stability rust was critical. On top of that, like, we've also integrated Apache Arrow and Apache Parque for persistence. I think for anybody who's really familiar with the nuts and bolts of our backend and our TSI and our, our time series merged Trees, this is a big break from that, you know, arrow on the sort of in MI side and then Par K in the on disk side. >>It, it allows us to, to present, you know, a unified set of APIs for those really fast real time inquiries that we talked about, as well as for very large, you know, historical sort of bulk data archives in that PARQUE format, which is also cool because there's an entire ecosystem sort of popping up around Parque in terms of the machine learning community, you know, and getting that all to work, we had to glue it together with aero flight. That's sort of what we're using as our, our RPC component. You know, it handles the orchestration and the, the transportation of the Coer data. Now we're moving to like a true Coer database model for this, this version of the engine, you know, and it removes a lot of overhead for us in terms of having to manage all that serialization, the deserialization, and, you know, to that again, like blurring that line between real time and historical data. It's, you know, it's, it's highly optimized for both streaming micro batch and then batches, but true streaming as well. >>Yeah. Again, I mean, it's funny you mentioned Rust. It is, it's been around for a long time, but it's popularity is, is you know, really starting to hit that steep part of the S-curve. And, and we're gonna dig into to more of that, but give us any, is there anything else that we should know about Bryan? Give us the last word? >>Well, I mean, I think first I'd like everybody sort of watching just to like take a look at what we're offering in terms of early access in beta programs. I mean, if, if, if you wanna participate or if you wanna work sort of in terms of early access with the, with the new engine, please reach out to the team. I'm sure you know, there's a lot of communications going out and you know, it'll be highly featured on our, our website, you know, but reach out to the team, believe it or not, like we have a lot more going on than just the new engine. And so there are also other programs, things we're, we're offering to customers in terms of the user interface, data collection and things like that. And, you know, if you're a customer of ours and you have a sales team, a commercial team that you work with, you can reach out to them and see what you can get access to because we can flip a lot of stuff on, especially in cloud through feature flags. >>But if there's something new that you wanna try out, we'd just love to hear from you. And then, you know, our goal would be that as we give you access to all of these new cool features that, you know, you would give us continuous feedback on these products and services, not only like what you need today, but then what you'll need tomorrow to, to sort of build the next versions of your business. Because you know, the whole database, the ecosystem as it expands out into to, you know, this vertically oriented stack of cloud services and enterprise databases and edge databases, you know, it's gonna be what we all make it together, not just, you know, those of us who were employed by Influx db. And then finally I would just say please, like watch in ICE in Tim's sessions, like these are two of our best and brightest, They're totally brilliant, completely pragmatic, and they are most of all customer obsessed, which is amazing. And there's no better takes, like honestly on the, the sort of technical details of this, then there's, especially when it comes to like the value that these investments will, will bring to our customers and our communities. So encourage you to, to, you know, pay more attention to them than you did to me, for sure. >>Brian Gilmore, great stuff. Really appreciate your time. Thank you. >>Yeah, thanks Dave. It was awesome. Look forward to it. >>Yeah, me too. Looking forward to see how the, the community actually applies these new innovations and goes, goes beyond just the historical into the real time really hot area. As Brian said in a moment, I'll be right back with Anna East dos Georgio to dig into the critical aspects of key open source components of the Influx DB engine, including Rust, Arrow, Parque, data fusion. Keep it right there. You don't wanna miss this >>Time series Data is everywhere. The number of sensors, systems and applications generating time series data increases every day. All these data sources producing so much data can cause analysis paralysis. Influx DB is an entire platform designed with everything you need to quickly build applications that generate value from time series data influx. DB Cloud is a serverless solution, which means you don't need to buy or manage your own servers. There's no need to worry about provisioning because you only pay for what you use. Influx DB Cloud is fully managed so you get the newest features and enhancements as they're added to the platform's code base. It also means you can spend time building solutions and delivering value to your users instead of wasting time and effort managing something else. Influx TVB Cloud offers a range of security features to protect your data, multiple layers of redundancy ensure you don't lose any data access controls ensure that only the people who should see your data can see it. >>And encryption protects your data at rest and in transit between any of our regions or cloud providers. InfluxDB uses a single API across the entire platform suite so you can build on open source, deploy to the cloud and then then easily query data in the cloud at the edge or on prem using the same scripts. And InfluxDB is schemaless automatically adjusting to changes in the shape of your data without requiring changes in your application. Logic. InfluxDB Cloud is production ready from day one. All it needs is your data and your imagination. Get started today@influxdata.com slash cloud. >>Okay, we're back. I'm Dave Valante with a Cube and you're watching evolving Influx DB into the smart data platform made possible by influx data. Anna ETOs Georgio is here, she's a developer advocate for influx data and we're gonna dig into the rationale and value contribution behind several open source technologies that Influx DB is leveraging to increase the granularity of time series analysis analysis and bring the world of data into real-time analytics and is welcome to the program. Thanks for coming on. >>Hi, thank you so much. It's a pleasure to be here. >>Oh, you're very welcome. Okay, so IX is being touted as this next gen open source core for Influx db. And my understanding is that it leverages in memory of course for speed. It's a kilo store, so it gives you a compression efficiency, it's gonna give you faster query speeds, you store files and object storage, so you got very cost effective approach. Are these the salient points on the platform? I know there are probably dozens of other features, but what are the high level value points that people should understand? >>Sure, that's a great question. So some of the main requirements that IOx is trying to achieve and some of the most impressive ones to me, the first one is that it aims to have no limits on cardinality and also allow you to write any kind of event data that you want, whether that's live tag or a field. It also wants to deliver the best in class performance on analytics queries. In addition to our already well served metrics queries, we also wanna have operator control over memory usage. So you should be able to define how much memory is used for buffering caching and query processing. Some other really important parts is the ability to have bulk data export and import super useful. Also broader ecosystem compatibility where possible we aim to use and embrace emerging standards in the data analytics ecosystem and have compatibility with things like sql, Python, and maybe even pandas in the future. >>Okay, so lot there. Now we talked to Brian about how you're using Rust and which is not a new programming language and of course we had some drama around Rust during the pandemic with the Mozilla layoffs, but the formation of the Rust Foundation really addressed any of those concerns. You got big guns like Amazon and Google and Microsoft throwing their collective weights behind it. It's really, the adoption is really starting to get steep on the S-curve. So lots of platforms, lots of adoption with rust, but why rust as an alternative to say c plus plus for example? >>Sure, that's a great question. So Russ was chosen because of his exceptional performance and reliability. So while Russ is synt tactically similar to c plus plus and it has similar performance, it also compiles to a native code like c plus plus. But unlike c plus plus, it also has much better memory safety. So memory safety is protection against bugs or security vulnerabilities that lead to excessive memory usage or memory leaks. And rust achieves this memory safety due to its like innovative type system. Additionally, it doesn't allow for dangling pointers. And dangling pointers are the main classes of errors that lead to exploitable security vulnerabilities in languages like c plus plus. So Russ like helps meet that requirement of having no limits on ality, for example, because it's, we're also using the Russ implementation of Apache Arrow and this control over memory and also Russ Russ's packaging system called crates IO offers everything that you need out of the box to have features like AY and a weight to fix race conditions, to protection against buffering overflows and to ensure thread safe async cashing structures as well. So essentially it's just like has all the control, all the fine grain control, you need to take advantage of memory and all your resources as well as possible so that you can handle those really, really high ity use cases. >>Yeah, and the more I learn about the, the new engine and, and the platform IOCs et cetera, you know, you, you see things like, you know, the old days not even to even today you do a lot of garbage collection in these, in these systems and there's an inverse, you know, impact relative to performance. So it looks like you really, you know, the community is modernizing the platform, but I wanna talk about Apache Arrow for a moment. It it's designed to address the constraints that are associated with analyzing large data sets. We, we know that, but please explain why, what, what is Arrow and and what does it bring to Influx db? >>Sure, yeah. So Arrow is a, a framework for defining in memory calmer data. And so much of the efficiency and performance of IOx comes from taking advantage of calmer data structures. And I will, if you don't mind, take a moment to kind of of illustrate why column or data structures are so valuable. Let's pretend that we are gathering field data about the temperature in our room and also maybe the temperature of our stove. And in our table we have those two temperature values as well as maybe a measurement value, timestamp value, maybe some other tag values that describe what room and what house, et cetera we're getting this data from. And so you can picture this table where we have like two rows with the two temperature values for both our room and the stove. Well usually our room temperature is regulated so those values don't change very often. >>So when you have calm oriented st calm oriented storage, essentially you take each row, each column and group it together. And so if that's the case and you're just taking temperature values from the room and a lot of those temperature values are the same, then you'll, you might be able to imagine how equal values will then enable each other and when they neighbor each other in the storage format, this provides a really perfect opportunity for cheap compression. And then this cheap compression enables high cardinality use cases. It also enables for faster scan rates. So if you wanna define like the men and max value of the temperature in the room across a thousand different points, you only have to get those a thousand different points in order to answer that question and you have those immediately available to you. But let's contrast this with a row oriented storage solution instead so that we can understand better the benefits of calmer oriented storage. >>So if you had a row oriented storage, you'd first have to look at every field like the temperature in, in the room and the temperature of the stove. You'd have to go across every tag value that maybe describes where the room is located or what model the stove is. And every timestamp you'd then have to pluck out that one temperature value that you want at that one time stamp and do that for every single row. So you're scanning across a ton more data and that's why Rowe Oriented doesn't provide the same efficiency as calmer and Apache Arrow is in memory calmer data, commoner data fit framework. So that's where a lot of the advantages come >>From. Okay. So you basically described like a traditional database, a row approach, but I've seen like a lot of traditional database say, okay, now we've got, we can handle colo format versus what you're talking about is really, you know, kind of native i, is it not as effective? Is the, is the foreman not as effective because it's largely a, a bolt on? Can you, can you like elucidate on that front? >>Yeah, it's, it's not as effective because you have more expensive compression and because you can't scan across the values as quickly. And so those are, that's pretty much the main reasons why, why RO row oriented storage isn't as efficient as calm, calmer oriented storage. Yeah. >>Got it. So let's talk about Arrow Data Fusion. What is data fusion? I know it's written in Rust, but what does it bring to the table here? >>Sure. So it's an extensible query execution framework and it uses Arrow as it's in memory format. So the way that it helps in influx DB IOCs is that okay, it's great if you can write unlimited amount of cardinality into influx Cbis, but if you don't have a query engine that can successfully query that data, then I don't know how much value it is for you. So Data fusion helps enable the, the query process and transformation of that data. It also has a PANDAS API so that you could take advantage of PANDAS data frames as well and all of the machine learning tools associated with Pandas. >>Okay. You're also leveraging Par K in the platform cause we heard a lot about Par K in the middle of the last decade cuz as a storage format to improve on Hadoop column stores. What are you doing with Parque and why is it important? >>Sure. So parque is the column oriented durable file format. So it's important because it'll enable bulk import, bulk export, it has compatibility with Python and Pandas, so it supports a broader ecosystem. Par K files also take very little disc disc space and they're faster to scan because again, they're column oriented in particular, I think PAR K files are like 16 times cheaper than CSV files, just as kind of a point of reference. And so that's essentially a lot of the, the benefits of par k. >>Got it. Very popular. So and he's, what exactly is influx data focusing on as a committer to these projects? What is your focus? What's the value that you're bringing to the community? >>Sure. So Influx DB first has contributed a lot of different, different things to the Apache ecosystem. For example, they contribute an implementation of Apache Arrow and go and that will support clearing with flux. Also, there has been a quite a few contributions to data fusion for things like memory optimization and supportive additional SQL features like support for timestamp, arithmetic and support for exist clauses and support for memory control. So yeah, Influx has contributed a a lot to the Apache ecosystem and continues to do so. And I think kind of the idea here is that if you can improve these upstream projects and then the long term strategy here is that the more you contribute and build those up, then the more you will perpetuate that cycle of improvement and the more we will invest in our own project as well. So it's just that kind of symbiotic relationship and appreciation of the open source community. >>Yeah. Got it. You got that virtuous cycle going, the people call the flywheel. Give us your last thoughts and kind of summarize, you know, where what, what the big takeaways are from your perspective. >>So I think the big takeaway is that influx data is doing a lot of really exciting things with Influx DB IOx and I really encourage, if you are interested in learning more about the technologies that Influx is leveraging to produce IOCs, the challenges associated with it and all of the hard work questions and you just wanna learn more, then I would encourage you to go to the monthly Tech talks and community office hours and they are on every second Wednesday of the month at 8:30 AM Pacific time. There's also a community forums and a community Slack channel look for the influx DDB unders IAC channel specifically to learn more about how to join those office hours and those monthly tech tech talks as well as ask any questions they have about iacs, what to expect and what you'd like to learn more about. I as a developer advocate, I wanna answer your questions. So if there's a particular technology or stack that you wanna dive deeper into and want more explanation about how INFLUX DB leverages it to build IOCs, I will be really excited to produce content on that topic for you. >>Yeah, that's awesome. You guys have a really rich community, collaborate with your peers, solve problems, and, and you guys super responsive, so really appreciate that. All right, thank you so much Anise for explaining all this open source stuff to the audience and why it's important to the future of data. >>Thank you. I really appreciate it. >>All right, you're very welcome. Okay, stay right there and in a moment I'll be back with Tim Yoakum, he's the director of engineering for Influx Data and we're gonna talk about how you update a SAS engine while the plane is flying at 30,000 feet. You don't wanna miss this. >>I'm really glad that we went with InfluxDB Cloud for our hosting because it has saved us a ton of time. It's helped us move faster, it's saved us money. And also InfluxDB has good support. My name's Alex Nada. I am CTO at Noble nine. Noble Nine is a platform to measure and manage service level objectives, which is a great way of measuring the reliability of your systems. You can essentially think of an slo, the product we're providing to our customers as a bunch of time series. So we need a way to store that data and the corresponding time series that are related to those. The main reason that we settled on InfluxDB as we were shopping around is that InfluxDB has a very flexible query language and as a general purpose time series database, it basically had the set of features we were looking for. >>As our platform has grown, we found InfluxDB Cloud to be a really scalable solution. We can quickly iterate on new features and functionality because Influx Cloud is entirely managed, it probably saved us at least a full additional person on our team. We also have the option of running InfluxDB Enterprise, which gives us the ability to even host off the cloud or in a private cloud if that's preferred by a customer. Influx data has been really flexible in adapting to the hosting requirements that we have. They listened to the challenges we were facing and they helped us solve it. As we've continued to grow, I'm really happy we have influx data by our side. >>Okay, we're back with Tim Yokum, who is the director of engineering at Influx Data. Tim, welcome. Good to see you. >>Good to see you. Thanks for having me. >>You're really welcome. Listen, we've been covering open source software in the cube for more than a decade, and we've kind of watched the innovation from the big data ecosystem. The cloud has been being built out on open source, mobile, social platforms, key databases, and of course influx DB and influx data has been a big consumer and contributor of open source software. So my question to you is, where have you seen the biggest bang for the buck from open source software? >>So yeah, you know, influx really, we thrive at the intersection of commercial services and open, so open source software. So OSS keeps us on the cutting edge. We benefit from OSS in delivering our own service from our core storage engine technologies to web services temping engines. Our, our team stays lean and focused because we build on proven tools. We really build on the shoulders of giants and like you've mentioned, even better, we contribute a lot back to the projects that we use as well as our own product influx db. >>You know, but I gotta ask you, Tim, because one of the challenge that that we've seen in particular, you saw this in the heyday of Hadoop, the, the innovations come so fast and furious and as a software company you gotta place bets, you gotta, you know, commit people and sometimes those bets can be risky and not pay off well, how have you managed this challenge? >>Oh, it moves fast. Yeah, that, that's a benefit though because it, the community moves so quickly that today's hot technology can be tomorrow's dinosaur. And what we, what we tend to do is, is we fail fast and fail often. We try a lot of things. You know, you look at Kubernetes for example, that ecosystem is driven by thousands of intelligent developers, engineers, builders, they're adding value every day. So we have to really keep up with that. And as the stack changes, we, we try different technologies, we try different methods, and at the end of the day, we come up with a better platform as a result of just the constant change in the environment. It is a challenge for us, but it's, it's something that we just do every day. >>So we have a survey partner down in New York City called Enterprise Technology Research etr, and they do these quarterly surveys of about 1500 CIOs, IT practitioners, and they really have a good pulse on what's happening with spending. And the data shows that containers generally, but specifically Kubernetes is one of the areas that has kind of, it's been off the charts and seen the most significant adoption and velocity particularly, you know, along with cloud. But, but really Kubernetes is just, you know, still up until the right consistently even with, you know, the macro headwinds and all, all of the stuff that we're sick of talking about. But, so what are you doing with Kubernetes in the platform? >>Yeah, it, it's really central to our ability to run the product. When we first started out, we were just on AWS and, and the way we were running was, was a little bit like containers junior. Now we're running Kubernetes everywhere at aws, Azure, Google Cloud. It allows us to have a consistent experience across three different cloud providers and we can manage that in code so our developers can focus on delivering services, not trying to learn the intricacies of Amazon, Azure, and Google and figure out how to deliver services on those three clouds with all of their differences. >>Just to follow up on that, is it, no. So I presume it's sounds like there's a PAs layer there to allow you guys to have a consistent experience across clouds and out to the edge, you know, wherever is that, is that correct? >>Yeah, so we've basically built more or less platform engineering, This is the new hot phrase, you know, it, it's, Kubernetes has made a lot of things easy for us because we've built a platform that our developers can lean on and they only have to learn one way of deploying their application, managing their application. And so that, that just gets all of the underlying infrastructure out of the way and, and lets them focus on delivering influx cloud. >>Yeah, and I know I'm taking a little bit of a tangent, but is that, that, I'll call it a PAs layer if I can use that term. Is that, are there specific attributes to Influx db or is it kind of just generally off the shelf paths? You know, are there, is, is there any purpose built capability there that, that is, is value add or is it pretty much generic? >>So we really build, we, we look at things through, with a build versus buy through a, a build versus by lens. Some things we want to leverage cloud provider services, for instance, Postgres databases for metadata, perhaps we'll get that off of our plate, let someone else run that. We're going to deploy a platform that our engineers can, can deliver on that has consistency that is, is all generated from code that we can as a, as an SRE group, as an ops team, that we can manage with very few people really, and we can stamp out clusters across multiple regions and in no time. >>So how, so sometimes you build, sometimes you buy it. How do you make those decisions and and what does that mean for the, for the platform and for customers? >>Yeah, so what we're doing is, it's like everybody else will do, we're we're looking for trade offs that make sense. You know, we really want to protect our customers data. So we look for services that support our own software with the most uptime, reliability, and durability we can get. Some things are just going to be easier to have a cloud provider take care of on our behalf. We make that transparent for our own team. And of course for customers you don't even see that, but we don't want to try to reinvent the wheel, like I had mentioned with SQL data stores for metadata, perhaps let's build on top of what of these three large cloud providers have already perfected. And we can then focus on our platform engineering and we can have our developers then focus on the influx data, software, influx, cloud software. >>So take it to the customer level, what does it mean for them? What's the value that they're gonna get out of all these innovations that we've been been talking about today and what can they expect in the future? >>So first of all, people who use the OSS product are really gonna be at home on our cloud platform. You can run it on your desktop machine, on a single server, what have you, but then you want to scale up. We have some 270 terabytes of data across, over 4 billion series keys that people have stored. So there's a proven ability to scale now in terms of the open source, open source software and how we've developed the platform. You're getting highly available high cardinality time series platform. We manage it and, and really as, as I mentioned earlier, we can keep up with the state of the art. We keep reinventing, we keep deploying things in real time. We deploy to our platform every day repeatedly all the time. And it's that continuous deployment that allows us to continue testing things in flight, rolling things out that change new features, better ways of doing deployments, safer ways of doing deployments. >>All of that happens behind the scenes. And like we had mentioned earlier, Kubernetes, I mean that, that allows us to get that done. We couldn't do it without having that platform as a, as a base layer for us to then put our software on. So we, we iterate quickly. When you're on the, the Influx cloud platform, you really are able to, to take advantage of new features immediately. We roll things out every day and as those things go into production, you have, you have the ability to, to use them. And so in the end we want you to focus on getting actual insights from your data instead of running infrastructure, you know, let, let us do that for you. So, >>And that makes sense, but so is the, is the, are the innovations that we're talking about in the evolution of Influx db, do, do you see that as sort of a natural evolution for existing customers? I, is it, I'm sure the answer is both, but is it opening up new territory for customers? Can you add some color to that? >>Yeah, it really is it, it's a little bit of both. Any engineer will say, well, it depends. So cloud native technologies are, are really the hot thing. Iot, industrial iot especially, people want to just shove tons of data out there and be able to do queries immediately and they don't wanna manage infrastructure. What we've started to see are people that use the cloud service as their, their data store backbone and then they use edge computing with R OSS product to ingest data from say, multiple production lines and downsample that data, send the rest of that data off influx cloud where the heavy processing takes place. So really us being in all the different clouds and iterating on that and being in all sorts of different regions allows for people to really get out of the, the business of man trying to manage that big data, have us take care of that. And of course as we change the platform end users benefit from that immediately. And, >>And so obviously taking away a lot of the heavy lifting for the infrastructure, would you say the same thing about security, especially as you go out to IOT and the Edge? How should we be thinking about the value that you bring from a security perspective? >>Yeah, we take, we take security super seriously. It, it's built into our dna. We do a lot of work to ensure that our platform is secure, that the data we store is, is kept private. It's of course always a concern. You see in the news all the time, companies being compromised, you know, that's something that you can have an entire team working on, which we do to make sure that the data that you have, whether it's in transit, whether it's at rest, is always kept secure, is only viewable by you. You know, you look at things like software, bill of materials, if you're running this yourself, you have to go vet all sorts of different pieces of software. And we do that, you know, as we use new tools. That's something that, that's just part of our jobs to make sure that the platform that we're running it has, has fully vetted software and, and with open source especially, that's a lot of work. And so it's, it's definitely new territory. Supply chain attacks are, are definitely happening at a higher clip than they used to, but that is, that is really just part of a day in the, the life for folks like us that are, are building platforms. >>Yeah, and that's key. I mean especially when you start getting into the, the, you know, we talk about IOT and the operations technologies, the engineers running the, that infrastructure, you know, historically, as you know, Tim, they, they would air gap everything. That's how they kept it safe. But that's not feasible anymore. Everything's >>That >>Connected now, right? And so you've gotta have a partner that is again, take away that heavy lifting to r and d so you can focus on some of the other activities. Right. Give us the, the last word and the, the key takeaways from your perspective. >>Well, you know, from my perspective I see it as, as a a two lane approach with, with influx, with Anytime series data, you know, you've got a lot of stuff that you're gonna run on-prem, what you had mentioned, air gaping. Sure there's plenty of need for that, but at the end of the day, people that don't want to run big data centers, people that want torus their data to, to a company that's, that's got a full platform set up for them that they can build on, send that data over to the cloud, the cloud is not going away. I think more hybrid approach is, is where the future lives and that's what we're prepared for. >>Tim, really appreciate you coming to the program. Great stuff. Good to see you. >>Thanks very much. Appreciate it. >>Okay, in a moment I'll be back to wrap up. Today's session, you're watching The Cube. >>Are you looking for some help getting started with InfluxDB Telegraph or Flux Check >>Out Influx DB University >>Where you can find our entire catalog of free training that will help you make the most of your time series data >>Get >>Started for free@influxdbu.com. >>We'll see you in class. >>Okay, so we heard today from three experts on time series and data, how the Influx DB platform is evolving to support new ways of analyzing large data sets very efficiently and effectively in real time. And we learned that key open source components like Apache Arrow and the Rust Programming environment Data fusion par K are being leveraged to support realtime data analytics at scale. We also learned about the contributions in importance of open source software and how the Influx DB community is evolving the platform with minimal disruption to support new workloads, new use cases, and the future of realtime data analytics. Now remember these sessions, they're all available on demand. You can go to the cube.net to find those. Don't forget to check out silicon angle.com for all the news related to things enterprise and emerging tech. And you should also check out influx data.com. There you can learn about the company's products. You'll find developer resources like free courses. You could join the developer community and work with your peers to learn and solve problems. And there are plenty of other resources around use cases and customer stories on the website. This is Dave Valante. Thank you for watching Evolving Influx DB into the smart data platform, made possible by influx data and brought to you by the Cube, your leader in enterprise and emerging tech coverage.