(upbeat music) >> Okay, welcome back everyone. I'm John Furrier here in theCUBE, in Palo Alto for "CUBE Conversation" with Chris Jones, Director of Product Management at Platform9. I've got a series of questions, had a great conversation earlier. Chris, I have a couple questions for you, what do you think? >> Let's do it, John. >> Okay, how does Platform9 Solution, you- can it be used on any infrastructure anywhere, cloud, edge, on-premise? >> It can, that's the beauty of our control plane, right? It was born in the cloud, and we primarily deliver that SaaS, which allows it to work in your data center, on bare metal, on VMs, or with public cloud infrastructure. We now give you the ability to take that control plane, install it in your data center, and then use it with anything, or even in air gap. And that includes capabilities with bare metal orchestration as well. >> Second question. How does Platform9 ensure maximum uptime, and proactive issue resolution? >> Oh, that's a good question. So if you come to Platform nine we're going to talk about always on assurance. What is driving that is a system of three components around self-healing, monitoring, and proactive assistance. So our software will heal broken things on nodes, right? If something stops running that should be running, it will attempt to restart that. We also have monitoring that's deployed with everything. So you build a cluster in AWS, well, we put open source monitoring agents, that are actually Prometheus, on every single node. That means it's resilient, right? So if you lose a node, you don't lose monitoring. But that data importantly comes back to our control plane, and that's the control plane that you can put in your data center as well. That data is what alerts us, and you as a user, anytime of the day that something's going wrong. Let's say etcd latency, good example, etcd is going slow. We'll find out, we might not be able to take restorative action immediately, but we're definitely going to reach out and say,, "You have a problem, let's get ahead of this and let's prevent that from becoming a bigger problem." And that's what we're delivering. When we say always on assurance, we're talking about self-healing, we're talking about remote monitoring, we're talking about being proactive with our customers, not waiting for the phone call or the support desk ticket saying, "Oh we think something's not working." Or worse, the customer has an outage. >> Awesome. Thanks for sharing. Can you explain the process for implementing Platform9 within a company's existing infrastructure. >> Are we doing air gap, or on-prem or SaaS approached? SaaS approach I think is by far the easiest, right? We can build a dedicated Platform9 control plane instance in a manner of minutes, for any customer. So when we do a proof of concept or onboarding, we just literally put in an email address, put in the name you want for your fully qualified domain name, and your instance is up. From that point onwards, the user can just log in, and using our CLI, talk to any number of, say, virtual machines, or physical servers in their environment for, you know, doing this in a data center or colo, and say, "I want these to be my Kubernetes control plane nodes. Here's the five of them. Here's the VIP for the load balancing, the API server and here are all of my compute nodes." And that CLI will work with the SaaS control plane, and go and build the cluster. That's as simple as it, CentOS, Ubuntu, just plain old operating system. Our software takes care of all the prerequisites, installing all the pieces, putting down MetalLB, CoreDNS, Metrics Server, Kubernetes dashboard, etcd backups. You built some servers. That's essentially what you've done, and the rest is being handled by Platform9. It's as simple as that. >> Great, thanks for that. What are the two traditional paths for companies considering the cloud native journey? The two paths. >> The traditional paths. I think that's your engineering team running so fast that before you even realize that you've got, you know, 10 EKS clusters. Or, hey, we can do this. You know, I've got the I can build it mentality. Let's go DIY completely open source Kubernetes on our infrastructure, and we're going to piecemeal build it all up together. They're, I think the pathways that people traditionally look at this journey, as opposed to having that third alternative saying can I just consume it on my infrastructure, be it cloud or on-premise or at the edge. >> Third is the new way, you guys do that. >> That's been our focus since the company was, you know, brought together back in the open OpenStack days. >> Awesome, what's the makeup of your customer base? Is there a certain pattern to the size or environments that you guys work with? Is there a pattern or consistency to your customer base? >> It's a spread, right? We've got large enterprises like Juniper, and we go all the way down to people with 20, 30, 50 nodes in total. We've got people in banking and finance, we've got things all the way through to telecommunications and storage infrastructure. >> What's your favorite feature of Platform9? >> My favorite feature? You know, if I ask, should I say this as a pre-sales engineer, let me show you a favorite thing. My immediate response is, I should never do this. (John laughs) To me it's just being able to define my cluster and say, go. And in five minutes I have that environment, I can see everything that's running, right? It's all unified, it's one spot, right? I'm a cluster admin. I said I wanted three control plane, 25 workers. Here's the infrastructure, it creates it, and once it's built, I can see everything that's running, right? All the applications that are there. One UI, I don't have to go click around. I'm not trying to solve things or download things. It's the fact that it's unified and just delivered in one hit. >> What is the one thing that people should know about Platform9 that they might not know about it? >> I think it's that we help developers and engineers as much as we can help our operations teams. I think, for a long time we've sort of targeted that user and said, hey, we, we really help you. It's like, but why are they doing this? Why are they building any infrastructure or any cloud platform? Well, it's to run applications and services, to help their customers, but how do they get there? There's people building and writing those things, and we're helping them, right? For the last two years, we've been really focused on making it simple, and I think that's an important thing to know. >> Chris, thanks so much, appreciate it. >> Yeah, thank you, John. >> Okay, that's theCUBE Q&A session here with Platform9. I'm John Furrier, thanks for watching. (light music)

hi everybody welcome back to re invent 2022. this is thecube's exclusive coverage we're here at the satellite set it's up on the fifth floor of the Venetian Conference Center and this is part of the global startup program the AWS startup showcase series that we've been running all through last year and and into this year with AWS and featuring some of its its Global Partners Ed wallson series the CEO of chaos search many times Cube Alum and Kevin Miller there's also a cube Alum vice president GM of S3 at AWS guys good to see you again yeah great to see you Dave hi Kevin this is we call this our Super Bowl so this must be like your I don't know uh World Cup it's a pretty big event yeah it's the World Cup for sure yeah so a lot of S3 talk you know I mean that's what got us all started in 2006 so absolutely what's new in S3 yeah it's been a great show we've had a number of really interesting launches over the last few weeks and a few at the show as well so you know we've been really focused on helping customers that are running Mass scale data Lakes including you know whether it's structured or unstructured data we actually announced just a few just an hour ago I think it was a new capability to give customers cross-account access points for sharing data securely with other parts of the organization and that's something that we'd heard from customers is as they are growing and have more data sets and they're looking to to get more out of their data they are increasingly looking to enable multiple teams across their businesses to access those data sets securely and that's what we provide with cross-count access points we also launched yesterday our multi-region access point failover capabilities and so again this is where customers have data sets and they're using multiple regions for certain critical workloads they're now able to to use that to fail to control the failover between different regions in AWS and then one other launch I would just highlight is some improvements we made to storage lens which is our really a very novel and you need capability to help customers really understand what storage they have where who's accessing it when it's being accessed and we added a bunch of new metrics storage lens has been pretty exciting for a lot of customers in fact we looked at the data and saw that customers who have adopted storage lens typically within six months they saved more than six times what they had invested in turning storage lens on and certainly in this environment right now we have a lot of customers who are it's pretty top of mind they're looking for ways to optimize their their costs in the cloud and take some of those savings and be able to reinvest them in new innovation so pretty exciting with the storage lens launch I think what's interesting about S3 is that you know pre-cloud Object Store was this kind of a niche right and then of course you guys announced you know S3 in 2006 as I said and okay great you know cheap and deep storage simple get put now the conversations about how to enable value from from data absolutely analytics and it's just a whole new world and Ed you've talked many times I love the term yeah we built chaos search on the on the shoulders of giants right and so the under underlying that is S3 but the value that you can build on top of that has been key and I don't think we've talked about his shoulders and Giants but we've talked about how we literally you know we have a big Vision right so hard to kind of solve the challenge to analytics at scale we really focus on the you know the you know Big Data coming environment get analytics so we talk about the on the shoulders Giants obviously Isaac Newton's you know metaphor of I learned from everything before and we layer on top so really when you talk about all the things come from S3 like I just smile because like we picked it up naturally we went all in an S3 and this is where I think you're going Dave but everyone is so let's just cut the chase like so any of the data platforms you're using S3 is what you're building but we did it a little bit differently so at first people using a cold storage like you said and then they ETL it up into a different platforms for analytics of different sorts now people are using it closer they're doing caching layers and cashing out and they're that's where but that's where the attributes of a scale or reliability are what we did is we actually make S3 a database so literally we have no persistence outside that three and that kind of comes in so it's working really well with clients because most of the thing is we pick up all these attributes of scale reliability and it shows up in the clients environments and so when you launch all these new scalable things we just see it like our clients constantly comment like one of our biggest customers fintech in uh Europe they go to Black Friday again black Friday's not one days and they lose scale from what is it 58 terabytes a day and they're going up to 187 terabytes a day and we don't Flinch they say how do you do that well we built our platform on S3 as long as you can stream it to S3 so they're saying I can't overrun S3 and it's a natural play so it's it's really nice that but we take out those attributes but same thing that's why we're able to you know help clients get you know really you know Equifax is a good example maybe they're able to consolidate 12 their divisions on one platform we couldn't have done that without the scale and the performance of what you can get S3 but also they saved 90 I'm able to do that but that's really because the only persistence is S3 and what you guys are delivering but and then we really for focus on shoulders Giants we're doing on top of that innovating on top of your platforms and bringing that out so things like you know we have a unique data representation that makes it easy to ingest this data because it's kind of coming at you four v's of big data we allow you to do that make it performant on s3h so now you're doing hot analytics on S3 as if it's just a native database in memory but there's no memory SSC caching and then multi-model once you get it there don't move it leverage it in place so you know elasticsearch access you know Cabana grafana access or SQL access with your tools so we're seeing that constantly but we always talk about on the shoulders of giants but even this week I get comments from our customers like how did you do that and most of it is because we built on top of what you guys provided so it's really working out pretty well and you know we talk a lot about digital transformation of course we had the pleasure sitting down with Adam solipski prior John Furrier flew to Seattle sits down his annual one-on-one with the AWS CEO which is kind of cool yeah it was it's good it's like study for the test you know and uh and so but but one of the interesting things he said was you know we're one of our challenges going forward is is how do we go Beyond digital transformation into business transformation like okay well that's that's interesting I was talking to a customer today AWS customer and obviously others because they're 100 year old company and they're basically their business was they call them like the Uber for for servicing appliances when your Appliance breaks you got to get a person to serve it a service if it's out of warranty you know these guys do that so they got to basically have a you know a network of technicians yeah and they gotta deal with the customers no phone right so they had a completely you know that was a business transformation right they're becoming you know everybody says they're coming a software company but they're building it of course yeah right on the cloud so wonder if you guys could each talk about what's what you're seeing in terms of changing not only in the sort of I.T and the digital transformation but also the business transformation yeah I know I I 100 agree that I think business transformation is probably that one of the top themes I'm hearing from customers of all sizes right now even in this environment I think customers are looking for what can I do to drive top line or you know improve bottom line or just improve my customer experience and really you know sort of have that effect where I'm helping customers get more done and you know it is it is very tricky because to do that successfully the customers that are doing that successfully I think are really getting into the lines of businesses and figuring out you know it's probably a different skill set possibly a different culture different norms and practices and process and so it's it's a lot more than just a like you said a lot more than just the technology involved but when it you know we sort of liquidate it down into the data that's where absolutely we see that as a critical function for lines of businesses to become more comfortable first off knowing what data sets they have what data they they could access but possibly aren't today and then starting to tap into those data sources and then as as that progresses figuring out how to share and collaborate with data sets across a company to you know to correlate across those data sets and and drive more insights and then as all that's being done of course it's important to measure the results and be able to really see is this what what effect is this having and proving that effect and certainly I've seen plenty of customers be able to show you know this is a percentage increase in top or bottom line and uh so that pattern is playing out a lot and actually a lot of how we think about where we're going with S3 is related to how do we make it easier for customers to to do everything that I just described to have to understand what data they have to make it accessible and you know it's great to have such a great ecosystem of partners that are then building on top of that and innovating to help customers connect really directly with the businesses that they're running and driving those insights well and customers are hours today one of the things I loved that Adam said he said where Amazon is strategically very very patient but tactically we're really impatient and the customers out there like how are you going to help me increase Revenue how are you going to help me cut costs you know we were talking about how off off camera how you know software can actually help do that yeah it's deflationary I love the quote right so software's deflationary as costs come up how do you go drive it also free up the team and you nail it it's like okay everyone wants to save money but they're not putting off these projects in fact the digital transformation or the business it's actually moving forward but they're getting a little bit bigger but everyone's looking for creative ways to look at their architecture and it becomes larger larger we talked about a couple of those examples but like even like uh things like observability they want to give this tool set this data to all the developers all their sres same data to all the security team and then to do that they need to find a way an architect should do that scale and save money simultaneously so we see constantly people who are pairing us up with some of these larger firms like uh or like keep your data dog keep your Splunk use us to reduce the cost that one and one is actually cheaper than what you have but then they use it either to save money we're saving 50 to 80 hard dollars but more importantly to free up your team from the toil and then they they turn around and make that budget neutral and then allowed to get the same tools to more people across the org because they're sometimes constrained of getting the access to everyone explain that a little bit more let's say I got a Splunk or data dog I'm sifting through you know logs how exactly do you help so it's pretty simple I'll use dad dog example so let's say using data dog preservability so it's just your developers your sres managing environments all these platforms are really good at being a monitoring alerting type of tool what they're not necessarily great at is keeping the data for longer periods like the log data the bigger data that's where we're strong what you see is like a data dog let's say you're using it for a minister for to keep 30 days of logs which is not enough like let's say you're running environment you're finding that performance issue you kind of want to look to last quarter in last month in or maybe last Black Friday so 30 days is not enough but will charge you two eighty two dollars and eighty cents a gigabyte don't focus on just 280 and then if you just turn the knob and keep seven days but keep two years of data on us which is on S3 it goes down to 22 cents plus our list price of 80 cents goes to a dollar two compared to 280. so here's the thing what they're able to do is just turn a knob get more data we do an integration so you can go right from data dog or grafana directly into our platform so the user doesn't see it but they save money A lot of times they don't just save the money now they use that to go fund and get data dog to a lot more people make sense so it's a creativity they're looking at it and they're looking at tools we see the same thing with a grafana if you look at the whole grafana play which is hey you can't put it in one place but put Prometheus for metrics or traces we fit well with logs but they're using that to bring down their costs because a lot of this data just really bogs down these applications the alerting monitoring are good at small data they're not good at the big data which is what we're really good at and then the one and one is actually less than you paid for the one so it and it works pretty well so things are really unpredictable right now in the economy you know during the pandemic we've sort of lockdown and then the stock market went crazy we're like okay it's going to end it's going to end and then it looked like it was going to end and then it you know but last year it reinvented just just in that sweet spot before Omicron so we we tucked it in which which was awesome right it was a great great event we really really missed one physical reinvent you know which was very rare so that's cool but I've called it the slingshot economy it feels like you know you're driving down the highway and you got to hit the brakes and then all of a sudden you're going okay we're through it Oh no you're gonna hit the brakes again yeah so it's very very hard to predict and I was listening to jassy this morning he was talking about yeah consumers they're still spending but what they're doing is they're they're shopping for more features they might be you know buying a TV that's less expensive you know more value for the money so okay so hopefully the consumer spending will get us out of this but you don't really know you know and I don't yeah you know we don't seem to have the algorithms we've never been through something like this before so what are you guys seeing in terms of customer Behavior given that uncertainty well one thing I would highlight that I think particularly going back to what we were just talking about as far as business and digital transformation I think some customers are still appreciating the fact that where you know yesterday you may have had to to buy some Capital put out some capital and commit to something for a large upfront expenditure is that you know today the value of being able to experiment and scale up and then most importantly scale down and dynamically based on is the experiment working out am I seeing real value from it and doing that on a time scale of a day or a week or a few months that is so important right now because again it gets to I am looking for a ways to innovate and to drive Top Line growth but I I can't commit to a multi-year sort of uh set of costs to to do that so and I think plenty of customers are finding that even a few months of experimentation gives them some really valuable insight as far as is this going to be successful or not and so I think that again just of course with S3 and storage from day one we've been elastic pay for what you use if you're not using the storage you don't get charged for it and I think that particularly right now having the applications and the rest of the ecosystem around the storage and the data be able to scale up and scale down is is just ever more important and when people see that like typically they're looking to do more with it so if they find you usually find these little Department projects but they see a way to actually move faster and save money I think it is a mix of those two they're looking to expand it which can be a nightmare for sales Cycles because they take longer but people are looking well why don't you leverage this and go across division so we do see people trying to leverage it because they're still I don't think digital transformation is slowing down but a lot more to be honest a lot more approvals at this point for everything it is you know Adam and another great quote in his in his keynote he said if you want to save money the Cloud's a place to do it absolutely and I read an article recently and I was looking through and I said this is the first time you know AWS has ever seen a downturn because the cloud was too early back then I'm like you weren't paying attention in 2008 because that was the first major inflection point for cloud adoption where CFO said okay stop the capex we're going to Opex and you saw the cloud take off and then 2010 started this you know amazing cycle that we really haven't seen anything like it where they were doubling down in Investments and they were real hardcore investment it wasn't like 1998 99 was all just going out the door for no clear reason yeah so that Foundation is now in place and I think it makes a lot of sense and it could be here for for a while where people are saying Hey I want to optimize and I'm going to do that on the cloud yeah no I mean I've obviously I certainly agree with Adam's quote I think really that's been in aws's DNA from from day one right is that ability to scale costs with with the actual consumption and paying for what you use and I think that you know certainly moments like now are ones that can really motivate change in an organization in a way that might not have been as palatable when it just it didn't feel like it was as necessary yeah all right we got to go give you a last word uh I think it's been a great event I love all your announcements I think this is wonderful uh it's been a great show I love uh in fact how many people are here at reinvent north of 50 000. yeah I mean I feel like it was it's as big if not bigger than 2019. people have said ah 2019 was a record when you count out all the professors I don't know it feels it feels as big if not bigger so there's great energy yeah it's quite amazing and uh and we're thrilled to be part of it guys thanks for coming on thecube again really appreciate it face to face all right thank you for watching this is Dave vellante for the cube your leader in Enterprise and emerging Tech coverage we'll be right back foreign

(lively music) >> Good afternoon cloud community and welcome back to beautiful Las Vegas, Nevada. We are here at AWS re:Invent, day four of our wall to wall coverage. It is day four in the afternoon and we are holding strong. I'm Savannah Peterson, joined by my fabulous co-host Paul Gillen. Paul, how you doing? >> I'm doing well, fine Savannah. You? >> You look great. >> We're in the home stretch here. >> Yeah, (laughs) we are. >> You still look fresh as a daisy. I don't know how you do it. >> (laughs) You're too kind. You're too kind, but I'm vain enough to take that compliment. I'm very excited about the conversation that we're going to have up next. We get to get a little DevRel and we got a little swagger on the stage. Welcome, Austin. How you doing? >> Hey, great to be here. Thanks for having me. >> Savannah: Yeah, it's our pleasure. How's the show been for you so far? >> Busy, exciting. Feels a lot like, you know it used to be right? >> Yeah, I know. A little reminiscent of the before times. >> Well, before times. >> Before we dig into the technical stuff, you're the most intriguingly dressed person we've had on the show this week. >> Austin: I feel extremely underdressed. >> Well, and we were talking about developer fancy. Talk to me a little bit about your approach to fashion. Wasn't expecting to lead with this, but I like this but I like this actually. >> No, it's actually good with my PR. You're going to love it. My approach, here's the thing, I give free advice all the time about developer relations, about things that work, have worked, and don't work in community and all that stuff. I love talking about that. Someone came up to me and said, "Where do you get your fashion tips from? What's the secret Discord server that I need to go on?" I'm like, "I will never tell." >> Oh, okay. >> This is an actual trait secret. >> Top secret. Wow! Talk about. >> If someone else starts wearing the hat, then everyone's going to be like, "There's so many white guys." Look, I'm a white guy with a beard that works in technology. >> Savannah: I've never met one of those. >> Exactly, there's none of them at all. So, you have to do something to kind stand out from the crowd a little bit. >> I love it, and it's a talk trigger. We're talking about it now. Production team loved it. It's fantastic. >> It's great. >> So your DevRel for Lightstep, in case the audience isn't familiar tell us about Lightstep. >> So Lightstep is a cloud native observability platform built at planet scale, and it powers observability at some places you've heard of like Spotify, GitHub, right? We're designed to really help developers that are working in the cloud with Kubernetes, with these huge distributed systems, understand application performance and being able to find problems, fix problems. We're also part of the ServiceNow family and as we all know ServiceNow is on a mission to help the world of work work better by powering digital transformation around IT and customer experiences for their many, many, many global 2000 customers. We love them very much. >> You know, it's a big love fest here. A lot of people have talked about the collaboration, so many companies working together. You mentioned unified observability. What is unified observability? >> So if you think about a tradition, or if you've heard about this traditional idea of observability where you have three pillars, right? You have metrics, and you have logs, and you have traces. All those three things are different data sources. They're picked up by different tools. They're analyzed by different people for different purposes. What we believe and what we're working to accomplish right now is to take all that and if you think those pillars, flip 'em on their side and think of them as streams of data. If we can take those streams and integrate them together and let you treat traces and metrics and logs not as these kind of inviolate experiences where you're kind of paging between things and going between tab A to tab B to tab C, and give you a standard way to query this, a standard way to display this, and letting you kind of find the most relevant data, then it really unlocks a lot of power for like developers and SREs to spend less time like managing tools. You know, figuring out where to build their query or what dashboard to check, more just being able to like kind of ask a question, get an answer. When you have an incident or an outage that's the most important thing, right? How quickly can you get those answers that you need so that you can restore system health? >> You don't want to be looking in multiple spots to figure out what's going on. >> Absolutely. I mean, some people hear unified observability and they go to like tool consolidation, right? That's something I hear from a lot of our users and a lot of people in re:Invent. I'll talk to SREs, they're like, "Yeah, we've got like six or seven different metrics products alone, just on services that they cover." It is important to kind of consolidate that but we're really taking it a step lower. We're looking at the data layer and trying to say, "Okay, if the data is all consistent and vendor neutral then that gives you flexibility not only from a tool consolidation perspective but also you know, a consistency, reliability. You could have a single way to deploy your observability out regardless of what cloud you're on, regardless if you're using Kubernetes or Fargate or whatever else. or even just Bare Metal or EC2 Bare Metal, right? There's been so much historically in this space. There's been a lot of silos and we think that unify diversability means that we kind of break down those silos, right? The way that we're doing it primarily is through a project called OpenTelemetry which you might have heard of. You want to talk about that in a minute? . >> Savannah: Yeah, let's talk about it right now. Why don't you tell us about it? Keep going, you're great. You're on a roll. >> I am. >> Savannah: We'll just hang out over here. >> It's day four. I'm going to ask the questions and answer the questions. (Savannah laughs) >> Yes, you're right. >> I do yeah. >> Open Tele- >> OpenTelemetry . >> Explain what OpenTelemetry is first. >> OpenTelemetry is a CNCF project, Cloud Native Computing Foundation. The goal is to make telemetry data, high quality telemetry data, a builtin feature of cloud native software right? So right now if you wanted to get logging data out, depending on your application stack, depending on your application run time, depending on language, depending on your deployment environment. You might have a lot... You have to make a lot of choices, right? About like, what am I going to use? >> Savannah: So many different choices, and the players are changing all the time. >> Exactly, and a lot of times what people will do is they'll go and they'll say like, "We have to use this commercial solution because they have a proprietary agent that can do a lot of this for us." You know? And if you look at all those proprietary agents, what you find very quickly is it's very commodified right? There's no real difference in what they're doing at a code level and what's stopped the industry from really adopting a standard way to create this logs and metrics and traces, is simply just the fact that there was no standard. And so, OpenTelemetry is that standard, right? We've got dozens of companies many of them like very, many of them here right? Competitors all the same, working together to build this open standard and implementation of telemetry data for cloud native software and really any software right? Like we support over 12 languages. We support Kubernetes, Amazon. AWS is a huge contributor actually and we're doing some really exciting stuff with them on their Amazon distribution of OpenTelemetry. So it's been extremely interesting to see it over the past like couple years go from like, "Hey, here's this like new thing that we're doing over here," to really it's a generalized acceptance that this is the way of the future. This is what we should have been doing all along. >> Yeah. >> My opinion is there is a perception out there that observability is kind of a commodity now that all the players have the same set of tools, same set of 15 or 17 or whatever tools, and that there's very little distinction in functionality. Would you agree with that? >> I don't know if I would characterize it that way entirely. I do think that there's a lot of duplicated effort that happens and part of the reason is because of this telemetry data problem, right? Because you have to wind up... You know, there's this idea of table stakes monitoring that we talk about right? Table stakes monitoring is the stuff that you're having to do every single day to kind of make sure your system is healthy to be able to... When there's an alert, gets triggered, to see why it got triggered and to go fix it, right? Because everyone has the kind of work on that table stake stuff and then build all these integrations, there's very little time for innovation on top of that right? Because you're spending all your time just like working on keeping up with technology. >> Savannah: Doing the boring stuff to make sure the wheels don't fall off, basically. >> Austin: Right? What I think the real advantage of OpenTelemetry is that it really, from like a vendor perspective, like it unblocks us from having to kind of do all this repetitive commodified work. It lets us help move that out to the community level so that... Instead of having to kind of build, your Kubernetes integration for example, you can just have like, "Hey, OpenTelemetry is integrated into Kubernetes and you just have this data now." If you are a commercial product, or if you're even someone that's interested in fixing a, scratching a particular itch about observability. It's like, "I have this specific way that I'm doing Kubernetes and I need something to help me really analyze that data. Well, I've got the data now I can just go create a project. I can create an analysis tool." I think that's what you'll see over time as OpenTelemetry promulgates out into the ecosystem is more people building interesting analysis features, people using things like machine learning to analyze this large amount, large and consistent amount of OpenTelemetry data. It's going to be a big shakeup I think, but it has the potential to really unlock a lot of value for our customers. >> Well, so you're, you're a developer relations guy. What are developers asking for right now out of their observability platforms? >> Austin: That's a great question. I think there's two things. The first is that they want it to just work. It's actually the biggest thing, right? There's so many kind of... This goes back to the tool proliferation, right? People have too much data in too many different places, and getting that data out can still be really challenging. And so, the biggest thing they want is just like, "I want something that I can... I want a lot of these questions I have to ask, answered already and OpenTelemetry is going towards it." Keep in mind it's the project's only three years old, so we obviously have room to grow but there are people running it in production and it works really well for them but there's more that we can do. The second thing is, and this isn't what really is interesting to me, is it's less what they're asking for and more what they're not asking for. Because a lot of the stuff that you see people, saying around, "Oh, we need this like very specific sort of lower level telemetry data, or we need this kind of universal thing." People really just want to be able to get questions or get questions answered, right? They want tools that kind of have these workflows where you don't have to be an expert because a lot of times this tooling gets locked behind sort of is gate kept almost in a organization where there are teams that's like, "We're responsible for this and we're going to set it up and manage it for you, and we won't let you do things outside of it because that would mess up- >> Savannah: Here's your sandbox and- >> Right, this is your sandbox you can play in and a lot of times that's really useful and very tuned for the problems that you saw yesterday, but people are looking at like what are the problems I'm going to get tomorrow? We're deploying more rapidly. We have more and more intentional change happening in the system. Like it's not enough to have this reactive sort of approach where our SRE teams are kind of like or this observability team is building a platform for us. Developers want to be able to get in and have these kind of guided workflows really that say like, "Hey, here's where you're starting at. Let's get you to an answer. Let's help you find the needle in the haystack as it were, without you having to become a master of six different or seven different tools." >> Savannah: Right, and it shouldn't be that complicated. >> It shouldn't be. I mean we've certainly... We've been working on this problem for many years now, starting with a lot of our team that started at Google and helped build Google's planet scale monitoring systems. So we have a lot of experience in the field. It's actually one... An interesting story that our founder or now general manager tells BHS, Ben Sigelman, and he told me this story once and it's like... He had built this really cool thing called Dapper that was a tracing system at Google, and people weren't using it. Because they were like, "This is really cool, but I don't know how to... but it's not relevant to me." And he's like, the one thing that we did to get to increase usage 20 times over was we just put a link. So we went to the place that people were already looking for that data and we added a link that says, "Hey, go over here and look at this." It's those simple connections being able to kind of draw people from like point A to point B, take them from familiar workflows into unfamiliar ones. You know, that's how we think about these problems right? How is this becoming a daily part of someone's usage? How is this helping them solve problems faster and really improve their their life? >> Savannah: Yeah, exactly. It comes down to quality of life. >> Warner made the case this morning that computer architecture should be inherently event-driven and that we are moving toward a world where the person matters less than what the software does, right? The software is triggering events. Does this complicate observability or simplify it? >> Austin: I think that at the end of the day, it's about getting the... Observability to me in a lot of ways is about modeling your system, right? It's about you as a developer being able to say this is what I expect the system to do and I don't think the actual application architecture really matters that much, right? Because it's about you. You are building a system, right? It can be event driven, can be support request response, can be whatever it is. You have to be able to say, "This is what I expect to... For these given inputs, this is the expected output." Now maybe there's a lot of stuff that happens in the middle that you don't really care about. And then, I talk to people here and everyone's talking about serverless right? Everyone... You can see there's obviously some amazing statistics about how many people are using Lambda, and it's very exciting. There's a lot of stuff that you shouldn't have to care about as a developer, but you should care about those inputs and outputs. You will need to have that kind of intermediate information and understand like, what was the exact path that I took through this invented system? What was the actual resources that were being used? Because even if you trust that all this magic behind the scenes is just going to work forever, sometimes it's still really useful to have that sort of lower level abstraction, to say like, "Well, this is what actually happened so that I can figure out when I deployed a new change, did I make performance better or worse?" Or being able to kind of segregate your data out and say like... Doing AB testing, right? Doing canary releases, doing all of these things that you hear about as best practices or well architected applications. Observability is at the core of all that. You need observability to kind of do any of, ask any of those higher level interesting questions. >> Savannah: We are here at ReInvent. Tell us a little bit more about the partnership with AWS. >> So I would have to actually probably refer you to someone at Service Now on that. I know that we are a partner. We collaborate with them on various things. But really at Lightstep, we're very focused on kind of the open source part of this. So we work with AWS through the OpenTelemetry project, on things like the AWS distribution for OpenTelemetry which is really... It's OpenTelemetry, again is really designed to be like a neutral standard but we know that there are going to be integrators and implementers that need to package up and bundle it in a certain way to make it easy for their end users to consume it. So that's what Amazon has done with ADOT which is the shortening for it. So it's available in several different ways. You can use it as like an SDK and drop it into your application. There's Lambda layers. If you want to get Lambda observability, you just add this extension in and then suddenly you're getting OpenTelemetry data on the other side. So it's really cool. It's been a really exciting to kind of work with people on the AWS side over the past several years. >> Savannah: It's exciting, >> I've personally seen just a lot of change. I was talking to a PM earlier this week... It's like, "Hey, two years ago I came and talked to you about OpenTelemetry and here we are today. You're still talking about OpenTelemetry." And they're like, "What changes?" Our customers have started coming to us asking for OpenTelemetry and we see the same thing now. >> Savannah: Timing is right. >> Timing is right, but we see the same thing... Even talking to ServiceNow customers who are... These very big enterprises, banks, finance, healthcare, whatever, telcos, it used to be... You'd have to go to them and say like, "Let me tell you about distributed tracing. Let me tell you about OpenTelemetry. Let me tell you about observability." Now they're coming in and saying, "Yeah, so we're standard." If you think about Kubernetes and how Kubernetes, a lot of enterprises have spent the past five-six years standardizing, and Kubernetes is a way to deploy applications or manage containerized applications. They're doing the same journey now with OpenTelemetry where they're saying, "This is what we're betting on and we want partners we want people to help us go along that way." >> I love it, and they work hand in hand in all CNCF projects as well that you're talking about. >> Austin: Right, so we're integrated into Kubernetes. You can find OpenTelemetry and things like kept in which is application standards. And over time, it'll just like promulgate out from there. So it's really exciting times. >> A bunch of CNCF projects in this area right? Prometheus. >> Prometheus, yeah. Yeah, so we inter-operate with Prometheus as well. So if you have Prometheus metrics, then OpenTelemetry can read those. It's a... OpenTelemetry metrics are like a super set of Prometheus. We've been working with the Prometheus community for quite a while to make sure that there's really good compatibility because so many people use Prometheus you know? >> Yeah. All right, so last question. New tradition for us here on theCUBE. We're looking for your 32nd hot take, Instagram reel, biggest theme, biggest buzz for those not here on the show floor. >> Oh gosh. >> Savannah: It could be for you too. It could be whatever for... >> I think the two things that are really striking to me is one serverless. Like I see... I thought people were talking about servers a lot and they were talking about it more than ever. Two, I really think it is observability right? Like we've gone from observability being kind of a niche. >> Savannah: Not that you're biased. >> Huh? >> Savannah: Not that you're biased. >> Not that I'm biased. It used to be a niche. I'd have to go niche thing where I would go and explain what this is to people and nowpeople are coming up. It's like, "Yeah, yeah, we're using OpenTelemetry." It's very cool. I've been involved with OpenTelemetry since the jump, since it was started really. It's been very exciting to see and gratifying to see like how much adoption we've gotten even in a short amount of time. >> Yeah, absolutely. It's a pretty... Yeah, it's been a lot. That was great. Perfect soundbite for us. >> Austin: Thanks, I love soundbites. >> Savannah: Yeah. Awesome. We love your hat and your soundbites equally. Thank you so much for being on the show with us today. >> Thank you for having me. >> Savannah: Hey, anytime, anytime. Will we see you in Amsterdam, speaking of KubeCon? Awesome, we'll be there. >> There's some real exciting OpenTelemetry stuff coming up for KubeCon. >> Well, we'll have to get you back on theCUBE. (talking simultaneously) Love that for us. Thank you all for tuning in two hour wall to wall coverage here, day four at AWS re:Invent in fabulous Las Vegas, Nevada, with Paul Gillin. I'm Savannah Peterson and you're watching theCUBE, the leader in high tech coverage. (lively music)

