Hello, I am Saurabh Hirani, member of the editorial team for systems engineering. Since there are many folks submitting talks on cloud costs optimization, this post is a guidance on how to think and frame (old and) new submissions.

Cost control is a pretty broad topic, so we felt it would be helpful to provide some focus for the more interesting aspects of cloud infrastructure management. It would be helpful for members to go through these before making their submissions so they have a better sense of what the editors and community are looking for. The final talk selections are also going to be made keeping these considerations in mind.

Here are some of the things that the community would be interested in understanding from your talks.

Why did you have to reduce cost?

Talk a bit about your journey and provide some context about what caused you to take notice of cloud costs.
Speak on the reasons why cost wasn’t a concern till now and what happened that made you shift focus from engineering tasks to cost control?

Possible reasons for this might be…

Did your free credits expire?
Did your business see a sudden surge in traffic that was cost prohibitive?
Was it just good old frugality and culture of using the optimum level of resources?

It will be interesting for members of the Rootconf community and participants in the conference if you can speak about your motivations. It helps set context on how controlling costs helped you achieve an end goal.

What were the most cash burning components?

Cost is not just about switching off resources that are not in use. It is also about identifying your workloads, finding their characteristics and exploring that specific domain to understand what are the best alternatives available.

Share more about your architecture and information flow to highlight the points which were most compute/network/storage intensive. Weave a bit of a story of your workloads to help the audience get a clearer sense of the challenges.

Were you incurring too much cost on managed services that you decided to roll out your own to save cost?
Did you architect your application in such a way that using spot instances became a good idea?
Did you realize that you could avoid cross AZ transfer by doing some architectural changes?

Talk about what hurt you (or your organisation) the most. Rank the pain. Show your scars and then talk about the solution.

Share more and convince your audience to the extent that they root for you.

Give a reason on why you did X?

“We used autoscaling and we never had to worry about underutilizing our infra.”

Blanket statements like these do not reveal a lot of interesting details and learnings that can actually help the audience make an informed decision on when to do something.

For example - autoscaling comes at the cost of taking time to boot up and infra to be ready - which may not apply if you are handling traffic spikes. It also has the issue of having a good probability that long running jobs may not complete when your infra scales in.

Elaborate on the tradeoffs of your choices - “We chose to do X because it gave the benefit A, B, C. It comes with the downside of P, Q, R but they weren’t big enough issues to impact us”.

You may not necessarily have disadvantages of the choices you made because they worked perfectly for you, which is also fine. But in most cases, there are limitations. Talk about them. That gives a balanced view to your journey.

How much cost was saved?

If you can’t publish $$ values - talk about percentage numbers. But don’t bring them in too early. By the time you talk about the numbers, you should feel that you’ve earned that right to brag about them by educating the audience with useful learnings. Again, avoid blanket statements - “Using ABC alone saved us 55% of costs.”

What is the path forward?

Are the current cost controls designed in such a way that they may make future scalability and architectural changes hard?
If your application decides to scale up with increase in user demand, will your cost grow linearly or will it grow exponentially?
Does your choice of technology come with a cost that is not yet impacting you?

For example - using serverless technology like AWS Lambda is great when you are at a certain level of scale. But as your invocations grow exponentially, you might be better off running something less-serverless.

Think about your choices and how you communicate them to the audience. You are essentially educating your community on the best practices that worked for you. Be aware and responsible for that.

A few other points you should consider:

Have an opinion on the good/bad parts of your cloud providers costing model for the services you used. This helps in follow up questions.
If you see everybody talking about generic Finops practices, double down and talk specifics. Show how you reduced your S3 cost by a factor of X, show how sacrificing a bit of resiliency yielded massive cost savings for you.
This is a story with suggestions peppered along. Generic talk guidelines fully apply here too — Talk about the problem, the solutions explored, the solution chosen, its advantages, its limitations and the way ahead.

I hope this helps you put together a talk that finds the audience and engagement that you are looking for. Thank you for contributing to the Rootconf community and sharing your experiences with us.

Rootconf Mini 2024

{{ gettext('Draft') }}