>>Live from San Diego, California at the cube, covering to clock in cloud native con brought to you by red hat, the cloud native computing foundation and its ecosystem Marsh. >>Welcome back to the cube bumps to men. And my cohost is John Troyer and we're in San Diego for coupon cloud native con 2019. Our fourth year of covering this show over 12,000 in attendance, such growth in the ecosystem. Lots of different projects to talk about, not just Kubernetes, but joining us first time on the program. Longtime watcher Webb Brown, who's the cofounder of cube costs, yet another project here in, in the uh, ecosystem. So thanks so much for joining us. Thank you so much for having me. All right. So, uh, as a, you know, every time we get a founder on his, you know, tell us a little bit about your background and give us that why of what led to the creation of QT. >>Yeah, absolutely. So, uh, our founding team all worked in infrastructure monitoring at Google for a long time and, you know, working in container orchestration environments, uh, we saw this challenge where teams that were moving and Coopernetti's, uh, were finding themselves, uh, kind of easy to let costs kind of get away from them. Um, there are a lot of moving parts that weren't there before. There's a lot of dynamic aspects that are hard to just really get your, your arms around it. Um, and we found ourselves just really pulled towards helping teams, you know, solve those problems. Um, so yeah, that was a little over a year ago today when we made the plunge and, and here we are. >>Yeah. You know, we remember the days when, you know, public cloud was supposed to be simple and inexpensive and we found out that maybe it's neither of those things necessarily. Um, you know, let's click it a little bit as to, you know, containers, Kubernetes, what's different about this then? Everything else we've been doing in public cloud, uh, for the last, you know, 10. >>Yeah. Yeah. So, so we believe in like, it's ideal state. It still has the ability to be exactly those things, right? Simple and much more affordable. Uh, but we think that there's like tools and elements of this that create risk to the contrary. Um, and we think kind of, you know, there's three things that are different here. Uh, first is that you now have access to these incredibly powerful abstractions that are available at global scale that give you access to these really expensive resources, right? And mistakes can be costly there. Uh, two is you're seeing this like move towards decentralized deployments where you're now having individual product or application engineering teams managing their own applications, even provisioning their own infrastructure and it's a lot higher velocity, a lot higher, like dynamic environments. And then three is just, uh, it's much harder, harder to have visibility when you're in these multitenant environments. Right? You know, you can now have many teams, many even departments shipping on a single VM or a, a S a small set of EMS. >>All right, if you could just give us kind of bumper sticker or sticker on the project itself. How long has it been around? Uh, it fell ball and get hub. I see. And how many people are using it, >>growth, things like that. Absolutely. Absolutely. So we started the project about a year ago. Um, the, the get hub project specifically is for doing cross cloud cost allocation. Um, there's a lot of challenges for like measuring the cost of say, CPU, Ram, storage, et cetera. When you talk about having, you know, spot instances and U S central on AWS versus, you know, committed use in, you know, us central on TCP. So this project helps develop a uniform standard and library to measure costs across all these different environments. Um, hundreds of teams are using it today. Uh, we have integrations with Azure, GCP, AWS, and we also support on-prem Kubernetes clusters. What kind of a minor detail web, but I mean, those costs change week over week as, uh, announcements happen as instances go up and down. I mean, how, how does the project and the community come together to, to even track all that? >>Yeah, no, we know it well. I mean, we're living and breathing and seeing exactly that. Um, and that speaks to, you know, really the complexity here. Um, and the project is designed to support exactly that. So constantly refreshing billing data, uh, dynamically looking at wind pods or jobs are coming up and going down and in real time look at the cost of the nodes that they're actually running on. Um, that is both the beauty and the challenge that we face is things can change so quickly and oftentimes that's for the better. But it's also a challenge to just stay on top of all the changes happening. What does, does the community help assemble that data? Are there AP? I mean, does that, I don't think there's cost API APIs for every cloud or maybe I'm wrong. So we have, we do have a billing API integrations for these three cloud providers. So like I mentioned, AWS, Azure, GCP, uh, the community has been instrumental in finding all these edge cases, right? So like, you know, GPU in this environment versus, you know, storage in this environment. And that's, it's really this long tail of complexity that's really hard for getting this right. And the ecosystem has been absolutely key to finding all those like nooks and crannies to get this just right. Okay. >>Just finishing that thought on, on the billing, you've got billing API in the public cloud, but on the, on premises environment, uh, your mileage may vary, I'm assuming. How does that fit in? >>Yeah, you can, you can think about is kind of bring your own pricing sheet, right? So like we want to support your environment and that could be you care about, you know, just the price of CPU, memory, storage, GPS, etc. But it could also be, you know, you have some centralized ops teams that you want to allocate or like amortize the costs of across all of your tenants in that cluster. So we want to meet you where you are and give you full custom, you know, like inputs to tailor this to your environment. Okay. >>We've talked about the project. There's also a company, a associated with us, help us understand the relationship, the size of the team, uh, kind of the business strategy there. >>Yeah, absolutely. So we have an open core model where our commercial product is built on top of this open source library. You can think about it providing a lot of the, the UI and enterprise management functionality, things like, you know, multi-cloud view, uh, longterm durable storage, SAML integrations, that sort of stuff. Um, you know, we're a small team of engineers right now. Um, you know, all engineers. So we're living and breathing the like actual, you know, writing go, you know, writing code every day. Well, w we're a lot of, we live in a world. Uh, we're maybe, I dunno for post dev ops yet, but there's a lot of dev ops here at this show. You, we've got many flavors of dev ops, dev, sec ops. I mean, is this, who is, and I'm, where I'm going is, is there a dev cost ops developers now have to be worrying about the cost of what they're doing, who, who is paying attention to the, to the, uh, the, the, the cash register. >>The at the top of the coop cross. Yeah. Stack. >> Yeah. I think it's very similar to what you just said is all of this is in flux, right? And there's so many different models, uh, that are, that are working and are constantly evolving. Um, what we typically see is it's uh, someone from the finance org and someone from the dev ops org that is jointly caring about this, this picture. Um, so you know, we have opinions on how this can work really well, but we also love to just let the industry and you know, in different enterprises guide us and kind of meet them where they are. Um, but, but we think that this is going to be continuing to evolve and change for the years to come just cause so much. >>It's such a big challenge. I've talked to some large enterprises that they assign engineering resources to do the financial engineering thing and it seems that number one is the cloud providers should be able to put, put some, you know, pieces in place. Secondly, you know, automation intelligence of, you know, that this entire ecosystem should be able to help. There. Is that, is that really where your, your, your team and your project is focusing to, you know, to take that, I don't want that, you know, you should be building new apps and helping my business not sitting there watching the meters and saying, Oh wait, I need >>yeah. Turn some knobs. Yeah. So I think the first part of what you mentioned is very relevant and, and was kind of the kicker that really pushed us over the edge to start this project start this company is we saw teams that were building their own internal solutions are doing all this ad hoc analysis and Oh by the way, pretty much every team we talked to is doing it differently. So that was what our real inspiration to say, okay, we have to do this. Um, we absolutely see an evolution to just more and more automation and intelligence. But you have to think about cost is not an isolated variable. Cost is very closely linked to reliability and performance, stability, all of these things. So you want to be really thoughtful and really careful when you start handing this stuff over to an algorithm. Right? Because it can mean, you know, performance regressions, it can mean, so we, you know, we absolutely see the industry evolving there. >>Um, we see a lot of teams that then in our view are like, uh, rightfully cautious before kind of handing over the keys, uh, to, to an algorithm or set of algorithms that are going to really dial the lever for them on, you know, the right amount of say, memory, compute, et cetera. I imagine there's also tradeoffs between, uh, engineering resources and cost. Right. I could do it the, the, the S the fast way with one engineer and it, and it might have one cost application. I might, uh, sure I could get my cloud costs down, but it might've taken me, you know, 10 engineer months to do. So. There's all, it's interesting. Is there a conversation in the, like, let's use the community in the broader sense about how to do this kind of capacity management and trade offs. Is there an emerging, you know, it's hard in the OSS world if there's not a project around that you can gather around. >>How do you have a conversation around, you know, costs and engineering trade offs? Yeah, I think we're still really early here and I think there's still huge opportunity. Um, and we just feel that it's incredibly challenging if you just look at the engineering side, you know, there's so much uncertainty to go in and say what's it going to take to move us from, you know, on demand a spot or move us from one reason to the other or one provider to the other. Um, that it's really hard to really put an expected costs on that and do an appropriate ROI. Um, what we've seen that, uh, a lot of teams are able to really easily identify the low hanging fruit where there's a very clear ROI, but these like, you know, marginal decisions, absolutely think there's, uh, more frameworks and more tools that can help teams make those decisions. Well, all right, so >>love to get your personal viewpoint as you're working for a startup. You're here in this massive ecosystem to tell us about that kind of environment, how it is in this cloud native ecosystem. And, uh, you know, any specific things around, you know, the event itself, >>they are welcomed. Yeah. Um, so, you know, we're coming from Google and a lot of our exposure to bigger conferences was, you know, things, things like Google IO and Google specific events. Um, and, and those are amazing to have their own, you know, ecosystem and kind of atmosphere. But, but I've never felt energy like this. I've never seen so many things that are new. So many things are changing all at once. Um, that it just, it's impossible to not get here and be excited by this stuff, right. Of like, um, you know, a lot of us have ideas how things were of all, but I definitely can't claim to like, you know, have really any real conviction around how this broader ecosystem or law that, and that just adds to the excitement of so many things are improving and evolving all at the same time. >>Yeah. Do you feel a small company like yourself can get attention with everything that's going on here? >>Yeah. I mean, what we want to do is we want to be the very best at costs. And capacity and, and, and while that touches on many things, that's really small area. So, you know, our approach is we're not going to be everything. And, and while that can be hard at times, um, we think that's right for a small team. And that's my general advice to anybody that comes to this eco is, is finding a real problem, uh, and be comfortable not being everything for everybody, but go and solve that for a set of users and do it the best. All right. If you could just give you the final word here, what should we be looking for for from Q cost, uh, kind of over the next year? Yeah, I think just, uh, you know, really getting, going deeper and broader in costs and capacity management. >>That's bringing our tools to more platforms, more users, uh, more intelligence and, and automation over time, but just continue to approve a visibility to make this easier and easier for teams to make these appropriate tradeoffs where they invest engineering resource and how they optimize costs. All right, well what, Brian, thanks so much for joining us. We are welcome to welcome. We're glad to welcome cube cost to the cube alumni. Thank you so much, John Troyer. I'm Stu Miniman and check out the cube.net for all the coverage. Uh, we've been for years at this event, uh, in the U S we've also done the European shows and so much more come in three days, wall to wall coverage. Thanks for watching the cube.