>>Good afternoon everyone, and welcome back to the Cube. I am Savannah Peterson here, coming to you from Detroit, Michigan. We're at Cuban Day three. Such a series of exciting interviews. We've done over 30, but this conversation is gonna be extra special, don't you think, John? >>Yeah, this is gonna be a good one. Griffon Labs is here with us. We're getting the conversation of what's going on in the industry management, watching the Kubernetes clusters. This is large scale conversations this week. It's gonna be a good one. >>Yeah. Yeah. I'm very excited. He's also got a fantastic Twitter handle, twitchy. H Please welcome Richie Hartman, who is the director of community here at Griffon. Richie, thank you so much for joining us. Thanks >>For having me. >>How's the show been for you? >>Busy. I, I mean, I, I, >>In >>A word, I have a ton of talks at at like maintain a thing and like the covering board searches at the TLC panel. I run forme day. So it's, it's been busy. It, yeah. Monday, I didn't have to run anything. That was quite nice. But there >>You, you have your hands in a lot. I'm not even gonna cover it. Looking at your bio, there's, there's so many different things that you're working on. I know that Grafana specifically had some announcements this week. Yeah, >>Yeah, yeah. We had quite a few, like the, the two largest ones is a, we now have a field Kubernetes integration on Grafana Cloud. So our, our approach is generally extremely open source first. So we try to push stuff into the exporters, like into the open source exporters, into mixes into things which are out there as open source for anyone to use. But that's little bit like a tool set, not a ready made solution. So when we talk integrations, we actually talk about things where you get this like one click experience, You log into your Grafana cloud, you click, I have a Kubernetes, which probably most of us have, and things just work like you in just the data. You have to write dashboards, you have to write alerts, you have to write everything to just get started with extremely opinionated dashboards, SLOs, alerts, again, all those things made by experts, so anyone can use them. And you don't have to reinvent the view for every single user. So that's the one. The other is, >>It's a big deal. >>Oh yeah, it is. Yeah. It is. It, we, we has, its heavily in integrations course. While, I mean, I don't have to convince anyone that perme is a DD factor standard in everything. Cloudnative. But again, it's, it's, it's sometimes a little bit hard to handle or a little bit not easy to get into. So, so smoothing this, this, this path onto onboarding yourself onto this stack and onto those types of solutions. Yes. Is what a lot of people need. Course, if you, if you look at the statistics from coupon, and we just heard this in the governing board session yesterday. Yeah. Like 60% of the people here are first time attendees. So there's a lot of people who just come into this thing and who need, like, this is your path. This is where you should be going. Or at least if you want to go, go there. This is how to get there. >>Here's your runway for takeoff. Yes. Yeah. I think that's a really good point. And I love that you, you had those numbers. I was curious. I, I had seen on Twitter, speaking of Twitter, I had seen, I had seen that, that there were a lot of people here coming for the first time. You're a community guy. Are we at an inflection point where this community is about to continue to scale? >>That's a very good question. Which I can't really answer. So I mean, >>Obviously I bet you're gonna try. >>I covid changed a few things. Yeah. Probably most people, >>A couple things. I mean, you know, casually, it's like such a gentle way of putting that, that was >>Beautiful. I'm gonna say yes, just to explode. All these new ERs are gonna learn Prometheus. They're gonna roll in with a open, open metrics, open telemetry. I love it, >>You know, But, but at the same time, like Cuban is, is ramping back up. But if you look at the, if you look at the registration numbers between Valencia Andro, it was more or less the same. Interesting. Which, so it didn't go onto this, onto this flu trajectory, which it was on like, up to, up to 2019. I expect this to take up again. But also with the economic situation, everything, I, I don't think >>It's, I think the jury's still out on hybrid. I think there's a lot, lot more hybrid. Let's see how the projects are gonna go. That's what I think it's gonna be the tell sign. How many people are in participating? How are the project's advancing? Some of the momentum, >>I mean, from the project level, Most of this is online anyway. Of course. That's how open source, right. I've been working for >>Ages. That's >>Cause you don't have any trouble budget or, or any office or, It's >>Always been that way. >>Yeah, precisely. So the projects are arguably spearheading this, this development and the, the online numbers. I I, I have some numbers in my head, but I'm, I'm not a hundred percent certain to, but they're higher for this time in Detroit than in volunteer as far somewhere. Cool. So that is growing and it's grown in parallel, which also is great. Cause it's much more accessible, much more inclusive. You don't have to have a budget of at least, let's say, I don't know, two to five k to, to fly over the pond and, and attend this thing. You can just do it from your home. So that is, that's a lot more inclusive. And I expect this to, to basically be a second more or less orthogonal growth, growth path. But the best thing about coupon is the hallway track. I'm just meeting people, talking to people and that kind of thing is not really possible with, >>It's, it's great to see people >>In person. No, and it makes such a difference. I mean, yeah. Even and interviewing people in person too. I mean, it does a, it's, it's, and, and this, this whole, I mean cncf, this whole community, every company here is community first. It's how these projects come to be. I think it's awesome. I feel like you got something you're saying to say, Johnny. >>Yeah. And I love some of the advancements. Rich Richie, we talked last time about, you know, open telemetry, open metrics. You're involved in dashboards. Yeah. One of the themes here is ease of use, simplicity, developer productivity. Where do you see the ease of use going from a project standpoint? For me, as you mentions everywhere, it's pretty much, it is, it's almost all corners of the world. Yep. And new people coming in. How, how are you making it easier? What's going on? Give us the update on that. >>So we also, funnily enough at precisely this topic in the TC panel just a few hours ago, about ease of use and about how to, how to make things easier to, to handle how developers currently, like if they just want to get into the cloud native seen, they have like, like we, we did some neck and math, like maybe 10 tools at least, which you have to be somewhat proficient in to just get started, which is honestly horrendous. Yeah. Course. Like with a server, I just had my survey install my thing and it runs, maybe I need a database, but that's roughly it. And this needs to change again. Like it's, it's nice that everything is, is un unraveled. And you have, you, you, you, you don't have those service boundaries which you had before. You can do all the horizontal scaling, you can do all the automatic scaling, all those things that they're super nice. But at the same time, this complexity, which used to be nicely compartmentalized, was deliberately broken up. And so it's becoming a lot harder to, to, like, we, we need to find new ways to compartmentalize this complexity back to, to human understandable levels again, in particular, as we keep onboarding new and new and new, new people, of course it's just not good use of anyone's time to, to just like learn the basics again and again and again. This is something which should be just compartmentalized and automated away. We're >>The three, We were talking to Matt Klein earlier and he was talking about as projects become mature and all over the place and have reach and and usage, you gotta work on the boring stuff. Yes. And when it's boring, that means you have success. Yes. But then you gotta work on the plumbing. What are some of the things that you guys are working on? Because people are relying on the product. >>Oh yeah. So for with my premises head on, the highlight feature is exponential or native or spars. Histograms. There's like three different names for one single concept. If you know Prometheus, you ha you currently have hard bucket boundaries where I say my latency is lower equal two seconds, one second, a hundred milliseconds, what have you. And I can put stuff into those histogram buckets accordingly to those predefined levels, which is extremely efficient, but like on the, on the code level. But it's not very nice for the humans course you need to understand your system before you're able to, to, to choose good cutoff points. And if you, if you, if you add new ones, that's completely fine. But if you want to actually change them, course you, you figured out that you made a fundamental mistake, you're going to have a break in the continue continuity of your observability data. And you cannot undo this in, into the past. So this is just gone native histograms. On the other hand, allow me to, to, okay, I'm not going to get get into the math, but basically you define a single formula, which there comes a good default. If you have good reasons, then you can change it. But if you don't, just don't talk, >>The people are in the math, Hit him up on Twitter. Twitter, h you'll get you that math. >>So the, >>The thing is people want the math, believe me. >>Oh >>Yeah. I mean we don't have time, but hit him up. Yeah. >>There's ProCon in two weeks in Munich and there will be whole talk about like the, the dirty details of all of the stuff. But the, the high level answer is it just does what people would expect it to do. And with very little overhead, you become, you get highly, highly or high resolution histograms, which is really important for a lot of use cases. But this is not just Prometheus with my open metrics head on the 2.0 feature, like the breaking highlight feature of Open Metrics 2.0 will be you guested precisely the same with my open telemetry head on. Low and behold the same underlying technology is being put or has been put into open telemetry. And we've worked for month and month and month and even longer between all different projects to, to assert that we have one single standard which is actually compatible with each other course. One of the worst things which you can have in the cloud ecosystem is if you have soly different things and they break in subtly wrong ways, like it's much better to just not work than to break in a way, which is just a little bit wrong. Of course you won't figure this out until it's too late. So we spent, like with all three hats, we spent insane amounts of time on making this happen and, and making this nice. >>Savannah, one of the things we have so much going on at Cube Con. I mean just you're unpacking like probably another day of cube. We can't go four days, but open time. >>I know, I know. I'm the same >>Open telemetry >>Challenge acceptance open. >>Sorry, we're gonna stay here. All the, They >>Shut the lights off on us last night. >>They literally gonna pull the plug on us. Yeah, yeah, yeah, yeah. They've done that before. It's not the first time we go until they kick us out. We love, love doing this. But Open telemetry is got a lot of news too. So that's, We haven't really talked much about that. >>We haven't at >>All. So there's a lot of stuff going on that, I won't call it boring. That's like code word's. That's cube talk for, for it's working. Yeah. So it's not bad, but there's a lot of stuff going on. Like open telemetry, open metrics, This is the stuff that matters cuz when you go in large scale, that's key. It's just what, missing all the, all the stuff. >>No, >>What are we missing? What are people missing? What's going on in the show that you think that's not actually being reported on? I mean it's a lot of high web assembly for instance got a lot >>Of high. Oh yeah, I was gonna say, I'm glad you're asking this because you, you've already mentioned about seven different hats that you wear. I can only imagine how many hats are actually in your hat cabinet. But you, you are someone with your, with your fingers in a lot of different things. So you can kind of give us a state of the union. Yeah. So go ahead. Let's talk about >>It. So I think you already hit a few good points. Ease of use is definitely one of them. And, and improving the developer experience and not having this like a value of pain. Yeah. That is one of the really big ones. It's going to be interesting cause it is boring. It is janitorial and it needs a different type of persona. A lot of, or maybe not most, but a large fraction of developers like the shiny stuff. And we could see this in Prometheus where like initially the people who contributed this the most where like those restless people who need to fix that one thing, this is impossible, are going to do it. Which changed over the years where the people who now contribute the most are off the janitorial. Like keep things boring, keep things running, still have substantial changes. But but not like more on the maintenance level. >>Yeah. The maintainers. I was just gonna bring that >>Up. Yeah. On the, on the keep things boring while still pushing 'em forward. Yeah. And the thing about ease of use is a lot of this is boring. A lot of this is strategy. A lot of this is toil. A lot of this takes lots of research also in areas where developers are not really good at, like UX for example, and ui like most software developers are really bad at those cause they just think differently from normal humans, I guess. >>So that's an interesting observation that you just made. I we could unpack that on a whole nother show as well. >>So the, the thing is this is going to be interesting for the open source scene course. This needs deliberate investment by companies who assign people to those projects and say, okay, fix that one thing or make it easier to use what have you. That is a lot easier with, with first party products and projects from companies cuz they can invest directly into the thing and they see much more of a value prop. It's, it's kind of normal by now to, to allow developers or even assigned developers onto open source projects. That's not so much the case for the tpms, for the architects, for the UX and your I people like for the documentation people that there's not as much awareness of that this is also driving value for everyone. Yes. And also there's not much as much. >>Yeah, that's a great point. This whole workflow production system of open source, which has grown and keeps growing and we'll keep growing. These be funded. And one of the things we were talking earlier in another session about is about the recession potentially we're hitting and the global issues, macroeconomics that might force some of these projects or companies not to get VC >>Funding. It's such a theme at the show. So, >>So to me, I said it's just not about VC funding. There's other funding mechanisms that's community oriented. There's companies participating, there's other meccas. Richie, if you could have your wishlist of how things could progress an open source, what would you want to see happen in terms of how it's, how things are funded, how things are executed. Cuz developers are going to run businesses. Cuz ultimately if you follow digital transformation to completion, it and developers aren't a department serving the business. They are the business. And that's coming fast. You know, what has to happen in your opinion, if you had the wish magic wand, what would you, what would you snap your fingers to make happen? >>If I had a magic wand that's very different from, from what is achievable. But let, let's >>Go with, Okay, go with the magic wand first. Cause we'll, we'll, we'll we'll riff on that. So >>I'm here for dreams. Yeah, yeah, >>Yeah. I mean I, I've been in open source for more than two, two decades, but now, and most of the open source is being driven forward by people who are not being paid for those. So for example, Gana is the first time I'm actually paid by a company to do my com community work. It's always been on the side. Of course I believe in it and I like doing it. I'm also not bad at it. And so I just kept doing it. But it was like at night on the weekends and everything. And to be honest, it's still at night and in the weekends, but the majority of it is during paid company time, which is awesome. Yeah. Most of the people who have driven this space forward are not in this position. They're doing it at night, they're doing it on the weekends. They're doing it out of dedication to a cause. Yeah. >>The commitment is insane. >>Yeah. At the same time you have companies mostly hyperscalers and either they have really big cloud offerings or they have really big advertisement business or both. And they're extracting a huge amount of value, which has been created in large part elsewhere. Like yes, they employ a ton of developers, but a lot of the technologies they built on and the shoulders of the giants they stand upon it are really poorly paid. And there are some efforts to like, I think the core foundation like which redistribute a little bit of money and such. But if I had my magic wand, everyone who is an open source and actually drives things forwards, get, I don't know, 20% of the value which they create just magically somehow. Yeah. >>Or, or other companies don't extract as much value and, and redistribute more like put more full-time engineers onto projects or whichever, like that would be the ideal state where the people who actually make the thing out of dedication are not more or less left on the sideline. Of course they're too dedicated to just say, Okay, I'm, I'm not doing this anymore. You figure this stuff out and let things tremble and falter. So I mean, it's like with nurses and such who, who just like, they, they know they have something which is important and they keep doing it. Of course they believe in it. >>I think this, I think this is an opportunity to start messaging this narrative because yeah, absolutely. Now we're at an inflection point where there's a big community, there is a shared responsibility in my opinion, to not spread the wealth, but make sure that it's equally balanced and, and the, and I think there's a way to do that. I don't know how yet, but I see that more than ever, it's not just come in, raid the kingdom, steal all the jewels, monetize it, and throw some token token money around. >>Well, in the burnout. Yeah, I mean I, the other thing that I'm thinking about too is it's, you know, it's, it's the, it's the financial aspect of this. It's the cognitive load. And I'm curious actually, when I ask you this question, how do you avoid burnout? You do a million different things and we're, you know, I'm sure the open source community that passion the >>Coach. Yeah. So it's just write code, >>It's, oh, my, my, my software engineering days are firmly over. I'm, I'm, I'm like, I'm the cat herer and the janitor and like this type of thing. I, I don't really write code anymore. >>It's how do you avoid burnout? >>So a i I didn't curse ahead burnout a few years ago. I was not nice, but that was still when I had like a full day job and that day job was super intense and on top I did all the things. Part of being honest, a lot of the people who do this are really dedicated and are really bad at setting boundaries between work >>And process. That's why I bring it up. Yeah. Literally why I bring it up. Yeah. >>I I I'm firmly in that area and I'm, I'm, I don't claim I have this fully figured out yet. It's also even more risky to some extent per like, it's, it's good if you're paid for this and you can do it during your work time. But on the other hand, if it's so nice and like if your hobby and your job are almost completely intersectional, it >>Becomes really, the lines are blurry. >>Yeah. And then yeah, like have work from home. You, you don't even commute anything or anymore. You just sit down at your computer and you just have fun doing your stuff and all of a sudden it's deep at night and you're still like, I want to keep going. >>Sounds like God, something cute. I >>Know. I was gonna say, I was like, passion is something we all have in common here on this. >>That's the key. That is the key point There is a, the, the passion project becomes the job. But now the contribution is interesting because now yeah, this ecosystem is, is has a commercial aspect. Again, this is the, this is the balance between commercialization and keeping that organic production system that's called open source. I mean, it's so fascinating and this is amazing. I want to continue that conversation. It's >>Awesome. Yeah. Yeah. This is, this is great. Richard, this entire conversation has been excellent. Thank you so much for joining us. How can people find you? I mean, I give em your Twitter handle, but if they wanna find out more about Grafana Prometheus and the 1700 things you do >>For grafana grafana.com, for Prometheus, promeus.io for my own stuff, GitHub slash richie age slash talks. Of course I track all my talks in there and like, I don't, I currently don't have a personal website cause I stop bothering, but my, like that repository is, is very, you find what I do over, like for example, the recording link will be uploaded to this GitHub. >>Yeah. Great. Follow. You also run a lot of events and a lot of community activity. Congratulations for you. Also, I talked about this last time, the largest IRC network on earth. You ran, built a data center from scratch. What happened? You done >>That? >>Haven't done a, he even built a cloud hyperscale compete with Amazon. That's the next one. Why don't you put that on the >>Plate? We'll be sure to feature whatever Richie does next year on the cube. >>I'm game. Yeah. >>Fantastic. On that note, Richie, again, thank you so much for being here, John, always a pleasure. Thank you. And thank you for tuning in to us here live from Detroit, Michigan on the cube. My name is Savannah Peterson and here's to hoping that you find balance in your life this weekend.

