 So let's get started. Good afternoon, KubeCon. You know, I'm Sonic Beharra here. I'm the head of products at a company called Cloud Analytics. Spent last 20 years in the armpit of infrastructure. As we know it, and in the open source space, starting with being an early engineer in virtualization at VMware to creating software-defined networking at a company called NYSERIA. I created an open source project called Neutron, which was a subsystem of networking for OpenStack, and then created the data center operating system as a commercial product based on the Apache Mesos project. But today I'm not here to talk about technology, but something rather more dear to my heart based on my experience on these years working in, you know, technology as well as more recently in the cloud native space. And that is how do you make the business case for the technology? How do you make it cross the chasm? How do you actually push it forward in your organizations? Right? So, you know, how can we help justify the value that we bring to the table, not just implement? And finally, how do we measure the value we are providing after we implement and close the feedback loop? We did what we were saying we were going to do and we showed that we did it and then finally close that loop, right? How do you do that? And I believe as cloud native crosses the chasm it becomes imperative on the community on all of us that we enable the t-shirts to speak to the suits, right? The DevOps folks to be able to speak to the finance and the line of business executives to actually make people understand why we do this. And I hope today I can give you one of the tools in your toolkit that will help you do just that. So, you can start with kind of the agenda why, then the how part of it and then what we'll do a demo of what this toolkit is and how you can use it and how we can actually participate and all make it better together. So let me start with something, why FinQ, right? Because there's a code that struck a car with me that says no one will pay you what you're worth. No one will ever pay you what you're worth. They will only pay you what they think you're worth or your project is worth. And the good news here in that code is you or we can control that thinking. If you set it up the context correctly, you have that control. If you don't, then it's a lost opportunity, right? So who wants to get paid more over here? Me? There you go. Lots of us, we can take a lot of these lessons and apply it to our regular lives. I'm going to focus really on Cloud Native and what it means to control the thinking on actually moving on a Cloud Native project if you have a non-Cloud Native, non-communityized infrastructure, how do you make the case for that? But some of the primitives or some of the concepts we talk about applies everywhere. So there is something in it for everyone. If you're a technologist, you're an engineer or not. So the way you control that thinking is by clearly defining and communicating the value. If you define the rules of the game, this is why it is important, how it's important, a priori, and then communicate it properly so that we are aligned on what are we doing and how we're driving that value. And if we don't do that, right, we're going to see more of this. Two articles that showed up in last week are just looking. It's like, yeah, we've done all this work. It's not useful, effectively. And that's where the objective is misguided because some projects, some companies clearly didn't define their objectives and didn't communicate the value. People say it's not worthwhile or worse yet. You're going to go on a failure mode for the project. So that's the high-level objective. You want to clearly define and communicate value. Taking the next step, so how do we do that for things we care about in this community is to help Kubernetes and Cloud Native in general, Kubernetes in specific, cross the chasm and become kind of standardized infrastructure layer. And I'll start that with the journey I hope our users take. We have a set of tools in the community. A lot of folks here have heard of the Landscape project or landscape.cnsfio. It's great. It's good for discovery. You go and discover the specific tools you need in your toolkit to implement a specific use case initiative or a project. And then we jump directly to implementing those, right, to getting dirty with Terraform or whatever installable you have, and then the YAML files for modernizing the applications, et cetera. And then, of course, once you have implemented it, all the challenges which most of the folks in this, the solutions exchange and the sessions here talk about is how do you operate and optimize and keep the lights running, right? We keep jumping the loop, but what we miss is that opportunity in between discovering and implementing, which is justifying and defining why we're doing how we will measure success so that when we actually operate and optimize, you get the credit that you deserve for what you did. And that's what I hope FinCube fills the gap. And to better understand the toolkit I'll talk about, we need to talk about a little bit basics of pricing and how people think of value and how they communicate, right? This is a rough hierarchy. I framed it in the order of Maslow's hierarchy of pricing, if you will, right? The base layer starts with cost. You add up all the cost for your Kubernetes project, people, hardware, cloud, time. You add that cost and that's the easiest way to say, this is how it costs. That's how people communicate value, which is not the right way necessarily, but it is the easiest way because you can do math. A lot of us are engineers. It's easy and this is what it costs. And if somebody is a business selling that, they will say that, okay, we allowed a margin on top of that cost and that's our business. Unfortunately, internal companies, internal teams, tech ops teams, DevOps teams, IT ops teams, just out of the cost. And then people view as not a value creator, but as a cost center that needs to be reduced and optimized and not as a value creator because of the model, how we define and communicate our value again, right? So the easiest way to take the next step would be think of a value-based pricing or value of the Kubernetes project that you're bringing on, bringing it to your company, the different kind of objectives. And I'll talk about that in the toolkit. Specifically, if you look at the value-based pricing, it talks about not the cost, but what it's doing for the company is how it's making it efficient, how it's making developers more productive. So if you can release more software faster, what does it mean to your business's top line? How is it making the infrastructure more available? So typically, you know, a single outage cost about $300,000 an hour on an average company, maybe different for your company. So if you shave off 10% of that, that's $30,000 an hour, multiply with number of outages you have. There you have another vector, the kind of availability vector and that's monetized, right? That would be a way to communicate the value that you're driving versus the cost you're optimizing. And really, my hope is, as folks start using that terminology and go from just being a cost center to a value creator, we can move to the next step, which I call true price, meaning not only the value you're creating for your company, but also the value you're having based on that, how you're having the sustainability impact, because things are more efficient, what is the environmental impact and what is really a true price of that initiative? Not only price in terms of dollars, not only for a price in terms of value, but in price in terms of the whole of the environment and everybody else that participates in the ecosystem, right? So that's where we would like to go, but where we are is very much a cost center, cost focused area, crawl, walk, run approach would be what if we can just move to the next step and talk in terms of the value you provide in terms of the amount we cost. So with that, let me introduce to you the toolkit. You can go to finncube.io and get a lot of the resources, the GitHub repositories, everything else today. It consists of three things, and I'll demo that to you. Once today it's just a plain, kind of an ROI calculator. It's an Excel sheet with like eight different sheets, very MVP-ish, so we can get started and expose people to the idea and see how folks use and what the feedback is. Once you do that, you get your ROI for one use case, which is moving for a non-cabinetized non-cloud-native infrastructure to a cubinitized cloud-native application architecture, and based on that it'll say what is the potential perceived impact for certain size clusters, for infrastructure efficiency, for developer productivity, and for infrastructure application availability. And you'll have the hypothesis or assumptions I have made, but because it's open source you can customize that model, which may better fit your company if you don't agree or doesn't work. The standard model doesn't work for you. Out pops like the graphs and charts you can show to make that business case based on that three objectives I mentioned efficiency, developer productivity, infrastructure availability, and then you have a very poor man's toolkit or poor man's way of very quick and dirty making the business case of why you want to move forward with this project. So that's the first two legs. The third leg will be a set of test cases or things you want to accomplish to prove out. So the first two are hypothesis. This is how much infrastructure efficiency will increase. This is how much the developer will be more productive. This is how much my attributes will go down. It'll be like, great. Now I'm doing the project. Maybe I'm doing a pilot or a POC or a small scale. What are the things we are measuring? What are the metrics we're measuring? That's how we put in our test plan or POC plan and see before Kubernetes and after Kubernetes. What is the meantime to resolution? Or what is the number of builds or release a shipped per quarter per day? And then you can close that loop in a very quantitative, in a very logical way, because once you have the numbers it's very clear what was before and what was after and what actually got delivered. Sometimes mistakes happen, you'll make a hypothesis and it'll probably may not be 100% right. But at least you have the framework to now continuously improve that model. So without further ado, let's head over to give me a second to finncube.io and the mirror of my displays and I can give you a live demo of the toolkit. Okay. So you can go to the finncube.io the first thing you can subscribe for updates to the toolkit. You can join the Slack channel to give feedback or go to GitHub if you want to kind of make changes or file issues, but I'll just go to the resources tab which will open up a kind of a shared Google Drive. I have the license files in there as kind of a patch to you guys can use it as you wish. Modify it. The first piece is the ROI calculator that I mentioned. It's got instructions make a copy for yourself. The first tab of this is pretty simple. The columns that are highlighted are all you need to fill out. Now all the other knobs you can, it's like the advanced user mode and hopefully over time I make more kind of a blog post on how to use that. You can talk about your project name, use case. Today we have only one use case which is Kubernetes from a non-cubinatized infrastructure. Future, we can talk about automation, application delivery, you know, more cloud native application services, other use cases as well. Talk about how large of your project you're talking, tiny 10 node cluster, you know small 100 node, medium node, etc. Let's 1000 node cluster and you can talk about what size of VMs or nodes you're using and without Kubernetes. And our assumption is that because it's intelligent cluster manager, we should be able and not only assumption, we have seen it in the industry is that you can use larger nodes and impact more services in less number of nodes. So you can talk about, you know what are your ideal size of Kubernetes nodes you will go to from your non-cubinatized node and expected, currently expected utilization. You can look up your actual number, so you know, whatever it is and 9% what I have while it looks low, it's very much with an industry standard if you go into any environment you see, maybe 15, 20% on some companies but really it's in that and you can make the assumption it increases by 2x or 3x and this is based on real life experience what I've seen in some of the studies folks have done is about 2-3x, net utilization increase you see. Forget requests and limits but really the raw utilization number if you look at the operating system level and you're making, it goes from 9% to 27% right. Everything else you can see how it computes on how many DevOps salaries, developer salaries, et cetera customisable and that's it and the next step is you go to the cover sheet and it gives you the graphs to have your first point of view, your strawman on a business case on operational efficiency, developer productivity and kind of application availability how much you're going to save before Kubernetes and after Kubernetes. So once you have this, if you want to customize it of course you can go to all these tabs which have details for each one of this value drivers if you will. So you can customize all the assumptions I made around before Kubernetes and after Kubernetes but that's kind of the advanced mode, player mode if you will. So for most folks this should be sufficient. You have the initial use case we'll take questions at the end and then you go back to the FinQ project the business case and it's got a template kind of a presentation where based on the numbers you and to your environment you've calculated, you've put in for each one of the objectives what do you expect the return or the impact will be. And again, based in the graphs and make why you think those will, sometimes these points of why you'll make that impact will be custom to your company or your application or how much how critical downtime is or what is the real true cost of your downtime etc. And once you have that you can show the summary of your total Kubernetes project your operational efficiency impact, develop productivity impact and your reliability or application availability, outage reduction impact and that should give you if not everything a very good strong foundational strongman to make that business case in current OE. Of why you'll take on that Kubernetes use case. So with that and I promise we'll have, I think we'll have plenty of time for Q&A or a little time at least once you and with that, you know, that is kind of the foundation of to pin Q as you can go ahead try it pretty low bar to entry you know, if you want you can create macros and other things but for most folks they can just get started, it's like Excel and PowerPoint and the reason I started with an MVP of an Excel and PowerPoint is because the roadmap or the thinking is that what is coming to tank and how people use and which pieces are confusing and which is valuable imagine it being a V1 beta spent six to nine months get that feedback and you know, see which things should be kind of prepopulated or which should be like the easy player mode and which should be in advanced player mode you get that feedback and then make it you know, call it GA and expand to more use cases like what is a, can I do a similar turnkey easy business case for application delivery or for some other kind of use cases which is additional value beyond moving to Kubernetes that it can do and once we have that kind of bootstrap we can of course make it like a web app that's the way landscape.cnc.io is based on community interest, how many people want to do it who wants to work on it, etc it's probably easier once we have this working in just a non-code or Excel code working we can move it to like a web app code so people can self-serve and becomes a easier use business casing toolkit not only for Kubernetes, a lot of these principles are beyond Kubernetes so if you're starting an open source project or starting a company or product you can use these same principles and should be able to build up a pricing plan of how you want to show why your thing is worth something or what is the impact it's having, right? So that's the thinking on the roadmap so to quickly summarize what we went through you know you have clearly defined and communicate value to make your project successful you need to intercept the journey early and do that, build that definition as early in the journey as possible to ensure that you're set up the company, set up the project for success second, join the FinQ community try it out, give feedback use it and that's how you will provide value to your company and to the community and we can upstream this back to the masses that everybody else can leverage that selective experiences of each one of us so that we can actually make technology the cloud native movement a lot more mainstream as we cross the chasm as we go into larger companies and bigger initiatives and finally that's how you become a hero and you know, get promoted right so that's how I had a top level I think we have plenty of time to take questions so I'll go ahead and open up the floor for questions and for once the questions we don't cover, I will be at boot SU-84 on the show floor cloud native to answer from there hi, thank you I really like the way that you quantify some of the advantages with Kubernetes on a numbers based level I think that's really important I was wondering if you could speak to the calculation of the value for improved developer velocity I saw you had on one slide and then a minor point of suggestion I leave the graphs for costs with and without Kubernetes the legends are reversed on the first two graphs which makes it seem like Kubernetes costs the colors were right but the placement of the bar was reversed I was wondering if you could speak to the developer productivity it's hard to quantify at least as I understand it when I quickly go back so I went really quick so there's a lot more to it so if you go to second tab it talks about developer productivity with and without Kubernetes and every stage of the application development journey when you can do more with less because you have a programmatic infrastructure this assumes you're non-cubinatized infrastructure probably not even containerized on microservices so if you're doing application definition or builds it just takes more work once you have a cubinatized infrastructure the line items will talk about the number of hours saved and the overall high level message without going to weeds here is that you can ship more builds more releases in less time and that equals to making more progress for the business therefore more features out in the market and therefore for every expensive developer we all the companies pay for work in charge supply you're actually making them more efficient and that's how the value is coming you know if I make if I pay a developer $100,000 make them 10% efficient that's $10,000 in value and here make them three times as efficient that's like $300,000 so that's the basic premise of the calculation good question thank you any other questions? I have a question up here I was wondering what the basis of just by taking an application and dropping it into a cubinatized cluster increases efficiency what's the basis of that? so the basis of efficiency is you know traditionally cuts commercial off the shelf for traditional virtual machine based applications which were non-containerized non-cloud native or which are applications where black boxes so it was hard to multiplex multiple applications on the same set of pool of cluster nodes same set of pool of hardware so the core premise is that once you go to a clustered system beat anything before it was mesos, docker swarm and I'm talking about cubinatized because it has become the de facto standard and it's like dial tone but once you go to a clustered cloud native system because you can multiplex multiple apps therefore you can basically bend back a little better okay so the basis is from cuts applications that expect to own the entire VM to containerized that could be a problem because most commercial applications are not delivered or don't support running in containers yet correct and that's why you'll have a business case this is why you should probably need to do at least that much work if I do the work is it worthwhile and that's a question we have seen a lot of users and customers like yeah I know it will be useful but I'm going to have to spend a month containerizing and this is a way you can kind of preempt that question like this is clear value and that there's a clear cost now let's decide should we do it or maybe for some of them it doesn't make sense to make that decision thanks any other questions I think we have a couple of more minutes oh there's two more questions over there hi my name is Lili I'm with kubecost I had a question just regarding ongoing validation for kubernetes so this seems like a really great tool for at least making the first initial business case to executive stakeholders but what happens once you have kubernetes in production is how would you view finkube as a tool to then further continue to validate ongoing projects over time thanks so the question was that you know from this lady from kubecost how do we validate an ongoing basis the value delivered so what I showed finkube as a toolkit early was a journey of moving to a cloud native architecture from discovery to justification to implementation but once you do that you have to operate and optimize there's an ecosystem of finops tooling and finops and cloud and capacity and availability optimization tooling which all of us observability tooling which you have to deal with and that was not the focus it's not the focus of finkube it's the commercial and open source tooling there what the folks should and can leverage to continuously operate continuously optimize and keep their infrastructure optimized and be able to report back close the loop there finkube is really focusing on early in the life cycle how do you set the rules of the game another question for the lady over there if there is no other question please take a moment to leave us any feedback appreciated join the finkube community and if you have more questions if you have more feedback come find me at the SU-84 booth happy to talk about finkube finops and what should we do next thank you