>> From theCUBE studios in Palo Alto in Boston, bringing you data driven insights from theCUBE and ETR. This is Breaking Analysis with Dave Vellante. >> In the words of my colleague CTO David Nicholson, Broadcom buys old cars, not to restore them to their original luster and beauty. Nope. They buy classic cars to extract the platinum that's inside the catalytic converter and monetize that. Broadcom's planned 61 billion acquisition of VMware will mark yet another new era and chapter for the virtualization pioneer, a mere seven months after finally getting spun out as an independent company by Dell. For VMware, this means a dramatically different operating model with financial performance and shareholder value creation as the dominant and perhaps the sole agenda item. For customers, it will mean a more focused portfolio, less aspirational vision pitches, and most certainly higher prices. Hello and welcome to this week's Wikibon CUBE Insights powered by ETR. In this Breaking Analysis, we'll share data, opinions and customer insights about this blockbuster deal and forecast the future of VMware, Broadcom and the broader ecosystem. Let's first look at the key deal points, it's been well covered in the press. But just for the record, $61 billion in a 50/50 cash and stock deal, resulting in a blended price of $138 per share, which is a 44% premium to the unaffected price, i.e. prior to the news breaking. Broadcom will assume 8 billion of VMware debt and promises that the acquisition will be immediately accretive and will generate 8.5 billion in EBITDA by year three. That's more than 4 billion in EBITDA relative to VMware's current performance today. In a classic Broadcom M&A approach, the company promises to dilever debt and maintain investment grade ratings. They will rebrand their software business as VMware, which will now comprise about 50% of revenues. There's a 40 day go shop and importantly, Broadcom promises to continue to return 60% of its free cash flow to shareholders in the form of dividends and buybacks. Okay, with that out of the way, we're going to get to the money slide literally in a moment that Broadcom shared on its investor call. Broadcom has more than 20 business units. It's CEO Hock Tan makes it really easy for his business unit managers to understand. Rule number one, you agreed to an operating plan with targets for revenue, growth, EBITDA, et cetera, hit your numbers consistently and we're good. You'll be very well compensated and life will be wonderful for you and your family. Miss the number, and we're going to have a frank and uncomfortable bottom line discussion. You'll four, perhaps five quarters to turn your business around, if you don't, we'll kill it or sell it if we can. Rule number two, refer to rule number one. Hello, VMware, here's the money slide. I'll interpret the bullet points on the left for clarity. Your fiscal year 2022 EBITDA was 4.7 billion. By year three, it will be 8.5 billion. And we Broadcom have four knobs to turn with you, VMware to help you get there. First knob, if it ain't recurring revenue with rubber stamp renewals, we're going to convert that revenue or kill it. Knob number two, we're going to focus R&D in the most profitable areas of the business. AKA expect the R&D budget to be cut. Number three, we're going to spend less on sales and marketing by focusing on existing customers. We're not going to lose money today and try to make it up many years down the road. And number four, we run Broadcom with 1% GNA. You will too. Any questions? Good. Now, just to give you a little sense of how Broadcom runs its business and how well run a company it is, let's do a little simple comparison with this financial snapshot. All we're doing here is taking the most recent quarterly earnings reports from Broadcom and VMware respectively. We take the quarterly revenue and multiply by four X to get the revenue run rate and then we calculate the ratios off of the most recent quarters revenue. It's worth spending some time on this to get a sense of how profitable the Broadcom business actually is and what the spreadsheet gurus at Broadcom are seeing with respect to the possibilities for VMware. So combined, we're talking about a 40 plus billion dollar company. Broadcom is growing at more than 20% per year. Whereas VMware's latest quarter showed a very disappointing 3% growth. Broadcom is mostly a hardware company, but its gross margin is in the high seventies. As a software company of course VMware has higher gross margins, but FYI, Broadcom's software business, the remains of Symantec and what they purchased as CA has 90% gross margin. But the I popper is operating margin. This is all non gap. So it excludes things like stock based compensation, but Broadcom had 61% operating margin last quarter. This is insanely off the charts compared to VMware's 25%. Oracle's non gap operating margin is 47% and Oracle is an incredibly profitable company. Now the red box is where the cuts are going to take place. Broadcom doesn't spend much on marketing. It doesn't have to. It's SG&A is 3% of revenue versus 18% for VMware and R&D spend is almost certainly going to get cut. The other eye popper is free cash flow as a percentage of revenue at 51% for Broadcom and 29% for VMware. 51%. That's incredible. And that my dear friends is why Broadcom a company with just under 30 billion in revenue has a market cap of 230 billion. Let's dig into the VMware portfolio a bit more and identify the possible areas that will be placed under the microscope by Hock Tan and his managers. The data from ETR's latest survey shows the net score or spending momentum across VMware's portfolio in this chart, net score essentially measures the net percent of customers that are spending more on a specific product or vendor. The yellow bar is the most recent survey and compares the April 22 survey data to April 21 and January of 22. Everything is down in the yellow from January, not surprising given the economic outlook and the change in spending patterns that we've reported. VMware Cloud on AWS remains the product in the ETR survey with the most momentum. It's the only offering in the portfolio with spending momentum above the 40% line, a level that we consider highly elevated. Unified Endpoint Management looks more than respectable, but that business is a rock fight with Microsoft. VMware Cloud is things like VMware Cloud foundation, VCF and VMware's cross cloud offerings. NSX came from the Nicira acquisition. Tanzu is not yet pervasive and one wonders if VMware is making any money there. Server is ESX and vSphere and is the bread and butter. That is where Broadcom is going to focus. It's going to look at VSAN and NSX, which is software probably profitable. And of course the other products and see if the investments are paying off, if they are Broadcom will keep, if they are not, you can bet your socks, they will be sold off or killed. Carbon Black is at the far right. VMware paid $2.1 billion for Carbon Black. And it's the lowest performer on this list in terms of net score or spending momentum. And that doesn't mean it's not profitable. It just doesn't have the momentum you'd like to see, so you can bet that is going to get scrutiny. Remember VMware's growth has been under pressure for the last several years. So it's been buying companies, dozens of them. It bought AirWatch, bought Heptio, Carbon Black, Nicira, SaltStack, Datrium, Versedo, Bitnami, and on and on and on. Many of these were to pick up engineering teams. Some of them were to drive new revenue. Now this is definitely going to be scrutinized by Broadcom. So that helps explain why Michael Dell would sell VMware. And where does VMware go from here? It's got great core product. It's an iconic name. It's got an awesome ecosystem, fantastic distribution channel, but its growth is slowing. It's got limited developer chops in a world that developers and cloud native is all the rage. It's got a far flung R&D agenda going at war with a lot of different places. And it's increasingly fighting this multi front war with cloud companies, companies like Cisco, IBM Red Hat, et cetera. VMware's kind of becoming a heavy lift. It's a perfect acquisition target for Broadcom and why the street loves this deal. And we titled this Breaking Analysis taming the VMware beast because VMware is a beast. It's ubiquitous. It's an epic software platform. EMC couldn't control it. Dell used it as a piggy bank, but really didn't change its operating model. Broadcom 100% will. Now one of the things that we get excited about is the future of systems architectures. We published a breaking analysis about a year ago, talking about AWS's secret weapon with Nitro and it's Annapurna custom Silicon efforts. Remember it acquired Annapurna for a measly $350 million. And we talked about how there's a new architecture and a new price performance curve emerging in the enterprise, driven by AWS and being followed by Microsoft, Google, Alibaba, a trend toward custom Silicon with the arm based Nitro and which is AWS's hypervisor and Nick strategy, enabling processor diversity with things like Graviton and Trainium and other diverse processors, really diversifying away from x86 and how this leads to much faster product cycles, faster tape out, lower costs. And our premise was that everyone in the data center is going to competes, is going to need a Nitro to be competitive long term. And customers are going to gravitate toward the most economically favorable platform. And as we describe the landscape with this chart, we've updated this for this Breaking Analysis and we'll come back to nitro in a moment. This is a two dimensional graphic with net score or spending momentum on the vertical axis and overlap formally known as market share or presence within the survey, pervasiveness that's on the horizontal axis. And we plot various companies and products and we've inserted VMware's net score breakdown. The granularity in those colored bars on the bottom right. Net score is essentially the green minus the red and a couple points on that. VMware in the latest survey has 6% new adoption. That's that lime green. It's interesting. The question Broadcom is going to ask is, how much does it cost you to acquire that 6% new. 32% of VMware customers in the survey are increasing spending, meaning they're increasing spending by 6% or more. That's the forest green. And the question Broadcom will dig into is what percent of that increased spend (chuckles) you're capturing is profitable spend? Whatever isn't profitable is going to be cut. Now that 52% gray area flat spending that is ripe for the Broadcom picking, that is the fat middle, and those customers are locked and loaded for future rent extraction via perpetual renewals and price increases. Only 8% of customers are spending less, that's the pinkish color and only 3% are defecting, that's the bright red. So very, very sticky profile. Perfect for Broadcom. Now the rest of the chart lays out some of the other competitor names and we've plotted many of the VMware products so you can see where they fit. They're all pretty respectable on the vertical axis, that's spending momentum. But what Broadcom wants is that core ESX vSphere base where we've superimposed the Broadcom logo. Broadcom doesn't care so much about spending momentum. It cares about profitability potential and then momentum. AWS and Azure, they're setting the pace in this business, in the upper right corner. Cisco very huge presence in the data center, as does Intel, they're not in the ETR survey, but we've superimposed them. Now, Intel of course, is in a dog fight within Nvidia, the Arm ecosystem, AMD, don't forget China. You see a Google cloud platform is in there. Oracle is also on the chart as well, somewhat lower on the vertical axis, but it doesn't have that spending momentum, but it has a big presence. And it owns a cloud as we've talked about many times and it's highly differentiated. It's got a strategy that allows it to differentiate from the pack. It's very financially driven. It knows how to extract lifetime value. Safra Catz operates in many ways, similar to what we're seeing from Hock Tan and company, different from a portfolio standpoint. Oracle's got the full stack, et cetera. So it's a different strategy. But very, very financially savvy. You could see IBM and IBM Red Hat in the mix and then Dell and HP. I want to come back to that momentarily to talk about where value is flowing. And then we plotted Nutanix, which with Acropolis could suck up some V tax avoidance business. Now notice Symantec and CA, relatively speaking in the ETR survey, they have horrible spending momentum. As we said, Broadcom doesn't care. Hock Tan is not going for growth at the expense of profitability. So we fully expect VMware to come down on the vertical axis over time and go up on the profit scale. Of course, ETR doesn't measure the profitability here. Now back to Nitro, VMware has this thing called Project Monterey. It's essentially their version of Nitro and will serve as their future architecture diversifying off x86 and accommodating alternative processors. And a much more efficient performance, price in energy consumption curve. Now, one of the things that we've advocated for, we said this about Dell and others, including VMware to take a page out of AWS and start developing custom Silicon to better integrate hardware and software and accelerate multi-cloud or what we call supercloud. That layer above the cloud, not just running on individual clouds. So this is all about efficiency and simplicity to own this space. And we've challenged organizations to do that because otherwise we feel like the cloud guys are just going to have consistently better costs, not necessarily price, but better cost structures, but it begs the question. What happens to Project Monterey? Hock Tan and Broadcom, they don't invest in something that is unproven and doesn't throw off free cash flow. If it's not going to pay off for years to come, they're probably not going to invest in it. And yet Project Monterey could help secure VMware's future in not only the data center, but at the edge and compete more effectively with cloud economics. So we think either Project Monterey is toast or the VMware team will knock on the door of one of Broadcom's 20 plus business units and say, guys, what if we work together with you to develop a version of Monterey that we can use and sell to everyone, it'd be the arms dealer to everyone and be competitive with the cloud and other players out there and create the de facto standard for data center performance and supercloud. I mean, it's not outrageously expensive to develop custom Silicon. Tesla is doing it for example. And Broadcom obviously is capable of doing it. It's got good relationships with semiconductor fabs. But I think this is going to be a tough sell to Broadcom, unless VMware can hide this in plain site and make it profitable fast, like AWS most likely has with Nitro and Graviton. Then Project Monterey and our pipe dream of alternatives to Nitro in the data center could happen but if it can't, it's going to be toast. Or maybe Intel or Nvidia will take it over or maybe the Monterey team will spin out a VMware and do a Pensando like deal and demonstrate the viability of this concept and then Broadcom will buy it back in 10 years. Here's a double click on that previous data that we put in tabular form. It's how the data on that previous slide was plotted. I just want to give you the background data here. So net score spending momentum is the sorted on the left. So it's sorted by net score in the left hand chart, that was the y-axis in the previous data set and then shared and or presence in the data set is the right hand chart. In other words, it's sorted on the right hand chart, right hand table. That right most column is shared and you can see it's sorted top to bottom, and that was the x-axis on the previous chart. The point is not many on the left hand side are above the 40% line. VMware Cloud on AWS is, it's expensive, so it's probably profitable and it's probably a keeper. We'll see about the rest of VMware's portfolio. Like what happens to Tanzu for example. On the right, we drew a red line, just arbitrarily at those companies and products with more than a hundred mentions in the survey, everything but Tanzu from VMware makes that cut. Again, this is no indication of profitability here, and that's what's going to matter to Broadcom. Now let's take a moment to address the question of Broadcom as a software company. What the heck do they know about software, right. Well, they're not dumb over there and they know how to run a business, but there is a strategic rationale to this move beyond just doing portfolios and extracting rents and cutting R&D, et cetera, et cetera. Why, for example, isn't Broadcom going after coming back to Dell or HPE, it could pick up for a lot less than VMware, and they got way more revenue than VMware. Well, it's obvious, software's more profitable of course, and Broadcom wants to move up the stack, but there's a trend going on, which Broadcom is very much in touch with. First, it sells to Dell and HPE and Cisco and all the OEM. so it's not going to disrupt that. But this chart shows that the value is flowing away from traditional servers and storage and networking to two places, merchant Silicon, which itself is morphing. Broadcom... We focus on the left hand side of this chart. Broadcom correctly believes that the world is shifting from a CPU centric center of gravity to a connectivity centric world. We've talked about this on theCUBE a lot. You should listen to Broadcom COO Charlie Kawwas speak about this. It's all that supporting infrastructure around the CPU where value is flowing, including of course, alternative GPUs and XPUs, and NPUs et cetera, that are sucking the value out of the traditional x86 architecture, offloading some of the security and networking and storage functions that traditionally have been done in x86 which are part of the waste right now in the data center. This is that shifting dynamic of Moore's law. Moore's law, not keeping pace. It's slowing down. It's slower relative to some of the combinatorial factors. When you add up in all the CPU and GPU and NPU and accelerators, et cetera. So we've talked about this a lot in Breaking Analysis episodes. So the value is shifting left within that middle circle. And it's shifting left within that left circle toward components, other than CPU, many of which Broadcom supplies. And then you go back to the middle, value is shifting from that middle section, that traditional data center up into hyperscale clouds, and then to the right toward infrastructure software to manage all that equipment in the data center and across clouds. And look Broadcom is an arms dealer. They simply sell to everyone, locking up key vectors of the value chain, cutting costs and raising prices. It's a pretty straightforward strategy, but not for the fate of heart. And Broadcom has become pretty good at it. Let's close with the customer feedback. I spoke with ETRs Eric Bradley this morning. He and I both reached out to VMware customers that we know and got their input. And here's a little snapshot of what they said. I'll just read this. Broadcom will be looking to invest in the core and divest of any underperforming assets, right on. It's just what we were saying. This doesn't bode well for future innovation, this is a CTO at a large travel company. Next comment, we're a Carbon Black customer. VMware didn't seem to interfere with Carbon Black, but now that we're concerned about short term disruption to their tech roadmap and long term, are they going to split and be sold off like Symantec was, this is a CISO at a large hospitality organization. Third comment, I got directly from a VMware practitioner, an IT director at a manufacturing firm. This individual said, moving off VMware would be very difficult for us. We have over 500 applications running on VMware, and it's really easy to manage. We're not going to move those into the cloud and we're worried Broadcom will raise prices and just extract rents. Last comment, we'll share as, Broadcom sees the cloud data center and IoT is their next revenue source. The VMware acquisition provides them immediate virtualization capabilities to support a lightweight IoT offering. Big concern for customers is what technology they will invest in and innovate, and which will be stripped off and sold. Interesting. I asked David Floyer to give me a back of napkin estimate for the following question. I said, David, if you're running mission critical applications on VMware, how much would it increase your operating cost moving those applications into the cloud? Or how much would it save? And he said, Dave, VMware's really easy to run. It can run any application pretty much anywhere, and you don't need an army of people to manage it. All your processes are tied to VMware, you're locked and loaded. Move that into the cloud and your operating cost would double by his estimates. Well, there you have it. Broadcom will pinpoint the optimal profit maximization strategy and raise prices to the point where customers say, you know what, we're still better off staying with VMware. And sadly, for many practitioners there aren't a lot of choices. You could move to the cloud and increase your cost for a lot of your applications. You could do it yourself with say Zen or OpenStack. Good luck with that. You could tap Nutanix. That will definitely work for some applications, but are you going to move your entire estate, your application portfolio to Nutanix? It's not likely. So you're going to pay more for VMware and that's the price you're going to pay for two decades of better IT. So our advice is get out ahead of this, do an application portfolio assessment. If you can move apps to the cloud for less, and you haven't yet, do it, start immediately. Definitely give Nutanix a call, but going to have to be selective as to what you actually can move, forget porting to OpenStack, or do it yourself Hypervisor, don't even go there. And start building new cloud native apps where it makes sense and let the VMware stuff go into manage decline. Let certain apps just die through attrition, shift your development resources to innovation in the cloud and build a brick wall around the stable apps with VMware. As Paul Maritz, the former CEO of VMware said, "We are building the software mainframe". Now marketing guys got a hold of that and said, Paul, stop saying that, but it's true. And with Broadcom's help that day we'll soon be here. That's it for today. Thanks to Stephanie Chan who helps research our topics for Breaking Analysis. Alex Myerson does the production and he also manages the Breaking Analysis podcast. Kristen Martin and Cheryl Knight help get the word out on social and thanks to Rob Hof, who was our editor in chief at siliconangle.com. Remember, these episodes are all available as podcast, wherever you listen, just search Breaking Analysis podcast. Check out ETRs website at etr.ai for all the survey action. We publish a full report every week on wikibon.com and siliconangle.com. You can email me directly at david.vellante@siliconangle.com. You can DM me at DVellante or comment on our LinkedIn posts. This is Dave Vellante for theCUBE Insights powered by ETR. Have a great week, stay safe, be well. And we'll see you next time. (upbeat music)