(upbeat music) >> Good Friday morning everyone from Motor City, Lisa Martin here with John Furrier. This is our third day, theCUBE's third day of coverage of KubeCon + CloudNativeCon 22' North America. John, we've had some amazing conversations the last three days. We've had some good conversations about observability. We're going to take that one step further and look beyond its three pillars. >> Yeah, this is going to be a great segment. Looking forward to this. This is about in depth conversation on observability. The guest is technical and it's on the front lines with customers. Looking forward to this segment. Should be great. >> Yeah. Ian Smith is here, the field CTO at Chronosphere. Ian, welcome to theCUBE. Great to have you. >> Thank you so much. It's great to be here. >> All right. Talk about the traditional three pillars, approach, and observability. What are some of the challenges with that, and how does Chronosphere solve those? >> Sure. So hopefully everyone knows people think of the three pillars as logs, metrics and traces. What do you do with that? There's no action there. It's just data, right? You collect this data, you go put it somewhere, but it's not actually talking about any sort of outcomes. And I think that's really the heart of the issue, is you're not achieving anything. You're just collecting a whole bunch of data. Where do you put it? What are you... What can you do with it? Those are the fundamental questions. And so one of the things that we're focused on at Chronosphere is, well, what are those outcomes? What is the real value of that? And for example, thinking about phases of observability. When you have an incident or you're trying to investigate something through observability, you probably want to know what's going on. You want to triage any problems you detect. And then finally, you want to understand the cause of those and be able to take longer term steps to address them. >> What do customers do when they start thinking about it? Because observability has that promise. Hey, you know, get the data, we'll throw AI at it. >> Ian: Yeah. >> And that'll solve the problem. When they get over their skis, when do they realize that they're really not tackling it properly, or the ones that are taking the right approach? What's the revelation? What's your take on that? You're in the front lines. What's going on with the customer? The good and the bad. What's the scene look like? >> Yeah, so I think the bad is, you know, you end up buying a lot of things or implementing even in open source or self building, and it's very disconnected. You're not... You don't have a workflow, you don't have a path to success. If you ask different teams, like how do you address these particular problems? They're going to give you a bunch of different answers. And then if you ask about what their success rate is, it's probably very uneven. Another key indicator of problems is that, well, do you always need particular senior engineers in your instance or to help answer particular performance problems? And it's a massive anti pattern, right? You have your senior engineers who are probably need to be focused on innovation and competitive differentiation, but then they become the bottleneck. And you have this massive sort of wedge of maybe less experienced engineers, but no less valuable in the overall company perspective, who aren't effective at being able to address these problems because the tooling isn't right, the workflows are incorrect. >> So the senior engineers are getting pulled in to kind of fix and troubleshoot or observe what the observability data did or didn't deliver. >> Correct. Yeah. And you know, the promise of observability, a lot of people talk about unknown unknowns and there's a lot of, you know, crafting complex queries and all this other things. It's a very romantic sort of deep dive approach. But realistically, you need to make it very accessible. If you're relying on complex query languages and the required knowledge about the architecture and everything every other team is doing, that knowledge is going to be super concentrated in just a couple of heads. And those heads shouldn't be woken up every time at 3:00 AM. They shouldn't be on every instant call. But oftentimes they are the sort of linchpin to addressing, oh, as a business we need to be up 99.99% of the time. So how do we accomplish that? Well, we're going to end up burning those people. >> Lisa: Yeah. >> But also it leads to a great dissatisfaction in the bulk of the engineers who are, you know, just trying to build and operate the services. >> So talk... You mentioned that some of the problems with the traditional three pillars are, it's not outcome based, it leads to silo approaches. What is Chronosphere's definition and can you walk us through those three phases and how that really gives you that competitive edge in the market? >> Yeah, so the three phases being know, triage and understand. So just knowing about a problem, and you can relate this very specifically to capabilities, but it's not capabilities first, not feature function first. So know, I need to be able to alert on things. So I do need to collect data that gives me those signals. But particularly as you know, the industry starts moving towards as slows. You start getting more business relevant data. Everyone knows about alert storms. And as you mentioned, you know, there's this great white hope of AI and machine learning, but AI machine learning is putting a trust in sort of a black box, or the more likely reality is that really statistical model. And you have to go and spend a very significant amount time programming it for sort of not great outcomes. So know, okay, I want to know that I have a problem, I want to maybe understand the symptoms of that particular problem. And then triage, okay, maybe I have a lot of things going wrong at the same time, but I need to be very precise about my resources. I need to be able to understand the scope and importance. Maybe I have five major SLOs being violated right now. Which one is the greatest business impact? Which symptoms are impacting my most valuable customers? And then from there, not getting into the situation, which is very common where, okay, well we have every... Your customer facing engineering team, they have to be on the call. So we have 15 customer facing web services. They all have to be on that call. Triage is that really important aspect of really mitigating the cost to the organization because everyone goes, oh, well I achieved my MTTR and my experience from a variety of vendors is that most organizations, unless you're essentially failing as a business, you achieve your SLA, you know, three nines, four nines, whatever it is. But the cost of doing that becomes incredibly extreme. >> This is huge point. I want to dig into that if you don't mind, 'cause you know, we've been all seeing the cost of ownership miles in it all, the cost of doing business, cost of the shark fan, the iceberg, what's under the water, all those metaphors. >> Ian: Yeah. >> When you look at what you're talking about here, there are actually, actually real hardcore costs that might be under the water, so to speak, like labor, senior engineering time, 'cause Cloud Native engineers are coding in the pipelines. A lot of impact. Can you quantify and just share an example or illustrate where the costs are? 'Cause this is something that's kind of not obvious. >> Ian: Yeah. >> On the hard costs. It's not like a dollar amount, but time resource breach, wrong triage, gap in the data. What are some of the costs? >> Yeah, and I think they're actually far more important than the hard costs of infrastructure and licensing. And of course there are many organizations out there using open source observability components together. And they go, Oh it's free. No licensing costs. But you think again about those outcomes. Okay, I have these 15 teams and okay, I have X number of incidents a month, if I pull a representative from every single one of those teams on. And it turns out that, you know, as we get down in further phases, we need to be able to understand and remediate the issue. But actually only two teams required of that. There's 13 individuals who do not need to be on the call. Okay, yes, I met my SLA and MTTR, but if I am from a competitive standpoint, I'm comparing myself to a very similar organization that only need to impact those two engineers versus the 15 that I had over here. Who is going to be the most competitive? Who's going to be most differentiated? And it's not just in terms of number of lines of code, but leading to burnout of your engineers and the churn of that VPs of engineering, particularly in today's economy, the hardest thing to do is acquire engineers and retain them. So why do you want to burn them unnecessarily on when you can say, okay, well I can achieve the same or better result if I think more clearly about my observability, but reduce the number of people involved, reduce the number of, you know, senior engineers involved, and ultimately have those resources more focused on innovation. >> You know, one thing I want, at least want get in there, but one thing that's come up a lot this year, more than I've ever seen before, we've heard about the skill gaps, obviously, but burnout is huge. >> Ian: Yes. >> That's coming up more and more. This is a real... This actually doesn't help the skills gap either. >> Ian: Correct. >> Because you got skills gap, that's a cost potentially. >> Ian: Yeah. >> And then you got burnout. >> Ian: Yeah. >> People just kind of sitting on their hands or just walking away. >> Yeah. So one of the things that we're doing with Chronosphere is, you know, while we do deal with the, you know, the pillar data, but we're thinking about it more, what can you achieve with that? Right? So, and aligning with the know, triage and understand. And so you think about things like alerts, you know, dashboards, you be able to start triaging your symptoms. But really importantly, how do we bring the capabilities of things like distributed tracing where they can actually impact this? And it's not just in the context of, well, what can we do in this one incident? So there may be scenarios where you, absolutely do need those power users or those really sophisticated engineers. But from a product challenge perspective, what I'm personally really excited about is how do you capture that insight and those capabilities and then feed that back in from a product perspective so it's accessible. So you know, everyone talks about unknown unknowns in observability and then everyone sort of is a little dismissive of monitoring, but monitoring that thing, that democratizes access and the decision making capacity. So if you say I once worked at an organization and there were three engineers in the whole company who could generate the list of customers who were impacted by a particular incident. And I was in post sales at the time. So anytime there was a major incident, need to go generate that list. Those three engineers were on every single incident until one of them got frustrated and built a tool. But he built it entirely on his own. But can you think from an observability perspective, can you build a thing that it makes all those kinds of capabilities accessible to the first point where you take that alert, you know, which customers are affected or whatever other context was useful last time, but took an hour, two hours to achieve. And so that's what really makes a dramatic difference over time, is it's not about the day one experience, but how does the product evolve with the requirements and the workflow- >> And Cloud Native engineers, they're coding so they can actually be reactive. That's interesting, a platform and a tool. >> Ian: Yes. >> And platform engineering is the hottest topic at this event. And this year, I would say with Cloud Native hearing a lot more. I mean, I think that comes from the fact that SREs not really SRE, I think it's more a platform engineer. >> Ian: Yes. >> Not everyone's an... Not company has an SRE or SRE environment. But platform engineering is becoming that new layer that enables the developers. >> Ian: Correct. >> This is what you're talking about. >> Yeah. And there's lots of different labels for it, but I think organizations that really think about it well they're thinking about things like those teams, that developer efficiency, developer productivity. Because again, it's about the outcomes. It's not, oh, we just need to keep the site reliable. Yes, you can do that, but as we talked about, there are many different ways that you can burn unnecessary resources. But if you focus on developer efficiency and productivity, there's retainment, there's that competitive differentiation. >> Let's uplevel those business outcomes. Obviously you talked about in three phases, know, triage and understand. You've got great alignment with the Cloud Native engineers, the end users. Imagine that you're facilitating company's ability to reduce churn, attract more talent, retain talent. But what are some of the business outcomes? Like to the customer experience to the brand? >> Ian: Sure. >> Talk about it in some of those contexts. >> Yeah. One of the things that not a lot of organizations think about is, what is the reliability of my observability solution? It's like, well, that's not what I'm focused on. I'm focused on the reliability of my own website. Okay, let's take the, common open source pattern. I'm going to deploy my observability solution next to my core site infrastructure. Okay, I now have a platform problem because DNS stopped working in cloud provider of my choice. It's also affecting my observability solution. So at the moment that I need- >> And the tool chain and everything else. >> Yeah. At the moment that I need it the most to understand what's going on and to be able to know triage and understand that fails me at the same time. It's like, so reliability has this very big impact. So being able to make sure that my solution's reliable so that when I need it the most, and I can affect reliability of my own solution, my own SLA. That's a really key aspect of it. One of the things though that we, look at is it's not just about the outcomes and the value, it's ROI, right? It's what are you investing to put into that? So we've talked a little bit about the engineering cost, there's the infrastructure cost, but there's also a massive data explosion, particularly with Cloud Native. >> Yes. Give us... Alright, put that into real world examples. A customer that you think really articulates the value of what Chronosphere is delivering and why you're different in the market. >> Yeah, so DoorDash is a great customer example. They're here at KubeCon talking about their experience with Chronosphere and you know, the Cloud Native technologies, Prometheus and those other components align with Chronosphere. But being able to undergo, you know, a transformation, they're a Cloud Native organization, but going a transformation from StatsD to very heavy microservices, very heavy Kubernetes and orchestration. And doing that with your massive explosion, particularly during the last couple of years, obviously that's had a very positive impact on their business. But being able to do that in a cost effective way, right? One of the dirty little secrets about observability in particular is your business growth might be, let's say 50%, 60%, your infrastructure spend in the cloud providers is maybe going to be another 10, 15% on top of that. But then you have the intersection of, well my engineers need more data to diagnose things. The business needs more data to understand what's going on. Plus we've had this massive explosion of containers and everything like that. So oftentimes your business growth is going to be more than doubled with your observability data growth and SaaS solutions and even your on-premises solutions. What's the main cost driver? It's the volume of data that you're processing and storing. And so Chronosphere one of the key things that we do, because we're focused on organizational pain for larger scale organizations, is well, how do we extract the maximum volume of the data you're generating without having to store all of that data and then present it not just from a cost perspective, but also from a performance perspective. >> Yes. >> John: Yeah. >> And so feeding all into developer productivity and also lowering that investment so that your return can stand out more clearly and more valuably when you are assessing that TCO. >> Better insights and outcomes drives developer productivity for sure. That also has top theme here at KubeCon this year. It always is, but this is more than ever 'cause of the velocity. My question for you, given that you're the field chief technology officer for Chronosphere and you have a unique position, you've got a great experience in the industry, been involved in some really big companies and cutting edge. What's the competitive landscape? 'Cause the customers sometimes are confused by all the pitches they're getting from other vendors. Some are bolting on observability. Some have created like I would say, a shim layer or horizontally scalable platform or platform engineering approach. It's a data problem. Okay. This is a data architecture challenge. You mentioned that many times. What's the difference between a pretender and a player in this space? What's the winning architecture look like? What's a, I won't say phony or fake solution, but ones that customers should be aware of? Because my opinion, if you have a gap in the data or you configure it wrong, like a bolt on and say DNS crashes you're dead in the water. >> Ian: Yeah. >> What's the right approach from a customer standpoint? How do they squint through all the noise to figure out what's the right approach? >> Yeah, so I mean, I think one of the ways, and I've worked with customers in a pre-sales capacity for a very long time I know all the tricks of guiding you through. I think it needs to be very clear that customers should not be guided by the vendor. You don't talk to one vendor and they decide, Oh, I'm going to evaluate based off this. We need to particularly get away from feature based evaluations. Features are very important, but they're all have to be aligned around outcomes. And then you have to clearly understand, where am I today? What do I do today? And what is going to be the transformation that I have to go through to take advantage of these features? They can get very entrancing to say, Oh, there's a list of 25 features that this solution has that no one else has, but how am I going to get value out of that? >> I mean, distributed tracing is a distributed word. Distributed is the key word. This is a system architecture. The holistic big picture comes in. How do they figure that out? Knowing what they're transforming into? How does it fit in? >> Ian: Yeah. >> What's the right approach? >> Too often I say distributed tracing, particularly, you know, bought, because again, look at the shiny features look at the the premise and the MTTR expectations, all these other things. And then it's off to the side. We go through the traditional usage of metrics very often, very log heavy approaches, maybe even some legacy APM. And then it's sort of at last resort. And out of all the tools, I think distributed tracing is the worst in the problem we talked about earlier where the most sophisticated engineers, the ones who are being longest tenured, are the only ones who end up using it. So adoption is really, really poor. So again, what do we do today? Well, we alert, we probably want to understand our symptoms, but then what is the key problem? Oh, we spend a lot of time digging into the where the problem exists in my architecture, we talked about, you know, getting every engineer in at the same time, but how do we reduce the number of engineers involved? How do we make it so that, well, this looks like a great day one experience, but what is my day 30 experience like? Day 90. How is the product get more valuable? How do I get my most senior engineers out of this, not just on day one, but as we progress through it? >> You got to operationalize it. That's the key. >> Yeah, Correct. >> Summarize this as we wrap here. When you're in customer conversations, what is the key factor behind Chronosphere's success? If you can boil it down to that key nugget, what is it? >> I think the key nugget is that we're not just fixated on sort of like technical features and functions and frankly gimmicks of like, Oh, what could you possibly do with these three pillars of data? It's more about what can we do to solve organizational pain at the high level? You know, things like what is the cost of these solutions? But then also on the individual level, it's like, what exactly is an engineer trying to do? And how is their quality of life affected by this kind of tooling? And it's something I'm very passionate about. >> Sounds like it. Well, the quality of life's important, right? For everybody, for the business, and ultimately ends up affecting the overall customer experience. So great job, Ian, thank you so much for joining John and me talking about what you guys are doing beyond the three pillars of observability at Chronosphere. We appreciate your insights. >> Thank you so much. >> John: All right. >> All right. For John Furrier and our guest, I'm Lisa Martin. You're watching theCUBE live Friday morning from KubeCon + CloudNativeCon 22' from Detroit. Our next guest joins theCUBE momentarily, so stick around. (upbeat music)

>>Good afternoon everyone, and welcome back to Cuan where my cohost John Farer and I are broadcasting live, along with Lisa Martin from Cuan Detroit, Michigan. We are joined this afternoon by two very interesting gentlemen who also happen to be legends on the cube. John, how long have you known the next few? They've, >>They've made their mark on the cube with Jerry Chen from Greylock was one of our most attended cube guests. He's a VC partner at Greylock and an investor and this company that just launched their new cloud observability platform should be a great segment. >>Well, I'm excited. I are. Are you excited? Should I string this out just a little bit longer? No, I won't. I won't do that to you. Please welcome Martin and Jeff from Chronosphere Martin. Jeff, thank you so much for being >>Here. Thank you for having us. Thank you. >>I noticed right away that you have raised a mammoth series C. Yeah. 200 million if I'm not mistaken. >>That is correct. >>Where's the company at? >>Yeah, so we raised that series C a year ago. In fact, we were just talking about it a year ago at Cub Con. Since then, at the time we're about 80 employees or so. Since then, we've tripled the headcount, so we're over 200 people. Casual, triple casual, triple of the headcount. Yeah. Luckily it was the support of business, which is also tripled in the last year. So we're very lucky from that perspective as well. And a couple of other things we're pretty proud of last year. We've had a hundred percent customer retention, which is always a great thing to have as a SaaS platform there. >>Real metric if you've had a hundred percent. I'm >>Kidding. It's a good metric to, to put out there if you had a hundred percent. I would say for sure. It's an A for sure and exactly welcome to meet >>Anyone else who's had a hundred percent >>Customer attention here at coupon this week and 90% of our customers are using more of the service and, and you know, therefore paying more for the service as well. So those are great science for us and I think it shows that we're clearly doing something right on the product side. I would say. And >>Last and last time you're on the cube. We're talking about about the right data. Not so much a lot of data, if I remember correctly. Yeah, a hundred percent. And that was a unique approach. Yeah, it's a data world on relative observability. And you guys just launched a new release of your platform, cloud native platform. What's new in the platform? Can you share an update on what you guys release? >>Yeah, well we did and, and you, you bring up a great point. You know, like it's not just in observably but overall data is exploding. Alright, so three things there. It's like, hey, can your platform even handle the explosion of data? Can it control it over time and make sure that as your business grows, the data doesn't continue explode at the same time. And then for the end users, can they make sense of all this data? Cuz what's the point of having it if the end users can't make sense of it? So actually our product announcement this time is a pretty big refresh of, of a lot of features in our, in our platform. And it actually tackles all three of these particular components. And I'll let Jeff, our head of product, Doug, >>You, you run product, you get the keys to the kingdom, I do product roadmap. People saying, Hey this, take this out. You're under a lot of pressure. What makes the platform platform a great observability product? >>So the keystone of what we do that's different is helping you control the data, right? As we're talking about there's an infinite amount of data. These systems are getting more and more and more complicated. A lot of what we do is help you understand the utility of the telemetry so that you can optimize for keeping and storing and paying for the data that's actually helpful as opposed to the stuff that isn't. >>What's the benefit now with observability, with all the noise out in the marketplace, there's been a shift over the past couple years. Cloud native at scale, you're seeing a lot more automation, almost a set to support the growth for more application development. We had a Docker CEO on earlier today, he said there are more applications being deployed in the past year than in the history of open source. So more and more apps are being deployed, more data's being generated. What's the key to observability right now that's gonna separate the winners from the losers? >>Yeah, I think, you know, not only are there more applications being deployed, but there are smaller and small applications being deployed mostly on containers these days more than if they, hence this conference gets larger and larger every year. Right? So, you know, I think the key is a can your system handle this data explosion is, is the first thing. Not only can it handle the data explosion, but you know, APM solutions have been around for a very long time and those were really introspecting into an application. Whereas these days what's more important is, well how is your application interfacing with every other application in your distributed architecture there, right? So the use case is slightly different there. And then to what Jeff was saying is like once the data is there, not only making use of what is actually useful to you, but then having the end user make sense of it. >>Because we, we, we always think about the technology changes. We forget that the end users are different now we used to have IT operations team operating everything and the developers would write the application, just throw it over the wall. These days the developers have to actually operate this thing in production. So the end users of these systems are very different as well. And you can imagine these are folks, your average developer as maybe not operated things for many years in production before. So they need to, that they need to pick up a new skill set, they need to use new tooling in order to, to do that. So yeah, it's, it's, >>And you got the developer persona, you got a developer that's building products for builders and developers that are building products to be consumed. So they're not, they're not really infrastructure builders, they're just app developers. >>Exactly. Exactly. That's right. And that's what a lot of the new functionality that we're introducing here at the show is all about is helping developers who build software by day and are on call by night, actually get in context. There's so much data chances of when that, when one of those pages goes off and your number comes up, that the problem happens to be in the part of the system that you know a lot about are pretty low, chances are you're gonna get bothered about something else. So we've built a feature, we call it collections that's about putting you in the right context and connecting you into the piece of the system where the problem is to orient you and to get you started. So instead of waiting through, through hundreds of millions of things, you're waiting through the stuff that's in the immediate neighborhood of where the >>Problem is. Yeah. To your point about data, you can't let it go unchecked. That's right. You gotta gotta understand that. And we were talking about containers again with, again with docker, you know, nuance point, but oh, scan your container. But not everyone's scanning the containers security nightmare, right? I mean, >>Well I think one of the things that I, I loved in reading the notes in preparation for you coming up is you've actually created cloud native observability with the goal of eliminating engineering burnout. And what you're talking about there is actually the cognitive burden of when things happen. Yeah, for sure. We we're, you know, we're not just designing for when everything goes right, You need to be prepared for when everything goes wrong and that poor lonely individual in the middle of the night has, it's >>A tough job. >>Has to navigate that >>And, and observability is just one thing you gotta mean like security is another thing. So, so many more things have been piled on top of the developer in addition to actually creating the application. Right? It is. There is a lot. And you know, observably is one of those key things you need to do your job. So as much as, as much as we can make that easier, that's a better bit. Like there are so many things being piled on right now. >>That's the holy grail right there. Because they don't want to be doing exactly >>The work. Exactly. They're not observability experts. >>Exactly. And automating that in. So where do you guys weigh in on the automation wave? Everything's automation. Yeah. Is that kind of a hand waving or what's going on? What's the reality? What's actually happening? >>Yeah, I think automation I think is key. You hear a lot of ai ml ops there. I, I don't know if I really believe in that or having a machine self heal itself or anything like that. But I think automation is key because there are a lot of repeatable tasks in a lot of what you're doing. So once you detect that something goes wrong, generally if you've seen it before, you know what the fix is. So I think automation plays a key on the sense that once it's detected again the second time, the third time, okay, I know what I did the previous time, let, let's make sure we can do that again. So automation I think is key. I think it helps a lot with the burnout. I dunno if I'd go as far as the >>Same burnout's a big deal. >>Well there's an example again in the, in the stuff we're releasing this week, a new feature we call query accelerator. That's a form of automation. Problem is you got all this data, mountain of data, put you in the right context so you're at least in the right neighborhood, but now you need to query it. You gotta get the data to actually inform the specific problem you're trying to solve. And the burden on the developer in that situation is really high. You have to know what you're looking for and you have to know how to efficiently ask for it. So you're not waiting for a long time and >>We >>Built a feature, you tell us what you want, we will figure out how to get it for you efficiently. That's the kind of automation that we're focused on. That's actually a good service. How can we, it >>Sounds >>Blissful. How can we accelerate and optimize what you were gonna do anyway, rather than trying to read your mind or predict the future. >>Yes, >>Savannah, some community forward. Yeah, I, I'm, so I'm curious, you, you clearly lead with a lot of empathy, both of you and, and putting your, well you probably have experience with this as well, but putting your mind or putting yourself in the mind to the developer are, what's that like for you from a product development standpoint? Are you doing a lot of community engagement? Are you talking to developers to try and anticipate what they're gonna be needing next in terms of, of your offering? Or how has that work >>For you? Oh, for sure. So, so I run product, I have a lot of product managers who work for me. Somebody that I used to work with, she was accusing me, but what she called, she called me an anthropologist of a product manager. I >>Get these kind of you, the very good design school vibes from you both of you, which >>Is, and the reason why she said the way you do this, you go and you live with them in order to figure out what a day in their life is really like, what the job is really like, what's easy, what's hard. And that's what we try to aim at and try to optimize for. So that's very much the way that we do all of >>Our work. And that's really also highlights the fact that we're in a market that requires acute realtime data from the customer. Cause it's, and it's all new data. Well >>Yeah, it's all changing. The tools change every day. I mean if we're not watching how, and >>So to your point, you need it in real time as well. The whole point of moving to cloud native is you have a reliable product or service there. And like if you need to wait a few minutes to even know that something's wrong, like you've already lost at that point, you've already lost a ton of customers, potentially. You've already lost a ton of business. You know, to your point about the, the community earlier, one other thing we're trying to do is also give back to the community a little bit. So actually two days ago we just announced the open source of a tool that we've been using in our product for a very long time. But of course our product is, is a paid product, right? But actually open source a part of that tool thus that the broader community can benefit as well. And that tool which, which tool is that? It's, it's called Prom lens. And it's actually the Prometheus project is the open sourced metrics project that everybody uses. So this is a query builder that helps developers understand how to create queries in a much more efficient way. We've had in our product for a long time, but we're like, let's give that back to the community so that the broader community of developers out there can have a much easier time creating these queries as well. What's >>Been the feedback? >>We only now it's two days ago so I'm not, I'm not exactly sure. I imagine >>It's great. They're probably playing with it right now. >>Exactly. Exactly. Exactly. For sure. I imagine. Great. >>Yeah, you guys mentioned burnout before and we heard this a lot now you mentioned in terms of data we've been hearing and reporting about Insta security world, which is also data specific observability ties right into security. Yep. How does a company figure out, first of all, burnout's a big problem. It's more and more data coming. It's like, it's like doesn't stop and the breaches are coming too. How does a company know when they need that their observability strategy is broken? Is there sig signs of you know, burnout? Is there signs of breaches? I mean, what are some of the tell signs that if I'm a CSO I go, you know what, maybe I should check out promisee. When do, when do you guys match in and go we're a perfect fit to solve that problem? >>Yeah, I, I would say, you know, because we're focused on the observability side, less so on the security side, some of those signals are like how many incidents do you have? How many outages do you have? What's the occurrence of these things and how long does it take to recover from from from these particular incidents? How >>Upsetting are we finding customers? >>Upsetting are >>Customer. Exactly. >>And and one trend was seeing >>Not churn happening. Exactly. >>And one trend we're seeing in the industry is that 68% of companies are saying that they're having more incidents over time. Right. And if you have more incidents, you can imagine more engineers are being paid, are being woken up and they're being put under more stress. And one thing you said that very interesting is, you know, I think generally in the observability world, you ideally actually don't want to figure out the problem when it goes wrong. Ideally what you want to do these days is figure out how do I remediate this and get the business back to a running state as quickly as I can. And then when the business isn't burning, let me go and figure out what the underlying root cause is. So the strategy there is changed as well from the APM days where like I don't want to figure out the problem in real time. I wanna make sure my business and my service is running as it should be. And then separately from that, once it is then I wanna go >>Under understand that assume it's gonna happen, be ready to close that isolate >>The >>Fire. Exactly. Exactly. And, and you know, you can imagine, you know the whole movement towards C I C D, like generally when you don't touch a system, nothing goes wrong. You deploy change, first thing you do is not figure out why you change break thing. Get that back like underplay that change roll that change back, get your business back to a estate and then take the time where you're not under pressure, you're not gonna be burnt out to figure out what was it about my change that that broke everything. So, yeah. Got >>It. >>Well it's not surprising that you've added some new exciting customers to the roster. We have. We have. You want to tell the audience who they might >>Be? Yes. It's been a few big names in the last year we're pretty excited about. One is Snapchat, I think everybody knows, knows that application And one is Robin Hood. So you know, you can imagine very large, I'll say tech forward companies that have completed their migrations to, to cloud native or a wallet on their way to Cloudnative and, and we like helping those customers for sure. We also like helping a lot of startups out there cause they start off in the cloud native world. Like if you're gonna build a business today, you're gonna use Kubernetes from day one. Right? But we're actually interestingly seeing more and more of is traditional enterprises who are just early, pretty early on in their cloudnative migration then now starting to adopt cloud native at scale and now they're running to the same problems. As well >>Said, the Gartner data last year was something like 85% of companies had not made that transformation. Right. So, and that, I mean that's looking at larger scale companies, obviously >>A hundred, you're >>Right on the pulse. They >>Have finished it, but a lot of them are starting it now. So we're seeing pilot >>Projects, testing and cadence. And I imagine it's a bit of a different pace when you're working with some of those transforming companies versus those startups that are, are just getting rolling. I >>Love and you know, you have a lot of legacy use case you have to, like, if you're a startup, you can imagine there's no baggage, there's no legacy. You're just starting brand new, right? If you're a large enterprise, you have to really think about, okay, well how do I get my active business moved over? But yeah. >>Yeah. And how do you guys see the whole cloud native scale moving with the hyper scales? Like aws? You've got a lot of multi-cloud conversation. We call it super cloud in our narrative, but there's now this new, we're gonna get some of common services being identified. We're seeing a, we're seeing a lot more people recognize and with Kubernetes that hey, you know what, you could get some common services maybe across clouds with SOS doing storage. We got Min iOS doing some storage. Yeah. Cloud flare, I mean starting to see a lot more non-hyper scale systems. >>Yeah, I mean I, and I think that's the pattern there and I think it, it's, especially for enterprise at the top end, right? You see a, a lot of companies are trying to de-risk by saying, Hey, I, I don't want to bet maybe on one cloud provider, I sort of need to hedge my bets a little bit. And Kubernetes is a great tool to go do that. You can imagine some of these other tools you mentioned is a great way to do that. Observability is another great way to do that. Or the cloud providers have their observability or monitoring tooling, but it's really optimized just for that cloud provider, just for those services there. So if you're really trying to run either your custom applications or a multi-cloud approach, you really can't use one cloud providers solution to go solve that problem. Do you >>Guys see yourselves with that unifying >>Layer? We, we, we are a little bit as that lay because it's agnostic to each of the cloud providers. And the other thing is we actually like to understand where our customers run and then try to run their observability stack on a different cloud provider. Cuz we use the cloud ourselves. We're not running our own data centers of course, but it's an interesting thing where everybody has a common dependency on the cloud provider. So when us e one ofs hate to call them out, but when us E one ofs goes down, imagine half the internet goes down, right? And that's the time that you actually need observability. Right? Seriously. And every other tooling there. So we try to find out where do you run and then we try to actually run you elsewhere. But yeah, >>I like that. And nobody wants to see the ugly bits anyway. Exactly. And we all know who when we're all using someone when everything >>Exactly. Exactly, exactly. >>People off the internet. So it's very, I, I really love that. Martin, Jeff, thank you so much for being here with us. Thank you. What's next? What, how do people find out, how do they get one of the jobs since three Xing your >>Employee growth? We're hiring a lot. I think the best thing is to go check out our website chronosphere.io. You'll find out a lot about our, our, our careers, our job openings, the culture we're trying to build here. Find out a lot about the product as well. If you do have an observability problem, like that's the best place to go to find out about that as well. Right. >>Fantastic. Well if you want to join a quarter billion, a quarter of a billion dollar rocket ship over here and certainly a unicorn, get in touch with Martin and Jeff. John, thank you so much for joining me for this very special edition and thank all of you for tuning in to the Cube live here from Motor City. My name's Savannah Peterson and we'll see you in a little bit. >>Robert Herbeck. People obviously know you from Shark Tanks, but the Herbeck group has been really laser focused on cyber security. So I actually helped to bring my.

