Episode Transcript
[00:00:00] Speaker A: What do you think are the skills that make a Finos practitioner become like an expert, a differentiator in the FinOS practice that anyone can have in their company.
[00:00:10] Speaker B: What is funny is that as practitioners ourselves, we do go through the FinOps maturity cycle as well through Walk, Crawl and Run. I found that in my own experience, the things that I cared about several years ago are now different today.
And I have been interviewing a lot of finops practitioner for a role that we had open in my company. And I found that some of them had basic FINOP skills and they were not very deep as far as field experience goes.
So the skills that are important, I think obviously you want to have your practitioner certification if you really want to be a serious about it, but you need to couple that with skills and those skills take the shape of a number of skills, presentation skills. Why? Because we need to present to executives, we need to present to business unit managers and business architects to action on recommendations.
That means, you know, PowerPoint skills. You need to have analytical skills, which means Excel or some type of bi, like tableau or, or Power BI dashboards, and you need to go deep on optimization opportunities.
So when I hear people just mention only right sizing, for instance, and rate optimization, and that is all they offer as far as recommendations in an interview, that tells me that their skills are very, very basic.
And so you need to go beyond the practitioner certification and that could take the shape of many different forms.
I'll pause for any questions you have here. Yeah, and we could dive deeper.
[00:02:16] Speaker A: Okay, sure.
So, yeah, I think that's very interesting. And of course you have different paths. As we know in phenoms, there is different Personas and different pathways that you can follow.
So if we are starting from this point of view, where you have all the basic finops knowledge, where you have all these soft skills, what do you think is the biggest gap that people have right now between being a finops practitioner and then becoming the expert in terms of development or skills? What do you think people are lucky enough maybe in the Personas, what FinOps engineers are lacking of and what FinOps management can be lacking of and product maybe are the three Personas and of course finance. Yeah, these three, four Personas. What do you think are the missing pieces in each of them?
[00:03:08] Speaker B: I think the biggest missing piece is that you need to talk to the various groups in the language they understand and the things they care about. So a finops practitioner needs to be broad, needs to have technical skills, to talk to engineers and architects, needs to have business skills to talk to business and product managers as well as executives. So what shape does that take in? You need to think about what they care about and present things in the language that they care about.
So, for example, we had recommendations for retention policies on S3 buckets to save the company a lot of money. But there was this one team that wasn't really actioning on it. And when we inquired about it, they said they were fearful of audits. They were afraid that they're going to get audited and they were keeping everything forever.
Even though things were eight or nine years old in that bucket and the likelihood of ever accessing again is probably zero, they wanted to keep it for fear of an audit.
So what was interesting is they didn't care about the cost efficiency about it. Their concern was about compliance. So I reached out to the compliance team and I found out that the compliance rules in our company is to keep things no longer than five years.
After five years, if there isn't a legal hold or some other compliance reason to keep it, you must delete it. It was unequivocal, doesn't have value, not subject to compliance, you have to delete it.
So therefore, in the next cadence, I went to that team and I just explained to them the, what compliance said and that actually broke the logjam to start creating retention policies for those S3 buckets. And even though they initially selected five years because that's what the compliance framework now a policy, now you can work on efficiency over time. The conversation then changes. You have a policy already. The conversation changes now to what is the value of that data? Do you really need it more than 2 years? Do you need it more than 3 years? And adjust the retention policy as appropriate.
So that was very interesting because that was the language and the motivation that they needed to start implementing a policy. It was had nothing to do with finops or cost efficiency.
You will be successful if you understand what the motivation of the various Personas that we relate to are involved and try to address it.
[00:06:03] Speaker A: Yeah, that's. That's totally correct. And, and you know, understanding the. I think everything as you said, is regarding understanding people and being able to know like what's driving them. If it's security, is it compliance, it is business returns, is it performance, is it reliability? You need to.
What the team involves is their driveway and then solve it around that topic so that you can be sure that that motivation is fulfilled and then you can apply the phenoms to that practice.
But, you know, that's a very good topic because you are saying that something that we could look let's say immature in terms of phenotype which is not controlling anything in S3 and not having any policies and not removing an S3 cost which is something that I have a case study as well on that.
Two having policy doing everything automated considering value. So how do you envision a mature company in terms of finop? So from your I would like to get your personal experience and not something that is more standardized. So what do you see a mature finops company doing in a day to day basis?
[00:07:23] Speaker B: Okay, that's. I'm glad you brought that up.
So I have my own criteria personally.
So one factor right in the beginning is are you doing showback or chargeback? Right. There's really no reason to do anything other than chargeback. But that tells me your maturity level because showback is like here's the bill and you don't really have accountability.
You're only going to get accountability now. It will drive action. Visibility to the bill and showing back will definitely drive action when you are in crawl or early stages of walk.
But if you really want to get to run and maturity you need to charge back. Why? Because it holds people accountable. And if you hold people accountable it will drive action.
Which means it'll drive efficiency, it'll drive waste reduction.
They are now responsible for their spend where before it was just an open book.
That's one criteria around around it. Automation is another one. Right? Putting processes on automation. If you are reducing waste manually and not fixing the underlying issues that cause the waste to begin with, well it's good for job security because you're going to be doing that forever. You're going to clean up a bunch of waste this year and next year you're going to have all the same unattached volumes and age snapshots that you had this year.
So the lesson to be learned there is why did it get there?
Well, in our company we had a data lifecycle management for snapshots but something broke and then it was the age snapshots were not being deleted and one of our CCOE architects noticed this. So that gave us the opportunity to fix what was broken in that mechanism.
So you need mechanism and automation to fix things and you need to check it because it could break. Your automation could break. You could come back and check it.
Also I distinguish a high walk versus a true run if they do proactive preventative governance instead of identification and remediation. So what can. What does that look like? There's a lot of governance tools today that Are they consider themselves automated finops governance.
But if you're not preventing a cost inefficient architecture from deploying on a git pull, you're back to the same problem as before. You're just going to have recurring inefficiencies.
So there are a lot of interesting tools right now that will prevent on a git pull or a deployment and say okay, you're inefficient, here's why and here's the dollar cost of your inefficiency.
So you could start out with soft enforcement, which is not and allow the deployment to go through.
Better yet is when you raise your maturity level, notify, stop and then suggest this is how you fix this inefficiency or ask for a justification from management to proceed as is with the inefficiency. But now at least you're making a smart database decision or practicing informed ignoring. Yeah, we know that this is not efficient, but our initiative is important. We're going to deploy these GP2 disks instead of GP3 etc.
Those two things will allow me allow to understand whether a company is mature or not. There are other things too.
[00:11:20] Speaker A: So but what I am getting the feeling of, and maybe you can dive deeper into this, is that you focus the maturity mostly on having a proactive approach so that things happen without the need of someone taking a look at that. Rather than a reactive approach, can you dive deep more on why proactiveness in finops is important?
[00:11:47] Speaker B: Yes, because you need to be purposeful and intentional of the things that you do in the cloud instead of haphazard.
Also, if you are well architected, you need to consider cost in your design along with security, reliability and performance.
It is a pillar. And if you are not considering cost in your decisions, then quite frankly you're not really well architected. And then all the efficient inefficiencies crawl in behind it.
Can you repeat the question?
[00:12:22] Speaker A: My question is that why do you think proactiveness is such that of importance instead of changing from a proactive perspective to a reactive perspective in finops? So as you said, automation is important, prevention is important, check back is important. All of this is more proactiveness. So where do you see the value to the business in taking this proactive approach?
[00:12:48] Speaker B: Because if you allow inefficiencies to creep in from the minute that your deployment is run, you're wastefully spending money and it could be weeks, months or years depending on your maturity level more than you uncover it. And then this is all this money spent that you're not going to be able to recover.
Additionally, it keeps you from doing more high value finops things like unit economics. If you're chasing waste and idle resources and cost efficient inefficiency in perpetuity, you're not free to do the higher tasks that brings you into a run maturity. You're not doing unit economics, you're not doing insightful reporting, you're not doing KPIs, you're just chasing waste and idle resources forever.
Again, it's great for job security.
It's really not the job of finops.
[00:13:40] Speaker A: Yeah, that's definitely true. And I think it relates a lot with what's happening in business that you can, you know, always start remediating things manually and start fixing things manually. But once you take a proactive approach and you leave that let's say low level work to an automation phase and then you can do high level work, as you mentioned, with business value. In your experience, how do you cultivate this, the purpose and the intent across a company and what have been the initiatives that you have seen that they are the most successful.
Working on this topic, you need to.
[00:14:20] Speaker B: Have skills, enablement and education.
And so in my current company when I first joined, it was a mature, immature practice.
What do I mean by that? Nobody was certified finops practitioner certified. They were doing very basic things around rate optimization and a little bit of right sizing and waste reduction. Right. They were buying our eyes savings plan, a little bit of idle resources and that is it.
And my team is in the ccoe. We're a subset of the CCOE and there are architects that are assigned to every business unit in the company and every team in the company.
Now some of these architects was FinOps friendly or FinOps champions, others not so much.
So initially we got many of the architects to action on the recommendations, work with the business teams to action on it.
But a couple of the architects were responsible for some of the biggest business units or a large portion of the bill and they were not actioning on the recommendations. So I'm always a curious person. So my curiosity is why is this going on?
And it was going on because they were busy with other priorities. They didn't understand what the ask was or the mission or the purpose of why we're trying to do what we need to do. So what I did is as a FinOp certified instructor, I put together my own training sessions. I did five one hour sessions on Fridays. At first I invited all the CCOE architects and probably three quarters of them joined the team.
The series of education and what was interesting is two of them which were not very finops enablers, became enablers through the training series once they understood what FinOps is trying to do and that cost as a design pillar and that we're looking at inefficiencies of workloads. Engineers care about inefficiencies.
It doesn't matter what kind of inefficiency it is, performance, reliability or cost, they care about inefficiencies. If something is inefficient and you approach it in that manner, then engineers will action. So as a result of my training series, a number of these engineers that were resistors now became enablers of finops, including one of the largest business units that had a lot of waste.
So that got took care of there.
Then I expanded that training to the business unit architects. Those are the architects in the teams that are actually responsible for it. And my intention is to adapt my training series for leadership and management.
And why do I say adapted? I don't want to talk about engineering specific issues in this training because leaders are really not going to be interested in the minutiae of the technical details. They're going to care about the business details of it. So I'm going to adapt the training series for the level of my audience, which is the executive, so that they understand what finops properly is. Once you do that, you get greater buy in and alignment and cultural adoption, you really, it's really a mindset. It's. It is about culture, it is about adoption, it is about a mindset on what it really is. There's a lot of myths in FinOps.
[00:18:13] Speaker A: Yeah, that's true. I think the awareness exercise that FinOps can do and you know, driving an initiative upwards and if you are, I think, if you are in, I think it works for every initiative but if you are enthusiastic to it and you can push it and you have especially like, it's always helpful that you have a manager that can help you drive it upwards and try to have a culture and you enable people and you start distributing things.
And of course if you have training preparation for doing that, it makes it great. But you can distribute and you can affect a lot more people. And I think we always focus of what we can do but we don't think about, okay, what if I spread this message across more people and then we together can do the same thing and they can help me drive this thing across the org. So I think that expansion movement is not something that is well mentioned in general and I think definitely the awareness exercise, a bit of the marketing exercise of phenops is like, okay, this is why it's useful, this is why will help you.
That's an exercise. And definitely it's because it's so clear the business value that you drive, like if you are a fino, you know, the business value that it drives that is very easy, let's say to sell it very easy to for each person. You just need to adapt the, as you mentioned, the context to it. And you need, you need to know what they are driving it so that you have it in their team. Like finance will have one driver, engineer will have one driver and leadership will have a different driver. But you need to understand it so that the, let's say the discourse of the pitch is different because they have different drivers, as you mentioned.
[00:19:58] Speaker B: Right.
Part of cultural adoption is you need to bring other teams along and there's things that they care about, as you just mentioned, as well as myths about finops that you have to dispel. So on the first part is at my company we had an expense management team which is basically finance. So I did. And they care about the forecast and the budget and they had their own cadences with the same teams that we had cadences. Now what they cared about was just actual spend on a monthly basis to budget and on an annual basis, year to date to budget.
And so I did approach for greater alignment and as a way to extend my FinOps team with finance.
And you know, I offered them the training series that I put together on what finops is. The first comment which was interesting was, well, we've been doing financial operations since the 1980s. And I'm like, yes, I know that FinOps is a portmanteau for financial operations, but Cloud FinOps is not the same thing as the term financial operations from 1984. In fact, the cloud didn't exist in 1984.
So that was one of the first myths that I needed to address and talk about. But when we engaged with the finance team, who holds the budget and they held it not only for cloud, but for on premises and labor and other things, it is an extension of the team.
We are talking about cloud spend essentially, right. And forecasting as well as actual spend to budget and whether you're over or under.
The other team that I sought alignment with was procurement.
And the reason is we do about a third of our bill in the marketplace and there are negotiation to be had. And these people are very specifically skilled at negotiating in contracts.
And I have always been on Lean FinOps teams.
So. And I'm not a legal person. I don't generally sign contracts.
So I sought alignment with our procurement team and gave them guidance on how to get access to our console and show them how to go to the marketplace and look at all the private offers. So what was the result of that?
One, we procured some software as a service where they negotiated a better deal for us and B, they could save time for me from walking through our internal processes to procure these third party software because we had processes to vet third parties. So it was an extension of my team.
So why wouldn't I align with procurement, why wouldn't align with finance? They're helping with this towards the same goal but from different perspectives. That's true, I think. Myths. Yeah, yeah, go ahead.
[00:23:10] Speaker A: No, no, no. My, my, my, my comment was more on the, on the procurement side, especially with the increasing usage of third party tools both for phenom, security, observability, everything.
[00:23:22] Speaker B: Yeah, security too.
[00:23:24] Speaker A: Yeah. All the role that, that you have and all the tools that you can have is them controlling it. And if you want your finops, let's say team to have some allies that can work on that specific thing that they are very skilled into, which is negotiating, having all the contracts, having everything you need to align with them.
[00:23:44] Speaker B: Right, right. You know what's interesting is I also align with security for a number of different reasons. But I think the thing that started it is our cloudtrail bill was pretty high, which is funny because cloudtrail is free for your first trail in every region, in every account.
So why is our cloudtrail bill high?
Well, it was high for a number of reasons. One, individual teams created their own cloudtrails and okay, I said, well, this is kind of wasteful.
So we also turned on data event recording and the bill skyrocketed.
So actually it was at the same time the security person reached out to me and we started discussing do we really need all these cloud trails? First of all, we have like two cloud trails company wide that are like organizational cloud trails. So why not just have one?
Do we really need the data from data event recording? Because it's very expensive. And what about all these teams that have their own cloud trail? Do they really need a cloud trail? Can we service their needs to look at a trail from our organizational trail?
So we were probably, we were able to reduce it by about 70% and perfection and my attention deficit disorder would want to have it bring it down to zero because it's a free service for your first trail and your first organization. But I'll take the win if we reduce it by 70%, then there are myths too that we could talk about, particularly two that I like to talk about.
[00:25:31] Speaker A: Okay, go ahead.
[00:25:32] Speaker B: You know what that.
Well, one is around right sizing and one is around tagging. And I have a very contrarian point of view about both.
So back in 2019, Corey Quinn from the Duckbuilding Group wrote a blog post which entitled right sizing, your EC2 instance is nonsense.
Now I probably agree, I don't agree with everything. I agree with mostly 90% or most of the view, which is a very wide, broad initiative to right sizing is nonsense. Why is it nonsense?
Because I've seen thousands of recommendations from numerous tools about right sizing this or that. And if you start vetting those recommendations, 80, 90% of them are not good recommendations. They don't take into account seasonality on a seasonal business or end of month or end of quarter.
Teams made a conscious decision to be a little bit over provisioned for peaks and they will refuse to act on it because it is more important to be able to service a request during a peak than to save $10 a month on an EC2 instance.
So I believe in targeted right sizing.
What do I mean by that? But before I get to right sizing, actually I like to do two other things.
Are they running on the right architecture and are they writing on the right instance family?
So we had an OpenSearch cluster. As you know, OpenSearch is mostly memory intensive, but it could be CPU intensive. You have to look into it, but it's mostly memory intensive.
This one cluster was running 11m instances, which M for AWS is a balanced instance type.
And I started scratching my head, why are we running M? I mean should be Rs, right?
Because it's memory intensive.
So an R has twice as much memory roughly than an M.
So Instead of running 11 EMs, they could run continue to run three M's for their control nodes and the other eight data nodes. If they switch to R, they only need four of them. So even though R is incrementally more expensive than an equivalent M, you're only running four hours instead of eight amps.
Now you throw an RI on top of it and you're very cost efficient. And now we've done nothing about right sizing. We just changed it down. We just switched the family type. That's the first problem. The second problem that I see is can your workload run Graviton?
If it's Linux based, why not? It has a greater performance headroom and it's 10 to 20% cheaper than an equivalent Intel.
So if your workload could run graviton, why wouldn't you do this?
If your workload is Windows based, can you run AMD instead of intel?
So before you ever get to right sizing, you should look at architecture and whether you have the same the right family type.
If you went through that first and you find that now you're running on the right family and architecture and you're grossly over provisioned, well then right size now.
But chances are you're gonna, you know, you're still gonna wade through a thousand recommendations just to right size 50 instances. So is right sizing your instances nonsense? For the most part it is. But there is a place for targeted right sizing for the grossly over provisioned. So when I hear a new practitioner talk about right sizing, right sizing, right sizing, I'm like, they need a little bit more experience.
[00:29:50] Speaker A: Yeah, that's true. I think I can share my view from more of a DevOps side, which is more of engineering side. You know the guys that are making the over provisioning from the background and is that the right sizing of or sometimes I think it gets like family setting correctly is sometimes called right sizing on its own, which is not exactly that, as you mentioned, but definitely if you adapt the image to be the right resource intensive for your application. So for example, Java applications are more memory intensive than Python application, let's call it that way. So you have to choose one node type for Java workloads and you can use a different one for Python nodes because the memory and the CPU will be almost the same.
So it's way different. You can have compute intensive in one and memory intensive in the other, so it really adapts into it.
And also the only thing which I think that is it kind of cannot work directly or completely is that once you do the instance right sizing or the instance change perfectly. On Kubernetes for example, you probably missed out the right sizing. What I mean by that is in Kubernetes specifically you need to put the limits and the resource request.
So if you messed up the resource request, you are basically over provisioning by default. And it's very difficult to do so because it's very difficult to buy. Let's say this happens because engineers such as me do an estimation and say we see it running in our local, we see it more or less in a pocket, we adjust one time and then we forget about it. And we said, I don't know this is going to run at most 1 gigabyte of RAM and 1 CPU and then you check later on and the request that you put is like 90% over and even with increase of workload the horizontal scaling would have solved that.
So you are probably running like especially for a steady so for non very high demand workloads. The provisioning in kubernetes like adjusting their request specifically the limits have differently because you can avoid some type of limits Adjusting the request is a very intense topic that in right sizing specifically. That's why I think a lot of kubernetes tools for right sizing work better than a normal EC2 instances because you need it constantly to do it because everyone is doing probably request the runtime. So that's my take on the request and the right sizing. I don't know if you have experience on the kubernetes topic.
[00:32:48] Speaker B: Not in kubernetes but every anecdotal evidence that when you go to a newer engine I think it was around maybe documentdb or Mongo or you go to a new Python library you can get efficiencies there that will translate to not needing as many computer memory resources as before which then gives you an opportunity to truly right size down. And other things too is new sizing or new gen sizing. I'm not sure I want to coin a term for if you're running a generation 4 or 5 you might be able to run a 6 or 7 like an M4 6 or an M7 and there's incremental savings and incremental performance increases for the same size you're just going to a new generation.
That will help a lot too. Besides what you just mentioned about tweaking the application, there's a lot of things you could do.
How you index a database, whether it's Dynamo or you know, open search can have impact on before you even get to right sizing. And then eventually if you should do all these steps first and then use data driven decisions like cloud watch or your profile and your workload after you re architect it, after you've gone to a new generation after you selected the right instance type family.
Now after done doing all that then you should look at whether you're over provisioned or not. First of all you already saved a lot of money from going to new generations.
And then if there's room for right sizing and the risk is low and the effort is low, then by all means so is right sizing nonsense.
Broadly it is, but I think there's targeted Room for right sizing under what we just discussed.
The other myth I see, which is contrarian, is around tagging.
[00:34:55] Speaker A: Okay, what are your thoughts on tagging?
[00:34:59] Speaker B: There are a couple better ways of tagging. One which completely you don't even need to do tagging at all.
So when I was a TAM at aws, we had a client. It's a very public case study. You could search it on the AWS cloud financial management blogs where they adopted what's called a micro account strategy.
In a micro account strategy, they determine how granular they needed to charge back to. Whether it's on a team or an application level, or even a microservices level, the granularity that you need to charge back to is where they created a micro account. So this company was much smaller than my current company where I'm at, but they had four or five times the number of accounts. Essentially they mapped an account to a cost center.
So now all the spend in that account is allocated to the chargeback code because they don't have multiple resources that belong to different charge centers. Everything is, it's a one to one mapping to a charge code. It's called a micro account strategy. So if you go to Google aws, CFM blog micro account, you'll hit five or six blog posts about that one company that did that. The beauty of that, it's 100% accurate, right? Because everything in the account gets to the charge code. It's complete.
So you have that. And now the only thing you have to worry about is shared cost allocation of shared services that come from another account.
But when it comes to tagging, not all resources support tags. So.
And it's a moving target with aws, a component of a new service or a new service that they launched that didn't support support tags right.
Now months later they support tags.
But chances are you deployed it already and when it didn't support tags and untagged. So you have to go back and figure it out. It's a moving target of what's tagg versus not taggle. How do you handle non taggable resources?
Right. If you're allocating by tax, right. It's not complete.
If you're not doing automation, you're going to be inefficient. If you're not tagging something at launch. Creation, creation of that resource, you're relying on people's good faith to go back and tag it properly.
What about resources that don't support on creation? There are a number of resources that will not support in creation now you need a piece of automation once it's up and running to go back and tag it again. You need automation. You can't do this manually.
What about tag drift?
What about things move to a workload or business unit moves to another team or it moves, it needs to be on a different charge code.
How do you update that?
So tagging is another one of those criteria where if a company is overly concerned with it and they should be concerned about it, tells me that they're not necessarily a run maturity.
Because you would have dealt with the automation already, you would have dealt with a number of things.
There is another alternative, very interesting that I saw is this company would not allow you to deploy anything into the cloud unless you register the application or workload in their cmdb.
And their CMDB would generate a guaranteed to be unique synthetic id.
And that synthetic ID in the CMD will map to the cost center, to the environment, to the business team, to the unit. If any of the metadata needs to be changed, they change it in the cmdb. So that's now their single source of truth is a cmdb. So the only thing they needed to tag and they, they put it into their deployment is it needs to have a synthetic ID and made an API call back to the CMDB to see if it's a valid synthetic ID or not.
If it didn't have the synthetic id, the git pull or the deployment will fail. If it didn't have a valid synthetic id, it will fail.
So now the only tag you need to concern yourself about is the synthetic id. I prefer a micro account strategy if your use case fits it. If you can map everything to a single account, you're out of the tagging business.
[00:39:55] Speaker A: I think I can share on that.
Not sure how much, but definitely probably the combination of both. So having a CMDB that can help you generate those micro accounts and have a link between those it's probably or it's a way that I have seen works perfectly. So you have a central place where you generate all these micro accounts. The accounts or my perspective needs to be on project project environment level. That's the approach that I've seen working the best is like you have, let's say you have an application a and then you have application a dev dev environment and application a prod environment. So each of them need to be a separate account because you need the separation so that if dev needs to go down, you just kill the project. Everything goes down, that's it. And you don't need dev anymore and you need to proto same if you have an. Especially if you have a staging environment. A staging environment sometimes are even not needed after a long time if you don't want to. And depending on the scope of the project, you can have it at the beginning for a poc, whatever, but then you can remove it. So as you mentioned, linking the project to a micro like to the environment like having a defining an account or a project in GCP defined to the project environment level. I think it's one of the best approach. You probably remove most of the tagging. I still advise to have some tagging on specifically certain things. If you are doing with microservices and things like that, you probably need some tagging on the low level. But what you said, combining CMDBs with micro accounts, you probably can remove even the synthetic ID because they will be probably linked directly in the CMDB like entry and that's it.
And you can from that cmdb you can manage everything from there because everything is, you know, compressed into an account. So you can like this account is this.
It doesn't have anything else but just the dev environment of this project. And this project is assigned to this team and this team belongs to this business unit. So you have everything. You have the cost center, you have the input of cost. That's it.
I share with you that that's a very good approach.
[00:42:14] Speaker B: It depends on the use case. Right. And the culture of the company and how they manage their business.
But a shoehorning, a tags tagging solution is the only solution.
You're not really considering that there are other alternatives that might be better for you. And I agree tagging is necessary for operational. Maybe it's for automation.
So you can opt in or opt out from let's say a backup or, or snapshot or whatever. Tagging is still very important for that I'm limiting my conversation to tagging for cost allocation or finops.
And I've seen weird tagging things where they don't have they have more than one tag for chargeback or cost allocation.
I mean like why it should just be one to one.
So you're. They're doing it this. If it has this tag, it gets charged back to this code. If it doesn't have this tag then it needs to have this other tag which then gets charged back to the same code. And if it's neither, it's gets charged by the linked account.
At that point why not just do a micro account strategy for doing it by linked account?
But you have to automate, you have to automate at launch creation and those resources that do not support being tagged at creation immediately after with a lambda function or an Azure function or whatever you need to do to tag it. Because you're generating cost on many of AWS services on a per second basis. So if you want to complete, you need to automate, you need to get the humans out of the process. Why do we have so much different tags? Also we have production, all uppercase production, lowercase production, camel case.
We have that because we have humans doing it instead of piece of automation. Where we define our standard is everything is lowercase. And now you don't have mixed case or uppercase. You just have the one key value name and they're the key value the same. You know the right case.
If you don't do it by automation, then you could fat finger it and have a typo or wrong case.
Automated.
I mean it's there. I mean all the tools are there already.
It's like we're in 2025. Why do we still talk about tagging problems? That's like 2015 in my mind, that's for sure.
[00:45:09] Speaker A: But I think it's a debate topic and it's very interesting.
As you know, we have the course and tagging dynamic conventions. We try to help people put the right scope into tagging and try to help them do in the right approach using micro accounts, using naming conventions as a support of tagging. Because it's also a very resourceful tool and putting the right side, you don't have to tag everything, all the values, everything you need to tag just right. So that is sustainable and of course, as you said, automation probably. There are few things that leverage automation as well as tagging. Like I don't think it makes a difference in most things than in tagging. So thanks a lot for today's conversation. Rick, it's been a pleasure to have you today. I think there is a lot of insight in this conversation. We'll leave all the reference to you and to everyone in the description and it's been a pleasure. I hope you had a great time.
[00:46:12] Speaker B: Pleasure is mine and thank you for the opportunity to share with the FinOps community.
[00:46:18] Speaker A: Yeah, pleasure. Pleasure to talk with you and see you in the next episode. Bye bye.
[00:46:23] Speaker B: Okay, take care.
Ra.