(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)

>> Announcer: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE conversation. >> As you may recall, coming into the second part of 2019 we reported, based on ETR Survey data, that there was a narrowing of spending on emerging tech and an unplugging of a lot of legacy systems. This was really because people were going from experimentation into operationalizing their digital initiatives. When COVID hit, conventional wisdom suggested that there would be a flight to safety. Now, interestingly, we reported with Eric Bradley, based on one of the Venns, that a lot of CIOs were still experimenting with emerging vendors. But this was very anecdotal. Today, we have more data, fresh data, from the ETR Emerging Technology Study on private companies, which really does suggest that there's a notable decline in experimentation, and that's affecting emerging technology vendors. Hi, everybody, this is Dave Vellante, and welcome to this week's Wikibon Cube Insights, powered by ETR. Once again, Sagar Kadakia is joining us. Sagar is the Director of Research at ETR. Sagar, good to see you. Thanks for coming on. >> Good to see you again. Thanks for having me, Dave. >> So, it's really important to point out, this Emerging Tech Study that you guys do, it's different from your quarterly Technology Spending Intention Survey. Take us through the methodology. Guys, maybe you could bring up the first chart. And, Sagar, walk us through how you guys approach this. >> No problem. So, a lot of the viewers are used to seeing a lot of the results from the Technology Spending Intention Survey, or the TSIS, as we call it. That study, as the title says, it really tracks spending intentions on more pervasive vendors, right, Microsoft, AWS, as an example. What we're going to look at today is our Emerging Technology Study, which we conduct biannually, in May and November. This study is a little bit different. We ask CIOs around evaluations, awareness, planned evaluations, so think of this as pre-spend, right. So that's a major differentiator from the TSIS. That, and this study, really focuses on private emerging providers. We're really only focused on those really emerging private companies, say, like your Series B to Series G or H, whatever it may be, so, two big differences within those studies. And then today what we're really going to look at is the results from the Emerging Technology Study. Just a couple of quick things here. We had 811 CIOs participate, which represents about 380 billion in annual IT spend, so the results from this study matter. We had almost 75 Fortune 100s take it. So, again, we're really measuring how private emerging providers are doing in the largest organizations. And so today we're going to be reviewing notable sectors, but largely this survey tracks roughly 356 private technologies and frameworks. >> All right, guys, bring up the pie chart, the next slide. Now, Sagar, this is sort of a snapshot here, and it basically says that 44% of CIOs agree that COVID has decreased the organization's evaluation and utilization of emerging tech, despite what I mentioned, Eric Bradley's Venn, which suggested one CIO in particular said, "Hey, I always pick somebody in the lower left "of the magic quadrant." But, again, this is a static view. I know we have some other data, but take us through this, and how this compares to other surveys that you've done. >> No problem. So let's start with the high level takeaways. And I'll actually kind of get into to the point that Eric was debating, 'cause that point is true. It's just really how you kind of slice and dice the data to get to that. So, what you're looking at here, and what the overall takeaway from the Emerging Technology Study was, is, you know, you are going to see notable declines in POCs, of proof-of-concepts, any valuations because of COVID-19. Even though we had been communicating for quite some time, you know, the last few months, that there's increasing pressure for companies to further digitize with COVID-19, there are IT budget constraints. There is a huge pivot in IT resources towards supporting remote employees, a decrease in risk tolerance, and so that's why what you're seeing here is a rather notable number of CIOs, 44%, that said that they are decreasing their organization's evaluation and utilization of private emerging providers. So that is notable. >> Now, as you pointed out, you guys run this survey a couple of times a year. So now let's look at the time series. Guys, if you bring up the next chart. We can see how the sentiment has changed since last year. And, of course, we're isolating here on some of larger companies. So, take us through what this data means. >> No problem. So, how do we quantify what we just saw in the prior slide? We saw 44% of CIOs indicating that they are going to be decreasing their evaluations. But what exactly does that mean? We can pretty much determine that by looking at a lot of the data that we captured through our Emerging Technology Study. There's a lot going on in this slide, but I'll walk you through it. What you're looking at here is Fortune 1000 organizations, so we've really isolated the data to those organizations that matter. So, let's start with the teal, kind of green line first, because I think it's a little bit easier to understand. What you're looking at, Fortune 1000 evaluations, both planned and current, okay? And you're looking at a time series, one year ago and six months ago. So, two of the answer options that we provide CIOs in this survey, right, think about the survey as a grid, where you have seven answer options going horizontally, and then 300-plus vendors and technologies going vertically. For any given vendor, they can essentially indicate one of these options, two of them being on currently evaluating them or I plan to evaluate them in six months. So what you're looking at here is effectively the aggregate number, or the average number of Fortune 1000 evaluations. So if you look into May 2019, all the way on the left of that chart, that 24% roughly means that a quarter of selections made by Fortune 1000 of the survey, they selected plan to evaluate or currently evaluating. If you fast-forward six months, to the middle of the chart, November '19, it's roughly the same, one in four technologies that are Fortune 1000 selected, they indicated that I plan or am currently evaluating them. But now look at that big drop off going into May 2020, the 17%, right? So now one out of every six technologies, or one out of every selections that they made was an evaluation. So a very notable drop. And then if you look at the blue line, this is another answer option that we provided CIOs: I'm aware of the technology but I have no plans to evaluate. So this answer option essentially tracks awareness levels. If you look at the last six months, look at that big uptick from 44% to over 50%, right? So now, essentially one out of every two technologies, or private technologies that a CIO is aware of, they have no plans to evaluate. So this is going to have an impact on the general landscape, when we think about those private emerging providers. But there is one caveat, and, Dave, this is what you mentioned earlier, this is what Eric was talking about. The providers that are doing well are the ones that are work-from-home aligned. And so, just like a few years ago, we were really analyzing results based on are you cloud-native or are you Cloud-aligned, because those technologies are going to do the best, what we're seeing in the emerging space is now the same thing. Those emerging providers that enable organizations to maintain productivity for their employees, essentially allowing their employees to work remotely, those emerging providers are still doing well. And that is probably the second biggest takeaway from this study. >> So now what we're seeing here is this flight to perceive safety, which, to your point, Sagar, doesn't necessarily mean good news for all enterprise tech vendors, but certainly for those that are positioned for the work-from-home pivot. So now let's take a look at a couple of sectors. We'll start with information security. We've reported for years about how the perimeter's been broken down, and that more spend was going to shift from inside the moat to a distributed network, and that's clearly what's happened as a result of COVID. Guys, if you bring up the next chart. Sagar, you take us through this. >> No problem. And as you imagine, I think that the big theme here is zero trust. So, a couple of things here. And let me just explain this chart a little bit, because we're going to be going through a couple of these. What you're seeing on the X-axis here, is this is effectively what we're classifying as near term growth opportunity from all customers. The way we measure that effectively is we look at all the evaluations, current evaluations, planned evaluations, we look at people who are evaluated and plan to utilize these vendors. The more indications you get on that the more to the top right you're going to be. The more indications you get around I'm aware of but I don't plan to evaluate, or I'm replacing this early-stage vendor, the further down and on the left you're going to be. So, on the X-axis you have near term growth opportunity from all customers, and on the Y-axis you have near term growth opportunity from, really, the biggest shops in the world, your Global 2000, your Forbes Private 225, like Cargill, as an example, and then, of course, your federal agencies. So you really want to be positioned up and to the right here. So, the big takeaway here is zero trust. So, just a couple of things on this slide when we think about zero trust. As organizations accelerate their Cloud and Saas spend because of COVID-19, and, you know, what we were talking about earlier, Dave, remote work becomes the new normal, that perimeter security approach is losing appeal, because the perimeter's less defined, right? Apps and data are increasingly being stored in the Cloud. That, and employees are working remotely from everywhere, and they're accessing all of these items. And so what we're seeing now is a big move into zero trust. So, if we look at that chart again, what you're going to see in that upper right quadrant are a lot of identity and access management players. And look at the bifurcation in general. This is what we were talking about earlier in terms of the landscape not doing well. Most security vendors are in that red area, you know, in the middle to the bottom. But if you look at the top right, what are you seeing here? Unify ID, Auth0, WSO2, right, all identity and access management players. These are critical in your zero trust approach, and this is one of the few area where we are seeing upticks. You also see here BitSight, Lucideus. So that's going to be security assessment. You're seeing VECTRA and Netskope and Darktrace, and a few others here. And Cloud Security and IDPS, Intrusion Detection and Prevention System. So, very few sectors are seeing an uptick, very few security sectors actually look pretty good, based on opportunities that are coming. But, essentially, all of them are in that work-from-home aligned security stack, so to speak. >> Right, and of course, as we know, as we've been reporting, buyers have options, from both established companies and these emerging companies that are public, Okta, CrowdStrike, Zscaler. We've seen the work-from-home pivot benefit those guys, but even Palo Alto Networks, even CISCO, I asked (other speaker drowns out speech) last week, I said, "Hey, what about this pivot to work from home? "What about this zero trust?" And he said, "Look, the reality is, yes, "a big part of our portfolio is exposed "to that traditional infrastructure, "but we have options for zero trust as well." So, from a buyer's standpoint, that perceived flight to safety, you have a lot of established vendors, and that clearly is showing up in your data. Now, the other sector that we want to talk about is database. We've been reporting a lot on database, data warehouse. So, why don't you take us through the next graphic here, if you would. >> Sagar: No problem. So, our theme here is that Snowflake is really separating itself from the pack, and, again, you can see that here. Private database and data warehousing vendors really continue to impact a lot of their public peers, and Snowflake is leading the way. We expect Snowflake to gain momentum in the next few years. And, look, there's some rumors that IPOing soon. And so when we think about that set-up, we like it, because as organizations transition away from hybrid Cloud architectures to 100% or near-100% public Cloud, Snowflake is really going to benefit. So they look good, their data stacks look pretty good, right, that's resiliency, redundancy across data centers. So we kind of like them as well. Redis Labs bring a DB and they look pretty good here on the opportunity side, but we are seeing a little bit of churn, so I think probably Snowflake and DataStax are probably our two favorites here. And again, when you think about Snowflake, we continue to think more pervasive vendors, like Paradata and Cloudera, and some of the other larger database firms, they're going to continue seeing wallet and market share losses due to some of these emerging providers. >> Yeah. If you could just keep that slide up for a second, I would point out, in many ways Snowflake is kind of a safer bet, you know, we talk about flight to safety, because they're well-funded, they're established. You can go from zero to Snowflake very quickly, that's sort of their mantra, if you will. But I want to point out and recognize that it is somewhat oranges and tangerines here, Snowflake being an analytical database. You take MariaDB, for instance, I look at that, anyway, as relational and operational. And then you mentioned DataStax. I would say Couchbase, Redis Labs, Aerospike. Cockroach is really a... EValue Store. You've got some non-relational databases in there. But we're looking at the entire sector of databases, which has become a really interesting market. But again, some of those established players are going to do very well, and I would put Snowflake on that cusp. As you pointed out, Bloomberg broke the story, I think last week, that they were contemplating an IPO, which we've known for a while. >> Yeah. And just one last thing on that. We do like some of the more pervasive players, right. Obviously, AWS, all their products, Redshift and DynamoDB. Microsoft looks really good. It's just really some of the other legacy ones, like the Teradatas, the Oracles, the Hadoops, right, that we are going to be impacted. And so the claw providers look really good. >> So, the last decade has really brought forth this whole notion of DevOps, infrastructure as code, the whole API economy. And that's the piece we want to jump into now. And there are some real stand-outs here, you know, despite the early data that we showed you, where CIOs are less prone to look at emerging vendors. There are some, for instance, if you bring up the next chart, guys, like Hashi, that really are standing out, aren't they? >> That's right, Dave. So, again, what you're seeing here is you're seeing that bifurcation that we were talking about earlier. There are a lot of infrastructure software vendors that are not positioned well, but if you look at the ones at the top right that are positioned well... We have two kind of things on here, starting with infrastructure automation. We think a winner here is emerging with Terraform. Look all the way up to the right, how well-positioned they are, how many opportunities they're getting. And for the second straight survey now, Terraform is leading along their peers, Chef, Puppet, SaltStack. And they're leading their peers in so many different categories, notably on allocating more spend, which is obviously very important. For Chef, Puppet and SaltStack, which you can see a little bit below, probably a little bit higher than the middle, we are seeing some elevator churn levels. And so, really, Terraform looks like they're kind of separating themselves. And we've got this great quote from the CIO just a few months ago, on why Terraform is likely pulling away, and I'll read it out here quickly. "The Terraform tool creates "an entire infrastructure in a box. "Unlike vendors that use procedural languages, "like Ants, Bull and Chef, "it will show you the infrastructure "in the way you want it to be. "You don't have to worry about "the things that happen underneath." I know some companies where you can put your entire Amazon infrastructure through Terraform. If Amazon disappears, if your availability drops, load balancers, RDS, everything, you just run Terraform and everything will be created in 10 to 15 minutes. So that shows you the power of Terraform and why we think it's ranked better than some of the other vendors. >> Yeah, I think that really does sum it up. And, actually, guys, if you don't mind bringing that chart back up again. So, a point out, so, Mitchell Hashimoto, Hashi, really, I believe I'm correct, talking to Stu about this a little bit, he sort of led the Terraform project, which is an Open Source project, and, to your point, very easy to deploy. Chef, Puppet, Salt, they were largely disrupted by Cloud, because they're designed to automate deployment largely on-prem and DevOps, and now Terraform sort of packages everything up into a platform. So, Hashi actually makes money, and you'll see it on this slide, and things, Vault, which is kind of their security play. You see GitLab on here. That's really application tooling to deploy code. You see Docker containers, you know, Docker, really all about open source, and they've had great adoption, Docker's challenge has always been monetization. You see Turbonomic on here, which is application resource management. You can't go too deep on these things, but it's pretty deep within this sector. But we are comparing different types of companies, but just to give you a sense as to where the momentum is. All right, let's wrap here. So maybe some final thoughts, Sagar, on the Emerging Technology Study, and then what we can expect in the coming month here, on the update in the Technology Spending Intention Study, please. >> Yeah, no problem. One last thing on the zero trust side that has been a big issue that we didn't get to cover, is VPN spend. Our data is pointing that, yes, even though VPN spend did increase the last few months because of remote work, we actually think that people are going to move away from that as they move onto zero trust. So just one last point on that, just in terms of overall thoughts, you know, again, as we cover it, you can see how bifurcated all these spaces are. Really, if we were to go sector by sector by sector, right, storage and block chain and MLAI and all that stuff, you would see there's a few or maybe one or two vendors doing well, and the majority of vendors are not seeing as many opportunities. And so, again, are you work-from-home aligned? Are you the best vendor of all the other emerging providers? And if you fit those two criteria then you will continue seeing POCs and evaluations. And if you don't fit that criteria, unfortunately, you're going to see less opportunities. So think that's really the big takeaway on that. And then, just in terms of next steps, we're already transitioning now to our next Technology Spending Intention Survey. That launched last week. And so, again, we're going to start getting a feel for how CIOs are spending in 2H-20, right, so, for the back half of the year. And our question changes a little bit. We ask them, "How do you plan on spending in the back half year "versus how you actually spent "in the first half of the year, or 1H-20?" So, we're kind of, tighten the screw, so to speak, and really getting an idea of what's spend going to look like in the back half, and we're also going to get some updates as it relates to budget impacts from COVID-19, as well as how vendor-relationships have changed, as well as business impacts, like layoffs and furloughs, and all that stuff. So we have a tremendous amount of data that's going to be coming in the next few weeks, and it should really prepare us for what to see over the summer and into the fall. >> Yeah, very excited, Sagar, to see that. I just wanted to double down on what you said about changes in networking. We've reported with you guys on NPLS networks, shifting to SD-WAN. But even VPN and SD-WAN are being called into question as the internet becomes the new private network. And so lots of changes there. And again, very excited to see updated data, return of post-COVID, as we exit this isolation economy. Really want to point out to folks that this is not a snapshot survey, right? This is an ongoing exercise that ETR runs, and grateful for our partnership with you guys. Check out ETR.plus, that's the ETR website. I publish weekly on Wikibon.com and SiliconANGLE.com. Sagar, thanks so much for coming on. Once again, great to have you. >> Thank you so much, for having me, Dave. I really appreciate it, as always. >> And thank you for watching this episode of theCube Insights, powered by ETR. This Dave Vellante. We'll see you next time. (gentle music)