(upbeat music) >> Hello, everyone. Welcome to theCUBE here, in Palo Alto, California for a Cube Conversation. I'm John Furrier, host of theCUBE. This is a KubeCon preview conversation. We got a great guest here, in studio, Madhura Maskasky, Co-Founder and VP of Product, Head of Product at Platform9. Madhura, great to see you. Thank you for coming in and sharing this conversation about, this cube conversation about KubeCon, a Kubecon conversation. >> Thanks for having me. >> A light nice play on words there, a little word play, but the fun thing about theCUBE is, we were there at the beginning when OpenStack was kind of on its transition, Kubernetes was just starting. I remember talking to Lou Tucker back in, I think Seattle or some event and Craig McLuckie was still working at Google at the time. And Google was debating on putting the paper out and so much has happened. Being present at creation, you guys have been there too with Platform9. Present at creation of the Kubernetes wave was not obvious only a few insiders kind of got the big picture. We were one of 'em. We saw this as a big wave. Docker containers at that time was a unicorn funded company. Now they've went back to their roots a few years ago. I think four years ago, they went back and recapped and now they're all pure open source. Since then Docker containers and containers have really powered the Kubernetes wave. Combined with the amazing work of the CNCF and KubeCon which we've been covering every year. You saw the maturation, you saw the wave, the early days, end user projects being contributed. Like Envoy's been a huge success. And then the white spaces filling in on the map, you got observability, you've got run time, you got all the things, still some white spaces in there but it's really been great to watch this growth. So I have to ask you, what do you expect this year? You guys have some cutting edge technology. You got Arlo announced and a lot's going on Kubernetes this year. It's going mainstream. You're starting to see the traditional enterprises embrace and some are scaling faster than others, manage services, plethora of choices. What do you expect this year at KubeCon North America in Detroit? >> Yeah, so I think you summarize kind of that life cycle or lifeline of Kubernetes pretty well. I think I remember the times when, just at the very beginning of Kubernetes, after it was released we were sitting I think with box, box dot com and they were describing to us why they are early adopters of Kubernetes. And we were just sitting down taking notes trying to understand this new project and what value it adds, right? And then flash forward to today where there are Dilbert strips written about Kubernetes. That's how popular it has become. So, I think as that has happened, I think one of the things that's also happened is the enterprises that adopted it relatively early are running it at a massive scale or looking to run it at massive scale. And so I think at scale cloud-native is going to be the most important theme. At scale governance, at scale manageability are going to be top of the mind. And the third factor, I think that's going to be top of the mind is cost control at scale. >> Yeah, and one of the things that we've seen is that the incubated projects a lot more being incubated now and you got the combination of end user and company contributed open source. You guys are contributing RLO >> RLO. >> and open source. >> Yeah. >> That's been part of your game plan there. So you guys are no stranger open source. How do you see this year's momentum? Is it more white space being filled? What's new coming out of the block? What do you think is going to come out of this year? What's rising in terms of traction? What do you see emerging as more notable that might not have been there last year? >> Yeah, so I think it's all about filling that white space, some level of consolidation, et cetera. That's usually the trend in the cloud-native space. And I think it's going to continue to be on that and it's going to be tooling that lets users simplify their lives. Now that Kubernetes is part of your day to day. And so it is observability, et cetera, have always been top of the mind, but I think starting this year, et cetera it's going to be at the next level. Which is gone other times of just running your Prometheus at individual cluster level, just to take that as an example. Now you need a solution- >> Yep. >> that operates at this massive scale across different distributions and your edge locations. So, it's taking those same problems but taking them to that next order of management. >> I'm looking at my notes here and I see orchestration and service mesh, which Envoy does. And you're seeing other solutions come out as well like Linkerd and whatnot. Some are more popular than others. What areas do you see are most needed? If you could go in there and be program chair for a day and you've got a day job as VP of product at Platform9. So you kind of have to have that future view of the roadmap and looking back at where you've come, what would you want to prioritize if you could bring your VP of product skills to the open source and saying, hey, can I point out some needs here? What would you say? >> Yeah, I think just the more tooling that lets people make sense and reduce some of the chaos that this prowling ecosystem of cloud-native creates. Which is tooling, that is not adding more tooling that covers white space is great, but introducing abilities that let you better manage what you have today is probably absolutely top of the mind. And I think that's really not covered today in terms of tools that are around. >> You know, I've been watching the top five incubated projects in CNCF, Argo cracked the top five. I think they got close to 12,000 GitHub stars. They have a conference now, ArgoCon here in California. What is that about? >> Yeah. >> Why is that so popular? I mean, I know it's kind of about obviously workflows and dealing with good pipeline, but why is that so popular right now? >> I think it's very interesting and I think Argo's journey and it's just climbed up in terms of its Github stars for example. And I think it's because as these scale factors that we talk about on one end number of nodes and clusters growing, and on the other end number of sites you're managing grows. I think that CD or continuous deployment of applications it used to kind of be something that you want to get to, it's that north star, but most enterprises wouldn't quite be there. They would either think that they're not ready and it's not needed enough to get there. But now when you're operating at that level of scale and to still maintain consistency without sky rocketing your costs, in terms of ops people, CD almost becomes a necessity. You need some kind of manageable, predictable way of deploying apps without having to go out with new releases that are going out every six months or so you need to do that on a daily basis, even hourly basis. And that's why. >> Scales the theme again, >> Yep. >> back to scale. >> Yep. >> All right, final question. We'll wrap up this preview for KubeCon in Detroit. Whereas we start getting the lay of the land and the focus. If you had to kind of predict the psychology of the developer that's going to be attending in person and they're going to have a hybrid event. So, they will be not as good as being in person. Us, it's going to be the first time kind of post pandemic when I think everyone's going to be together in LA it was a weird time in the calendar and Valencia was the kind of the first international one but this is the first time in North America. So, we're expecting a big audience. >> Mhm. >> If you could predict or what's your view on the psychology of the attendee this year? Obviously pumped to be back. But what do you think they're going to be thinking about? what's on their mind? What are they going to be peaked on? What's the focus? Where will be the psychology? Where will be the mindset? What are people going to be looking for this year? If you had to make a prediction on what the attendees are going to be thinking about what would you say? >> Yeah. So there's always a curiosity in terms of what's new, what new cool tools that are coming out that's going to help address some of the gaps. What can I try out? That's always as I go back to my development roots, first in mind, but then very quickly it comes down to what's going to help me do my job easier, better, faster, at lower cost. And I think again, I keep going back to that theme of automation, declarative automation, automation at scale, governance at scale, these are going to be top of the mind for both developers and ops teams. >> We'll be there covering it like a blanket like we always do from day one, present at creation at KubeCon we are going to be covering again for the consecutive year in a row. We love the CNCF. We love what they do. We thank the developers this year, again continue going mainstream closer and closer to the front lines as the company is the application. As we say, here on theCUBE we'll be there bringing you all the signal. Thanks for coming in and sharing your thoughts on KubeCon 2022. >> Thank you for having me. >> Okay. I'm John Furrier here in theCUBE in Palo Alto, California. Thanks for watching. (upbeat music)

>> Narrator: TheCUBE presents Kubecon and Cloudnativecon Europe, 2022. Brought to you by Red Hat, the cloud native computing foundation and its ecosystem partners. >> Welcome to Valencia, Spain in Kubecon, Cloudnativecon Europe, 2022. I'm Keith Townsend and we are in a beautiful locale. The city itself is not that big, 100,000, I mean, sorry, about 800,000 people. And we got out, got to see a little bit of the sites. It is an amazing city. I'm from the US, it's hard to put in context how a city of 800,000 people can be so beautiful. I'm here with Anish Dhar and Ganesh Datta, Co-founder and CTO of Cortex. Anish you're CEO of Cortex. We were having a conversation. One of the things that I asked my client is what is good. And you're claiming to answer the question about what is quality when it comes to measuring microservices? What is quality? >> Yeah, I think it really depends on the company and I think that's really the philosophy we have. When we built Cortex, is that we understood that different companies have different definitions of quality, but they need to be able to be represented in really objective ways. I think what ends up happening in most engineering organizations is that quality lives in people's heads. The engineers who write the services they're often the ones who understand all the intricacies with the service. What are the downstream dependencies, who's on call for this service? Where does the documentation live? All of these things I think impact the quality of the service. And as these engineers leave the company or they switch teams, they often take that tribal knowledge with them. And so I think quality really comes down to being able to objectively codify your best practices in some way and have that distributed to all engineers in the company. >> And to add to that, I think very concrete examples for an organization that's already modern like their idea of quality might be uptime incidents. For somebody that's like going through a modernization strategy, they're trying to get to the 21st century, they're trying to get to Kubernetes. For them, quality means where are we in that journey? Are you on our latest platforms? Are you running CI, are you doing continuous delivery? Like quality can mean a lot of things and so our perspective is how do we give you the tools to say as an organization, here's what quality means to us. >> So at first, my mind was going through when you said quality, Anish, you started out the conversation about having this kind of non-codified set of measurements, historical knowledge, et cetera. I was thinking observability, measuring how much time does it take to have a transaction. But Ganesh you're introducing this new thing. I'm working with this project where we're migrating a monolith application to a set of microservices. And you're telling me Cortex helps me measure the quality of what I'm doing in my project? >> Ganesh: Absolutely. >> How is that? >> Yeah, it's a great question. So I think when you think about observability, you think about uptime and latency and transactions and throughput and all this stuff. And I think that's very high level and I think that's one perspective of what quality is, but as you're going through this journey, you might say like the fact that we're tracking that stuff, the fact that you're using APM, you're using distributed tracing, that is one element of service quality. Maybe service quality means you're doing CICD, you're running vulnerability scans. You're using Docker. Like what that means to us can be very different. So observability is just one aspect of are you doing things the right way? Good to us means you're using SLOs. You are tracking those metrics. You're reporting that somewhere. And so that's like one component for our organization of what quality can mean. >> I'm kind of taken back by this because I've not seen someone kind of give the idea. And I think later on, this is the perfect segment to introduce theCUBE clock in which I'm going to give you a minute to kind of like give me the elevator pitch, but we're going to have the deep conversation right now. When you go in and you... What's the first process you do when you engage in a customer? Does a customer go and get this off of repository, install it, the open source version, and then what? I mean, what's the experience? >> Yeah, absolutely. So we have both a smart and on-prem version of Cortex. It's really straightforward. Basically we have a service discovery onboarding flow where customers can connect to different sets of source for their services. It could be Kubernetes, ECS, Git Repos, APM tools, and then we'll actually automatically map all of that service data with all of the integration data in the company. So we'll take that service and map it to its on call rotation to the JIRA tickets that have the service tag associated with it, to the data algo SLOs. And what that ends ends up producing is this service catalog that has all the information you need to understand your service. Almost like a single pane of glass to work with the service. And then once you have all of that data inside Cortex, then you can start writing scorecards, which grade the quality of those services across those different verticals Ganesh was talking about. Like whether it's a monolith, a microservice transition, whether it's production readiness or security standards, you can really start tracking that. And then engineers start understanding where the areas of risk with my service across reliability or security or operation maturity. I think it gives us in insane visibility into what's actually being built and the quality of that compared to your standards. >> So, okay, I have a standards for SLO that is usually something that is, it might not even be measured. So how do you help me understand that I'm lacking a measurable system for tracking SLO and what's the next step for helping me get that system? >> Yeah, I think our perspective is very much how do we help you create a culture where developers understand what's expected of them? So if SLOs are part of what we consider observability or reliability, then Cortex's perspective is, hey, we want to help your organization adopt SLOs. And so that service cataloging concept, the service catalog says, hey, here's my API integration. Then a scorecard, the organization goes in and says, we want every service owner to define their SLOs, we want you to define your thresholds. We want you to be tracking them, are you passing your SLOs? And so we're not being prescriptive about here's what we think your SLOs should be, ours is more around, hey, we're going to help you like if you care about SLOs, we're going to tell the service owners saying, hey, you need to have at least two SLOs for your service and you got to be tracking them. And the service catalog that data flows from a service catalog into those scorecards. And so we're helping them adopt that mindset of, hey, SLOs are important. It is a component of like a holistic service reliability excellence metric that we care about. >> So what happens when I already have systems for like SLO, how do I integrate that system with Cortex? >> That's one of the coolest things. So the service catalog can be pretty smart about it. So let's say you've sucked in your services from your GitHub. And so now your services are in Cortex. What we can do is we can actually discover from your APM tools, you can say like, hey, for this service, we have guessed that this is the corresponding APM in Datadog. And so from Datadog, here are your SLOs, here are your monitors. And so we can start mapping all the different parts of your world into the Cortex. And that's the power of the service catalog. The service catalog says, given a service, here's everything about that service. Here's the vulnerability scans. Here's the APM, the monitors, the SLOs, the JIRA ticket is like all that stuff comes into a single place. And then our scorecards product can go back out and say, hey, Datadog, tell me about this SLOs for the service. And so we're going to get that information live and then score your services against that. And so we're like integrating with all of your third party tools and integrations to create that single pan of glass. >> Yeah, and to add to that, I think one of the most interesting use cases with scorecards is, okay, which teams have actually adopted SLOs in the first place? I think a lot of companies struggle with how do we make sure engineers defined SLOs are passing them actually care about them. And scorecards can be used to one, which teams are actually meeting these guidelines? And then two, let's get those teams adopted on SLOs. Let's track that, you can do all of that in Cortex, which is I think a really interesting use case that we've seen. >> So let's talk about kind of my use case in the end to end process for integrating Cortex into migrations. So I have this monolithic application, I want to break it into microservices and then I want to ensure that I'm delivering if not, you know what, let's leave it a little bit more open ended. How do I know that I'm better at the end of I was in a monolith before, how do I measure that now that I'm in microservices and on cloud native, that I'm better? >> That's a good question. I think it comes down to, and we talk about this all the time for our customers that are going through that process. You can't define better if you don't define a baseline, like what does good mean to us? And so you need to start by saying, why are we moving to microservices? Is it because we want teams to move faster? Is it because we care about reliability up time? Like what is the core metric that we're tracking? And so you start by defining that as an organization. And that is kind of like a hand wavy thing. Why are we doing microservices? Once you have that, then you define this scorecard. And that's like our golden path. Once we're done doing this microservice migration, can we say like, yes, we have been successful and those metrics that we care about are being tracked. And so where Cortex fits in is from the very first step of creating a service, you can use Cortex to define templates. Like one click, you go in, it spins up a microservice for you that follows all your best practices. And so from there, ideally you're meeting 80% of your standards already. And then you can use scorecards to track historical progress. So you can say, are we meeting our golden path standards? Like if it's uptime, you can track uptime metrics and scorecards. If it's around velocity, you can track velocity metrics. Is it just around modernization? Are you doing CICD and vulnerability scans, like moving faster as a team? You can track that. And so you can start seeing like trends at a per team level, at a per department level, at a per product level saying, hey, we are seeing consistent progress in the metrics that we care about. And this microservice journey is helping us with that. So I think that's the kind of phased progress that we see with Cortex. >> So I'm going to give you kind of a hand wavy thing. We're told that cloud native helps me to do things faster with less defects so that I can do new opportunities. Let's stretch into kind of this non-tech, this new opportunities perspective. I want to be able to move my microservices. I want to be able to move my architecture to microservices, so I reduce call wait time on my customer service calls. So I can easily see how I can measure are we iterating faster? Are we putting out more updates quicker? That's pretty easy to measure. The number of defects, easy to measure. I can imagine a scorecard, but what about this wait time? I don't necessarily manage the call center system, but I get the data. How do I measure that the microservice migration was successful from a business process perspective? >> Yeah, that's a good question. I think it comes down to two things. One, the flexibility of scorecard means you can pipe in that data to Cortex. And what we recommend customers is track the outcome metrics and track the input metrics as well. And so what is the input metric to call wait time? Like maybe it's the fact that if something goes wrong, we have the run books to quickly roll back to an older version that we know is running. That way MTTR is faster. Or when something happens, we know the owner for that service and we can go back to them and say like, hey, we're going to ping you as an incident commander. Those are kind of the input metrics to, if we do these things, then we know our call wait time is going to drop because we're able to respond faster to incidents. And so you want to track those input metrics. And then you want to track the output metrics as well. And so if you have those metrics coming in from your Prometheus or your Datadogs or whatever, you can pipe that into Cortex and say, hey, we're going to look at both of these things holistically. So we want to see is there a correlation between those input metrics like are we doing things the right way, versus are we seeing the value that we want to come out of that? And so I think that's the value of Cortex is not so much around, hey, we're going to be prescriptive about it. It's here's this framework that will let you track all of that and say, are we doing things the right way and is it giving us the value that we want? And being able to report that update to engineer leadership and say, hey, maybe these services are not doing like we're not improving call wait time. Okay, why is that? Are these services behind on the actual input metrics that we care about? And so being able to see that I think is super valuable. >> Yeah, absolutely, I think just to touch on the reporting, I think that's one of the most value add things Cortex can provide. If you think about it, the service is atomic unit of your software. It represents everything that's being built and that bubbles up into teams, products, business units, and Cortex lets you represent that. So now I can, as a CTO, come in and say, hey, these product lines are they actually meeting our standards? Where are the areas of risk? Where should I be investing more resources? I think Cortex is almost like the best way to get the actual health of your engineering organization. >> All right Anish and Ganesh. We're going to go into the speed round here. >> Ganesh: It's time for the Q clock? >> Time for the Q clock. Start the Q clock. (upbeat music) Let's go on. >> Ganesh: Let's do it. >> Anish: Let's do it. >> Let's go on. You're you're 10 seconds in. >> Oh, we can start talking. Okay, well I would say, Anish was just touching on this. For a CTO, their question is how do I know if engineering quality is good? And they don't care about the microservice level. They care about as a business, is my engineering team actually producing. >> Keith: Follow the green, not the dream. (Ganesh laughs) >> And so the question is, well, how do we codify service quality? We don't want this to be a hand wavy thing that says like, oh, my team is good, my team is bad. We want to come in and define here's what service quality means. And we want that to be a number. You want that to be something that can- >> A goal without a timeline is just a dream. >> And CTO comes in and they say, here's what we care about. Here's how we're tracking it. Here are the teams that are doing well. We're going to reward the winners. We're going to move towards a world where every single team is doing service quality. And that's where Cortex can provide. We can give you that visibility that you never have before. >> For that five seconds. >> And hey, your SRE can't be the one handling all this. So let Cortex- >> Shoot the bad guy. >> Shot that, we're done. From Valencia Spain, I'm Keith Townsend. And you're watching theCube. The leader in high tech coverage. (soft music) (soft music) >> Narrator: TheCube presents Kubecon and Cloudnativecon Europe, 2022 brought to you by Red Hat, the cloud native computing foundation and its ecosystem partners. >> Welcome to Valencia, Spain in Kubecon, Cloudnativecon Europe, 2022. I'm Keith Townsend. And we are in a beautiful locale. The city itself is not that big 100,000, I mean, sorry, about 800,000 people. And we got out, got to see a little bit of the sites. It is an amazing city. I'm from the US, it's hard to put in context how a city of 800,000 people can be so beautiful. I'm here with Anish Dhar and Ganesh Datta, Co-founder and CTO of Cortex. Anish you're CEO of Cortex. We were having a conversation. One of the things that I asked my client is what is good. And you're claiming to answer the question about what is quality when it comes to measuring microservices? What is quality? >> Yeah, I think it really depends on the company. And I think that's really the philosophy we have when we build Cortex is that we understood that different companies have different definitions of quality, but they need to be able to be represented in really objective ways. I think what ends up happening in most engineering organizations is that quality lives in people's heads. Engineers who write the services, they're often the ones who understand all the intricacies with the service. What are the downstream I dependencies, who's on call for this service, where does the documentation live? All of these things, I think impact the quality of the service. And as these engineers leave the company or they switch teams, they often take that tribal knowledge with them. And so I think quality really comes down to being able to objectively like codify your best practices in some way, and have that distributed to all engineers in the company. >> And to add to that, I think like very concrete examples for an organization that's already modern their idea of quality might be uptime incidents. For somebody that's like going through a modernization strategy, they're trying to get to the 21st century. They're trying to get to Kubernetes. For them quality means like, where are we in that journey? Are you on our latest platforms? Are you running CI? Are you doing continuous delivery? Like quality can mean a lot of things. And so our perspective is how do we give you the tools to say as an organization here's what quality means to us. >> So at first my mind was going through when you said quality and as you started out the conversation about having this kind of non codified set of measurements, historical knowledge, et cetera. I was thinking observability measuring how much time does it take to have a transaction? But Ganesh you're introducing this new thing. I'm working with this project where we're migrating a monolith application to a set of microservices. And you're telling me Cortex helps me measure the quality of what I'm doing in my project? >> Ganesh: Absolutely. >> How is that? >> Yeah, it's a great question. So I think when you think about observability, you think about uptime and latency and transactions and throughput and all this stuff and I think that's very high level. And I think that's one perspective of what quality is. But as you're going through this journey, you might say like the fact that we're tracking that stuff, the fact that you're using APM, you're using distributed tracing, that is one element of service quality. Maybe service quality means you're doing CICD, you're running vulnerability scans. You're using Docker. Like what that means to us can be very different. So observability is just one aspect of, are you doing things the right way? Good to us means you're using SLOs. You are tracking those metrics. You're reporting that somewhere. And so that's like one component for our organization of what quality can mean. >> Wow, I'm kind of taken me back by this because I've not seen someone kind of give the idea. And I think later on, this is the perfect segment to introduce theCube clock in which I'm going to give you a minute to kind of like give me the elevator pitch, but we're going to have the deep conversation right now. When you go in and you... what's the first process you do when you engage in a customer? Does a customer go and get this off of repository, install it, the open source version and then what, I mean, what's the experience? >> Yeah, absolutely. So we have both a smart and on-prem version of Cortex. It's really straightforward. Basically we have a service discovery onboarding flow where customers can connect to different set of source for their services. It could be Kubernetes, ECS, Git Repos, APM tools, and then we'll actually automatically map all of that service data with all of the integration data in the company. So we'll take that service and map it to its on call rotation to the JIRA tickets that have the service tag associated with it, to the data algo SLOs. And what that ends up producing is this service catalog that has all the information you need to understand your service. Almost like a single pane of glass to work with the service. And then once you have all of that data inside Cortex, then you can start writing scorecards, which grade the quality of those services across those different verticals Ganesh was talking about. like whether it's a monolith, a microservice transition, whether it's production readiness or security standards, you can really start tracking that. And then engineers start understanding where are the areas of risk with my service across reliability or security or operation maturity. I think it gives us insane visibility into what's actually being built and the quality of that compared to your standards. >> So, okay, I have a standard for SLO. That is usually something that is, it might not even be measured. So how do you help me understand that I'm lacking a measurable system for tracking SLO and what's the next step for helping me get that system? >> Yeah, I think our perspective is very much how do we help you create a culture where developers understand what's expected of them? So if SLOs are part of what we consider observability and reliability, then Cortex's perspective is, hey, we want to help your organization adopt SLOs. And so that service cataloging concept, the service catalog says, hey, here's my APM integration. Then a scorecard, the organization goes in and says, we want every service owner to define their SLOs. We want to define your thresholds. We want you to be tracking them. Are you passing your SLOs? And so we're not being prescriptive about here's what we think your SLOs should be. Ours is more around, hey, we're going to help you like if you care about SLOs, we're going to tell the service owners saying, hey, you need to have at least two SLOs for your service and you've got to be tracking them. And the service catalog that data flows from the service catalog into those scorecards. And so we're helping them adopt that mindset of, hey, SLOs are important. It is a component of like a holistic service reliability excellence metric that we care about. >> So what happens when I already have systems for like SLO, how do I integrate that system with Cortex? >> That's one of the coolest things. So the service catalog can be pretty smart about it. So let's say you've sucked in your services from your GitHub. And so now your services are in Cortex. What we can do is we can actually discover from your APM tools, we can say like, hey, for this service we have guessed that this is the corresponding APM in Datadog. And so from Datadog, here are your SLOs, here are your monitors. And so we can start mapping all the different parts of your world into the Cortex. And that's the power of the service catalog. The service catalog says, given a service, here's everything about that service. Here's the vulnerability scans, here's the APM, the monitor, the SLOs, the JIRA ticket, like all that stuff comes into a single place. And then our scorecard product can go back out and say, hey, Datadog, tell me about this SLOs for the service. And so we're going to get that information live and then score your services against that. And so we're like integrating with all of your third party tools and integrations to create that single pan of glass. >> Yeah and to add to that, I think one of the most interesting use cases with scorecards is, okay, which teams have actually adopted SLOs in the first place? I think a lot of companies struggle with how do we make sure engineers defined SLOs are passing them actually care about them? And scorecards can be used to one, which teams are actually meeting these guidelines? And then two let's get those teams adopted on SLOs. Let's track that. You can do all of that in Cortex, which is, I think a really interesting use case that we've seen. >> So let's talk about kind of my use case in the end to end process for integrating Cortex into migrations. So I have this monolithic application, I want to break it into microservices and then I want to ensure that I'm delivering you know what, let's leave it a little bit more open ended. How do I know that I'm better at the end of I was in a monolith before, how do I measure that now that I'm in microservices and on cloud native, that I'm better? >> That's a good question. I think it comes down to, and we talk about this all the time for our customers that are going through that process. You can't define better if you don't define a baseline, like what does good mean to us? And so you need to start by saying, why are we moving to microservices? Is it because we want teams to move faster? Is it because we care about reliability up time? Like what is the core metric that we're tracking? And so you start by defining that as an organization. And that is kind of like a hand wavy thing. Why are we doing microservices? Once you have that, then you define the scorecard and that's like our golden path. Once we're done doing this microservice migration, can we say like, yes, we have been successful. And like those metrics that we care about are being tracked. And so where Cortex fits in is from the very first step of creating a service. You can use Cortex to define templates. Like one click, you go in, it spins up a microservice for you that follows all your best practices. And so from there, ideally you're meeting 80% of your standards already. And then you can use scorecards to track historical progress. So you can say, are we meeting our golden path standards? Like if it's uptime, you can track uptime metrics and scorecards. If it's around velocity, you can track velocity metrics. Is it just around modernization? Are you doing CICD and vulnerability scans, like moving faster as a team? You can track that. And so you can start seeing like trends at a per team level, at a per department level, at a per product level. Saying, hey, we are seeing consistent progress in the metrics that we care about. And this microservice journey is helping us with that. So I think that's the kind of phased progress that we see with Cortex. >> So I'm going to give you kind of a hand wavy thing. We're told that cloud native helps me to do things faster with less defects so that I can do new opportunities. Let's stretch into kind of this non-tech, this new opportunities perspective. I want to be able to move my microservices. I want to be able to move my architecture to microservices so I reduce call wait time on my customer service calls. So, I could easily see how I can measure are we iterating faster? Are we putting out more updates quicker? That's pretty easy to measure. The number of defects, easy to measure. I can imagine a scorecard. But what about this wait time? I don't necessarily manage the call center system, but I get the data. How do I measure that the microservice migration was successful from a business process perspective? >> Yeah, that's a good question. I think it comes down to two things. One, the flexibility of scorecard means you can pipe in that data to Cortex. And what we recommend customers is track the outcome metrics and track the input metrics as well. And so what is the input metric to call wait time? Like maybe it's the fact that if something goes wrong, we have the run book to quickly roll back to an older version that we know is running that way MTTR is faster. Or when something happens, we know the owner for that service and we can go back to them and say like, hey, we're going to ping you as an incident commander. Those are kind the input metrics to, if we do these things, then we know our call wait time is going to drop because we're able to respond faster to incidents. And so you want to track those input metrics and then you want to track the output metrics as well. And so if you have those metrics coming in from your Prometheus or your Datadogs or whatever, you can pipe that into Cortex and say, hey, we're going to look at both of these things holistically. So we want to see is there a correlation between those input metrics? Are we doing things the right way versus are we seeing the value that we want to come out of that? And so I think that's the value of Cortex is not so much around, hey, we're going to be prescriptive about it. It's here's this framework that will let you track all of that and say, are we doing things the right way and is it giving us the value that we want? And being able to report that update to engineer leadership and say, hey, maybe these services are not doing like we're not improving call wait time. Okay, why is that? Are these services behind on like the actual input metrics that we care about? And so being able to see that I think is super valuable. >> Yeah, absolutely. I think just to touch on the reporting, I think that's one of the most value add things Cortex can provide. If you think about it, the service is atomic unit of your software. It represents everything that's being built and that bubbles up into teams, products, business units, and Cortex lets you represent that. So now I can, as a CTO, come in and say, hey, these product lines are they actually meeting our standards? Where are the areas of risk? Where should I be investing more resources? I think Cortex is almost like the best way to get the actual health of your engineering organization. >> All right, Anish and Ganesh. We're going to go into the speed round here. >> Ganesh: It's time for the Q clock >> Time for the Q clock. Start the Q clock. (upbeat music) >> Let's go on. >> Ganesh: Let's do it. >> Anish: Let's do it. >> Let's go on, you're 10 seconds in. >> Oh, we can start talking. Okay, well I would say, Anish was just touching on this, for a CTO, their question is how do I know if engineering quality is good? And they don't care about the microservice level. They care about as a business, is my enduring team actually producing- >> Keith: Follow the green, not the dream. (Ganesh laughs) >> And so the question is, well, how do we codify service quality? We don't want this to be a hand wavy thing that says like, oh, my team is good, my team is bad. We want to come in and define here's what service quality means. And we want that to be a number. You want that to be something that you can- >> A goal without a timeline is just a dream. >> And a CTO comes in and they say, here's what we care about, here's how we're tracking it. Here are the teams that are doing well. We're going to reward the winners. We're going to move towards a world where every single team is doing service quality. And that's what Cortex can provide. We can give you that visibility that you never had before. >> For that five seconds. >> And hey, your SRE can't be the one handling all this. So let Cortex- >> Shoot the bad guy. >> Shot that, we're done. From Valencia Spain, I'm Keith Townsend. And you're watching theCube, the leader in high tech coverage. (soft music)

