[Webinar] The True Cost of Moving Fast & Breaking Things

You can also view the full presentation deck here.

 

[Transcript]

0:05
okay let’s get started so before I clear the stage for our amazing speakers
0:13
the co-founding CEO of Finn out and commodore
0:19
um he’s a devops team lead uh both have loads of experience with
0:27
infrastructure cost optimization reduction and this is what we’re going to talk about today so uh in the world
0:37
of cloud cost comes in different forms some of it is direct cars that you
0:44
pay for usage for uh Cloud span for different tools and some of the cost is
0:52
indirect you will occur technical debt you lose velocity and
1:01
um many other things that need will dive into and then we will take over and talk
1:08
more about cost optimization go on fennel’s perspective so uh without
1:15
further Ado let’s get started so let me hand over the mic to Neil Benatar and if
1:22
they get away and uh let’s get started thank you I’m just gonna get started with the
1:28
presentation hi guys uh can you guys uh hear me well ODI can
1:35
you say can you nod amazing so hi very nice to meet you all
1:41
uh my name is Neil I’m in Commodore for almost a year and I’m gonna start
1:46
speaking this whole webinar in rhymes actually not um I’m a devops team lead
1:51
in Commodore I also do uh part of a back-end Team Management
1:57
um boy is here with me as a CEO for fin out um and we’ll just get started with uh
2:04
why it takes why accuring uh uh technical debt is
2:09
actually a real deal and something that we must handle um so the first slide is is the Mark
2:15
Zuckerberg saying move fast and break things uh and and this is this was the good advice this was like the best best
2:21
practice for for us startups as we started uh to go fast deliver features
2:27
uh break things it’s fine fix it uh growth usage adoption scale
2:33
but then but then uh actually when you run fast actually it has a price uh you
2:39
have to think about reliability and cost optimization and think about uptime and quality and all that kind of all that
2:45
kind of stuff uh and this is something that you really need to take uh put in
2:50
effort to understanding what happens when you run fast uh so before we start I’m just going to talk a little bit
2:56
about uh psychology psychology lesson about uh a paradox called the region of
3:02
beta Paradox what essentially it means that people generally can sometimes be
3:07
better off in a really bad situation rather than being in like a mediocre one
3:13
um so a good example for this is like when you’re in a relationship and it’s like okay it’s not that good you’re not
3:18
very happy but you’re not very bad uh and then you just stick it you stick into it and you’re like in your
3:24
relationship and you come take take it take it slowly uh but then if you’re in a really bad relationship
3:30
and he kept on fighting and everything was really bad you’d probably think about breaking this relationship up and
3:36
finding off hopefully a better partner and stuff like that um I think for this uh webinar when we
3:42
talk about uh out running your ability to do something this could be a good a good time to actually think about the
3:49
things that you’re experiencing right now in your organization and to actually motivate you into doing something about
3:55
it so what is what are the signs that you run too fast
4:00
um I think I listed down several uh ones these are really just symptoms uh and
4:05
I’m gonna go through them uh one by one um
4:11
there are other symptoms um obviously when you run too fast I’m just going to focus on these uh the
4:17
first one is when your Dev velocity uh has really slowed down so your double
4:22
velocity then is is larger than the velocity net uh on
4:28
was faster than it is right now um why does it happen or why why is this
4:33
happening when you run fast um so if we’ve all been in in a Greenfield project and we started and it
4:39
was great and we didn’t have anything to think about and we didn’t have clients and we could run and test and break
4:46
things and no one really mattered but as soon as you we have bigger clients that are
4:52
needing specific things that are not exactly what we thought this service would do so we we added if and then this
4:58
if just comes and invites Us in the ass again after we uh try to solve a bug and
5:04
then there’s a there’s a P0 severity uh affecting production so you’re developing velocity when you run really
5:10
fast you don’t think about your quality your code become fragile you forget to add tests because you have to run fast
5:16
and then this essentially makes your velocity slower in the long game so this
5:22
is something that you really need to take take uh this is something that happens when you run too fast a second point is when there’s only one
5:29
one developer or engineer which can solve a specific issue so it’s very
5:34
common for startups to have this one engineer that knows how to fix everything uh and it’ll be what we call them in Hebrew we call himaga
5:41
um but it’s just that guy who keeps on fixing everything that’s happening um and when we have this hap when we
5:47
have this happening it’s it’s like a it’s like a double-edged sword right so we want to make sure that he’s fixing
5:52
things uh and he’s uh we get to production fast and we solve the issues
5:58
that are affecting our business really fast but then everything uh when he’s the only one doing it uh it’s a single
6:05
point of failure so he can leave or he can be sick or he can be on holiday uh
6:10
and this can some this really affect our business uh and also obviously this means that other Engineers are not
6:17
actually interacting with our code uh uh the way the way that we all want them to be so we want all the entire R D team to
6:24
be able to solve pretty called bugs the next point is uh the fact that when
6:32
we run fast we really don’t invest in that time it takes us to find root causes for uh really problems that are
6:39
affecting your business so when you run fast you don’t really put in time to add your right your at the right metrics or
6:45
logs or uh APNs or anything which is not delivering features fast you
6:52
really run and deliver the feature even when the quality is you know you want to test it out you a B test you make sure
6:59
that you you it provides the MVP but a lot of the time you forget about what
7:04
happens when uh when the service is down or how do you uh track an issue for a
7:09
specific customer and then when this happens you take a lot of time to find a root cause for production issues well
7:15
and obviously the worst time to handle a production issue is is to add these logs
7:20
or metrics or or whatever is when you’re in production issues well the last sign
7:27
that you ran too fast is that you can’t make sense of what is draining your resources uh so you have your CEO your
7:33
Finance or or anyone coming to you and say hey why what is this spell for data dog what is this bill for AWS and you
7:40
don’t really have the ability to to say okay yeah it’s because we scaled our DB because we have this customer join or
7:47
it’s because we’re trying a POC for a specific customer a lot of the times you just look at the bill just kind of
7:53
increasing and you’re like okay and I don’t really know what this what this is and this is obviously costly uh and
7:59
obviously for all of these things once you actually have to handle them um it takes time it takes it takes uh
8:06
time to understand time to to uh plan and you don’t want to you don’t want to
8:12
do you don’t want to be in any of these situations so how do you really what what do you do in order to run fast I
8:19
believe that you have to I I’m all for running fast but um for running fast with the right gear and for me running
8:25
fast with the right gear meaning that meaning that you have the right kpis to measure and measure them as you run as
8:32
you as you run so a good kpi for us is something that we do in Commodores is
8:38
these four kpis one of them is the percentage of engineering teams uh
8:43
solving critical bugs so how many people are actually solving the problem uh that we look at this kpis uh quarter by
8:49
quarter making sure that the percentage is above a specific threshold um and we adjust it according to the
8:55
right reasons so if we had many people joining the engineering teams or we say okay if we don’t uh we have a threshold
9:02
that we that we look in and this is obviously going to help you make sure that your engineering team is really
9:09
balanced and the they all know how to solve those critical bugs and not just just one developer we we take a lot of
9:17
time investing in measuring our mttr and TTD we use data dog Incident Management for that
9:22
um it’s it’s really means of how long it takes mptr if you guys are not aware of meantime to recover or resolve nttd mean
9:30
time to discover so how long it takes you to understand that you have an issue and how long it actually takes you to
9:35
fix it um so whenever whenever we have an issue and we obviously have issues everyone
9:40
have issues um how long actually takes you to understand that there was an issue do you have the right monitors do you have
9:46
the right tools do you have the right knowledge and then do you have the uh the ability to be agile and push thanks
9:52
to production uh with a short cycle time uh a next kpi is how long it takes you
9:59
to run the board and to activate uh this is something that uh is really important for companies uh in this in this case
10:06
you have to do you have to do uh more with less and you don’t want to invest
10:11
time for a senior developer to onboard a junior developer for a long time so you
10:17
invest in time in uh onboarding plans and tooling and make sure that you have
10:23
all the right services so they can start uh actually providing value to the team and you have to measure this so if this
10:30
if this increases uh over time you wanna you wanna understand that you actually are affecting your ability to run fast
10:37
the last thing is obviously looking at costs uh we use multiple tools uh to look at costs and how we how these
10:44
distribute both for both through Cloud providers but also we have we we really look into everything that the r d
10:51
department is paying for so not just the big AWS or gcp or Azure if you’re using
10:57
it uh some datadog bi platforms that kind of stuff so when you have kpis it’s
11:02
really important to have them because if you catch these things that are drifting
11:07
from your data point you can handle them right at the spot instead of waiting for
11:12
it to grow and to grow into big big debt and then actually having to fix them uh
11:18
retroactively which obviously takes you more and more time um so this is why you should use kpi
11:24
when you run fast thank you for this present for this presentation I’m sorry this is me in the
11:31
Britney Spears and with a title saying oops I that that’s it again thank you
11:36
Woody um I’m just gonna talk about a specific case study because even though we run
11:41
with kpis and kpis are really important for us to pinpoint exactly what happens and to uh
11:48
fix it uh at the time uh we do actually come across issues where we have issues
11:54
in their our ability to run fast so in Commodore we had an r d mttd increasing
12:00
for in the last quarter by 20 and when you do come across and you want to handle a tech debt it’s really important
12:06
to ask why and to try to help us hypothesize together uh onto on exactly what happened is it a lack of knowledge
12:13
by the other developers is it a lack of tooling is it lack of processes and this is kind of this is the kind of stuff
12:19
that’s going to help you to improve and to be able to run fast again for us uh we did encounter an issue where not all
12:27
of our on-call Engineers were trained enough uh so we went on training for the
12:32
on-call engineers and we documented playbooks for all the P Zeros or the highest severity of the issues that
12:39
could happen and make sure that all of them had documented playbooks to do when they arise we also use several tools
12:46
that helped us to democratize knowledge around the specific area um so for for databases we’ve used the
12:53
datadog data database analysis we added uh
12:58
additional tooling which will allow us to pinpoint issues that were uh in the
13:03
root cause so we added specific logs to those specific Services which were actually happening we made sure that we
13:10
all the metrics were on point um and we actually changed the entire
13:15
process of determining who should handle uh which errors so we used to have one on-call engineer which was affecting
13:22
effectively uh the uh say the the point of contact for any uh P0 issue and now
13:29
we have area of responsibilities for specific errors in the system um so this is what you do when you
13:35
actually have a tech debt and you want to handle them do you want you want to ask why and the next thing to do once
13:40
you actually added them is to make sure that you don’t get hit by it again so if you have an issue that was mitigated by
13:47
creating a metric or a log or an issue that you’re currently facing you want to make sure that you want to install a
13:52
process which enforces apms or logs as part of your definition of done for any other delivery
13:58
um so this is what you do when you do actually encounter technical debt uh and which will allow you to stop running as
14:04
fast um what I’m going to do next is I’m going to show you a really really quick scenario for how Commodore can make uh
14:12
uh developer uh actually save time by understanding a root cause of a specific
14:18
issue uh and kubernetes um it’s not going to be too long but I’m gonna run through it really really quickly
14:25
um can you guys see my screen so this is Commodore uh in Commodore
14:31
there’s there is a concept of services uh so this is this is my entire Services
14:37
I can see uh really kubernetes deployments and from my multiple clusters and I can see multiple
14:43
namespaces and such I’m just going to zoom into a specific service where I can I actually have an issue so it’s painted
14:49
as red and it’s unhealthy and it’s unhealthy for a while so what I
14:57
what I’m doing right now as a developer is I’m zooming into and deciding exactly what happened what what started and once
15:04
I do I can see that there was a deploy and then a second deploy and then it really in availability issues which
15:10
started right here uh which is still ongoing so I can look at the availability issue and see that it’s
15:16
going on pretty much daily this is a demo account obviously and I can investigate and understand
15:21
exactly what happened for this scenario I can I can get the logs for this for this and I can understand okay from the
15:27
exact the exact beginning of this availability issue and I can see that there is an error log saying my API rate
15:34
limit is higher than the maximum acceptable size um I can get some pot health and latest
15:39
deploy and all that kind of stuff I do get some information about a latest deploy that happened three minutes before and I saw that right here so when
15:46
I look at this deploy um I can see everything that’s changed in this kubernetes cluster and this is
15:52
really something that Commodore is doing for a developer to give them context of what happened before in kubernetes you
15:57
only know exactly what happened right now and what Commodore is doing which is going to help a developer to understand
16:03
what exactly what he did is actually integrating with his GitHub and seeing all the comments that happen between
16:08
these deploys I see that guy actually deployed a commit uh which actually
16:14
changed the API rate limit from 800 to 2500 and this was not in the actual
16:19
config map sorry this is not in the actual deployment it was actually in the config map and commodore actually understands the relations between uh
16:27
resources in kubernetes which is going to allow me as a developer to actually understand uh exactly the root cause by
16:34
just a couple of clicks instead of actually going to my devops engineer and say hey I don’t know what is this config
16:40
map how is it related to my deployment all that kind of stuff
16:45
um so this is this is pretty much it for the demonstration I’m gonna hand it over
16:50
to Roy uh for uh continuing for fan out
16:56
uh have a good one thank you near so much for uh for
17:02
fascinated talk um I’m happy to continue and give a bit
17:07
more uh a bit more context on more stuff that starts to happen when you run super
17:12
fast and break and break things um so you all know this common scenario
17:19
and I’m gonna share uh you know a short uh short story with you right so we’re starting to migrate to the cloud regardless of our cloud of choice as it
17:26
can be AWS and to be Azure gcp ACI uh oci Alibaba whatever it is
17:32
um and we try to utilize the basic Services right so uh we’re using a bunch of instances we’re using some some
17:38
databases storage so everything’s makes sense and uh you know it’s it’s okay
17:44
um but then we start to run a bit faster right the minister start to be utilizing more and more services and start to buy
17:51
some auxiliary services like snowflake like data log um and use a bit more uh you know weird
17:57
kind of uh or Edge uh edge cases for uh for managed services on NWS this is
18:03
where interest structure is out to get more complicated and our cost structure starts to behave you know a bit a bit
18:10
unpredictable but still still manageable but you know the more we continue to run
18:16
the more services and usage-based price services and software will continue to uh to buy we see that you know different
18:23
departments can buy like different tools to do the same kind of kind of job so you know oftentimes we can see gearbox
18:29
and you Relic and Splunk in the same organizations and uh you know for multiple clouds you multiple everything
18:35
and now uh you know we we start to understand that uh you know there’s a price for running for running that fast
18:42
and uh and breaking stuff and these actual you know dollar sign price
18:48
um so you know we started to spend like tons of hours on Excel sheets starting
18:54
to uh to crunch some numbers and you know connecting the dots between bills from uh from multiple multiple different
18:59
providers uh Finance starts to constantly nag us with you know the implication of uh how much money do we
19:06
spend on building our product and um you know we start to justify every
19:11
invoice that we’re getting from AWS and now is up by five percent again great but is this good is this not good and
19:18
finance demands answer because really they can’t understand anything that that we did and like we start to have tons of
19:26
Cloud waste and uh less latest of Forester uh uh you know a survey I
19:32
mentioned that like 40 of the cloud instances are a level higher than what
19:37
they should do like uh 2x instead of 1x which means that we’re like 40 of our instances are just costing us
19:44
double than what they should have and like the more uh the more of that we were accumulating the more Technologies
19:51
I’ll be using the harder it is to start to right size and it’s very hard to start to create those uh accountabilities within with an
19:57
organization like to make sure that uh devs are actually you know actually care about what they’re uh what they’re doing
20:05
um so stop running or you know it’s uh uh it’s it’s a bit hard for the things
20:12
to say but like we we can start to be more more accountable for uh for what we
20:18
are and there’s a bunch of tips that uh you know uh fanart wants to uh wants to share in order to uh uh to deal better
20:24
with uh uh with with Cloud cost so you can continue to run uh but you can run
20:29
more responsibly uh with uh with your Cloud expenses so uh first tip is about
20:34
observability uh right so uh same as Commodore is helping with that with kubernetes troubleshooting thin out and
20:40
you know its competitors are happening with uh with observability data on terms of of cost management so it’s the first
20:47
thing you need to do really right so excels are amazing and you know it’s kind of probably the best product ever
20:53
built um but excels has has its limitations right so uh it’s very uh very tough to
20:59
maintain and like very uh when it comes to multiple data sources in multiple performance you need to do like a lava
21:06
fork in order to uh to get visibility so you know now you migrated uh from AWS
21:11
Athena to snowflake great so now you have another data source that you need to start to think of how to integrate
21:17
into Excel and steam starts to have start to change anything you know your developers are not changing the uh
21:22
tagging schemes for for a specific service and everything everything is breaking so
21:27
it’s very important to first like find a single source that you can trust and make sure that it’s the downstream
21:34
service for every uh you know every service that they’re using all of the uh all of the cloud providers all of the
21:40
solutions as enriched as possible including kubernetes support including everything that uh you know all
21:45
technologies that you’re using at this as a service um then it’s important to start to create a
21:52
single terminology within within the company so you know every uh every developer when talking about cost
21:58
management really understands like uh what are the basic uh basic paradigms and what are the wasting stuff that uh
22:04
uh that were uh you know working towards uh towards optimizing so uh we can you
22:10
know we can optimize for specific unit economics we can optimize for specific stuff that uh uh uh you know Costa
22:15
custom locations that that we have and as long as we have like a common common Target organization it’s significantly
22:21
easier to uh to run those uh you know discussions um tagging and labeling especially in
22:28
kubernetes like it’s super Dynamic environment is key because like now we we created a new deployment and it’s
22:35
running on on cluster it’s like a half half of all the nodes in the cluster and like no one knows who is responsible for
22:41
it no one knows what it does um and you know when we have hundreds of or thousands of developers trying to
22:47
track use the specific kubernetes deployment and it’s charging us so much money is uh is in a location nightmare
22:53
so four Stacks Force labels uh you know so every resource has a you know a
22:59
specific set of predefined labels that it has to uh uh has to uh to feel in
23:04
order for us to track down on those costs and be able to show back in charge with them um
23:10
and we need you know the uh the ability to start and answer the basics so bills
23:15
can go up bills can go down this can even steady um and if it’s going up like is it good
23:21
or bad right so let’s take a uh Black Friday you know it’s the most common example like everyone Cloud builds uh
23:27
throughout the planet is going up but it usually is a good thing because we’re servicing more customers remaining in
23:32
more Revenue but is it growing at the right amount uh so you know the five percent increase on the cloud expense
23:39
when we have 10 increase on revenue is great but five percent increase when you have only two percent increase in
23:44
Revenue that’s over provisioning so it’s a very thin line of uh of doing that and it’s very important to have to do that
23:50
and we talk about concept implementation a bit a bit later um second tip is cost governance
23:58
um so you can’t let anyone do whatever they want uh you know as giving developers
24:04
the ability to uh uh uh to do you know uh uh to ask what’s any resources that
24:11
they want probably not gonna gonna end up with and when you start to monitor our environment constantly so we need to
24:17
make sure that you know we have our playbooks and we have our guidelines of what’s uh what’s possible and what’s not
24:22
in our environment so uh we we need to track anomalies we need to define the budgets we need to
24:28
forecast on cloud costs in order to be able to uh like match uh naturally what’s happening
24:33
um we need to treat cost as if it’s a first party metric right so uh same as you know kubernetes is crashing I’m
24:39
running to Commodore in order to restore the service but why am I ignoring the cost Spike so right the cost bike is
24:45
really changing our entire financial model of of the company and its close and noticed so we need to treat cost
24:51
packs as if it’s for production production incident and make sure that we never gonna I’m gonna increase budget
24:57
We’re not gonna get a request from Finance in a couple of uh in two months and now we need to like Trace back two
25:04
months of Dev work into what’s uh what actually happened um and it’s very important that this is
25:10
like um implementing fin Ops to act to its fullest to give each uh uh each team
25:16
member in the company the ability to like interact with cost the way that is
25:21
makes sense for them so if they’re uh you know an engineering director they’re a budget owner for for cloud so they
25:28
need to be able to see how much they spend they need to be able to direct their own budgets and be able to
25:33
forecast and be able to act on cost recommendations if it’s financed and interested in our organization you know
25:38
and if it’s the actual developer they can see the cost per their specific service and make sure that you know they’re responsible for that specific
25:43
kubernetes deployment or namespace uh so every single person within the organization need to be aware that what
25:50
is uh what is doing costs money and be able to to consume those cost uh those
25:55
cost metrics um tip number three is cost avoidance so
26:00
you know the best uh best way to not uh not spend money is to just not do it
26:08
um and you know going back to uh to Developers for uh for example you so if you’re gonna give a developer the uh the
26:14
ability to you know uh just run and kept kubernetes uh kubernetes resources
26:19
they’re obviously going to do it right it’s the easiest way to build a service like I don’t care how much CPU you’re
26:24
doing it I don’t catch how much uh how much RAM Duty that is going to request you know infinite kind of kind of resources uh my service is guaranteed to
26:31
run perfect and I don’t care that the company is losing money um like no no developer would not say
26:38
that right um but uh if we’re gonna Force developers to start to think like what
26:43
are the boundaries of your service like what memory do you actually consume what’s your CPU requirements let’s
26:48
optimize your service even before it’s got into production and use resources and requests and limits uh that way we
26:54
can start to uh really uh create custody is like very contained and very very
27:00
limited same with uh with horizontal uh horizontal scaling both on parts and
27:05
cluster levels so don’t over provision your pod just in case you will need them at some point and don’t request like
27:10
infinite number of replicas just because you may need it scale when uh you know when it’s uh when it makes sense both on
27:16
multiple pods and on multiple nodes within within the cluster and really manage kubernetes cost it’s like often
27:22
overlooked but uh companies are spending money per instance for the cloud provider but actually running pods and
27:29
pods and instances are just not the same um and we need someone to make that translation for you so manage kubernetes
27:36
cost is like super important uh bonus tips which is a bunch of uh you
27:41
know unrelated stuff that you wanted to share with you guys um so get Engineers to focus on your
27:47
usage costs so I mentioned in touch this point earlier like Engineers need to be aware of what you’re doing
27:52
um it’s very important it can be understated like Engineers really need to treat cost if it’s a metric that they
27:59
care about um custom ambassadors is a concept that we saw working amazingly across
28:05
different different departments so if it’s you know a bigger organization it’s very hard to create that Finance culture
28:10
so just find that one developer in the team that cares about it and maximum like the ambassador of the team try to
28:17
uh you know to give him special swag try to give him like a special recognition for the company wherever it’s possible
28:22
to be like the hero that actually saved money and once other developers sees that you know we have that one
28:28
Ambassador that really cares about uh Cloud cost they start to get contagious and start to get into a gamification so
28:33
they want to save money as well they want to be recognized as well um and we started working with
28:38
organization it’s amazing it’s a great a great thing to do and we really encourage doing that
28:45
um optimization backlogs are like never ending right we always gonna gonna find
28:51
more ways to save money we’re always going to find the opportunities to cut down costs and to re-architecture our
28:56
environment to uh to do that um and it’s very important to keep like a tight backlog so it’s not uh we’re not
29:03
going to stop everything that we’re doing in order to optimize costs but we can like get you know small tasks into
29:09
uh into Sprints we cannot start to prioritize them and something that’s really helpful is to give a dollar sign
29:15
of uh you know how much money we can save for each optimization project and make sure that you know we continue to uh to optimize it with uh with time and
29:22
we’re selecting the uh uh lowest lowest hanging fruits that bring us the most amount of money you know as the first uh
29:29
first task that we’re running um and celebrate success uh developers
29:34
are working hard in order to uh uh to save money we you know we have companies
29:40
that have dashboards of you know developers that save the most amount of money every week so like celebrate it like encourage it
29:46
make a culture of cost like uh cost awareness and it’s going to work uh work
29:51
amazingly um and uh you know obviously I’m biased
29:57
here but you know it’s very hard to achieve all of this without having a tool that can help you so the cloud providers are great with starting to
30:03
show your own tool but um you know a tool needs to be a bit more uh uh uh you know full in terms of
30:11
how we can get that how I can get the fin apps uh Phoenix practice and service in place uh so if you’re interested uh
30:17
we uh I will be happy to show you a demo a bit of what uh what Finance is doing and just to give a small tears of uh you
30:23
know what uh what we can do so we talked about kubernetes cost optimization and you know when it talks about saving
30:29
money uh kubernetes is usually one of the uh you know most uh most expensive
30:34
Solutions but they’re also uh solutions that is really really up like easy to
30:40
optimize and if we’re going to start you know to monitor kubernetes kubernetes vendors especially like a request and uh
30:47
for uh for memory and CPU um you know so we can start to see like what’s the usage over time of our for
30:54
pods and services we know what memory how much memory the request we know what
30:59
was the max usage of dot memory or even you know a Pia p90p uh and the 80 same
31:06
with sapu as a request one and a half cores but you know usually we’re uh just need the
31:11
0.779 so we just change the kubernetes request in the MLS and we can actually give a dollar sign on that in that
31:18
efforts it’s going to take a few minutes of work and we can save you know hundreds of dollars every month just in
31:23
just in kubernetes and this specific kubernetes deployment cost so it’s really important to uh to always think
31:28
about it and make sure that the you know we’re uh we’re having that uh that level of thought within within the
31:36
organization and we have a tool that added and support us and you know once we start to get uh to get into that
31:42
culture so companies can start to like really uh grab those costs before they’re uh before they’re happening we
31:49
can find out the issues on the Fly uh and we can create that culture of uh of
31:55
cost awareness within within organizations of tools or like a great way of of doing that uh and running and
32:04
uh thank you so much and I think I’m gonna pass the torch back to UDI to manage a q a of some sort
32:15
was an amazing session I hope everyone learned at least something uh new at
32:21
this one thing that they didn’t know before and we will share the recording and uh slide decks with everyone along
32:28
with ways to contact Commodore and Finn out and uh
32:33
and even with social so you can keep in touch and if you have any other questions
32:40
um in the future feel free to reach out and do we have any questions before we
32:47
close we have almost a Time so let’s see this is your time if you
32:54
haven’t already you can drop your questions below in the Q a
33:00
more in the chat if you want to be cheeky okay
33:05
no questions excellent session I agree so if we’re all in agreement here so
33:13
thank you it’s been great and see you next time thank you and everyone who
33:19
joined us bye-bye