hello everybody and thank you for joining us today at the virtual Vertica BBC 2020 today's breakout session is entitled the road to autonomous database management how Domo is delivering SLA for less my name is su LeClair I'm the director of marketing at Vertica and I'll be your host for this webinar joining me is Ben white senior database engineer at Domo but before we begin I want to encourage you to submit questions or comments during the virtual session you don't have to wait just type your question or comment in the question box below the slides and click Submit there will be a Q&A session at the end of the presentation we'll answer as many questions as we're able to during that time any questions that we aren't able to address or drew our best to answer them offline alternatively you can visit vertical forums to post your questions there after the session our engineering team is planning to join the forum to keep the conversation going also as a reminder you can maximize your screen by clicking the double arrow button in the lower right corner of the slide and yes this virtual session is being recorded and will be available to view on demand this week we'll send you notification as soon as it's ready now let's get started then over to you greetings everyone and welcome to our virtual Vertica Big Data conference 2020 had we been in Boston the song you would have heard playing in the intro would have been Boogie Nights by heatwaves if you've never heard of it it's a great song to fully appreciate that song the way I do you have to believe that I am a genuine database whisperer then you have to picture me at 3 a.m. on my laptop tailing a vertical log getting myself all psyched up now as cool as they may sound 3 a.m. boogie nights are not sustainable they don't scale in fact today's discussion is really all about how Domo engineers the end of 3 a.m. boogie nights again well I am Ben white senior database engineer at Domo and as we heard the topic today the road to autonomous database management how Domo is delivering SLA for less the title is a mouthful in retrospect I probably could have come up with something snazzy er but it is I think honest for me the most honest word in that title is Road when I hear that word it evokes for me thoughts of the journey and how important it is to just enjoy it when you truly embrace the journey often you look up and wonder how did we get here where are we and of course what's next right now I don't intend to come across this too deep so I'll submit there's nothing particularly prescient and simply noticing the elephant in the room when it comes to database economy my opinion is then merely and perhaps more accurately my observation the office context imagine a place where thousands and thousands of users submit millions of ad-hoc queries every hour now imagine someone promised all these users that we could deliver bi leverage at cloud scale in record time I know what many of you should be thinking who in the world would do such a thing of course that news was well received and after the cheers from executives and business analysts everywhere and chance of Keep Calm and query on finally started to subside someone that turns an ass that's possible we can do that right except this is no imaginary place this is a very real challenge we face the demo through imaginative engineering demo continues to redefine what's possible the beautiful minds at Domo truly embrace the database engineering paradigm that one size does not fit all that little philosophical nugget is one I would pick up while reading the white papers and books of some guy named stone breaker so to understand how I and by extension Domo came to truly value analytic database administration look no further than that philosophy and what embracing it would mean it meant really that while others were engineering skyscrapers we would endeavor to build Datta neighborhoods with a diverse kapala G of database configuration this is where our journey at Domo really gets under way without any purposeful intent to define our destination not necessarily thinking about database as a service or anything like that we had planned this ecosystem of clusters capable of efficiently performing varied workloads we achieve this with custom configurations for node count resource pool configuration parameters etc but it also meant concerning ourselves with the unattended consequences of our ambition the impact of increased DDL activities on the catalog system overhead in general what would be the management requirements of an ever-evolving infrastructure we would be introducing multiple points of failure what are the advantages the disadvantages those types of discussions and considerations really help to define what would be the basic characteristics of our system the database itself needed to be trivial redundant potentially ephemeral customizable and above all scalable and we'll get more into that later with this knowledge of what we were getting into automation would have to be an integral part of development one might even say automation will become the first point of interest on our journey now using popular DevOps tools like saltstack terraform ServiceNow everything would be automated I mean it discluded everything from larger multi-step tasks like database designs database cluster creation and reboots to smaller routine tasks like license updates move-out and projection refreshes all of this cool automation certainly made it easier for us to respond to problems within the ecosystem these methods alone still if our database administration reactionary and reacting to an unpredictable stream of slow query complaints is not a good way to manage a database in fact that's exactly how three a.m. Boogie Nights happen and again I understand there was a certain appeal to them but ultimately managing that level of instability is not sustainable earlier I mentioned an elephant in the room which brings us to the second point of interest on our road to autonomy analytics more specifically analytic database administration why our analytics so important not just in this case but generally speaking I mean we have a whole conference set up to discuss it domo itself is self-service analytics the answer is curiosity analytics is the method in which we feed the insatiable human curiosity and that really is the impetus for analytic database administration analytics is also the part of the road I like to think of as a bridge the bridge if you will from automation to autonomy and with that in mind I say to you my fellow engineers developers administrators that as conductors of the symphony of data we call analytics we have proven to be capable producers of analytic capacity you take pride in that and rightfully so the challenge now is to become more conscientious consumers in some way shape or form many of you already employ some level of analytics to inform your decisions far too often we are using data that would be categorized as nagging perhaps you're monitoring slow queries in the management console better still maybe you consult the workflows analyzing how about a logging and alerting system like sumo logic if you're lucky you do have demo where you monitor and alert on query metrics like this all examples of analytics that help inform our decisions being a Domo the incorporation of analytics into database administration is very organic in other words pretty much company mandated as a company that provides BI leverage a cloud scale it makes sense that we would want to use our own product could be better at the business of doma adoption of stretches across the entire company and everyone uses demo to deliver insights into the hands of the people that need it when they need it most so it should come as no surprise that we have from the very beginning use our own product to make informed decisions as it relates to the application back engine in engineering we call it our internal system demo for Domo Domo for Domo in its current iteration uses a rules-based engine with elements through machine learning to identify and eliminate conditions that cause slow query performance pulling data from a number of sources including our own we could identify all sorts of issues like global query performance actual query count success rate for instance as a function of query count and of course environment timeout errors this was a foundation right this recognition that we should be using analytics to be better conductors of curiosity these types of real-time alerts were a legitimate step in the right direction for the engineering team though we saw ourselves in an interesting position as far as demo for demo we started exploring the dynamics of using the platform to not only monitor an alert of course but to also triage and remediate just how much economy could we give the application what were the pros and cons of that Trust is a big part of that equation trust in the decision-making process trust that we can mitigate any negative impacts and Trust in the very data itself still much of the data comes from systems that interacted directly and in some cases in directly with the database by its very nature much of the data was past tense and limited you know things that had already happened without any reference or correlation to the condition the mayor to those events fortunately the vertical platform holds a tremendous amount of information about the transaction it had performed its configurations the characteristics of its objects like tables projections containers resource pools etc this treasure trove of metadata is collected in the vertical system tables and the appropriately named data collector tables as a version 9 3 there are over 190 tables that define the system tables while the data collector is the collection of 215 components a rich collection can be found in the vertical system tables these tables provide a robust stable set of views that let you monitor information about your system resources background processes workload and performance allowing you to more efficiently profile diagnose and correlate historical data such as low streams query profiles to pool mover operations and more here you see a simple query to retrieve the names and descriptions of the system tables and an example of some of the tables you'll find the system tables are divided into two schemas the catalog schema contains information about persistent objects and the monitor schema tracks transient system States most of the tables you find there can be grouped into the following areas system information system resources background processes and workload and performance the Vertica data collector extends system table functionality by gathering and retaining aggregating information about your database collecting the data collector mixes information available in system table a moment ago I show you how you get a list of the system tables in their description but here we see how to get that information for the data collector tables with data from the data collecting tables in the system tables we now have enough data to analyze that we would describe as conditional or leading data that will allow us to be proactive in our system management this is a big deal for Domo and particularly Domo for demo because from here we took the critical next step where we analyze this data for conditions we know or suspect lead to poor performance and then we can suggest the recommended remediation really for the first time we were using conditional data to be proactive in a database management in record time we track many of the same conditions the Vertica support analyzes via scrutinize like tables with too many production or non partition fact tables which can negatively affect query performance and life in vertical in viral suggests if the table has a data a time step column you recommend the partitioning by the month we also can track catalog sizes percentage of total memory and alert thresholds and trigger remediations requests per hour is a very important metric in determining when a trigger are scaling solution tracking memory usage over time allows us to adjust resource pool parameters to achieve the optimal performance for the workload of course the workload analyzer is a great example of analytic database administration I mean from here one can easily see the logical next step where we were able to execute these recommendations manually or automatically be of some configuration parameter now when I started preparing for this discussion this slide made a lot of sense as far as the logical next iteration for the workload analyzing now I left it in because together with the next slide it really illustrates how firmly Vertica has its finger on the pulse of the database engineering community in 10 that OS management console tada we have the updated work lies will load analyzer we've added a column to show tuning commands the management console allows the user to select to run certain recommendations currently tuning commands that are louder and alive statistics but you can see where this is going for us using Domo with our vertical connector we were able to then pull the metadata from all of our clusters we constantly analyze that data for any number of known conditions we build these recommendations into script that we can then execute immediately the actions or we can save it to a later time for manual execution and as you would expect those actions are triggered by thresholds that we can set from the moment nyan mode was released to beta our team began working on a serviceable auto-scaling solution the elastic nature of AI mode separated store that compute clearly lent itself to our ecosystems requirement for scalability in building our system we worked hard to overcome many of the obstacles they came with the more rigid architecture of enterprise mode but with the introduction is CRM mode we now have a practical way of giving our ecosystem at Domo the architectural elasticity our model requires using analytics we can now scale our environment to match demand what we've built is a system that scales without adding management overhead or our necessary cost all the while maintaining optimal performance well we're really this is just our journey up to now and which begs the question what's next for us we expand the use of Domo for Domo within our own application stack maybe more importantly we continue to build logic into the tools we have by bringing machine learning and artificial intelligence to our analysis and decision making really do to further illustrate those priorities we announced the support for Amazon sage maker autopilot at our demo collusive conference just a couple of weeks ago for vertical the future must include in database economy the enhanced capabilities in the new management console to me are clear nod to that future in fact with a streamline and lightweight database design process all the pieces should be in place versions deliver economists database management itself we'll see well I would like to thank you for listening and now of course we will have a Q&A session hopefully very robust thank you [Applause]