>> Announcer: "theCUBE" presents "Kubecon and Cloudnativecon Europe, 2022" brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain and "Kubecon + Cloudnativecon Europe, 2022." I'm Keith Townsend, and we're continuing the conversations with amazing people doing amazing things. I think we've moved beyond a certain phase of the hype cycle when it comes to Kubernetes. And we're going to go a little bit in detail with that today, and on all the sessions, I have today with me, Taylor Dolezal. New head of CNCF Ecosystem. So, first off, what does that mean new head of? You're the head of CNCF Ecosystem? What is the CNCF Ecosystem? >> Yeah. Yeah. It's really the end user ecosystem. So, the CNCF is comprised of really three pillars. And there's the governing board, they oversee the budget and fun things, make sure everything's signed and proper. Then there's the Technical Oversight Committee, TOC. And they really help decide the technical direction of the organization through deliberation and talking about which projects get invited and accepted. Projects get donated, and the TOC votes on who's going to make it in, based on all this criteria. And then, lastly, is the end user ecosystem, that encompasses a whole bunch of different working groups, special interest groups. And that's been really interesting to kind of get a deeper sense into, as of late. So, there are groups like the developer experience group, and the user research group. And those have very specific focuses that kind of go across all industries. But what we've seen lately, is that there are really deep wants to create, whether it be financial services user group, and things like that, because end users are having trouble with going to all of the different meetings. If you're a company, a vendor member company that's selling authentication software, or something in networking, makes sense to have a SIG network, SIG off, and those kinds of things. But when it comes down to like Boeing that just joined, does that make sense for them to jump into all those meetings? Or does it make sense to have some other kind of thing that is representative of them, so that they can attend that one thing, it's specific to their industry? They can get that download and kind of come up to speed, or find the best practices as quickly as possible in a nice synthesized way. >> So, you're 10 weeks into this role. You're coming from a customer environment. So, talk to me a little bit about the customer side of it? When you're looking at something, it's odd to call CNCF massive. But it is, 7.1 million members, and the number of contributing projects, et cetera. Talk to me about the view from the outside versus the view now that you're inside? >> Yeah, so honestly, it's been fun to kind of... For me, it's really mirrored the open-source journey. I've gone to Kubecon before, gotten to enjoy all of the booths, and trying to understand what's going on, and then worked for HashiCorp before coming to the CNCF. And so, get that vendor member kind of experience working the booth itself. So, kind of getting deeper and deeper into the stack of the conference itself. And I keep saying, vendor member and end user members, the difference between those, is end users are not organizations that sell cloud native services. Those are the groups that are kind of more consuming, the Airbnbs, the Boeings, the Mercedes, these people that use these technologies and want to kind of give that feedback back to these projects. But yeah, very incredibly massive and just sprawling when it comes to working in all those contexts. >> So, I have so many questions around, like the differences between having you as an end user and in inter-operating with vendors and the CNCF itself. So, let's start from the end user lens. When you're an end user and you're out discovering open-source and cloud native products, what's that journey like? How do you go from saying, okay, I'm primarily focused on vendor solutions, to let me look at this cloud native stack? >> Yeah, so really with that, there's been, I think that a lot of people have started to work with me and ask for, "Can we have recommended architectures? Can we have blueprints for how to do these things?" When the CNCF doesn't want to take that position, we don't want to kind of be the king maker and be like, this is the only way forward. We want to be inclusive, we want to pull in these projects, and kind of give everyone the same boot strap and jump... I missing the word of it, just ability to kind of like springboard off of that. Create a nice base for everybody to get started with, and then, see what works out, learn from one another. I think that when it comes to Kubernetes, and Prometheus, and some other projects, being able to share best practices between those groups of what works best as well. So, within all of the separations of the CNCF, I think that's something I've found really fun, is kind of like seeing how the projects relate to those verticals and those groups as well. Is how you run a project, might actually have a really good play inside of an organization like, "I like that idea. Let's try that out with our team." >> So, like this idea of springboarding. You know, is when an entrepreneur says, "You know what? I'm going to quit my job and springboard off into doing something new." There's a lot of uncertainty, but for enterprise, that can be really scary. Like we're used to our big vendors, HashiCorp, VMware, Cisco kind of guiding us and telling us like, what's next? What is that experience like, springboarding off into something as massive as cloud native? >> So, I think it's really, it's a great question. So, I think that's why the CNCF works so well, is the fact that it's a safe place for all these companies to come together, even companies of competing products. you know, having that common vision of, we want to make production boring again, we don't want to have so much sprawl and have to take in so much knowledge at once. Can we kind of work together to create all these things to get rid of our adminis trivia or maintenance tasks? I think that when it comes to open-source in general, there's a fantastic book it's called "Working in Public," it's by Stripe Press. I recommend it all over the place. It's orange, so you'll recognize it. Yeah, it's easy to see. But it's really good 'cause it talks about the maintainer journey, and what things make it difficult. And so, I think that that's what the CNCF is really working hard to try to get rid of, is all this monotonous, all these monotonous things, filing issues, best practices. How do you adopt open-source within your organization? We have tips and tricks, and kind of playbooks in ways that you could accomplish that. So, that's what I find really useful for those kinds of situations. Then it becomes easier to adopt that within your organization. >> So, I asked Priyanka, CNCF executive director last night, a pretty tough question. And this is kind of in the meat of what you do. What happens when you? Let's pick on service mesh 'cause everyone likes to pick on service mesh. >> XXXX: Yeah. >> What happens when there's differences at that vendor level on the direction of a CIG or a project, or the ecosystem around service mesh? >> Yeah, so that's the fun part. Honestly, is 'cause people get to hash it out. And so, I think that's been the biggest thing for me finding out, was that there's more than one way to do thing. And so, I think it always comes down to use case. What are you trying to do? And then you get to solve after that. So, it really is, I know it depends, which is the worst answer. But I really do think that's the case, because if you have people that are using something within the automotive space, or in the financial services space, they're going to have completely different needs, wants, you know, some might need to run Coball or Fortran, others might not have to. So, even at that level, just down to what your tech stack looks like, audits, and those kinds of things, that can just really differ. So, I think it does come down to something more like that. >> So, the CNCF loosely has become kind of a standards body. And it's centered around the core project Kubernetes? >> Mm-hmm. >> So, what does it mean, when we're looking at larger segments such as service mesh or observability, et cetera, to be Kubernetes compliant? Where's the point, if any, that the CNCF steps in versus just letting everyone hash it out? Is it Kubernetes just need to be Kubernetes compliant and everything else is free for all? >> Honestly, in many cases, it's up to the communities themselves to decide that. So, the groups that are running OCI, the Open Container Interface, Open Storage Interface, all of those things that we've agreed on as ways to implement those technologies, I think that's where the CNCF, that's the line. That's where the CNCF gets up to. And then, it's like we help foster those communities and those conversations and asking, does this work for you? If not, let's talk about it, let's figure out why it might not. And then, really working closely with community to kind of help bring those things forward and create action items. >> So, it's all about putting the right people in the rooms and not necessarily playing referee, but to get people in the right room to have and facilitate the conversation? >> Absolutely. Absolutely. Like all of the booths behind us could have their own conferences, but we want to bring everybody together to have those conversations. And again, sprawling can be really wild at certain times, but it's good to have those cross understandings, or to hear from somebody that you're like, "Oh, my goodness, I didn't even think about that kind of context or use case." So, really inclusive conversation. >> So, organizations like Boeing, Adobe, Microsoft, from an end user perspective, it's sometimes difficult to get those organizations into these types of communities. How do you encourage them to participate in the conversation 'cause their voice is extremely important? >> Yeah, that I'd also say it really is the community. I really liked the Kubernetes documentary that was put out, working with some of the CNCF folks and core, and beginning Kubernetes contributors and maintainers. And it just kind of blew me away when they had said, you know, what we thought was success, was seeing Kubernetes in an Amazon Data Center. That's when we knew that this was going to take root. And you'd rarely hear that, is like, "When somebody that we typically compete with, its success is seeing it, seeing them use that." And so, I thought was really cool. >> You know, I like to use this technology for my community of skipping rope. You see the girls and boys jumping double Dutch rope. And you think, "I can do that. Like it's just jumping." But there's this hesitation to actually, how do you start? How do you get inside of it? The question is how do you become a member of the community? We've talked a lot about what happens when you're in the community. But how do you join the community? >> So, really, there's a whole bunch of ways that you can. Actually, the shirt that I'm wearing, I got from the 114 Release. So, this is just a fun example of that community. And just kind of how welcoming and inviting that they are. Really, I do think it's kind of like a job breaker. Almost you start at the outside, you start using these technologies, even more generally like, what is DevOps? What is production? How do I get to infrastructure, architecture, or software engineering? Once you start there, you start working your way in, you develop a stack, and then you start to see these tools, technologies, workflows. And then, after you've kind of gotten a good amount of time spent with it, you might really enjoy it like that, and then want to help contribute like, "I like this, but it would be great to have a function that did this. Or I want a feature that does that." At that point in time, you can either take a look at the source code on GitHub, or wherever it's hosted, and then start to kind of come up with that, some ideas to contribute back to that. And then, beyond that, you can actually say, "No, I kind of want to have these conversations with people." Join in those special interest groups, and those meetings to kind of talk about things. And then, after a while, you can kind of find yourself in a contributor role, and then a maintainer role. After that, if you really like the project, and want to kind of work with community on that front. So, I think you had asked before, like Microsoft, Adobe and these others. Really it's about steering the projects. It's these communities want these things, and then, these companies say, "Okay, this is great. Let's join in the conversation with the community." And together again, inclusivity, and bringing everybody to the table to have that discussion and push things forward. >> So, Taylor, closing message. What would you want people watching this show to get when they think about ecosystem and CNCF? >> So, ecosystem it's a big place, come on in. Yeah, (laughs) the water's just fine. I really want people to take away the fact that... I think really when it comes down to, it really is the community, it's you. We are the end user ecosystem. We're the people that build the tools, and we need help. No matter how big or small, when you come in and join the community, you don't have to rewrite the Kubernetes scheduler. You can help make documentation that much more easy to understand, and in doing so, helping thousands of people, If I'm going through the instructions or reading a paragraph, doesn't make sense, that has such a profound impact. And I think a lot of people miss that. It's like, even just changing punctuation can have such a giant difference. >> Yeah, I think people sometimes forget that community, especially community-run projects, they need product managers. They need people that will help with communications, people that will help with messaging, websites updating. Just reachability, anywhere from developing code to developing documentation, there's ways to jump in and help the community. From Valencia, Spain, I'm Keith Townsend, and you're watching "theCUBE," the leader in high tech coverage. (bright upbeat music)

>> Instructor: "theCUBE" presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain and we're at KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend, and my co-host, Enrico Signoretti. Enrico's really proud of me. I've called him Enrico instead of Enrique every session. >> Every day. >> Senior IT analyst at GigaOm. We're talking to fantastic builders at KubeCon, CloudNativeCon Europe 2022 about the projects and their efforts. Enrico, up to this point, it's been all about provisioning, insecurity, what conversation have we been missing? >> Well, I mean, I think that we passed the point of having the conversation of deployment, of provisioning. Everybody's very skilled, actually everything is done at day two. They are discovering that, well, there is a security problem. There is an observability problem a and in fact, we are meeting with a lot of people and there are a lot of conversation with people really needing to understand what is happening. I mean, in their cluster work, why it is happening and all the questions that come with it. And the more I talk with people in the show floor here or even in the various sessions is about, we are growing so that our clusters are becoming bigger and bigger, applications are becoming bigger as well. So we need to now understand better what is happening. As it's not only about cost, it's about everything at the end. >> So I think that's a great set up for our guests, Matt Provo, founder and CEO of StormForge and Patrick Brixton? >> Bergstrom. >> Bergstrom. >> Yeah. >> I spelled it right, I didn't say it right, Bergstrom, CTO. We're at KubeCon, CloudNativeCon where projects are discussed, built and StormForge, I've heard the pitch before, so forgive me. And I'm kind of torn. I have service mesh. What do I need more, like what problem is StormForge solving? >> You want to take it? >> Sure, absolutely. So it's interesting because, my background is in the enterprise, right? I was an executive at UnitedHealth Group before that I worked at Best Buy and one of the issues that we always had was, especially as you migrate to the cloud, it seems like the CPU dial or the memory dial is your reliability dial. So it's like, oh, I just turned that all the way to the right and everything's hunky-dory, right? But then we run into the issue like you and I were just talking about, where it gets very very expensive very quickly. And so my first conversations with Matt and the StormForge group, and they were telling me about the product and what we're dealing with. I said, that is the problem statement that I have always struggled with and I wish this existed 10 years ago when I was dealing with EC2 costs, right? And now with Kubernetes, it's the same thing. It's so easy to provision. So realistically what it is, is we take your raw telemetry data and we essentially monitor the performance of your application, and then we can tell you using our machine learning algorithms, the exact configuration that you should be using for your application to achieve the results that you're looking for without over-provisioning. So we reduce your consumption of CPU, of memory and production which ultimately nine times out of 10, actually I would say 10 out of 10, reduces your cost significantly without sacrificing reliability. >> So can your solution also help to optimize the application in the long run? Because, yes, of course-- >> Yep. >> The lowering fluid as you know optimize the deployment. >> Yeah. >> But actually the long-term is optimizing the application. >> Yes. >> Which is the real problem. >> Yep. >> So, we're fine with the former of what you just said, but we exist to do the latter. And so, we're squarely and completely focused at the application layer. As long as you can track or understand the metrics you care about for your application, we can optimize against it. We love that we don't know your application, we don't know what the SLA and SLO requirements are for your app, you do, and so, in our world it's about empowering the developer into the process, not automating them out of it and I think sometimes AI and machine learning sort of gets a bad rap from that standpoint. And so, at this point the company's been around since 2016, kind of from the very early days of Kubernetes, we've always been, squarely focused on Kubernetes, using our core machine learning engine to optimize metrics at the application layer that people care about and need to go after. And the truth of the matter is today and over time, setting a cluster up on Kubernetes has largely been solved. And yet the promise of Kubernetes around portability and flexibility, downstream when you operationalize, the complexity smacks you in the face and that's where StormForge comes in. And so we're a vertical, kind of vertically oriented solution, that's absolutely focused on solving that problem. >> Well, I don't want to play, actually. I want to play the devils advocate here and-- >> You wouldn't be a good analyst if you didn't. >> So the problem is when you talk with clients, users, there are many of them still working with Java, something that is really tough. I mean, all of us loved Java. >> Yeah, absolutely. >> Maybe 20 years ago. Yeah, but not anymore, but still they have developers, they have porting applications, microservices. Yes, but not very optimized, et cetera, cetera, et cetera. So it's becoming tough. So how you can interact with this kind of old hybrid or anyway, not well engineered applications. >> Yeah. >> We do that today. We actually, part of our platform is we offer performance testing in a lower environment and stage and we, like Matt was saying, we can use any metric that you care about and we can work with any configuration for that application. So perfect example is Java, you have to worry about your heap size, your garbage collection tuning and one of the things that really struck me very early on about the StormForge product is because it is true machine learning. You remove the human bias from that. So like a lot of what I did in the past, especially around SRE and performance tuning, we were only as good as our humans were because of what they knew. And so, we kind of got stuck in these paths of making the same configuration adjustments, making the same changes to the application, hoping for different results. But then when you apply machine learning capability to that the machine will recommend things you never would've dreamed of. And you get amazing results out of that. >> So both me and Enrico have been doing this for a long time. Like, I have battled to my last breath the argument when it's a bare metal or a VM, look, I cannot give you any more memory. >> Yeah. >> And the argument going all the way up to the CIO and the CIO basically saying, you know what, Keith you're cheap, my developer resources are expensive, buy bigger box. >> Yeah. >> Yap. >> Buying a bigger box in the cloud to your point is no longer a option because it's just expensive. >> Yeah. >> Talk to me about the carrot or the stick as developers are realizing that they have to be more responsible. Where's the culture change coming from? Is it the shift in responsibility? >> I think the center of the bullseye for us is within those sets of decisions, not in a static way, but in an ongoing way, especially as the development of applications becomes more and more rapid and the management of them. Our charge and our belief wholeheartedly is that you shouldn't have to choose. You should not have to choose between costs or performance. You should not have to choose where your applications live, in a public private or hybrid cloud environment. And so, we want to empower people to be able to sit in the middle of all of that chaos and for those trade offs and those difficult interactions to no longer be a thing. We're at a place now where we've done hundreds of deployments and never once have we met a developer who said, "I'm really excited to get out of bed and come to work every day and manually tune my application." One side, secondly, we've never met, a manager or someone with budget that said, please don't increase the value of my investment that I've made to lift and shift us over to the cloud or to Kubernetes or some combination of both. And so what we're seeing is the converging of these groups, their happy place is the lack of needing to be able to make those trade offs, and that's been exciting for us. >> So, I'm listening and looks like that your solution is right in the middle in application performance, management, observability. >> Yeah. >> And, monitoring. >> Yeah. >> So it's a little bit of all of this. >> Yeah, so we want to be, the intel inside of all of that, we often get lumped into one of those categories, it used to be APM a lot, we sometimes get, are you observability or and we're really not any of those things, in and of themselves, but we instead we've invested in deep integrations and partnerships with a lot of that tooling 'cause in a lot of ways, the tool chain is hardening in a cloud native and in Kubernetes world. And so, integrating in intelligently, staying focused and great at what we solve for, but then seamlessly partnering and not requiring switching for our users who have already invested likely, in a APM or observability. >> So to go a little bit deeper. What does it mean integration? I mean, do you provide data to this, other applications in the environment or are they supporting you in the work that you do. >> Yeah, we're a data consumer for the most part. In fact, one of our big taglines is take your observability and turn it into action ability, right? Like how do you take that, it's one thing to collect all of the data, but then how do you know what to do with it, right? So to Matt's point, we integrate with folks like Datadog, we integrate with Prometheus today. So we want to collect that telemetry data and then do something useful with it for you. >> But also we want Datadog customers, for example, we have a very close partnership with Datadog so that in your existing Datadog dashboard, now you have-- >> Yeah. >> The StormForge capability showing up in the same location. >> Yep. >> And so you don't have to switch out. >> So I was just going to ask, is it a push pull? What is the developer experience when you say you provide developer this resolve ML learnings about performance, how do they receive it? Like, what's the developer experience. >> They can receive it, for a while we were CLI only, like any good developer tool. >> Right. >> And, we have our own UI. And so it is a push in a lot of cases where I can come to one spot, I've got my applications and every time I'm going to release or plan for a release or I have released and I want to pull in observability data from a production standpoint, I can visualize all of that within the StormForge UI and platform, make decisions, we allow you to set your, kind of comfort level of automation that you're okay with. You can be completely set and forget or you can be somewhere along that spectrum and you can say, as long as it's within, these thresholds, go ahead and release the application or go ahead and apply the configuration. But we also allow you to experience the same, a lot of the same functionality right now, in Grafana, in Datadog and a bunch of others that are coming. >> So I've talked to Tim Crawford who talks to a lot of CIOs and he's saying one of the biggest challenges or if not, one of the biggest challenges CIOs are facing are resource constraints. >> Yeah. >> They cannot find the developers to begin with to get this feedback. How are you hoping to address this biggest pain point for CIOs-- >> Yeah.6 >> And developers? >> You should take that one. >> Yeah, absolutely. So like my background, like I said at UnitedHealth Group, right. It's not always just about cost savings. In fact, the way that I look about at some of these tech challenges, especially when we talk about scalability there's kind of three pillars that I consider, right? There's the tech scalability, how am I solving those challenges? There's the financial piece 'cause you can only throw money at a problem for so long and it's the same thing with the human piece. I can only find so many bodies and right now that pool is very small, and so, we are absolutely squarely in that footprint of we enable your team to focus on the things that they matter, not manual tuning like Matt said. And then there are other resource constraints that I think that a lot of folks don't talk about too. Like, you were talking about private cloud for instance and so having a physical data center, I've worked with physical data centers that companies I've worked for have owned where it is literally full, wall to wall. You can't rack any more servers in it, and so their biggest option is, well, I could spend $1.2 billion to build a new one if I wanted to, or if you had a capability to truly optimize your compute to what you needed and free up 30% of your capacity of that data center. So you can deploy additional name spaces into your cluster, like that's a huge opportunity. >> So I have another question. I mean, maybe it doesn't sound very intelligent at this point, but, so is it an ongoing process or is it something that you do at the very beginning, I mean you start deploying this. >> Yeah. >> And maybe as a service. >> Yep. >> Once in a year I say, okay, let's do it again and see if something change it. >> Sure. >> So one spot, one single.. >> Yeah, would you recommend somebody performance test just once a year? Like, so that's my thing is, at previous roles, my role was to do performance test every single release, and that was at a minimum once a week and if your thing did not get faster, you had to have an executive exception to get it into production and that's the space that we want to live in as well as part of your CICD process, like this should be continuous verification, every time you deploy, we want to make sure that we're recommending the perfect configuration for your application in the name space that you're deploying into. >> And I would be as bold as to say that we believe that we can be a part of adding, actually adding a step in the CICD process that's connected to optimization and that no application should be released, monitored, and sort of analyzed on an ongoing basis without optimization being a part of that. And again, not just from a cost perspective, but for cost and performance. >> Almost a couple of hundred vendors on this floor. You mentioned some of the big ones Datadog, et cetera, but what happens when one of the up and comings out of nowhere, completely new data structure, some imaginative way to click to telemetry data. >> Yeah. >> How do, how do you react to that? >> Yeah, to us it's zeros and ones. >> Yeah. >> And, we really are data agnostic from the standpoint of, we're fortunate enough from the design of our algorithm standpoint, it doesn't get caught up on data structure issues, as long as you can capture it and make it available through one of a series of inputs, one would be load or performance tests, could be telemetry, could be observability, if we have access to it. Honestly, the messier the better from time to time from a machine learning standpoint, it's pretty powerful to see. We've never had a deployment where we saved less than 30%, while also improving performance by at least 10%. But the typical results for us are 40 to 60% savings and 30 to 40% improvement in performance. >> And what happens if the application is, I mean, yes Kubernetes is the best thing of the world but sometimes we have to, external data sources or, we have to connect with external services anyway. >> Yeah. >> So, can you provide an indication also on this particular application, like, where the problem could be? >> Yeah. >> Yeah, and that's absolutely one of the things that we look at too, 'cause it's, especially when you talk about resource consumption it's never a flat line, right? Like depending on your application, depending on the workloads that you're running it varies from sometimes minute to minute, day to day, or it could be week to week even. And so, especially with some of the products that we have coming out with what we want to do, integrating heavily with the HPA and being able to handle some of those bumps and not necessarily bumps, but bursts and being able to do it in a way that's intelligent so that we can make sure that, like I said, it's the perfect configuration for the application regardless of the time of day that you're operating in or what your traffic patterns look like, or, what your disc looks like, right. Like 'cause with our low environment testing, any metric you throw at us, we can optimize for. >> So Matt and Patrick, thank you for stopping by. >> Yeah. >> Yes. >> We can go all day because day two is I think the biggest challenge right now, not just in Kubernetes but application re-platforming and transformation, very, very difficult. Most CTOs and EASs that I talked to, this is the challenge space. From Valencia, Spain, I'm Keith Townsend, along with my host Enrico Signoretti and you're watching "theCube" the leader in high-tech coverage. (whimsical music)

