Cost optimization challenges with DevOps.
Now, one of the things that we have to keep in mind is that when it comes to fit jobs in containers,
things need to be looked at a little differently.
So when it comes to DevOps, basically we want to be aware that they're going to consume typically resources
a little bit more quickly.
And that's because, again, they're rolling out new resources or testing.
They're trying to see what works, what doesn't.
Now, the cost also may not be the biggest concern to the engineering groups.
So because of that, we need to work with them basically as a finance professional to help engage them,
to make sure that they're reviewing the cause before they deploy all these vans, or they deploy these
container services basically running up the costs when they may not need to.
Another thing that comes up is the fact that we're going to her resources.
And what that means is typically you use like a solution like TerraForm or Fuse and eight of us.
You have basically cloud formation or cloud.
You have the plan manager.
And what you do is put in all your code to deploy the resources so that it's a repeatable and predictable
process.
And that can pose some challenges because again, the engineers, if something works, they're not going
to want to muck with it because that's time and hassle for them.
So we have to work with them to make sure that they're using again, the most efficient deployment that
they can.
Our own a resistance can come into play for any number of reasons, can be that it's just taking up
their time.
It could be also too that, you know, setting up like, for example, the labeling, the tagging.
This is just something that they might not have been doing.
And now all of a sudden, you're asking them to sort of do some extra work that can cause some issues.
Traditional spin offs, cost allocation does not work.
And this is true because we have a moving target here.
For example, when we deploy a VM, we put an application on a VM that VM is running that application,
and we know that as long as it's up, it's still running an application.
When it comes to containers, basically what happens here is we're going to deploy clusters of basically
nodes, and those nodes will have multiple containers, if not hundreds of them, and it'll be extremely
hard to keep track.
And then typically as well, it's been typically a practice to deploy multiple applications on multiple
containers.
And so it's a very dynamic way and distributed manner to deploy resources.
So that poses that challenge of how do we keep track of who's using what and what container is actually,
you know, going to this cost center and what is it?
So this is again going to be an issue.
And so because of that, we have that multiple container and application deployment, which I just mentioned.
Now, a couple of the things that we want to look at from a fit us professional, we should always look
at an approach to educate engineering about costs.
They their aware cos they're not, you know, ignorant or anything.
They're just busy and they're just trying to get their job done.
What are the challenge, though, realize it's just a result of cabinet days and how it's deployed?
Collaboration can always be a concern, so we need to always work with the teams the best we can, and
a lot of this can be a challenge too if we don't have that enterprise buying in with policies and documentation.
Now.
When it comes to container spending, there's a long To-Do list here, and there's a lot more things
we look at.
Basically, we can look at everything from setting up allocation policies, for example, how to govern
the spending.
We get set up quality service.
We could use a best effort allocation serve, for example, there may be peak times that we may need
to deploy a burst of allocation, but on the other hand, there may be some resources we can deploy
off hours and that's what we could use, like a fast effort approach.
Also, too, it's important to realize that there's static costs and dynamic costs that are always moving.
And basically, some of the costs, for example, when it comes to static costs will be basically the
nodes that we've reserved, for example, the EPIs, but some of the runtime costs could be when we
actually deploy the containers and we kick them off.
We use the network bandwidth, set up security tools, et cetera.
Always, always right, size the best we can and always try to take advantage of discounts that are
available.
The container services are available, of course, on all the major platforms listed there.
And some of the things that we could do to help mitigate spending in more detail is listed here.
Basically, everything from looking at our billing hierarchy to resources to namespaces to labels as
well.
And this is listed on the final absorbed site as well.
They have a great page on containers spending and how to address it.
Lastly, for our test tips, be aware that container costs are difficult to manage.
For what reason?
Well, because of the fact that we have multiple containers and apps, and that the traditional finance
approach is like tying a tag to a VM or a storage blob just doesn't work.
Always want to use container classes and always, of course, use labels and in spaces, it's all that
I had.
Let's move on.