(upbeat music) >> Hi, and welcome to another CUBEConversation where we go in-depth into the topics that are most important to the technology industry with the thought leaders who are actually getting the work done. I'm Peter Burris, and we've got a great conversation today, and it all starts with the idea of how do you get smart people outside of your organization, in-service organizations to help you achieve your outcomes? It's a challenge because as we become more dependent upon services, we discover that service companies are often trying to sell us bills of goods or visions that aren't solving our exact problem. There's a new breed of service company that's really fascinated by your problem, and wants to sell it. Starts with engineering, starts with value add, and then leads to other types of potential relationships and activities. So what do those service companies look like? Well, to have that conversation, we've got Greg Tinker, who is the CTO and founder of Serene IT. Greg, welcome back to theCUBE. >> Thank you very much Peter, glad to be here. >> So tell us a little bit about Serene IT. >> So Serene IT is a, well we call it a next generation bar. So what do I mean by that? We mean that we are an engineering-first firm, so our staff is big, we're across the U.S., we have multiple branches and we just went international into Canada, with Serene IT Canada. We have other international branches that we coming online next year. So with that being said though, the key to our growth, the key to our success is the fact that we're an engineering firm first. We have very few sales staff. Our sales staff are more of an account management style, more of a nurturer or a farmer, we would call it, versus a hunter that means someone going out, because the customers are coming to us with their problems because they need a smart engineering bench to help them. They're not looking for somebody else's to bring them askew, or resell them a product. That can be easily done by some of the large conglomerates that are already out there, not to mention, spend 30 seconds on Google, you can pretty much buy anything you want. >> Yeah, and you know Fred Brookes said a million years ago, when I was, even before I got into computer science, wrote "The Mythical Man Month", and made the observation that the solution to a hard problem typically, is not more people, >> Right. >> It's working smarter, and working more with the right people. So tell a little about how you're able to find the right people from the industry, and bring them together to turn them into the right team. >> It's a great question, Peter, so I've been very fortunate. I loved my career at Hewlett Packard. I left on good terms because I saw a problem in the industry that I wanted to go and tackle head-on. It's easy for people to sit back and talk about it, it's more difficult to actually go and try to solve the problem, and I'm trying to solve the problem. The problem is, there's a lot of orders out there that bring very low value today, they bring a lot of resale. And that's great for those clients that just know what they want. The vast majority of customers don't know what they want today because the technologies are so advanced, they need help to get from where they were, a legacy model, to a more modern software-defined ecosystem. >> And the business problems are so complex. >> Yes. >> It's that combination of complex business problems, 'cause your competitions and your customers are pushing you, and now advanced technologies that have to be marshaled to solve those problems. >> That's exactly right, so with that being said, I set out build an engineering firm and resale would be something later, but we sell through the engineering consulting firms to solve those business problems for our clients. And so our engineering bench is comprised of engineers from Cisco, from Dell, from HPE, from a lot of big conglomerates that everybody all knows. But when you work in this industry, in the labs of these big conglomerates, me coming from HPE, when you do that, you get a lot of friends across the pillars. >> Sure. >> You build networks. >> You build networks. And quite frankly, it's the Marvel lab guys that own today Q-Logic. We all know each other, and with that being said, some of these guys want to go out and try to solve these big problems with companies like myself, and so with that being said, that's how we're building Serene IT, is engineering-first, and we have a very large technical bench today. Just think about it, the company came online in 2017 with just two, so today, we are significantly bigger than that. We're approaching a 50-plus headcount, and we continue to expand with multiple branches, and our growth rate is almost double every six months. And it's something I'm having a great deal of fun doing. The key thing here though is solving business problems and helping customers. >> Well let's talk about that, because every IT organization faces the challenge that they've been so focused on the hardware assets for so long, or the application assets. Now they're trying to focus on the data assets, but they find themselves often in conflict with the business They're not doing a particularly good job of translating a business opportunity into a technology solution still. >> True. >> You've got these great engineers. How are you getting them to also speak business, so that you facilitate that domain expertise about the business so it can be turned into a technology-reliable solution? >> Like any good engineering firm, you have to have levels right? So we have a knock all the way to level four, and our level four engineers are our master technologists that are usually patent published or some varied nature thereof, with usually a multitude of master ASC certification structures to be able to state the fact that they are level four. We also have some college kids that are coming up that are wanting to learn with us, which is good. But I want to tell you on that same point though, is we only allow those elite, the level three, the level four guys, to be in front of our clients, because they've been in this industry a long time. Like myself, we can understand the business problems, as well as the technology problems, and help a client go from zero to hero. That's what we do well. >> So you're bringing in people who have been business people, but have strong engineering backgrounds >> Correct. >> In product domains, in service domains, in the industry, and you're bringing them together and saying, let's go back to being engineers, that can still talk business. >> That's exactly it, that's the key differentiator with us, is the fact that we're not talking just essays, a lot of ours, in our mindsets have essays they call engineers. We don't hire anyone that can't put fingers on a keyboard. If they can't make magic happen on a keyboard, they're of no value to us, they're of no value to our clients, which is what they need help with. So if we're not able to sit down and have a conversation and pull out a laptop and make some some magic happen with, name it, Ansible, Puppet, Shell, Saltstack, that's just in automation CodeLogics, C-code we've got all the cool stuff in that space. But if we can't sit down and write Python, Ruby on Rails and whatnot, and make something tangible to a client in very short order, we didn't do our job. >> So a lot of companies that I've experienced, a lot of customers I've talked to, have what I would call the "goldilocks" problem with their service providers. By that I mean, some of their service providers don't have the technical chops to just throw numbers at it, so they're too cold. Some of their service providers are too smart, or pushing too hard and they get suspicious of them. How do you be that just right, stay focused on the problem bringing the other team, the engineers or the IT folks that you're working with along with you, so you get that natural technology transfer so the business gets the capability that it can run and you can go do something else? >> So that's a good point, Peter. I mean, we're still working out some of those details, I'll tell you, to be honest with you on that stuff. >> Everybody is. >> Yeah. We're getting better at it, you know customers. If we get to aggressive, and tell the customers this is what's wrong with your problem, this is where you need to go, we call their baby ugly, it puts a lot of contention right on the onset, so it causes problems. So we have to be very cognitive of what they have, and where they want to go, and show them where we're going and why we're doing it, and not just focus on "You did it the wrong way". We don't want to focus on that. That's already done, that ship's already sailed, why bash it? I tell my engineers don't talk negative, there's no good going to come of it. Focus on what you have, and where you need to go with it, and how we're going to get there. Keep it a positive message, and you'll find it'd be more receptive, and it's working for our team. >> Well I'll tell you, one of the things I've heard about Serene IT is that you guys especially developed competencies in technologies that have worked in the past. >> You can say that. >> It seems as though one of the things you're able to do is you're able not to make something so new and so distinct that the client can't see how they can possibly operate it without you. You're taking a lot of open-source, a lot of established tried-and-true technologies and using your smarts to put them together in new and interesting ways so the customer says, "Oh that was smart, that was smart. "I can do that, oh yes, now I get it". Is that, am I mis-characterizing your guys? >> No, you're not, you're actually spot-on. We actually have one of the largest ZFS file systems on the planet right now with 142 million users hitting it and-- >> ZFS? >> Yeah, it's old school. >> With 142 million, okay. >> Yeah, it's old-school But if what's old is new again, we're just putting a new wrapper around it. It worked great in its day, but you put that old technology, the file system itself that's been around for a long time, one of the biggest file systems at 128 bit. You take that file system and you put that on today's Red Hat, Caldera, SUSE, name your favorite. You put that on a big machine, a Linux machine today, a large scale like an HPDL380 with NVME drives with a back-end data store, like a 3PAR or Primäre, or name whatever you want on the back end with a big fiber channel, you'd be surprised what we can do with that thing. So we're able to keep customers' costs down by showing them we can take a old-school technology and make it far bigger than you ever imagined, and give you more horsepower and at less cost, and customers are really receptive to that. Now is that perfect for every footprint? No, that was a unique situation. Not everybody's got 142 million users.(chuckles) >> Well, that's true. And so let me build on that, because the other thing that the CIOs I talk to and senior IT people and also business people, increasingly, is they want to make sure that the solution works now, but that it's not going to end-of-life options for them. >> Yeah. >> How do you do this using tried-and-true technologies combined into new and interesting ways, in a way that still nonetheless gives customers future growth options or future application options? >> I'm not a fan of vendor-locking, I'm not a fan of Franken-monsters. Our team of engineers, we have a mandate that they do not build anything like that, I won't approve it. Because I don't want to have a customer locked in to Serene IT. That was never the intent. We want them to choose us, we want them to come to our team and get our value, so we can show them how to grow their business, and do it in a nice, sustainable way, so we can show their staff how to support it. That takes us into our managed services component. Most of the big things we design and do, we're what we call an adaptive managed services, an AMS model. What do I mean by that statement? We're not a WITO. What's a WITO, you ask? It's a "Walk In, Take Over". That's the big boys, that's the DXEs of the world, that's the Assentras, that's what they do. And they do that well. We're not here to compete with that. But what we're here to do is say, to a company or business, whoever they might be, you probably don't need us to take over everything in your IT shop, and really, we're not going to be the best at that, nor are they in some cases, the other vendors. I'll tell you, you know your business the best. We know infrastructure the best, and we can show you where you can build your skillsets up and get better at it. We can automate a lot of it and show you how to manage the automation, and there'll be certain key points that maybe you guys don't want to own for various reasons, and we will manage just that key component, and we do that today with a lot of our big clients. >> Greg Tinker, CTO and founder of Serene IT, thanks very much for being on theCUBE. >> Thank you, Peter. >> And once again, I want to thank you for participating in this CUBEConversation. Until next time. (upbeat music)