(calm music) >> Hi everybody. We're here at VeeamON 2022. This is day two of the CUBE's continuous coverage. I'm Dave Vellante. My co-host is Dave Nicholson. A ton of energy. The keynotes, day two keynotes are all about products at Veeam. Veeam, the color of green, same color as money. And so, and it flows in this ecosystem. I'll tell you right now, Michael Cade is here. He's the senior technologist for product strategy at Veeam. Michael, fresh off the keynotes. >> Yeah, yeah. >> Welcome. Danny Allen's keynote was fantastic. I mean, that story he told blew me away. I can't wait to have him back. Stay tuned for that one. But we're going to talk about protecting containers, Kasten. You guys got announcements of Kasten by Veeam, you call it K10 version five, I think? >> Yeah. So just rolled into 5.0 release this week. Now, it's a bit different to what we see from a VBR release cycle kind of thing, cause we're constantly working on a two week sprint cycle. So as much as 5.0's been launched and announced, we're going to see that trickling out over the next couple of months until we get round to Cube (indistinct) and we do all of this again, right? >> So let's back up. I first bumped into Kasten, gosh, it was several years ago at VeeamON. Like, wow this is a really interesting company. I had deep conversations with them. They had a sheer, sheer cat grin, like something was going on and okay finally you acquire them, but go back a little bit of history. Like why the need for this? Containers used to be ephemeral. You know, you didn't have to persist them. That changed, but you guys are way ahead of that trend. Talk a little bit more about the history there and then we'll get into current day. >> Yeah, I think the need for stateful workloads within Kubernetes is absolutely grown. I think we just saw 1.24 of Kubernetes get released last week or a couple of weeks ago now. And really the focus there, you can see, at least three of the big ticket items in that release are focused around storage and data. So it just encourages that the community is wanting to put these data services within that. But it's also common, right? It's great to think about a stateless... If you've got stateless application but even a web server's got some state, right? There's always going to be some data associated to an application. And if there isn't then like, great but that doesn't really work- >> You're right. Where'd they click, where'd they go? I mean little things like that, right? >> Yeah. Yeah, exactly. So one of the things that we are seeing from that is like obviously the requirement to back up and put in a lot of data services in there, and taking full like exposure of the Kubernetes ecosystem, HA, and very tiny containers versus these large like virtual machines that we've always had the story at Veeam around the portability and being able to move them left, right, here, there, and everywhere. But from a K10 point of view, the ability to not only protect them, but also move those applications or move that data wherever they need to be. >> Okay. So, and Kubernetes of course has evolved. I mean the early days of Kubernetes, they kept it simple, kind of like Veeam actually. Right? >> Yeah. >> And then, you know, even though Mesosphere and even Docker Swarm, they were trying to do more sophisticated cluster management. Kubernetes has now got projects getting much more complicated. So more complicated workloads mean more data, more critical data means more protection. Okay, so you acquire Kasten, we know that's a small part of your business today but it's going to be growing. We know this cause everybody's developing applications. So what's different about protecting containers? Danny talks about modern data protection. Okay, when I first heard that, I'm like, eh, nice tagline, but then he peel the onion. He explains how in virtualization, you went from agents to backing up of VMware instance, a virtual instance. What's different about containers? What constitutes modern data protection for containers? >> Yeah, so I think the story that Danny tells as well, is so when we had our physical agents and virtualization came along and a lot of... And this is really where Veeam was born, right, we went into the virtualization API, the VMware API, and we started leveraging that to be more storage efficient. The admin overhead around those agents weren't there then, we could just back up using the API. Whereas obviously a lot of our competition would use agents still and put that resource overhead on top of that. So that's where Veeam initially got the kickstart in that world. I think it's very similar to when it comes to Kubernetes because K10 is deployed within the Kubernetes cluster and it leverages the Kubernetes API to pull out that data in a more efficient way. You could use image based backups or traditional NAS based backups to protect some of the data, and backup's kind of the... It's only one of the ticks in the boxes, right? You have to be able to restore and know what that data is. >> But wait, your competitors aren't as fat, dumb and happy today as they were back then, right? So it can't... They use the same APIs and- >> Yeah. >> So what makes you guys different? >> So I think that's testament to the Kubernetes and the community behind that and things like the CSI driver, which enables the storage vendors to take that CSI abstraction layer and then integrate their storage components, their snapshot technologies, and other efficiency models in there, and be able to leverage that as part of a universal data protection API. So really that's one tick in the box and you're absolutely right, there's open source tools that can do exactly what we're doing to a degree on that backup and recovery. Where it gets really interesting is the mobility of data and how we're protecting that. Because as much as stateful workloads are seen within the Kubernetes environments now, they're also seen outside. So things like Amazon RDS, but the front end lives in Kubernetes going to that stateless point. But being able to protect the whole application and being very application aware means that we can capture everything and restore wherever we want that to go as well. Like, so the demo that I just did was actually a Postgres database in AWS, and us being able to clone or migrate that out into an EKS cluster as a staple set. So again, we're not leveraging RDS at that point, but it gives us the freedom of movement of that data. >> Yeah, I want to talk about that, what you actually demoed. One of the interesting things, we were talking earlier, I didn't see any CLI when you were going through the integration of K10 V5 and V12. >> Yeah. >> That was very interesting, but I'm more skeptical of this concept, of the single pane of glass and how useful that is. Who is this integration targeting? Are you targeting the sort of traditional Veeam user who is now adding as a responsibility, the management of protecting these Kubernetes environments? Or are you at the same time targeting the current owners of those environments? Cause I know you talk about shift left and- >> Yeah. >> You know, nobody needs Kubernetes if you only have one container and one thing you're doing. So at some point it's all about automation, it's about blueprints, it's about getting those things in early. So you get up, you talk about this integration, who cares about that kind of integration? >> Yeah, so I think it's a bit of both, right? So we're definitely focused around the DevOps focused engineer. Let's just call it that. And under an umbrella, the cloud engineer that's looking after Kubernetes, from an application delivery perspective. But I think more and more as we get further up the mountain, CIS admin, obviously who we speak to the tech decision makers, the solutions architects systems engineers, they're going to inherit and be that platform operator around the Kubernetes clusters. And they're probably going to land with the requirement around data management as well. So the specific VBR centralized management is very much for the backup admin, the infrastructure admin or the cloud based engineer that's looking after the Kubernetes cluster and the data within that. Still we speak to app developers who are conscious of what their database looks like, because that's an external data service. And the biggest question that we have or the biggest conversation we have with them is that the source code, the GitHub or the source repository, that's fine, that will get your... That'll get some of the way back up and running, but when it comes to a Postgres database or some sort of data service, oh, that's out of the CI/CD pipeline. So it's whether they're interested in that or whether that gets farmed out into another pre-operations, the traditional operations team. >> So I want to unpack your press release a little bit. It's full of all the acronyms, so maybe you can help us- >> Sure. >> Cipher. You got security everywhere enhance platform hardening, including KMS. That's key- >> Yeah, key management service, yeah. >> System, okay. With AWS, KMS and HashiCorp vault. Awesome, love to see HashiCorp company. >> Yeah. >> RBAC objects in UI dashboards, ransomware attacks, AWS S3. So anyway, security everywhere. What do you mean by that? >> So I think traditionally at Veeam, and continue that, right? From a security perspective, if you think about the failure scenario and ransomware's, the hot topic, right, when it comes to security, but we can think about security as, if we think about that as the bang, right, the bang is something bad's happen, fire, flood, blood, type stuff. And we tend to be that right hand side of that, we tend to be the remediation. We're definitely the one, the last line of defense to get stuff back when something really bad happens. And I think what we've done from a K10 point of view, is not only enhance that, so with the likes of being able to... We're not going to reinvent the wheel, let's use the services that HashiCorp have done from a HashiCorp vault point of view and integrate from a key management system. But then also things like S3 or ransomware prevention. So I want to know if something bad's happened and Kasten actually did something more generic from a Veeam ONE perspective, but one of the pieces that we've seen since we've then started to send our backups to an immutable object storage, is let's be more of that left as well and start looking at the preventative tasks that we can help with. Now, we're not going to be a security company, but you heard all the way through Danny's like keynote, and probably when he is been on here, is that it's always, we're always mindful of that security focus. >> On that point, what was being looked for? A spike in CPU utilization that would be associated with encryption? >> Yeah, exactly that. >> Is that what was being looked- >> That could be... Yeah, exactly that. So that could be from a virtual machine point of view but from a K10, and it specifically is that we're going to look at the S3 bucket or the object storage, we're going to see if there's a rate of change that's out of the normal. It's an abnormal rate. And then with that, we can say, okay, that doesn't look right, alert us through observability tools, again, around the cloud native ecosystem, Prometheus Grafana. And then we're going to get insight into that before the bang happens, hopefully before the bang. >> So that's an interesting when we talk about adjacencies and moving into this area of security- >> We're talking to Zeus about that too. >> Exactly. That's that sort of creep where you can actually add value. It's interesting. >> So, okay. So we talked about shift left, get that, and then expanded ecosystem, industry leading technologies. By the way, one of them is the Red Hat Marketplace. And I think, I heard Anton's... Anton was amazing. He is the head of product management at Veeam. Is been to every VeeamON. He's got family in Ukraine. He's based in Switzerland. >> Yeah. >> But he chose not to come here because he's obviously supporting, you know, the carnage that's going on in Ukraine. But anyway, I think he said the Red Hat team is actually in Ukraine developing, you know, while the bombs are dropping. That's amazing. But anyway, back to our interview here, expanded ecosystem, Red Hat, SUSE with Rancher, they've got some momentum. vSphere with Tanzu, they're in the game. Talk about that ecosystem and its importance. >> Yeah, and I think, and it goes back to your point around the CLI, right? Is that it feels like the next stage of Kubernetes is going to be very much focused towards the operator or the operations team. The CIS admin of today is going to have to look after that. And at the moment it's all very command line, it's all CLI driven. And I think the marketplace is OpenShift, being our biggest foothold around our customer base, is definitely around OpenShift. But things like, obviously we are a longstanding alliance partner with VMware as well. So their Tanzu operations actually there's support for TKGS, so vSphere Tanzu grid services is another part of the big release of 5.0. But all three of those and the common marketplace gives us a UI, gives us a way of being able to see and visualize that rather than having to go and hunt down the commands and get our information through some- >> Oh, some people are going to be unhappy about that. >> Yeah. >> But I contend the human eye has evolved to see in color for a very good reason. So I want to see things in red, yellow, and green at times. >> There you go, yeah. >> So when we hear a company like Veeam talk about, look we have no platform agenda, we don't care which cloud it's in. We don't care if it's on-prem or Google Azure, AWS. We had Wasabi on, we have... Great, they got an S3 compatible, you know, target, and others as well. When we hear them, companies like you, talk about that consistent experience, single pane of glass that you're skeptical of, maybe cause it's technically challenging, one of the things, we call it super cloud, right, that's come up. Danny and I were riffing on that the other day and we'll do that more this afternoon. But it brings up something that we were talking about with Zeus, Dave, which is the edge, right? And it seems like Kubernetes, and we think about OpenShift. >> Yeah. >> We were there last week at Red Hat Summit. It's like 50% of the conversation, if not more, was the edge. Right, and really true edge, worst cases, use cases. Two weeks ago we were at Dell Tech, there was a lot of edge talk, but it was retail stores, like Lowe's. Okay, that's kind of near edge, but the far edge, we're talking space, right? So seems like Kubernetes fits there and OpenShift, you know, particularly, as well as some of the others that we mentioned. What about edge? How much of what you're doing with container data protection do you see as informing you about the edge opportunity? Are you seeing any patterns there? Nobody's really talking about it in data protection yet. >> So yeah, large scale numbers of these very small clusters that are out there on farms or in wind turbines, and that is definitely something that is being spoken about. There's not much mention actually in this 5.0 release because we actually support things like K3s,(indistinct), that all came in 4.5, but I think, to your first point as well, David, is that, look, we don't really care what that Kubernetes distribution is. So you've got K3s lightweight Kubernetes distribution, we support it, because it uses the same native Kubernetes APIs, and we get deployed inside of that. I think where we've got these large scale and large numbers of edge deployments of Kubernetes and that you require potentially some data management down there, and they might want to send everything into a centralized location or a more centralized location than a farm shed out in the country. I think we're going to see a big number of that. But then we also have our multi cluster dashboard that gives us the ability to centralize all of the control plane. So we don't have to go into each individual K10 deployment to manage those policies. We can have one big centralized management multi cluster dashboard, and we can set global policies there. So if you're running a database and maybe it's the same one across all of your different edge locations, where you could just set one policy to say I want to protect that data on an hourly basis, a daily basis, whatever that needs to be, rather than having to go into each individual one. >> And then send it back to that central repository. So that's the model that you see, you don't see the opportunity, at least at this point in time, of actually persisting it at the edge? >> So I think it depends. I think we see both, but again, that's the footprint. And maybe like you mentioned about up in space having a Kubernetes cluster up there. You don't really want to be sending up a NAS device or a storage device, right, to have to sit alongside it. So it's probably, but then equally, what's the art of the possible to get that back down to our planet, like as part of a consistent copy of data? >> Or even a farm or other remote locations. The question is, I mean, EVs, you know, we believe there's going to be tons of data, we just don't.. You think about Tesla as a use case, they don't persist a ton of their data. Maybe if a deer runs across, you know, the front of the car, oh, persist that, send that back to the cloud. >> I don't want anyone knowing my Tesla data. I'll tell you that right now. (all laughing) >> Well, there you go, that one too. All right, well, that's future discussion, we're still trying to squint through those patterns. I got so many questions for you, Michael, but we got to go. Thanks so much for coming to theCUBE. >> Always. >> Great job on the keynote today and good luck. >> Thank you. Thanks for having me. >> All right, keep it right there. We got a ton of product talk today. As I said, Danny Allan's coming back, we got the ecosystem coming, a bunch of the cloud providers. We have, well, iland was up on stage. They were just recently acquired by 11:11 Systems. They were an example today of a cloud service provider. We're going to unpack it all here on theCUBE at VeeamON 2022 from Las Vegas at the Aria. Keep it right there. (calm music)

>>The cube presents, Coon and cloud native con Europe 22, brought to you by the cloud native computing foundation. >>Welcome to Melissa Spain. And we're at cuon cloud native con Europe, 2022. I'm Keith Townsend. And my co-host en Rico senior Etti en Rico's really proud of me. I've called him en Rico and said IK, every session, senior it analyst giga, O we're talking to fantastic builders at Cuban cloud native con about the projects and the efforts en Rico up to this point, it's been all about provisioning insecurity. What, what conversation have we been missing? >>Well, I mean, I, I think, I think that, uh, uh, we passed the point of having the conversation of deployment of provisioning. You know, everybody's very skilled, actually everything is done at day two. They are discovering that, well, there is a security problem. There is an observability problem. And in fact, we are meeting with a lot of people and there are a lot of conversation with people really needing to understand what is happening. I mean, in their classroom, what, why it is happening and all the, the questions that come with it. I mean, and, uh, the more I talk with, uh, people in the, in the show floor here, or even in the, you know, in the various sessions is about, you know, we are growing, the, our clusters are becoming bigger and bigger. Uh, applications are becoming, you know, bigger as well. So we need to know, understand better what is happening. It's not only, you know, about cost it's about everything at the >>End. So I think that's a great set up for our guests, max, Provo, founder, and CEO of storm for forge and Patrick Britton, Bergstrom, Brookstone. Yeah, I spelled it right. I didn't say it right. Berg storm CTO. We're at Q con cloud native con we're projects are discussed, built and storm forge. I I've heard the pitch before, so forgive me. And I'm, I'm, I'm, I'm, I'm, I'm kind of torn. I have service mesh. What do I need more like, what problem is storm for solving? >>You wanna take it? >>Sure, absolutely. So it it's interesting because, uh, my background is in the enterprise, right? I was an executive at United health group. Um, before that I worked at best buy. Um, and one of the issues that we always had was, especially as you migrate to the cloud, it seems like the CPU dial or the memory dial is your reliability dial. So it's like, oh, I just turned that all the way to the right and everything's hunky Dory. Right. Uh, but then we run into the issue like you and I were just talking about where it gets very, very expensive, very quickly. Uh, and so my first conversations with Matt and the storm forge group, and they were telling me about the product and, and what we're dealing with. I said, that is the problem statement that I have always struggled with. And I wish this existed 10 years ago when I was dealing with EC two costs, right? And now with Kubernetes, it's the same thing. It's so easy to provision. So realistically, what it is is we take your raw telemetry data and we essentially monitor the performance of your application. And then we can tell you using our machine learning algorithms, the exact configuration that you should be using for your application to achieve the results that you're looking for without over provisioning. So we reduce your consumption of CPU of memory and production, which ultimately nine times outta 10, actually I would say 10 out of 10 reduces your cost significantly without sacrificing reliability. >>So can your solution also help to optimize the application in the long run? Because yes, of course, yep. You know, the lowing fluid is, you know, optimize the deployment. Yeah. But actually the long term is optimizing the application. Yes. Which is the real problem. >>Yep. So we actually, um, we're fine with the, the former of what you just said, but we exist to do the latter. And so we're squarely and completely focused at the application layer. Um, we are, uh, as long as you can track or understand the metrics you care about for your application, uh, we can optimize against it. Um, we love that we don't know your application. We don't know what the SLA and SLO requirements are for your app. You do. And so in, in our world, it's about empowering the developer into the process, not automating them out of it. And I think sometimes AI and machine learning sort of gets a bad wrap from that standpoint. And so, uh, we've at this point, the company's been around, you know, since 2016, uh, kind of from the very early days of Kubernetes, we've always been, you know, squarely focused on Kubernetes using our core machine learning, uh, engine to optimize metrics at the application layer, uh, that people care about and, and need to need to go after. And the truth of the matter is today. And over time, you know, setting a cluster up on Kubernetes has largely been solved. Um, and yet the promise of, of Kubernetes around portability and flexibility, uh, downstream when you operationalize the complexity, smacks you in the face. And, uh, and that's where, where storm forge comes in. And so we're a vertical, you know, kind of vertically oriented solution. Um, that's, that's absolutely focused on solving that problem. >>Well, I don't want to play, actually. I want to play the, uh, devils advocate here and, you know, >>You wouldn't be a good analyst if you didn't. >>So the, the problem is when you talk with clients, users, they, there are many of them still working with Java with, you know, something that is really tough. Mm-hmm <affirmative>, I mean, we loved all of us loved Java. Yeah, absolutely. Maybe 20 years ago. Yeah. But not anymore, but still they have developers. They are porting applications, microservices. Yes. But not very optimized, etcetera. C cetera. So it's becoming tough. So how you can interact with these kind of yeah. Old hybrid or anyway, not well in generic applications. >>Yeah. We, we do that today. We actually, part of our platform is we offer performance testing in a lower environment and stage. And we like Matt was saying, we can use any metric that you care about and we can work with any configuration for that application. So the perfect example is Java, you know, you have to worry about your heap size, your garbage collection tuning. Um, and one of the things that really struck, struck me very early on about the storm forage product is because it is true machine learning. You remove the human bias from that. So like a lot of what I did in the past, especially around SRE and, and performance tuning, we were only as good as our humans were because of what they knew. And so we were, we kind of got stuck in these paths of making the same configuration adjustments, making the same changes to the application, hoping for different results. But then when you apply machine learning capability to that, the machine will recommend things you never would've dreamed of. And you get amazing results out of >>That. So both me and an Rico have been doing this for a long time. Like I have battled to my last breath, the, the argument when it's a bare metal or a VM. Yeah. Look, I cannot give you any more memory. Yeah. And the, the argument going all the way up to the CIO and the CIO basically saying, you know what, Keith you're cheap, my developer resources expensive, my bigger box. Yep. Uh, buying a bigger box in the cloud to your point is no longer a option because it's just expensive. Talk to me about the carrot or the stick as developers are realizing that they have to be more responsible. Where's the culture change coming from? So is it, that is that if it, is it the shift in responsibility? >>I think the center of the bullseye for us is within those sets of decisions, not in a static way, but in an ongoing way, especially, um, especially as the development of applications becomes more and more rapid. And the management of them, our, our charge and our belief wholeheartedly is that you shouldn't have to choose, you should not have to choose between costs or performance. You should not have to choose where your, you know, your applications live, uh, in a public private or, or hybrid cloud environment. And so we want to empower people to be able to sit in the middle of all of that chaos and for those trade-offs and those difficult interactions to no, no longer be a thing. You know, we're at, we're at a place now where we've done, you know, hundreds of deployments and never once have we met a developer who said, I'm really excited to get outta bed and come to work every day and manually tune my application. <laugh> One side, secondly, we've never met, uh, you know, uh, a manager or someone with budget that said, uh, please don't, you know, increase the value of my investment that I've made to lift and shift us over mm-hmm <affirmative>, you know, to the cloud or to Kubernetes or, or some combination of both. And so what we're seeing is the converging of these groups, um, at, you know, their happy place is the lack of needing to be able to, uh, make those trade offs. And that's been exciting for us. So, >>You know, I'm listening and looks like that your solution is right in the middle in application per performance management, observability. Yeah. And, uh, and monitoring. So it's a little bit of all of this. >>So we, we, we, we want to be, you know, the Intel inside of all of that, mm-hmm, <affirmative>, we don't, you know, we often get lumped into one of those categories. It used to be APM a lot. We sometimes get a, are you observability or, and we're really not any of those things in and of themselves, but we, instead of invested in deep integrations and partnerships with a lot of those, uh, with a lot of that tooling, cuz in a lot of ways, the, the tool chain is hardening, uh, in a cloud native and, and Kubernetes world. And so, you know, integrating in intelligently staying focused and great at what we solve for, but then seamlessly partnering and not requiring switching for, for our users who have already invested likely in a APM or observability. >>So to go a little bit deeper. Sure. What does it mean integration? I mean, do you provide data to this, you know, other applications in, in the environment or are they supporting you in the work that you >>Yeah, we're, we're a data consumer for the most part. Um, in fact, one of our big taglines is take your observability and turn it into actionability, right? Like how do you take the it's one thing to collect all of the data, but then how do you know what to do with it? Right. So to Matt's point, um, we integrate with folks like Datadog. Um, we integrate with Prometheus today. So we want to collect that telemetry data and then do something useful with it for you. >>But, but also we want Datadog customers. For example, we have a very close partnership with, with Datadog, so that in your existing data dog dashboard, now you have yeah. This, the storm for capability showing up in the same location. Yep. And so you don't have to switch out. >>So I was just gonna ask, is it a push pull? What is the developer experience? When you say you provide developer, this resolve ML, uh, learnings about performance mm-hmm <affirmative> how do they receive it? Like what, yeah, what's the, what's the, what's the developer experience >>They can receive it. So we have our own, we used to for a while we were CLI only like any good developer tool. Right. Uh, and you know, we have our own UI. And so it is a push in that, in, in a lot of cases where I can come to one spot, um, I've got my applications and every time I'm going to release or plan for a release or I have released, and I want to take, pull in, uh, observability data from a production standpoint, I can visualize all of that within the storm for UI and platform, make decisions. We allow you to, to set your, you know, kind of comfort level of automation that you're, you're okay with. You can be completely set and forget, or you can be somewhere along that spectrum. And you can say, as long as it's within, you know, these thresholds, go ahead and release the application or go ahead and apply the configuration. Um, but we also allow you to experience, uh, the same, a lot of the same functionality right now, you know, in Grafana in Datadog, uh, and a bunch of others that are coming. >>So I've talked to Tim Crawford who talks to a lot of CIOs and he's saying one of the biggest challenges, or if not, one of the biggest challenges CIOs are facing are resource constraints. Yeah. They cannot find the developers to begin with to get this feedback. How are you hoping to address this biggest pain point for CIOs? Yeah. >>Development? >>Just take that one. Yeah, absolutely. That's um, so like my background, like I said, at United health group, right. It's not always just about cost savings. In fact, um, the way that I look about at some of these tech challenges, especially when we talk about scalability, there's kind of three pillars that I consider, right? There's the tech scalability, how am I solving those challenges? There's the financial piece, cuz you can only throw money at a problem for so long. And it's the same thing with the human piece. I can only find so many bodies and right now that pool is very small. And so we are absolutely squarely in that footprint of, we enable your team to focus on the things that they matter, not manual tuning like Matt said. And then there are other resource constraints that I think that a lot of folks don't talk about too. >>Like we were, you were talking about private cloud for instance. And so having a physical data center, um, I've worked with physical data centers that companies I've worked for have owned where it is literally full wall to wall. You can't rack any more servers in it. And so their biggest option is, well, I could spend 1.2 billion to build a new one if I wanted to. Or if you had a capability to truly optimize your compute to what you needed and free up 30% of your capacity of that data center. So you can deploy additional name spaces into your cluster. Like that's a huge opportunity. >>So either out of question, I mean, may, maybe it, it doesn't sound very intelligent at this point, but so is it an ongoing process or is it something that you do at the very beginning mean you start deploying this. Yeah. And maybe as a service. Yep. Once in a year I say, okay, let's do it again and see if something changes. Sure. So one spot 1, 1, 1 single, you know? >>Yeah. Um, would you recommend somebody performance tests just once a year? >>Like, so that's my thing is, uh, previous at previous roles I had, uh, my role was you performance test, every single release. And that was at a minimum once a week. And if your thing did not get faster, you had to have an executive exception to get it into production. And that's the space that we wanna live in as well as part of your C I C D process. Like this should be continuous verification every time you deploy, we wanna make sure that we're recommending the perfect configuration for your application in the name space that you're deploying >>Into. And I would be as bold as to say that we believe that we can be a part of adding, actually adding a step in the C I C D process that's connected to optimization and that no application should be released monitored and sort of, uh, analyzed on an ongoing basis without optimization being a part of that. And again, not just from a cost perspective, yeah. Cost end performance, >>Almost a couple of hundred vendors on this floor. You know, you mentioned some of the big ones, data, dog, et cetera. But what happens when one of the up and comings out of nowhere, completely new data structure, some imaginable way to click to elementry data. Yeah. How do, how do you react to that? >>Yeah. To us it's zeros and ones. Yeah. Uh, and you know, we're, we're, we're really, we really are data agnostic from the standpoint of, um, we're not, we we're fortunate enough to, from the design of our algorithm standpoint, it doesn't get caught up on data structure issues. Um, you know, as long as you can capture it and make it available, uh, through, you know, one of a series of inputs, what one, one would be load or performance tests, uh, could be telemetry, could be observability if we have access to it. Um, honestly the messier, the, the better from time to time, uh, from a machine learning standpoint, um, it, it, it's pretty powerful to see we've, we've never had a deployment where we, uh, where we saved less than 30% while also improving performance by at least 10%. But the typical results for us are 40 to 60% savings and, you know, 30 to 40% improvement in performance. >>And what happens if the application is, I, I mean, yes, Kubernetes is the best thing of the world, but sometimes we have to, you know, external data sources or, or, you know, we have to connect with external services anyway. Mm-hmm <affirmative> yeah. So can you, you know, uh, can you provide an indication also on, on, on this particular application, like, you know, where the problem could >>Be? Yeah, yeah. And that, that's absolutely one of the things that we look at too, cuz it's um, especially when you talk about resource consumption, it's never a flat line, right? Like depending on your application, depending on the workloads that you're running, um, it varies from sometimes minute to minute, day to day, or it could be week to week even. Um, and so especially with some of the products that we have coming out with what we want to do, you know, partnering with, uh, you know, integrating heavily with the HPA and being able to handle some of those bumps and not necessarily bumps, but bursts and being able to do it in a way that's intelligent so that we can make sure that, like I said, it's the perfect configuration for the application regardless of the time of day that you're operating in or what your traffic patterns look like. Um, or you know, what your disc looks like, right? Like cuz with our, our low environment testing, any metric you throw at us, we can, we can optimize for. >>So Madden Patrick, thank you for stopping by. Yeah. Yes. We can go all day. Because day two is I think the biggest challenge right now. Yeah. Not just in Kubernetes, but application replatforming and re and transformation. Very, very difficult. Most CTOs and S that I talked to, this is the challenge space from Valencia Spain. I'm Keith Townsend, along with my host en Rico senior. And you're watching the queue, the leader in high tech coverage.

