 Good afternoon and welcome to our talk with Phenobs through the Cloudcast jungle. Today we'll talk about how you can achieve transparency in your cloud to optimize custom usage within the Phenobs framework. We will also take you on a little journey through a real jungle, so stick with us. My name is Viviane and I'm here with my lovely colleague Vanessa. We both work at Liquid Reply. I have a background in media informatics and I'm specialized on data analysis and Phenobs. With a focus on knowledge sharing because there are still enough people out there who don't know how to save money in the cloud and how to optimize it. I'm Vanessa. I ended up doing Phenobs like two years ago and before that I did I was a technical project manager and also a cloud consultant and what I really like about Phenobs that it brings all of those dimensions together and even more there is one one topic I need to talk about and it's green ups because that's I would say is my new passion and green ups is all all about optimizing your cloud environment for sustainability. So measuring the carbon footprint and optimizing that one but I guess that's a topic for another day. So let's start our expedition through the cloudcast jungle. This is our agenda for today. First of all we will talk about the problem and we will introduce you to Phenobs. We will enable you to become your own guide and achieve transparency and in the end we will give you an outlook into the future. Okay let's start with the problem. Why do we even need that Phenobs? Previously pre-cloud and the old on-prem days there was a super easy and straightforward process. At least it was easy for the finance people right? It's on the left side here on the slides you can see an engineering team or a project team and that team had a demand maybe a demand for some piece of hardware let's say a standard on-prem server and they communicated that demand to their project manager maybe to the team lead that's the person in the middle and that person verified it, planned his or her budget accordingly, approved it and then forwarded it to the procurement department. The person on the right side the procurement person and then purchased a piece of hardware the server and yeah that's it pretty straightforward and six to eight weeks later a beautiful server arrived and with it came the invoice. The controlling department or finance department on the right side of the slide they processed the invoice and that was pretty easy because the costs were already planned before and it's just standard capital expenditure they were able to amortize it everything is fine purchase done and the engineering team used the server and usually quickly the server was over or underutilized hopefully overutilized and so that started the whole procurement purchasing process all over again. To stay in jungle terms because that's what it's all about today that old process was all like planting one tree after another now the present the cloud days you see it's a lot more complex than before now engineers can buy the resources by the push of a button but it's not only with one cloud provider but with all of them and at the same time it's not only about infrastructure but service anymore maybe you've heard about past SAS and fast whatever else is out there and so they can buy it just whatever cloud resource they want and wish for by the push of a button without waiting for any approval of our team lead of a project manager or else. The difficulty with that is that also nobody planned in the budget so at the end of the month an invoice more than one invoice typically arrives and the controlling department on the right side with the question mark were asking themselves okay where did that came from all of these variable costs we haven't planned them what's happening so they're diving deeper into the invoice and quickly they stumble upon a huge amount of data so you can see like in the back of that slide that's AWS curfile that's short for cost and usage report and that curfile is a huge CSV full of rows and rows of rows and each row shows the purchasing of one resource in one hour one time unit and you can imagine that curfile has like a million rows for a short amount of time and yeah it's just not human readable anymore and so in the present what does the finance department do in the best case they go back to the engineering people and just ask them but then the engineering people have to continuously justify them about every single line item of that curfile that's annoying right I mean in the worst case that the finance department wants to go back to the old on-prem processes meaning they again try to get a debt approval process or maybe they can or allowed to apply some policies but that hinders innovation because the engineering people then can't buy those resources super quick anymore so the time to market is not as fast as it would be with the cloud and yeah it's not working well and at the end of the day also silos start building up so the people are annoyed of each other obviously and so they don't they stop talking to each other angry and things are not working properly yeah so what can we do about that baby this is where FinOps comes in to save the day so what is FinOps exactly FinOps is a cloud financial management discipline it's a cultural practice to break down the silos between the different departments this is the issue and as I mentioned before about the current process FinOps is a combination of DevOps and finance and FinOps is not something you do alone so you could see the collaboration between the different departments as the engine for the FinOps practice the goal here is to get the most value out of the cloud usage with constant usage optimizations and if all the stakeholders work together they can collaborate on data-driven spending decisions and they can leverage all the promised benefits of the public cloud and this is how the future looks like first of all you take all the data of the cloud so not just the builds or not just the cost of usage report you just saw you take all the data from all the different cloud providers you use and then you normalize them you make them readable and usable you put them into useful KPIs for all the different stakeholders to work with and this breaks down the silos so they start working together and they can make cloud-based innovation and this whole process contributes to transparency and transparency is very essential especially to efficiently optimize costs and save costs and without transparency people stay confused in their cloud and with the collaboration they can manage the cloud cost jungle together so how to achieve transparency that's our main topic for the day and we'll demonstrate that by using a wild tropical jungle so imagine you're stranded there in that beautiful some color the green hell and some of these plans maybe you you've stranded there with a few strangers you don't know yet and of course you need to survive and so you look at your surroundings you see all of those plants maybe you see some plants that look familiar others do not we are not biologists I'm not I'm an IT person but you need to make sense out of this jungle because I mean you want to survive now so what do you do next how do you start yeah just getting familiar with your environment well you guessed it it starts with transparency and mapping that to the cloud before we come back to our jungle I'm talking about the account structure the account structure is the first step in achieving transparency and accounts themselves are like isolated units they're like units where you can group resources or accounts are also units just like a logical kind of grouping and when you have an account it's not only beneficial for billing because the invoices at the end of the month are an on an on account basis but it's also beneficial for other things like for example security because when one account gets compromised it doesn't automatically mean the other one is so there are a few different benefits to that how to decide the account structure is heavily dependent on your organizational structure and on the right side of the slide you see an example of proposed account structure and that could start with the company on top then you have like different departments below that different products and at the end you have staging for each of the products or in that example just for product that and in that example the in in none of these so in in the staging accounts there are the cloud resources then so you would see a VM or maybe a EC2 instance if you were working with AWS under one of these dev product that accounts but you will probably not encounter one of these cloud resources and at any other account because the others are just used for logical yeah grouping of resources and just as a means to make sense of your invoicing at the end of the month so for the account structure to define that in your company you really need again the involvement of the different stakeholders because the finance people can tell you okay what are the cost centers that are relevant how does the invoicing process work at your company but you also need the business department and of course also the engineers and all together you can finally define a strategy about your account structure and going back to our jungle let's make it easy let's divide our jungle into three areas so maybe on on the top left you see some trees let's make it super easy and call that the tree area and then on the right we have some bushes and plants let's call it the perennial area and then on the bottom we have weeds and small plants let's make it easy and call it a small plants area so now stranded in our jungle we finally kind of know maybe where we are looking around but we still don't know okay which of these small plants can I eat or which trees can I use to buy to buy to build a house and so we need to go one level deeper and make a bit more sense and get a few more details in our jungle and that's where we have to talk about tagging so what is tagging tagging is essential to optimize costs and you do that by assigning useful information to any resource of an account or to an account itself and this information consists of a key and a value and this provides an extra layer of granularity for the cost allocation and in this whole tagging process of course you need to involve all the different stakeholders like we said a thousand times before and your tagging strategy need to be aligned with your company and if you look at our example here you can see that we added another layer we added the resources and if you question yourself okay when do I need to tag and when do I need to create an extra account for resources you can see that we have on the right side of our example we have the database a and the database b and here we have the tag owner and if you think about it you wouldn't create extra accounts for all the different owners that exist because then you would have a lot of different accounts and it would be just too much or if you just look at pot a and pot b here we have the tag team so we have a front end and a back end team and you wouldn't tag these services either you wouldn't create an extra account for these services either you would just tag them because in the end you would just know which team is producing which costs of an account and if we map that back to our jungle we can see now that we added some tags here we have the tag tree for example and with the value rubber tree we have the tag perennial with the value banana and we have the usage tag so we can see now that we can but that we can have some trees for manufacturing we have trees for food and we have some plans for medicine so we know a lot now about our jungle but there are still some resources that are hard to allocate or that we cannot tag here in our example would be something like the sun or the water because we know that all of our plants use water but we don't know how much and we need to allocate this to get a full picture of our jungle and it's the same in the cloud we have here untaggable resources at all we have two different kinds we have the shared costs these are shared by different teams and used by different teams for example network charges support charges or shared storage then we have public cloud resources that are not taggable at all these are most of the time special services like the AW app mesh there are three different split cost models which help us to allocate these shared costs first of all we have the even split here the shared costs are distributed evenly among the different business units next we have the proportional split here it depends on the raw spend of the business unit so if business unit A has the most raw spend they will pay the most of the shared costs and we have the fixed split this is a fixed percentage and it's determined by the evaluated past spent and we go back to our jungle now and we have here the percentage share of the water consumption so we added 20 percent to the small plants area because there are a lot of weeds and they don't need that much of water and for the other two parts we added 40 percent so we know a lot of our jungle now looks pretty good right and I think we can survive now and we can live in our jungle but we want to evolve with our jungle we want to know when is the next time we can harvest our plants or how do our grand plants grow and how is our jungle and we want to live in it and for that we need monitoring and it's the same with the cloud we need cloud monitoring cloud monitoring assesses the elements of the cloud for example health checks and it's not enough to just look at the total costs of the cloud because it's not specific enough and you don't know where to optimising our cloud and the account structure and the tagging helps us to know where the costs come from but there are still a lot of parameters we can monitor and to know which are the right ones for us we need individual FinOps KPIs aligned with the companies and the different stakeholders in our example here you can see a Grafana dashboard and for this company they have KPIs like the CPU cost the memory cost the utilization the requests so a lot of different things and not just the total costs and you may ask now okay but why do I need a third-party tool why can I just use my existing cost monitoring tool from AWS Azure or GCP there are two answers so on the one hand if you use more than one cloud and you can see with a third-party tool you can see all the data from all your different cloud providers in one dashboard together and on the other hand if you just use one cloud provider third-party tool is still good because it helps you with a KPI definition and it provides special stakeholder views for you we brought some monitoring KPIs with us so these are more technical KPIs but these are also an insight for the other departments so first of all we have the average price of compute for our power you want to decrease that number over time and you can do that through right sizing and reservations Vanessa will talk about that in a few slides we have the count of anomalies anomalies are something like a spike in your costs and here it's about the consistent identification of the anomalies and the time it takes to address them we have the percentage of the tax resources and of the untact resources and we have the percentage of idle resources and here listen carefully here you can achieve the biggest cost savings just by shutting down idle resources so it's not that hard just shut down what you don't need and in our jungle scenario we have now a beautiful dashboard so we have the growth rate we have the count of ripe bananas and we have the weeds coverage and in our case these are the right KPIs for us because we want to survive in the jungle so these are right maybe a biologist would have different KPIs regarding the animals that live in the jungle or other ones but for us these are the right ones and we can survive and live in our jungle so in a nutshell collaboration is key and one of the first steps of phenox so you really need the involvement and maybe even a buy-in from people of finance of IT teams of business maybe your C-level people and you need to create a strategy for all of the topics we mentioned before you start your journey speaking of accounts and tagging it's great if you already have that strategy or if you've created it but you need to implement it consistently because it doesn't make a lot of sense as you might know if you apply it just once and then forget about it it's not of great use to you same for tagging and regarding the untaggable costs it really pays off if you revisit the untaggable costs from time to time so it's awesome if you've decided for one of the cost models maybe explained before but from time to time the cloud providers have of course features they're working on their products and so it might make sense to revisit those untaggable costs because some of them might not be untaggable anymore for example Vivi mentioned the AWS app mesh might be in the future that it's somehow a taggable fourth point is monitoring we now okay all of us all of us that work somehow in IT so I guess all of us are already doing monitoring on a performance level but we also need that finance monitoring we engineers are now responsible also for costs but at the same time we need to enable the finance people and the business people to work with us to get their buy-in and their understanding of how the cloud works and what they need to consider when they define their user stories or plan the budget so we've talked a lot about transparency and we survived in our general because it's transparent and yeah achieving transparency or those concepts that we have we've explained those are not rocket science at all but from our experience most companies most people struggle with these topics because usually they work in there just within their teams for example they've great tagging but just in their project in their isolated world here again you really need to involve the whole company because phenops is all about change about a cultural mindset okay so we've achieved transparency now we can finally start optimizing paying and using less for our cloud resources so the way forward you see that's us the green people there with the lantern transparency we can now finally start for example with processes there are a few strategies with the cloud where it can save a lot of money for example by committing to instance types or instance families it's called commitment based discounts you can save up to 60% but it pays of course off if you before that know which machine types you really need you could also work on implementing phenops in the agile culture or in the agile framework of your company maybe you're already working in sprints and with user stories and you might know the definition of done and so you could add thinking of phenops so you could add in the definition of done one sentence about you're having the costs in mind or making that even a bit stricter after or in parallel to the to the process dimension you can now really start optimizing and lowering the costs usually when companies start out with phenops they have about 30% of well waste so you can reduce 30% of your costs as soon as you know where to look as soon as you have to transparency optimizing means on the one side shutting down idle resources of course shut down what you don't need on the other hand it could mean yeah right sizing so choosing the right instance size for your workload typically it's the lazy way to just use an over provision and just use a larger instance and with right sizing you reduce that size you take a look at your monitoring and see okay just 5% of the CPU of that machine is being used I can definitely make that a bit smaller and the third point that we've mentioned here is out of scaling so scaling is really one of the benefits of the cloud but a lot of people don't use the out of scaling functionality at all and so that's really something you could look into and then at the end of the road there is redesigning your applications so they are architectural patterns like for example containers or server less that might reduce your costs even further but I would say that's really a topic you shouldn't look into right away except if it's a greenfield project of course because coming back to a not greenfield project because typically it's a lot of it takes a bit of effort or a lot of effort to redesign the applications so that's something you can then tackle as soon as you you've already reduced the cost and I know that whole jungle metaphor we are talking about it's super cheesy I think it's a great way that you can remember what we were talked about today the bottom line FinOps as it is in the jungle FinOps is a continuously evolving system FinOps is all about accountability it's all about the engineers that spin up the resources they need to be accountable we need to be accountable for the costs we incur when we deploy a resource but at the same time FinOps is about enabling other people and about the mindset change in the company because it doesn't work like in the ancient times with the on-prem times that old process that's outdated so we don't we need to look not only at us as engineers and think of costs but we also have the more or less duty to enable the other departments and explain the finance people why the cloud incurs variable costs why it's not about capital expenditure anymore so FinOps really is about yeah a community of people and cultural mindset change for your whole company and there is nothing more left to say than go out there be your own jungle guide and guide others in your company or at home thank you