>> Narrator: Live from Austin Texas. It's theCUBE, covering KubeKon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Welcome back everyone, live here in Austin Texas, theCUBE's exclusive coverage of CloudNativeConference and KubeKon, for Kubernetes' Conference. I'm John Furrier, co-founder of SiliconANGLE and my co-host Stu Miniman, our analyst. And next is Matt Klein, a software engineer at Lyft, ride-hailing service, car sharing, social network, great company, everyone knows that everyone loves Lyft. Thanks for coming on. >> Thanks very much for having me. >> All right so you're a customer of all this technology. You guys built, and I think this is like the shiny use cases of our generation, entrepreneurs and techies build their own stuff because they can't get product from the general market. You guys had a large-scale demand for the service, you had to go out and build your own with open source and all those tools, you had a problem you had to solve, you build it, used some open source and then give it back to open source and be part of the community, and everybody wins, you donated it back. This is, this is the future, this is what it's going to be like, great community work. What problem were you solving? Obviously Lyft, everyone knows it's hard, they see their car, lot of real time going on, lot of stuff happening >> Matt: Yeah, sure. >> magic's happening behind the scenes, you had to build that. Talk about the problem you solved. >> Well, I think, you know, when people look at Lyft, like you were saying, they look at the app and the car, and I think many people think that it's a relative simple thing. Like how hard could it be to bring up your app and say, I want a ride, and you know, get that car from here to there, but it turns out that it's really complicated. There's a lot of real-time systems involved in actually finding what are all the cars that are near you, and what's the fastest route, all of that stuff. So, I think what people don't realize is that Lyft is a very large, real-time system that, at current scale, operates at millions of requests per second, and has a lot of different use cases around databases, and caching, you know, all those technologies. So, Lyft was built on open source, as you say, and, you know Lyft grew from what I think most companies do, which is a very simple, monolithic stack, you know, it starts with a PHP application, we're a big user of MongoDB, and some load balancer, and then, you know-- >> John: That breaks (laughs) >> Well, well no but but people do that because that's what's very quick to do. And I think what happened, like most companies, is, or that most companies that become very successful, is Lyft grew a lot, and like the few companies that can become very successful, they start to outgrow some of that basic software, or the basic pieces that they're actually using. So, as Lyft started to grow a lot, things just didn't actually start working, so then we had to start fixing and building different things. >> Yeah, Matt, scale is one of those things that gets talked about a lot. But, I mean Lyft, you know, really does operate at a significant scale. >> Matt: Yeah, sure. >> Maybe you can talk a little bit about, you know, what kind of things were breaking, >> Matt: Absolutely, yeah, and then what led to Envoy and why that happened. >> Yeah, sure. I mean, I think there's two different types of scale, and I think this is something that people don't talk about enough. There's scale in terms of things that people talk about, in terms of data throughput or requests per second, or stuff like that. But there's also people scale, right. So, as organizations grow, we go from 10 developers to 50 developers to 100, where Lyft is now many hundreds of developers and we're continuing to grow, and what I think people don't talk about enough is the human scale, so you know, so we have a lot of people that are trying to edit code, and at a certain size, that number of people, you can't all be editing on that same code base. So that's I think the biggest move where people start moving towards this microservice or service-oriented architecture, so you start splitting that apart to get people-scale. People-scale probably usually comes with requests per second scale and data scale and that kind of stuff. But these problems come hand in hand, where as you grow the number of people, you start going into microservices, and then suddenly you have actual scale problems. The database is not working, or the network is not actually reliable. So from Envoy perspective, so Envoy is an open source proxy we built at Lyft, it's now part of CNCF, it's having tremendous uptake across the industry, which is fantastic, and the reason that we built Envoy is what we're seeing now in the industry is people are moving towards polyglot architectures, so they're moving towards architectures with many different applications, or many different languages. And it used to be that you could use Java and you could have one particular library that would do all of your networking and service discovery and load balancing, and now you might have six different languages. So how as an organization do you actually deal with that? And what we decided to do was build an out-of-process proxy, which allows people to build a lot of functionality into one place, around load balancing, and service discovery, and rate limiting, and buffering, and all those kinds of things, and also most importantly, observability. So things like tracing and stats and logging. And that allowed us to actually understand what was going on in the network, so that when problems were happening, we could actually debug what was going on. And what we saw at Lyft, about three years ago, is we had started our microservices journey, but it was actually almost, it was almost stopped, because what people found is they had started to build services because supposedly it was faster than the monolith, but then we would start having problems with tail latency and other things, and they didn't know hot to debug it. So they didn't trust those services, and then at that point they say, not surprisingly, we're just going to go back and we're going to build it back into the monolith. So, we're almost in that situation where things are kind of in that split. >> So Matt I have to think that's the natural, where you led to service mesh, and Istio specifically and Lyft, Google, IBM all working on that. Talk a little bit about, more about what Istio, it was really the buzz coming in with service mesh, there's also there's some competing offerings out there, Conduit, new one announced this week, maybe give us the landscape, kind of where we are, and what you're seeing. >> So I think service mesh is, it's incredible to look around this conference, I think there's 15 or more talks on service mesh between all of the Buoyant talks on Linker D and Conduit and Istio and Envoy, it's super fantastic. I think the reason that service mesh is so compelling to people is that we have these problems where people want to build in five or six languages, they have some common problems around load balancing and other types of things, and this is a great solution for offloading some of those problems into a common place. So, the confusion that I see right now around the industry is service mesh is really split into two pieces. It's split into the data plane, so the proxy, and the control plane. So the proxy's the thing that actually moves the bytes, moves the requests, and the control plane is the thing that actually tells all the proxies what to do, tells it the topology, tells it all the configurations, all the settings. So the landscape right now is essentially that Envoy is a proxy, it's a data plane. Envoy has been built into a bunch of control planes, so Istio is a control plane, it's reference proxy is Envoy, though other companies have shown that they can integrate with Istio. Linker D has shown that, NGINX has shown that. Buoyant just came out with a new combined control plane data plane service mesh called Conduit, that was brand new a couple days ago, and I think we're going to see other companies get in there, because this is a very popular paradigm, so having the competition is good. I think it's going to push everyone to be better. >> How do companies make sense of this, I mean, if I'm just a boring enterprise with complexity, legacy, you know I have a lot of stuff, maybe not the kind of scale in terms of transactions per second, because they're not Lyft, but they still have a lot of stuff. They got servers, they got data center, they got stuff in the cloud, they're trying to put this cloud native package in because the developer movement is clearly pushing the legacy guy, old guard, into cloud. So how does your stuff translate into the mainstream, how would you categorize it? >> Well, what I counsel people is, and I think that's actually a problem that we have within the industry, is that I think sometimes we push people towards complexity that they don't necessarily need yet. And I'm not saying that all of these cloud native technologies aren't great, right, I mean people here are doing fantastic things. >> You know how to drive a car, so to speak, you don't know how to use the tech. >> Right, and I advise companies and organizations to use the technology and the complexity that they need. So I think that service mesh and microservices and tracing and a lot of the stuff that's being talked about at this conference are very important if you have the scale to have a service-oriented microservice architecture. And, you know, some enterprises they're segmented enough where they may not actually need a full microservice real-time architecture. So I think that the thing to actually decide is, number one, do you need a microservice architecture, and it's okay if you don't, that's just fine, take the complexity that you need. If you do need a microservice architecture, then I think you're going to have a set of common problems around things like networking, and databases, and those types of things, and then yes, you are probably going to need to build in more complicated technologies to actually deal with that. But the key takeaway is that as you bring on, as you bring on more complexity, the complexity is a snowballing effect. More complexity yields more complexity. >> So Matt, might be a little bit out of bounds for what we're talking about, but when I think about autonomous vehicles, that's just going to put even more strain on the kind of the distributed natured systems, you know, things that have to have the edge, you know. Are we laying the groundwork at a conference like this? How's Lyft looking at this? >> For sure, and I mean, we're obviously starting to look into autonomous a lot, obviously Uber's doing that a fair amount, and if you actually start looking at the sheer amount of data that is generated by these cars when they're actually moving around, it's terabytes and terabytes of data, you start thinking through the complexity of ingesting that data from the cars into a cloud and actually analyzing it and doing things with it either offline or in real-time, it's pretty incredible. So, yes, I think that these are just more massive scale real-time systems that require more data, more hard drives, more networks, and as you manage more things with more people, it becomes more complicated for sure. >> What are you doing inside Lyft, your job. I mean obviously, you're involved in open source. Like, what are you coding specifically these days, what's the current assignment? >> Yeah, so I'm a software engineer at Lyft, I lead our networking team. Our networking team owns obviously all the stuff that we do with Envoy, we own our edge system, so basically how internet traffic comes into Lyft, all of our service discovery systems, rate limiting, auth between services. We're increasingly owning our GRPC communications, so how people define their APIs, moving from a more polling-based API to a more push-based API. So our team essentially owns the end-to-end pipe from all of our back-end services to the client, so that's APIs, analytics, stats, logging, >> So to the app >> Yeah, right, right, to the app, so, on the phone. So that's my job. I also help a lot with general kind of infrastructure architecture, so we're increasingly moving towards Kubernetes, so that's a big thing that we're doing at Lyft. Like many companies of Lyft's kind of age range, we started on VMs and AWS and we used SaltStack and you know, it's the standard story from companies that were probably six or eight years old. >> Classic dev ops. >> Right, and >> Gen One devops. >> And now we're trying to move into the, as you say, Gen Two world, which is pretty fantastic. So this is becoming, probably, the most applicable conference for us, because we're obviously doing a lot with service mesh, and we're leading the way with Envoy. But as we integrate with technologies like Istio and increasingly use Kubernetes, and all of the different related technologies, we are trying to kind of get rid of all of our bespoke stuff that many companies like Lyft had, and we're trying to get on that general train. >> I mean you guys, I mean this is going to be written in the history books, you look at this time in a generation, I mean this is going to define open source for a long, long time, because, I say Gen one kind of sounds pejorative but it's not. It's really, you need to build your own, you couldn't just buy Oracle database, because, you probably have some maybe Oracle in there, but like, you build your own. Facebook did it, you guys are doing it. Why, because you're badass, you had to. Otherwise you don't build customers. >> Right and I absolutely agree about that. I think we are in a very unique time right now, and I actually think that if you look out 10 years, and you look at some of the services that are coming online, and like Amazon just did Fargate, that whole container scheduling system, and Azure has one, and I think Google has one, but the idea there is that in 10 years' time, people are really going to be writing business logic, they're going to insert that business logic >> They may do a powerpoint slides. >> That would be nice. >> I mean it's easy to me, like powerpoint, it's so easy, that's, I'm not going to say that's coding, but that's the way it should be. >> I absolutely agree, and we'll keep moving towards that, but the way that's going to happen is, more and more plumbing if you will, will get built into these clouds, so that people don't have to worry about all this stuff. But we're in this intermediate time, where people are building these massive scale systems, and the pieces that they need is not necessarily there. >> I've been saying in theCUBE now for multiple events, all through this last year, kind of crystallized and we were talking about with Kelsey about this, Hightower, yesterday, craft is coming back to programming. So you've got software engineering, and you've got craftsmanship. And so, there's real software engineering being done, it's engineering. Application development is going to go back to the old school of real craft. I mean, Agile, all it did was create a treadmill of de-risking rapid build scale, by listening to data and constantly iterating, but it kind of took the craft out of it. >> I agree. >> But that turned into engineering. Now you have developers working on say business logic or just solving, building a healthcare app. That's just awesome software. Do you agree with this craft? >> I absolutely agree, and actually what we say about Envoy, so kind of the catchword buzz phrase of Envoy is to make the network transparent to applications. And I think most of what's happening in infrastructure right now is to get back to a time where application developers can focus on business logic, and not have to worry about how some of this plumbing actually works. And what you see around the industry right now, is it is just too painful for people to operate some of these large systems. And I think we're heading in the right direction, all of the trends are there, but it's going to take a lot more time to actually make that happen. >> I remember when I was graduating college in the 80s, sound old but, not to date myself, but the jobs were for software engineering. I mean that is what they called it, and now we're back to this devops brought it, cloud, the systems kind of engineering, really at a large scale, because you got to think about these things. >> Yeah, and I think what's also kind of interesting is that companies have moved toward this devops culture, or expecting developers to operate their systems, to be on call for them and I think that's fantastic, but what we're not doing as an industry is we're not actually teaching and helping people how to do this. So like we have this expectation that people know how to be on-call and know how to make dashboards, and know how to do all this work, but they don't learn it in school, and actually we come into organizations where we may not help them learn these skills. >> Every company has different cultures, that complicates things. >> So I think we're also, as an industry, we are figuring out how to train people and how to help them actually do this in a way that makes sense. >> Well, fascinating conversation Matt. Congratulations on all your success. Obviously a big fan of Lyft, one of the board members gave a keynote, she's from Palo Alto, from Floodgate. Great investors, great fans of the company. Congratulations, great success story, and again open source, this is the new playbook, community scale contribution, innovation. TheCUBE's doing it's share here live in Austin, Texas, for KubeKon, for Kubernetes conference and CloudNativeCon. I'm John Furrrier, for Stu Miniman, we'll be back with more after this short break. (futuristic music)