>>Okay, welcome back everyone. Cube's coverage here. Live on the floor at AWS summit, 2022, an in person event in San Francisco. Of course, AWS summit, 2022 in New York city is coming up this summer. The cube will be there as well. Make sure you check us out then too, but we day two of coverage had a great guest here. I Han VP of developer relations, Mongo DB, formally of AWS. We've been known each other for a long time doing, uh, developer relations at Mongo DB. Welcome to the queue. Good to see >>You. Thank to be here. Thanks for inviting me, John. It's great >>To, so Mongo DB is, um, first of all, stocks' doing really well right now. Businesswise is good, but I still think it's undervalue. A lot of people think is, is a lot more going huge success with Atlas. So congratulations to the team over there. Um, what's the update? What's the relationship withs, you know, guys have been great partners for years. What's the new thing. Yeah. >>So MongoDB Atlas obviously runs on several different major cloud providers, but AWS is the largest partner that we work with in the public cloud. So the majority of our Atlas workloads for our customers are running on the AWS platform. And just earlier this year, we announced a new strategic collaboration agreement with AWS. That's gonna further strengthen and deepen that partnership that we have with them. >>What's the main product value right now on the scale on, on Atlas, what's the drive in the revenue momentum. >>So, I mean, you know, there's a huge trend in the industry towards cloud managed databases, right? You look back 10, 15 years ago when we first met, most customers were only and operating their own data infrastructure, either running it in their own data centers, or maybe if they were really early using the primitives that cloud providers like AWS offered to run their databases in the cloud when Amazon launched RDS back in 2009, I think it was, we started to see this trend towards cloud managed databases. We followed that with our own Atlas offering back in 2016. And as Andy jazzy from AWS would say very often it's offloading that UND differentiated, heavy lifting, allowing developers to focus on building applications. They don't have to win and operate the data infrastructure. We do it for them, and that has proven incredibly popular amongst our customers. You know, Atlas route right now is growing at 50, sorry, 85% car year on year growth. >>You know, um, I've been following MongoDB for a long, long time. I mean, going back to the lamp stack days, you know, and you think about what Mongo has done as a product because of the developer traction, you know, Mongo can't do this, just keeps getting better every year. And, and the, I think the stickiness with developers is a real big part of that. Can you your view there cuz you're in VE relations. I mean, developers all love Mongo. They're teaching in school. People are picking up a side hustles, they're coding on it, using it all everywhere. I mean it's well known. >>There's a few different reasons for that. I think the main one is the, the document orientated model that we use, the document data models that are used by Mongo DB, just a net way for developers to work with data. And then, uh, we've invested in creating 16 first party drivers that allow developers using various different programming languages, whether that's JavaScript or Python or rust to integrate MongoDB, natively and idiomatic with their software. So it's very, very easy for a developer to pick up MongoDB, grab one of these drivers from their package manager of their choice and then build applications that natively manipulate data inside MongoDB, whether that's MongoDB Atlas or our enterprise edition on their own premises. They get a very consistent and very easy to, I easy to use developer experience with our, with our platform. >>Talk about the go to market with AWS. You guys also have a tightly coupled relationships. There's been announcements there recently. Uh, what's changing most right now that people should pay attention to. Well, >>The first thing is there's a huge amount of technical integration between MongoDB and AWS services. And that's the basis for many of our customers choosing to run Mon Mongo DB on AWS. We're active in 23 AWS regions around the world. And there's many other integration points as well, like cryptographic protection of Mongo MongoDB, stored data using Amazon cryptographic services, for example, or building serverless applications with AWS Lambda and MongoDB servers. So there's a ton of technical integration. Yeah, but what we started to work on now is go to market integration with AWS as well. So you can buy Mongo DB Atlas through AWS's marketplace. You can use the payer, you go offering to pay for it with your AWS bill. And then we're collaborating with AWS on migrations and other joint go to market activities as well. That >>Means get incentives, the sales people at AWS. >>Of course our moreover I mean, it's just really easy for customers, really easy for developers to consume. Yeah, they don't need to contract with MongoDB. They can use their existing AWS contracting, their existing discounting relationships and pre purchasing arrangements with AWS to consume Atlas. >>It's the classic meet the customers where they >>Are exactly right. Meet the developer where they are and meet the customers where they are now with this new model as well. >>Yeah. I love marketplace. I think it's been great. You know, even with its kind of catalog and vibe, I think it's gonna get better and better, uh, over there teams doing good work. Um, and it's easy to consume. That's key. >>Yeah. Super easy. Reduce that friction and make it real easy for developers to adopt this. Right. >>Talk about some of the top customers that you guys share with AWS. What are some of the customers you guys have together and what the benefits of the >>Relationship joint references that we talk about? A lot, one of them is Shutterfly. So in the photographic products area, they built a eCommerce offering with MongoDB and AWS. The second is seven 11 with seven 11. We're doing a lot in the mobile space. So edge applications, we've got a feature in MongoDB Atlas that allows you to synchronize data with databases on mobile devices. Those can be phones point of sale devices or handheld devices that might be used in the parcel industry, for example. So seven 11 using us in that way. And then lastly with Pitney Bowes, we've got a big digital transformation project with Pitney Bowes where they've reimagined their, uh, postage and packaging services, delivering those to their customers, using MongoDB as a data store as well. >>I wanna get in some of the trends, you've got a great per you know, you know, Mongo from Amazon side and now you're there. Um, Mongo's, as you pointed out has, has been around for a long time. What are some of the stats? I mean, how many customers, how many countries? Well, it's pretty massive >>Mind. We've got almost quarter of a billion downloads today, 240 million MongoDB downloads since we launched the first product <laugh>, we've got 33,000 active customers that are using MongoDB Atlas today and we're running well over a million free tier clusters on MongoDB Atlas across all of the different providers where we operate the service as well. So these numbers are, you know, mind blowing in terms of scale. Uh, but of course at the core of that is operational excellence. Customers love Mongo DBS because they don't have to operate it themselves. They don't have to deal with fairly conditions. They don't have to deal with scaling. They don't have to deal with deployment. We all, we do all of those things as part of the service offering and customers get an endpoint that they can use with their applications to store and retrieve data reliably. And with consistently high perform, >>You know, it's, you know, in the media, something has to be dead. Someone's the death of the iPhone, the death of this, nothing that really dies. Mongo DB has always been kind of like talked about, well, it doesn't scale on the high end. Of course, Oracle was saying that, I mean, all the, all the big database vendors were kind of throwing darts at, at Mongo, uh, DB, uh, but it kept scaling. Atlas is a whole nother. Could you just unpack that a little bit more? Why is it so important? Because scale is just, I mean, it's, it's horizontal, but it's also performant. >>Exactly. Right. So with, uh, Mongo DB's document access model that I've described already, you break some of the limitations that exist inside traditional relational databases. So, you know, they don't scale well, if you've got high concurrent and see of data access, and they're typically difficult and expensive to scale because you need to share data. Once you grow beyond individual cluster nodes, and you'll know that all relational databases suffer from these same kinds of issues with non relational systems, no SQL systems like MongoDB, you have to think a little bit more about design at the beginning. So designing database to cater for the different access patterns that you have, but in return for that upfront preparation, that design work, you get near limitless, scalability and performance will scale nearly linearly with that scalability as well. So very much more high performance, very much more simplicity for the developer as their database gets larger and their cluster gets larger to support it. >>Yeah. You know, Amazon web service has always had an a and D jazz. We talk to us all the time, every interview I've done with Swami and Matt wood or whoever on the team and executive levels always said the same thing. There's not one database to rule the world, right? Obvious you're talking about Oracle, but even within AWS customers, they're mixing and matching databases based on use cases. So in distributed environment, they're all working together. So, um, you guys fit nicely into that. So how does that, >>I think strategy slightly counterbalances that so, you know, they would say use the specific tool for the specific task that you have in hand. Yeah. What we try to focus on is creating the simple and most effective developer experience that we can, and then supporting different facets to the product in order to allow developers to different use cases. A really good example with something like MongoDB Atlas search. So we integrated Apache Luine into MongoDB Atlas. Customers can very simply apply Apache Luine search indexes to the data that they've got in MongoDB. And then they can interact with that search data using the same drivers as an API. Yeah, yeah. That they use for regular queries. So if you want to run search on your application data, you don't need a separate open search or elastic search cluster, just turn on MongoDB Atlas search and use that, that search facet. So it's interest and we have other capabilities that it's >>Vertically integrating inside within Mongo, >>Correct? Yes. That's better. Yeah. With the guy, all of creating a really simple and effective developer experience, boosting developer productivity and helping developers get more done in less time. >>You mentioned serverless earlier, what's the serverless angle with AWS when Mongo, >>Is there one? Yeah. So we have MongoDB serverless currently in preview, uh, has the same kind of characteristics that you would, or the characteristics that you would expect from a serverless data base. So consumption based model, you provision an endpoint and that will scale elastically in accordance with your usage and you get billed by consumption units so much like the serverless paradigm that we've seen delivered by AWS, the same kind of model for Mongo, DB, Atlas serverless. >>What, what attracted you to Mongo DBS? So you knew them before, or you moved over there. Um, what's going on there? What's the culture like right now? Oh, >>The culture's great. I mean, it's a much smaller company than AWS where I was before, you know, it's a very large organization. And one of the things that I really like about MongoDB is, as I've said earlier, we can serve the different use cases that a developer might have with a single product, with different aspects, to it, different facets to it. Uh, and it's a really great conversation to have with a, with a developer, with a developer customer, to be able to offer one thing that helps them solve five or six different problems that have traditionally been quite hard for them to wrestle with quite difficult for them to, to deal with. And then we've got this focus on developer experience through these driver packages that we have as well. So it's really great to have as a developer relations pro have that kind of tooling in my kit bag that can help developers become more effective. >>Talk about tooling, cuz you know, I always have, uh, kind of moments where I waffle between more. I love platforms, tools are being over overused, too many tools tool with the tool, you know, the expressions, but we're seeing from developers, the ones that don't want to go into the hood, we serverless plays beautifully. Yep. They want tools. They do. And, and the, the new engineering developers that are coming outta college and universities, they love tools. >>Yeah. And we actually have quite a few of those built into Mongo, DB Atlas. So inside Mongo, DB Atlas, we've got things like an index optimizer, which will suggest the best way that you might index your data for better perform months inside MongoDB, running on Atlas, we've got a data Explorer, which is much like another product that we've got called MongoDB compass that allows you to see and manipulate the data that you have stored within your database natively within the Atlas interface. Uh, and then we also have, uh, whole slew of different metrics, monitoring capabilities built into the platform as well. So these are aspects of Atlas that developers can take advantage of. And then over on the client side, visual studio code plugins. Yeah. So you can manipulate and operate with data directly inside visual studio code, which is obviously the most common and popular IDE out there today, as well as integration with things like infrastructure is code tools. So we support cloud formation for provisioning. We have CDK constructs inside. Yeah. The CDK construct library. We also have a lot of customers using Terraform to provision MongoDB across both AWS and other providers. So having that developer tooling of course is super important. Yeah. Aspect of the developer experience, trying to >>Build out deploying observability is a big one. How does that fit in? Cuz you knew need to talk and not only measure everything here, but talk to other systems. >>Yeah. So we recently announced a provider for Prometheus and Grafana. So we can emit metrics into those providers. Obviously CNCF projects, very common and popular inside customers that are running on Kubernetes. We've got a Kubernetes operator for MongoDB Atlas as well. Good. So you can provision MongoDB Atlas from within Kubernetes as well as having our own native metrics directly within Atlas as well. >>Ian you're crushing it. You got all the, the data, the fingertips. Are you gonna be at Cuban this year? Uh, >>I will be, but some of our team members will definitely be there. >>Yeah, we'll be at, uh, EU. The cube will be there. Great. Thanks for coming on. Appreciate the insight final world. I'll give you the last word. Tell the audience what's going on. What's at Mongo DB. What should they pay attention to? If they've used Mongo and are aware of it? What's the update. What's >>The so you should come to MongoDB world actually in New York at the beginning of June, June 7th, the ninth in the Javit center in New York. Gonna have our own show there. And of course we'd love to see you there. >>Okay. Cube comes here day two of eight, us summit, 2020, this Cub I'm John for your host. Stay with us more. Our coverage as day two winds down. Great coverage.

(gentle music) >> Hello, welcome to theCUBE's presentation of the AWS Showcase season one, episode two with the ISV Startups partners. I'm John Furrier, your host of theCUBE. We're joined by Morgan McLean, director of product management at Splunk, and Danielle Greshock, who is the director of ISVs solution architects at AWS. Welcome to the show. Thanks for coming on. >> Thanks for having us. >> And great. Thanks for having us. >> Great to see both of you, both theCUBE alumni, but the Splunk-AWS relationship has been going very, very well. You guys are doing great business enabling this app revolution. And cloud scale has been going extremely well. So let's get into it. You guys are involved in a lot of action around application revolution, around OpenTelemetry and open source. So let's get into it. What's the latest? >> Danielle, you go ahead. >> Well, I'll just jump in first. Obviously last year, not last year, but in 2020, we launched the AWS Distro for OpenTelemetry. The idea being essentially, we're able to bring in data from partners, from infrastructure running on AWS, from apps running on AWS, to really be able to increase observability across all cloud assets at your entire cloud platform. So, Morgan, if you want to chime in on how Splunk >> Morgan: Certainly. >> has worked out OpenTelemetry. >> Yeah. I mean, OpenTelemetry is super exciting. Obviously, there's a lot of partnership points between Amazon and Splunk, but OpenTelemetry is probably one of them that's the most visible to people who aren't already maybe using these two products together. And so, as Danielle mentioned, Amazon has their own distribution of OpenTelemetry, Splunk has their own, as well, and of course there's the main open source distribution that everybody knows and loves. Just for our viewers, just for clarity's sake, the separate distributions are fundamentally very similar to, almost identical to what's offered in the open source space, but they come preconfigured and they come with support guarantees from each company, meaning that you can actually get paid full support for an open source project, which is really fantastic for customers. And as Danielle mentioned, it's a great demonstration of the alliance between Splunk and Amazon Web Services. For example, the AWS Distro, when you use it, can export data to Amazon CloudWatch, various Amazon backed open source initiatives like Prometheus and others, and to Splunk Observability Cloud and to Splunk Enterprise. So it's a place that we've worked very closely together, and it's something that we're very excited about. >> So, Morgan, I want to get your take on the on the product management side and also how product are built these days. >> One of the big things we're seeing in cloud is that open source has been the big enabler for a lot of refactoring. And you got multiple distributions, but the innovations on top of that, can you talk about how you see the productization of new innovations with open source as you guys go into this market, because this is the new dynamic with cloud. We're seeing examples all over the place. Obviously, Amazon's going next level with what they're doing, and that open source, it's not a one game for all of it. You can have mix and match. Take us through the product angle. >> And in many ways, this is just another wave of the same thing, right? Like, if you think back in time, we all used and still use in many cases, virtual machines, most of those are based on Linux, right? Another large open source project. And so, open source software has been accelerating innovation in the cloud space and in the computing space generally for a very long time, which is fantastic. Our excitement with something like OpenTelemetry comes from both the project's capabilities but also what we can do with it. So for those who aren't already familiar with OpenTelemetry, OpenTelemetry allows you to extract really critical system telemetry, application signals and everything else you need from your own applications, from new services, from your infrastructure, from everything that you're running in a cloud environment. You can then send that data to another location for processing. And so John, you ask like, how does this accelerate innovation? What does it unlock? Well, the insight you can gain from this data means you can become so much more efficient as a development organization. You can make your applications so much more effective because when you send that data to something like Splunk Observability Cloud, to something like Amazon CloudWatch, to various other solutions on the market, they can give you deep, deep insight into your application's performance, to its structure, they can help you reduce outages. And so, it's very, very powerful because it allows organizations to use tools like Splunk, like Amazon, like other things to innovate so much more effectively. >> Danielle, can you comment >> If I could... >> on the AWS side because this is again on the big point. You guys are going next level, and you're starting to see patterns in the ISV world, certainly on the architecture side of partners doing things differently now on top of what they've already done. Could you share how AWS is helping customers accelerate? >> Well, just as Morgan was talking about what OpenTelemetry provides, you can see how from a partnership perspective, this is so valuable, right? What the partner team here at AWS is in the business of doing, is really enabling customer choice, right? And having that ability to plug in and pull data from different sources, post it to different sources, make it available for visibility across all of your resources is very powerful and it's something from the partner community that we really value because we want customers to be able to select best of breed solutions, what works for their business, which businesses are different and they may have different needs, and that also fosters that true innovation. A small company is going to develop and release software a lot differently than a large enterprise. And so, being able to support something like OpenTelemetry just enables that for all different kinds of customers. >> Morgan, add to that because the velocity of releases, certainly operational, stability, is key every predominant security, uptime, these are top concerns. And, you mention data too, >> And you mention challenges. >> You got the data in here. So you got a lot of data moving around, a lot of value. What's your take? >> Yeah. So, I'll speak with some specifics. So a challenge that developers have had for years when you're developing large services, which you can now do with platforms like AWS. So, it's very easy to go develop huge deployments. But a challenge they have is you go and build a mess, right? And like, I've worked earlier in my career in Web Services. And I remember in one of the first orgs I was in, I was one of the five people who really understood our ecommerce stack. Right? And so like, I would get dragged into all these meetings and I'd have to go draw like the 50 services we had, and how they interacted, and the changes that were made in the last week. And without observability tools like Splunk Observability Cloud, like the ones offered by Amazon, like the ones that are backed by the data that comes with OpenTelemetry, organizations basically rely on people like this, to go draw out their deployments so they understand what it is they've built. Well, as you can imagine, this crimps your development velocity, because most of your engineers, most of your tech leads, most of everyone else don't actually understand what it is they've built what it is they're running, because they need that global context. You get something like OpenTelemetry and the solutions that consume the data from it, and suddenly now, all your developers have that context, all of them when they're adding functionality to a service or they're updating their infrastructure, can actually understand how it interacts with the rest of the broader application. This lets you speed up your time to development, this lets you ship more safely, more securely. And finally, when things do go wrong, which will be less frequent, but when they do go wrong, you can fix them super rapidly. >> If I'm a customer, let me ask a question. I'm a customer and I say, "Okay, I love AWS, I love Splunk, I love OpenTelemetry. I got to have open sources, technology innovation is happening." What's the integration? What are some of the standards? Can you take us through how that's working together with you guys as a shared platform? >> Yeah. So let's take the Amazon distribution for OpenTelemetry or even the Splunk one. One of the first things they do is they include all of the receivers, all of the sort of data capture components that you need, out of box for platforms like AWS, right? And so, right away, you get that power and flexibility where you're getting access to all of these data sources, right? And so, that's part of that partnership. And additionally, once the data comes into OpenTelemetry, you can now send that to various different data sources, including, as Danielle mentioned, to multiple at the same time. So you can use whatever tools you want. And so when you talk about like what the partnership is actually providing to you as a customer and still, this is just within the context of OpenTelemetry, obviously there's a much broader partnership between these two companies than just that. But within the context of OpenTelemetry means you can download one of these distributions. It's fully supported. It works with both solutions and everything is just great, right? You don't need to go fiddle with that out of the box. To be clear, OpenTelemetry is a batteries included project, right? This means that even the standard distributions of OpenTelemetry include the components you need. You have to go directly, reference them and ensure that they're packaged in there, but they exist, right. But the nice thing about these distributions is that it's done, it's out of the box, you don't even have to worry about is something missing or do I need to include new exporters or new receivers? It's all there. It's preconfigured. It just works. And if something goes wrong and you have a support contact, you pick up the phone, you talk to someone to get it fixed. >> Danielle, what's the Amazon side 'cause agility and scale is one of the highlights you guys are seeing. How does this tie into that and how are you guys working backwards from the customers to support the partners? >> Well, I think just to add on essentially to what Morgan said, I think that AWS is a cloud platform, has always really had a focus on developers. And, we talk a lot about how AWS and Amazon as a whole really embraces this continuous integration and continuous deployment methods inside of our organization. And we talk about services, and observability is a huge part of that. The only way that you're actually able to release hundreds, thousands of times a day like Amazon does, is by having an observability platform, to be able to measure metrics, see changes in the environment, to be able to roll back if you need to, and to be able to quickly mitigate any challenges or anything that goes wrong at any part of the process. And so, when we preach that to our customers, I think it's something that we do that because we live it and breathe it. And so, things such as OpenTelemetry and such as the products that Splunk builds, those are also ways in which we believe our customers can achieve that. >> Yeah. And we can... I mean, as I mentioned before, this partnership goes well beyond OpenTelemetry, right? And so, if you go use like Splunk Enterprise, Enterprise Cloud, Splunk Observability Cloud, and you're running on AWS, you have excellent support and excellent visibility into your Amazon infrastructure, into the services and applications you've deployed on top of that infrastructure. We try and give you, and I think we do succeed in this. We give you the best possible experience, the deepest possible visibility, into what it is you've deployed on AWS, so that you can be even more successful as a business, and so that you can be even more successful on AWS as a platform. >> Yeah. This is a great conversation, Morgan. You mentioned the early days of Web Services. AWS stands for Amazon Web Services built on web services. So interesting throwback there, but made me think about the days of the early days of web services. And if you look at data, what's going on now, the top partners in AWS, you're seeing a lot of people thinking about data differently, they're refactoring, a lot of machine learning, a lot of AI going on at scale. So then, you got cloud native, things like Kubernetes and these new services being stood up and teared down with automation. A whole new operating model's coming. And so when you think about observability, the importance of it, I mean, can you share your perspective on this whole 'nother level? I mean, I always say that whole another level sounds cliche, but it is next level. I mean, this is completely different. What's your reaction? >> Yeah. There there's a ton of factors here, right? So as you point out, companies are totally shifting how they use their cloud infrastructure. And part of this you see during their cloud migrations, a part of it you see after, and they're shifting from their sort of stateful VMs that they may have had in the past to infrastructure that they tear down and put up regularly. And there's a lot more automation. With this, comes as I mentioned before, complexity, right? And also, with this comes more and more businesses becoming even more reliant on their digital infrastructure. And so, not having observability into your applications, into your services, into your infrastructure, to me, is akin to running a business, say running a large warehousing or distribution company, but not having any idea where you're shipping products or where things are, or not having any accounting or CFO, right? Like, business has become so digital. Business is so reliant on technology, and that's unlocked a ton of new things. It's great. But not having visibility into how that technology works or what it is that's deployed or how to fix it is akin to having no visibility to anything else in your business. It's nuts. And so, observability is super, super critical, particularly for customers who are adopting this new wave of cloud technologies on platforms like AWS. >> Danielle, on your side too, you're enabling this new capability so that businesses can do it, the partners do it, we're calling it super cloud. We've been calling it super cloud kind of dynamic where new things are happening with the data. And you guys are evolving with that. Can you share what you're seeing on your side as your partners start to go to the next level? What are you guys doing? How does it all come together? >> Well, we always talk about what has happened with data in the last couple of years, which the cloud has really enabled around, you know, variety and velocity and there's one other "V" that's escaping me right now, but essentially, all of this data is coming in and providing the ability for us to make better decisions, to build better products, to provide better experiences for customers. And so, I just think, the OpenTelemetry project, as well as what Splunk is doing is just another example of how we're taking this massive amount of data and being able to provide better experiences and outcomes for customers. >> And you guys have been working along together for long time, Splunk, and, it's been a great partners, if we're going back with that been covering it on theCUBE and SiliconANGLE. So, we know that, the change is key observability. Can you imagine a company without a CFO, Morgan? That's just boggles your mind, but that's what it's like right now. So... >> It is, yeah. >> And the people who take advantage of that are winning, right? So it's like, that's the key. >> Yeah, I know. I mean, even in my own career, right, I've moved between different companies. And I remember, when I joined Google in particular, which is where I worked at previously, I was very impressed with their internal observability tools. And I'm certain, I haven't worked at Amazon. I'm certainly, I just assume inside of Amazon they're excellent as well, so a lot of the large cloud firms these days. But it was so refreshing going from an organization where if we had some outage or something went wrong, there were like a very small set of people who could actually understand what was going on. And then you would just have to manually dive through logs and correlate requests manually between services. It's very challenging. And so, when things went wrong, they went wrong for a long, long time. And so, the companies that understood this even in the past are already very successful as a result. I think now, the rest of the industry is really in the midst of adopting these observability practices and the tools that are required to implement them, because you're right. Otherwise your development velocity slows down. Now you're getting out competed by your competition. And then, when you have a problem, it blows up for ages. And once again, your competition can take advantage of it. >> And, can you just summarize the observability piece relative to the OpenTelemetry? Where is that going to go? Where do you see that evolving? >> Sure. >> I see open source is growing like crazy, we all know that. >> Of course. >> But OpenTelemetry in particular and open source, 'cause this is a big hot area. >> Yes. So to set the stage for people, OpenTelemetry, unlocks observability in many ways. As I mentioned earlier, OpenTelemetry is how you capture data out of your application. It doesn't process it. It's not a replacement for something like Amazon CloudWatch or any Splunk's products, but it's how we get the data out of your system, which is a remarkably difficult problem. I won't dive into it today, but, those who work in this space are very aware. That's why this project exists and it's so big, that actually extracting information, metrics, logs, distributed traces, profiles, everything else, from your applications and from your infrastructure is very, very difficult. So for OpenTelemetry, where it's going is just continually getting better at extracting more types of data from more sources, and doing that more effectively for people in a more standardized way. That will unlock firms like Splunk, firms, like Amazon and others to better process this data. In terms of where that's going, the sky's the limit, right? Like, everyone's familiar with APM, people are familiar with infrastructure monitoring, but there's a lot more capabilities coming there for security analytics, for network performance monitoring, for getting down all the way to single lines of coding your application, how they impact everything. There's just so much power that's coming to the industry right now. I'm really excited to see where things go in the next few years. >> And Danielle, you're in the middle of all the action as a solution architect, really set the stage for their companies and the ISVs, and this is a big, hot area. What are the patterns you're seeing and what are some of the best practices that you're doing will help companies? >> Right. So I think, summarizing our entire conversation, the big things that we're seeing in the market is essentially more and more companies are looking to move to a continuous deployment and a continuous integration environment. And they're looking to innovate faster and spend less time hot patching or hot fixing their environments and they want to spend more time innovating. And so, that you know, the patterns that we're seeing is... What I see and what I actually experience firsthand at re:Invent when I talk to probably over 40 or 50 ISVs, is customers want to know in their environment, where are their changes? Where are their security vulnerabilities? Where are their data changes, and what are customers really experiencing, whether it's latency, poor experience throughout their products, those types of things? So security, data, and observability are just key to all of that experience and that's what we're definitely seeing as patterns, what we're seeing with our customers and also what value our ISVs are providing in that space. >> That's awesome. And the other thing I would observe is that there's more of an integration story going on around joint projects, whether it's open source. >> Absolutely. >> Because this is where we want to get that services connected. And it's mutual beneficial. I mean, this is really >> Exactly. >> whole 'nother, new kind of interoperable cloud scale. >> Yeah, if I could say one thing else there, I think that, a lot of the customers who are trying to move into the cloud now are, maybe not technology forward companies and they really need that solution. And that's very important. I think COVID has pushed a lot of companies into the cloud maybe very quickly. And, that has been something else we've observed in the market. So, solutions and full solutions between ISVs and ISVs, or ISVs and AWS is just becoming more and more common thing that we see. >> And, you mentioned John, in the open source space as well. Like, we're certainly from Amazon to Splunk. So we're talking a lot about those, but there's a lot of other firms involved in projects like OpenTelemetry. And I think it's very endearing, very heartening to see how well they cooperate in this community and how, when their interests are aligned, how effective they can be. And it's been very exciting to work in the space and very pleasant, honestly, to see everything come together with this huge set of customers and partners. >> Yeah. The pleasant surprise of the pandemic has been that people come into the cloud and they like it and they, "Hey, this works," and they double down on it. Then they realize, there's more there and they refactor. So, you're seeing real examples of that. So, this is a great discussion, great success story. Congratulations Morgan, Danielle. >> Thank you. >> Great partnership between Splunk and AWS. We've been following for a long time. And again, this highlights this whole another level of integrating super cloud kind of experience where people are getting more capabilities and doing more together, so great stuff. >> And this is just one facet of that, right? Like, there's all the other connections of Splunk Enterprise, Splunk security analytics products, and others. It's a deep, deep partnership between these firms. >> Yeah. And the companies that innovate and get that new capability are going to have an advantage. And you're seeing... >> Yes. >> Right? >> Agreed. >> And this is awesome, and great stuff, thank you for coming on and sharing that insight. >> Thank you. >> Congratulations Morgan over there at Splunk, great stuff. And Danielle, thanks for coming on and sharing the AWS perspective. >> Thanks for having me. >> And you guys are going to the next level. You moving up to stack as they say, all good stuff for customers. Thanks. >> Thank you. >> Okay. >> Thank you. >> This is season one, episode two of the AWS Partner Showcase. I'm John Furrier with theCUBE. Thanks for watching. (gentle music)

(gentle music) >> Hello, welcome to theCUBE's presentation of the AWS Showcase season one, episode two with the ISV Startups partners. I'm John Furrier, your host of theCUBE. We're joined by Morgan McLean, director of product management at Splunk, and Danielle Greshock, who is the director of ISVs solution architects at AWS. Welcome to the show. Thanks for coming on. >> Thanks for having us. >> And great. Thanks for having us. >> Great to see both of you, both theCUBE alumni, but the Splunk-AWS relationship has been going very, very well. You guys are doing great business enabling this app revolution. And cloud scale has been going extremely well. So let's get into it. You guys are involved in a lot of action around application revolution, around OpenTelemetry and open source. So let's get into it. What's the latest? >> Danielle, you go ahead. >> Well, I'll just jump in first. Obviously last year, not last year, but in 2020, we launched the AWS Distro for OpenTelemetry. The idea being essentially, we're able to bring in data from partners, from infrastructure running on AWS, from apps running on AWS, to really be able to increase observability across all cloud assets at your entire cloud platform. So, Morgan, if you want to chime in on how Splunk >> Morgan: Certainly. >> has worked out OpenTelemetry. >> Yeah. I mean, OpenTelemetry is super exciting. Obviously, there's a lot of partnership points between Amazon and Splunk, but OpenTelemetry is probably one of them that's the most visible to people who aren't already maybe using these two products together. And so, as Danielle mentioned, Amazon has their own distribution of OpenTelemetry, Splunk has their own, as well, and of course there's the main open source distribution that everybody knows and loves. Just for our viewers, just for clarity's sake, the separate distributions are fundamentally very similar to, almost identical to what's offered in the open source space, but they come preconfigured and they come with support guarantees from each company, meaning that you can actually get paid full support for an open source project, which is really fantastic for customers. And as Danielle mentioned, it's a great demonstration of the alliance between Splunk and Amazon Web Services. For example, the AWS Distro, when you use it, can export data to Amazon CloudWatch, various Amazon backed open source initiatives like Prometheus and others, and to Splunk Observability Cloud and to Splunk Enterprise. So it's a place that we've worked very closely together, and it's something that we're very excited about. >> So, Morgan, I want to get your take on the on the product management side and also how product are built these days. >> One of the big things we're seeing in cloud is that open source has been the big enabler for a lot of refactoring. And you got multiple distributions, but the innovations on top of that, can you talk about how you see the productization of new innovations with open source as you guys go into this market, because this is the new dynamic with cloud. We're seeing examples all over the place. Obviously, Amazon's going next level with what they're doing, and that open source, it's not a one game for all of it. You can have mix and match. Take us through the product angle. >> And in many ways, this is just another wave of the same thing, right? Like, if you think back in time, we all used and still use in many cases, virtual machines, most of those are based on Linux, right? Another large open source project. And so, open source software has been accelerating innovation in the cloud space and in the computing space generally for a very long time, which is fantastic. Our excitement with something like OpenTelemetry comes from both the project's capabilities but also what we can do with it. So for those who aren't already familiar with OpenTelemetry, OpenTelemetry allows you to extract really critical system telemetry, application signals and everything else you need from your own applications, from new services, from your infrastructure, from everything that you're running in a cloud environment. You can then send that data to another location for processing. And so John, you ask like, how does this accelerate innovation? What does it unlock? Well, the insight you can gain from this data means you can become so much more efficient as a development organization. You can make your applications so much more effective because when you send that data to something like Splunk Observability Cloud, to something like Amazon CloudWatch, to various other solutions on the market, they can give you deep, deep insight into your application's performance, to its structure, they can help you reduce outages. And so, it's very, very powerful because it allows organizations to use tools like Splunk, like Amazon, like other things to innovate so much more effectively. >> Danielle, can you comment >> If I could... >> on the AWS side because this is again on the big point. You guys are going next level, and you're starting to see patterns in the ISV world, certainly on the architecture side of partners doing things differently now on top of what they've already done. Could you share how AWS is helping customers accelerate? >> Well, just as Morgan was talking about what OpenTelemetry provides, you can see how from a partnership perspective, this is so valuable, right? What the partner team here at AWS is in the business of doing, is really enabling customer choice, right? And having that ability to plug in and pull data from different sources, post it to different sources, make it available for visibility across all of your resources is very powerful and it's something from the partner community that we really value because we want customers to be able to select best of breed solutions, what works for their business, which businesses are different and they may have different needs, and that also fosters that true innovation. A small company is going to develop and release software a lot differently than a large enterprise. And so, being able to support something like OpenTelemetry just enables that for all different kinds of customers. >> Morgan, add to that because the velocity of releases, certainly operational, stability, is key every predominant security, uptime, these are top concerns. And, you mention data too, >> And you mention challenges. >> You got the data in here. So you got a lot of data moving around, a lot of value. What's your take? >> Yeah. So, I'll speak with some specifics. So a challenge that developers have had for years when you're developing large services, which you can now do with platforms like AWS. So, it's very easy to go develop huge deployments. But a challenge they have is you go and build a mess, right? And like, I've worked earlier in my career in Web Services. And I remember in one of the first orgs I was in, I was one of the five people who really understood our ecommerce stack. Right? And so like, I would get dragged into all these meetings and I'd have to go draw like the 50 services we had, and how they interacted, and the changes that were made in the last week. And without observability tools like Splunk Observability Cloud, like the ones offered by Amazon, like the ones that are backed by the data that comes with OpenTelemetry, organizations basically rely on people like this, to go draw out their deployments so they understand what it is they've built. Well, as you can imagine, this crimps your development velocity, because most of your engineers, most of your tech leads, most of everyone else don't actually understand what it is they've built what it is they're running, because they need that global context. You get something like OpenTelemetry and the solutions that consume the data from it, and suddenly now, all your developers have that context, all of them when they're adding functionality to a service or they're updating their infrastructure, can actually understand how it interacts with the rest of the broader application. This lets you speed up your time to development, this lets you ship more safely, more securely. And finally, when things do go wrong, which will be less frequent, but when they do go wrong, you can fix them super rapidly. >> If I'm a customer, let me ask a question. I'm a customer and I say, "Okay, I love AWS, I love Splunk, I love OpenTelemetry. I got to have open sources, technology innovation is happening." What's the integration? What are some of the standards? Can you take us through how that's working together with you guys as a shared platform? >> Yeah. So let's take the Amazon distribution for OpenTelemetry or even the Splunk one. One of the first things they do is they include all of the receivers, all of the sort of data capture components that you need, out of box for platforms like AWS, right? And so, right away, you get that power and flexibility where you're getting access to all of these data sources, right? And so, that's part of that partnership. And additionally, once the data comes into OpenTelemetry, you can now send that to various different data sources, including, as Danielle mentioned, to multiple at the same time. So you can use whatever tools you want. And so when you talk about like what the partnership is actually providing to you as a customer and still, this is just within the context of OpenTelemetry, obviously there's a much broader partnership between these two companies than just that. But within the context of OpenTelemetry means you can download one of these distributions. It's fully supported. It works with both solutions and everything is just great, right? You don't need to go fiddle with that out of the box. To be clear, OpenTelemetry is a batteries included project, right? This means that even the standard distributions of OpenTelemetry include the components you need. You have to go directly, reference them and ensure that they're packaged in there, but they exist, right. But the nice thing about these distributions is that it's done, it's out of the box, you don't even have to worry about is something missing or do I need to include new exporters or new receivers? It's all there. It's preconfigured. It just works. And if something goes wrong and you have a support contact, you pick up the phone, you talk to someone to get it fixed. >> Danielle, what's the Amazon side 'cause agility and scale is one of the highlights you guys are seeing. How does this tie into that and how are you guys working backwards from the customers to support the partners? >> Well, I think just to add on essentially to what Morgan said, I think that AWS is a cloud platform, has always really had a focus on developers. And, we talk a lot about how AWS and Amazon as a whole really embraces this continuous integration and continuous deployment methods inside of our organization. And we talk about services, and observability is a huge part of that. The only way that you're actually able to release hundreds, thousands of times a day like Amazon does, is by having an observability platform, to be able to measure metrics, see changes in the environment, to be able to roll back if you need to, and to be able to quickly mitigate any challenges or anything that goes wrong at any part of the process. And so, when we preach that to our customers, I think it's something that we do that because we live it and breathe it. And so, things such as OpenTelemetry and such as the products that Splunk builds, those are also ways in which we believe our customers can achieve that. >> Yeah. And we can... I mean, as I mentioned before, this partnership goes well beyond OpenTelemetry, right? And so, if you go use like Splunk Enterprise, Enterprise Cloud, Splunk Observability Cloud, and you're running on AWS, you have excellent support and excellent visibility into your Amazon infrastructure, into the services and applications you've deployed on top of that infrastructure. We try and give you, and I think we do succeed in this. We give you the best possible experience, the deepest possible visibility, into what it is you've deployed on AWS, so that you can be even more successful as a business, and so that you can be even more successful on AWS as a platform. >> Yeah. This is a great conversation, Morgan. You mentioned the early days of Web Services. AWS stands for Amazon Web Services built on web services. So interesting throwback there, but made me think about the days of the early days of web services. And if you look at data, what's going on now, the top partners in AWS, you're seeing a lot of people thinking about data differently, they're refactoring, a lot of machine learning, a lot of AI going on at scale. So then, you got cloud native, things like Kubernetes and these new services being stood up and teared down with automation. A whole new operating model's coming. And so when you think about observability, the importance of it, I mean, can you share your perspective on this whole 'nother level? I mean, I always say that whole another level sounds cliche, but it is next level. I mean, this is completely different. What's your reaction? >> Yeah. There there's a ton of factors here, right? So as you point out, companies are totally shifting how they use their cloud infrastructure. And part of this you see during their cloud migrations, a part of it you see after, and they're shifting from their sort of stateful VMs that they may have had in the past to infrastructure that they tear down and put up regularly. And there's a lot more automation. With this, comes as I mentioned before, complexity, right? And also, with this comes more and more businesses becoming even more reliant on their digital infrastructure. And so, not having observability into your applications, into your services, into your infrastructure, to me, is akin to running a business, say running a large warehousing or distribution company, but not having any idea where you're shipping products or where things are, or not having any accounting or CFO, right? Like, business has become so digital. Business is so reliant on technology, and that's unlocked a ton of new things. It's great. But not having visibility into how that technology works or what it is that's deployed or how to fix it is akin to having no visibility to anything else in your business. It's nuts. And so, observability is super, super critical, particularly for customers who are adopting this new wave of cloud technologies on platforms like AWS. >> Danielle, on your side too, you're enabling this new capability so that businesses can do it, the partners do it, we're calling it super cloud. We've been calling it super cloud kind of dynamic where new things are happening with the data. And you guys are evolving with that. Can you share what you're seeing on your side as your partners start to go to the next level? What are you guys doing? How does it all come together? >> Well, we always talk about what has happened with data in the last couple of years, which the cloud has really enabled around, you know, variety and velocity and there's one other "V" that's escaping me right now, but essentially, all of this data is coming in and providing the ability for us to make better decisions, to build better products, to provide better experiences for customers. And so, I just think, the OpenTelemetry project, as well as what Splunk is doing is just another example of how we're taking this massive amount of data and being able to provide better experiences and outcomes for customers. >> And you guys have been working along together for long time, Splunk, and, it's been a great partners, if we're going back with that been covering it on theCUBE and SiliconANGLE. So, we know that, the change is key observability. Can you imagine a company without a CFO, Morgan? That's just boggles your mind, but that's what it's like right now. So... >> It is, yeah. >> And the people who take advantage of that are winning, right? So it's like, that's the key. >> Yeah, I know. I mean, even in my own career, right, I've moved between different companies. And I remember, when I joined Google in particular, which is where I worked at previously, I was very impressed with their internal observability tools. And I'm certain, I haven't worked at Amazon. I'm certainly, I just assume inside of Amazon they're excellent as well, so a lot of the large cloud firms these days. But it was so refreshing going from an organization where if we had some outage or something went wrong, there were like a very small set of people who could actually understand what was going on. And then you would just have to manually dive through logs and correlate requests manually between services. It's very challenging. And so, when things went wrong, they went wrong for a long, long time. And so, the companies that understood this even in the past are already very successful as a result. I think now, the rest of the industry is really in the midst of adopting these observability practices and the tools that are required to implement them, because you're right. Otherwise your development velocity slows down. Now you're getting out competed by your competition. And then, when you have a problem, it blows up for ages. And once again, your competition can take advantage of it. >> And, can you just summarize the observability piece relative to the OpenTelemetry? Where is that going to go? Where do you see that evolving? >> Sure. >> I see open source is growing like crazy, we all know that. >> Of course. >> But OpenTelemetry in particular and open source, 'cause this is a big hot area. >> Yes. So to set the stage for people, OpenTelemetry, unlocks observability in many ways. As I mentioned earlier, OpenTelemetry is how you capture data out of your application. It doesn't process it. It's not a replacement for something like Amazon CloudWatch or any Splunk's products, but it's how we get the data out of your system, which is a remarkably difficult problem. I won't dive into it today, but, those who work in this space are very aware. That's why this project exists and it's so big, that actually extracting information, metrics, logs, distributed traces, profiles, everything else, from your applications and from your infrastructure is very, very difficult. So for OpenTelemetry, where it's going is just continually getting better at extracting more types of data from more sources, and doing that more effectively for people in a more standardized way. That will unlock firms like Splunk, firms, like Amazon and others to better process this data. In terms of where that's going, the sky's the limit, right? Like, everyone's familiar with APM, people are familiar with infrastructure monitoring, but there's a lot more capabilities coming there for security analytics, for network performance monitoring, for getting down all the way to single lines of coding your application, how they impact everything. There's just so much power that's coming to the industry right now. I'm really excited to see where things go in the next few years. >> And Danielle, you're in the middle of all the action as a solution architect, really set the stage for their companies and the ISVs, and this is a big, hot area. What are the patterns you're seeing and what are some of the best practices that you're doing will help companies? >> Right. So I think, summarizing our entire conversation, the big things that we're seeing in the market is essentially more and more companies are looking to move to a continuous deployment and a continuous integration environment. And they're looking to innovate faster and spend less time hot patching or hot fixing their environments and they want to spend more time innovating. And so, that you know, the patterns that we're seeing is... What I see and what I actually experience firsthand at re:Invent when I talk to probably over 40 or 50 ISVs, is customers want to know in their environment, where are their changes? Where are their security vulnerabilities? Where are their data changes, and what are customers really experiencing, whether it's latency, poor experience throughout their products, those types of things? So security, data, and observability are just key to all of that experience and that's what we're definitely seeing as patterns, what we're seeing with our customers and also what value our ISVs are providing in that space. >> That's awesome. And the other thing I would observe is that there's more of an integration story going on around joint projects, whether it's open source. >> Absolutely. >> Because this is where we want to get that services connected. And it's mutual beneficial. I mean, this is really >> Exactly. >> whole 'nother, new kind of interoperable cloud scale. >> Yeah, if I could say one thing else there, I think that, a lot of the customers who are trying to move into the cloud now are, maybe not technology forward companies and they really need that solution. And that's very important. I think COVID has pushed a lot of companies into the cloud maybe very quickly. And, that has been something else we've observed in the market. So, solutions and full solutions between ISVs and ISVs, or ISVs and AWS is just becoming more and more common thing that we see. >> And, you mentioned John, in the open source space as well. Like, we're certainly from Amazon to Splunk. So we're talking a lot about those, but there's a lot of other firms involved in projects like OpenTelemetry. And I think it's very endearing, very heartening to see how well they cooperate in this community and how, when their interests are aligned, how effective they can be. And it's been very exciting to work in the space and very pleasant, honestly, to see everything come together with this huge set of customers and partners. >> Yeah. The pleasant surprise of the pandemic has been that people come into the cloud and they like it and they, "Hey, this works," and they double down on it. Then they realize, there's more there and they refactor. So, you're seeing real examples of that. So, this is a great discussion, great success story. Congratulations Morgan, Danielle. >> Thank you. >> Great partnership between Splunk and AWS. We've been following for a long time. And again, this highlights this whole another level of integrating super cloud kind of experience where people are getting more capabilities and doing more together, so great stuff. >> And this is just one facet of that, right? Like, there's all the other connections of Splunk Enterprise, Splunk security analytics products, and others. It's a deep, deep partnership between these firms. >> Yeah. And the companies that innovate and get that new capability are going to have an advantage. And you're seeing... >> Yes. >> Right? >> Agreed. >> And this is awesome, and great stuff, thank you for coming on and sharing that insight. >> Thank you. >> Congratulations Morgan over there at Splunk, great stuff. And Danielle, thanks for coming on and sharing the AWS perspective. >> Thanks for having me. >> And you guys are going to the next level. You moving up to stack as they say, all good stuff for customers. Thanks. >> Thank you. >> Okay. >> Thank you. >> This is season one, episode two of the AWS Partner Showcase. I'm John Furrier with theCUBE. Thanks for watching. (gentle music)

(bright upbeat music) >> The adoption of container orchestration platforms is accelerating at a rate as fast or faster than any category in enterprise IT. Survey data from Enterprise Technology Research shows Kubernetes specifically leads the pack into both spending velocity and market share. Now like virtualization in its early days, containers bring many new performance and tuning challenges in particular insuring consistent and predictable application performance is tricky especially because containers, they're so flexible and they enable portability. Things are constantly changing. DevOps pros have to way through a sea of observability data and tuning the environment becomes a continuous exercise of trial and error. This endless cycle taxes resources and kills operational efficiency. So teams often just capitulate and simply dial up and throw unnecessary resources at the problem. StormForge is a company founded mid last decade that is attacking these issues with a combination of machine learning and data analysis. And with me to talk about a new offering that directly addresses these concerns is Matt Provo, founder and CEO of StormForge. Matt, welcome to theCUBE. Good to see you. >> Good to see you. Thanks for having me. >> Yeah, so we saw you guys at a KubeCon sort of first introduce you to our community but add a little color to my intro there if you will. >> Yeah, well, Semi stole my thunder but I'm okay with that. Absolutely agree with everything you said in the intro. You know, the problem that we have set out to solve which is tailor made for the use of real machine learning not machine learning kind of as a marketing tag is connected to how workloads on Kubernetes are really managed from a resource efficiency standpoint. And so a number of years ago, we built the core machine learning engine and have now turned that into a platform around how Kubernetes resources are managed at scale. And so organizations today as they're moving more workloads over, sort of drink the Kool-Aid of the flexibility that comes with Kubernetes and how many knobs you can turn. And developers in many ways love it. Once they start to operationalize the use of Kubernetes and move workloads from pre-production into production, they run into a pretty significant complexity wall. And this is where StormForge comes in to try to help them manage those resources more effectively in ensuring and implementing the right kind of automation that empowers developers into the process ultimately does not automate them out of it. >> So you've got news. You had launch coming to further address these problems. Tell us about that. >> Yeah, so historically, you know, like any machine learning engine, we think about data inputs and what kind of data is going to feed our system to be able to draw the appropriate insights out for the user. And so historically we've kind of been single threaded on load and performance tests in a pre-production environment. And there's been a lot of adoption of that, a lot of excitement around it and frankly amazing results. My vision has been for us to be able to close the loop, however, between data coming out of pre-production and the associated optimizations and data coming out of production environment and our ability to optimize that. A lot of our users along the way have said these results in pre-production are fantastic. How do I know they reflect reality of what my application is going to experience in a production environment? And so we're super excited to announce kind of the a second core module for our platform called Optimize Live. The data input for that is observability and telemetry data coming out of APM platforms and other data sources. >> So this is like Nirvana. So I wonder if we could talk a little bit more about the challenges that this addresses. I mean, I've been around a while and it really have observed... And I used to ask, you know, technology companies all the time. Okay, so you're telling me beforehand what the optimal configuration should be and resource allocation. What happens if something changes? >> Yeah. >> And then it's always, always a pause. >> Yeah. >> And Kubernetes is more of a rapidly changing environment than anything we've ever seen. So specifically the problem you're addressing. Maybe talk about that a little bit. >> Yeah, so we view what happens in pre-production as sort of the experimentation phase. And our machine learning is allowing the user to experiment in scenario plan. What we're doing with Optimize Live and adding the the production piece is what we kind of also call kind of our observation phase. And so you need to be able to run the appropriate checks and balances between those two environments to ensure that what you're actually deploying and monitoring from an application performance, from a cost standpoint is with your SLOs and your SLAs as well as your business objectives. And so that's the entire point of this edition is to allow our users to experience hopefully the Nirvana associated with that because it's an exciting opportunity for them and really something that no else is doing from the standpoint of closing that loop. >> So you said front machine learning not as a marketing tag. So I want you to sort of double click on that. What's different than how other companies approach this problem? >> Yeah, I mean, part of it is a bias for me and a frustration as a founder of the reason I started the company in the first place. I think machine learning or AI gets tagged to a lot of stuff. It's very buzzwordy. It looks good. I'm fortunate to have found a number of folks from the outset of the company with, you know, PhDs in Applied Mathematics and a focus on actually building real AI at the core that is connected to solving the right kind of actual business problems. And so, you know, for the first three or four years of the company's history, we really operated as a lab. And that was our focus. We then decided, we're trying to connect a fantastic team with differentiated technology to the right market timing. And when we saw all these pain points around how fast the adoption of containers and Kubernetes have taken place but the pain that the developers are running into, we actually found for ourselves that this was the perfect use case. >> So how specifically does Optimize Live work? Can you add a little detail on that? >> Yes, so when you... Many organizations today have an existing monitoring APM observability suite really in place. They've also got a metric source. So this could be something like Datadog or Prometheus. And once that data starts flowing, there's an out of the box or kind of a piece of Kubernetes that ships with it called the VPA or the Vertical Pod Autoscaler. And less than, really than 1% of Kubernetes users take advantage of the VPA mostly because it's really challenging to configure and it's not super compatible with the the tool set or, you know, the ecosystem of tools in a Kubernetes environment. And so our biggest competitor is the VPA. And what's happening in this environment or in this world for developers is they're having to make decisions on a number of different metrics or resource elements typically things like memory and CPU. And they have to decide what are the requests I'm going to allow application and what are the limits? So what are those thresholds that I'm going to be okay with so that I can, again, try to hit my business objectives and keep in line with my SLAs? And to your earlier point in the intro, it's often guesswork. You know, they either have to rely on out of the box recommendations that ship with the databases and other services that they are using or it's a super manual process to go through and try to configure and tune this. And so with Optimize Live, we're making that one click. And so we're continuously and consistently observing and watching the data that's flowing through these tools and we're serving back recommendations for the user. They can choose to let those recommendations automatically patch and deploy or they can retain some semblance of control over are the recommendations and manually deploy them into their environment themselves. And we, again, really believe that the user knows their application. They know the goals that they have and we don't. But we have a system that's smart enough to align with the business objectives and ultimately provide the relevant recommendations at that point. >> So the business objectives are an input from the application team? >> Yep. >> And then your system is smart enough to adapt and address those. >> Application over application, right? And so the thresholds in any given organization across their different ecosystem of apps or environment could be different. The business objectives could be different. And so we don't want to predefine that for people. We want to give them the opportunity to build those thresholds in and then allow the machine learning to learn and to send recommendations within those bounds. >> And we're going to hear later from a customer who's hosting a Drupal, one of the largest Drupal hosts. So it's all do it yourself across thousands of customers so it's, you know, very unpredictable. I want to make something clear though as to where you fit in the ecosystem. You're not an observability platform, you leverage observability platforms, right? So talk about that and where you fit into the ecosystem. >> Yeah, so it's a great point. We're also, you know, a series B startup and growing. We've the choice to be very intentionally focused on the problems that we've solve. And we've chosen to partner or integrate otherwise. And so we do get put into the APM category from time to time. We are really an intelligence platform. And that intelligence and insights that we're able to draw is because of the core machine learning we've built over the years. And we also don't want organizations or users to have to switch from tools and investments that they've already made. And so we were never going to catch up to to Datadog or Dynatrace or Splunk or AppDynamics or some of the other. And we're totally fine with that. They've got great market share and penetration. They do solve real problems. Instead, we felt like users would want a seamless integration into the tools they're already using. And so we view ourselves as kind of the Intel inside for that kind of a scenario. And it takes observability and APM data and insights that were somewhat reactive. They're visualized and somewhat reactive. And we add that proactive nature onto it, the insights and ultimately the appropriate level of automation. >> So when I think, Matt, about cloud native and I go back to the sort of origins of CNCF who's a, you know, handful of companies. And now you look at the participants it'll, you know, make your eyes bleed. How do you address dealing with all those companies and what is the partnership strategy? >> Yeah, it's so interesting because it's just that even that CNCF landscape has exploded. It was not too long ago where it was as small or smaller than the FinOps landscape today which by the way, the FinOps piece is also on a a neck breaking, you know, growth curve. We, I do see, although there are a lot of companies and a lot of tools, we're starting to see a significant amount of consistency or hardening of the tool chain, you know, with our customers and users. And so we've made strategic and intentional decisions on deep partnerships in some cases like OEM uses of our technology and certainly, you know, intelligent and seamless integrations into a few. So, you know, we'll be announcing a really exciting partnership with AWS and that specifically what they're doing with EKS, their Kubernetes distribution and services. We've got a deep partnership and integration with Datadog and then with Prometheus and specifically a few other cloud providers that are operating, manage Prometheus environments. >> Okay, so where do you want to take this thing? You're not taking the observability guys head on, smart move. So many of those even entering the market now. But what is the vision? >> Yeah, so we've had this debate a lot as well 'cause it's super difficult to create a category. You know, on one hand, you know, I have a lot of respect for founders and companies that do that. On the other hand from a market timing standpoint, you know we fit into AIOps, that's really where we fit. You know, we've made a bet on the future of Kubernetes and what that's going to look like. And so from a containers and Kubernetes standpoint, that's our bet. But we're an AIOps platform. You know, we'll continue getting better at the problems we solve with machine learning and we'll continue adding data inputs. So we'll go, you know, we'll go beyond the application layer which is really where we play now. We'll add, you know, kind of whole cluster optimization capabilities across the full stack. And the way we will get there is by continuing to add different data inputs that make sense across the different layers of the stack. And it's exciting. We can stay vertically oriented on the problems that we're really good at solving but we can become more applicable and compatible over time. >> So that's your next concentric circle. As the observability vendors expand their observation space, you can just play right into that. >> Yeah. >> The more data you get because your purpose built to solving these types of problems. >> Yeah, so you can imagine a world right now out of observability, we're taking things like telemetry data pretty quickly. You can imagine a world where we take traces and logs and other data inputs as that ecosystem continues to grow, it just feeds our own, you know, we are reliant on data. >> Excellent, Matt, thank you so much. >> Thanks for having me. >> Appreciate for coming on. Okay, keep it right there in a moment. We're going to hear from a customer with a highly diverse and constantly changing environment that I mentioned earlier. They went through a major replatforming with Kubernetes on AWS. You're watching theCUBE, you are leader in enterprise tech coverage. (bright upbeat music)