The main goal of implementing DevOps in the first instance is to enable you to improve the quality of your product delivery, delivering high quality in little time through speedy end-to-end delivery, while also delivering value for money without implementation costing the earth.
However, for software development teams and tech organisations, where DevOps is very much the golden standard approach, it can be very easy to lose sight of cost. Consequently, it becomes very easy to rack up a costly bill for the privilege of getting DevOps up and running.
As such, DevOps teams need to focus on cost. Cost efficiency and cost management need to be baked into the mindsets of the DevOps teams, to ensure both sustainable growth and operational agility in harmony. By designing and deploying solutions with cost efficiency in mind, your teams can optimise resource usage, reduce unnecessary exorbitant operational costs, and enhance the overall return on investment. In essence, cost efficiency is integral to creating robust, scalable, and financially sustainable DevOps practices.
In this blog, I will cover 4 of the most efficient steps that DevOps teams can take to ensure that cost efficiency and cost management are not forgotten but are instead actively monitored and integrated into the organisation’s quest for state-of-the-art DevOps practices.
Step #1: Plan ahead for product optimisations and prove value on pre-production environments.
While DevOps and FinOps generally encourage more experimentation with products and architecture in close-to – if not actual – production environments, this can have unexpected cost implications in a critical environment. If an experiment goes wrong on production, the costs may well go through the roof, for example, unproven ideas leading to broken products, in turn resulting in reduction of site throughput, and loss of potential revenue.
If there are work items to optimise product performance or tweak the product architecture to reduce costs, make sure you discuss a detailed plan in Product Planning or Sprint Planning meetings, so team members know what avenues to explore. There is such a thing as too much or too little when it comes to optimisations – so it’s getting a balance between what works well and what costs the least.
Then, when working on these optimisation work items, it is better to prove their worth on non-production environments. If you have test or dev environments setup that replicate production setup, these are perfect for trialling if optimisations have the desired effect. If they do, great! Apply to production. If not, then at least you can be assured that production would not have been affected. Whilst it may still be costly, it still works!
Take-home points:
Discuss planning optimisations as a team in Product Planning or Sprint Planning meetings.
Use test environments to understand the cost implications of product optimisations.
Evaluate the cost implications from the test environments, before committing to applying the optimisation in production
Step #2: Use cloud provider cost tracking capabilities.
The best DevOps teams are those who can balance development effort, nail testing packs, automate CI/CD pipelines, and keep an eye on monitoring the tools and products they develop. Monitoring and observability is not just about application and team metrics though; arguably more important – from a financial perspective at least – is cost metrics, or tracking of accumulated costs.
Regardless of which cloud provider you choose to host your team’s product architecture, AWS, Azure and GCP all have cost tracking capabilities built-into them. Cloud cost management tools, such as AWS Cost Explorer, Google Cloud’s Cost Management, and Azure Cost Management, help teams monitor spending and identify savings opportunities. You can automate alerts for cost spikes, use resource tagging for better tracking, and optimise resource allocation based on actual usage rather than assumptions. These tools, their data and visuals can also be integrated into other third-party observability provider tools, like Dynatrace or NewRelic dashboards. This provides you with the ultimate centralised view for all your monitoring needs.
Tagging is a really important point to note here too; not enough DevOps teams have strategies around how architecture is tagged, making it hard to narrow down specific areas, resources or stacks where costs are at their highest. Likewise, there is such a thing as too much tagging; so again, it’s about finding a balance. Typically, the most useful and concise tags to define are: Owner (whether that be a team or a certain individual), Environment (Dev/Test/Prod), Application Type, Technology, Group or Name of the Resource.
Take-home points:
Use the tools that AWS, Azure and GCP provide.
Integrate the data and graphs they provide into observability dashboards used across the team.
Design and implement a tagging strategy for your cloud resources.
Step #3: Keep an eye on cost of CI/CD and general DevOps automation practices.
Costs don’t just get generated from hosting product architecture, or from system throughput… they can also be generated from CI/CD pipelines running too frequently and for too long.
From experience, tools like Azure DevOps have associated charges for CI/CD pipelines; you get charged for use of Microsoft-hosted CI/CD agents and you get charged after a certain number of build minutes and the size of the build artefacts used, on a monthly basis. There have been times where I’ve viewed the monthly Azure bill and found that our pipelines were costing more money than necessary. This isn’t just a CI/CD pipeline-specific issue… this can apply to all parts of the DevOps processes.
Putting time and effort into automating and speeding up parts of the CI/CD pipelines can help save extra expenditure. If there is one big build running that does lots of different tasks, try breaking them up into smaller builds that run at different frequencies. For example, try keeping your commit CI/CD pipelines to just building and unit testing code. Try having separate CI/CD pipelines to run code scanning analysis or full test regression packs, that only run on a daily or other timewise basis. Keep an eye on the bills as they come in; if something is costing too much and is related to the DevOps process, optimise it to save the extra expenditure.
Take-home points:
Study cloud provider bills as they come through, to identify where DevOps practices may be costing more money.
Run DevOps-related tasks – such as nightly SonarQube checks or regression test runs – to a tighter, more concise schedule.
Optimise CI/CD pipelines and test stages to reduce dev costs.
Step #4: Ensure every team member has an awareness & basic understanding of how cloud costs work.
DevOps is all about building multi-faceted and skilled teams, with different parts of the software development life cycle (SDLC) working together rather than staying siloed. This has to be the same approach when it comes to tracking of cloud costs. It is not just the responsibility of the operations teams to be concerned about cloud costs. Likewise, even if teams are multi-faceted already, it is not just one person’s role or task to be aware of the cost implications of work. Everyone in the team has a responsibility to be aware of associated costs with what they produce.
However, being aware is one thing; understanding is another. You can be aware of costs but not fully understand what to do with them. If you understand where the costs are coming from, why, and how to rectify those costly areas, this implies your awareness is at a far deeper level. Being aware of costs won’t change anything; having an understanding of the costs – however basic that understanding is – drives a proactive change across the teams, products and architectures.
Public cloud providers such as AWS, Azure and GCP have a lot of documentation of their pricing models, making it easier to gain that cost understanding. In-built tools for technology choices like MongoDB Atlas and Compass allow you to see how number of database calls and size of database calls affects billing. There are plenty of tools, resources and ways to gain more awareness and understanding of costs… you just have to make time for it!
Take-home points:
Encourage your teams to keep up to date with all things cloud cost
Make use of Communities of Practice, to share cost tips and tricks across teams
Make use of the ample documentation provided by the cloud providers themselves
Conclusion
The aim of mastering DevOps is to make your organisation’s product delivery faster, smoother and of a better quality. However, without keeping an eye on your cloud costs, the benefits of DevOps might not be realised, or negated if you’re spending more than necessary. These 4 steps are by far the most efficient (and easy to implement) ways to ensure cost awareness, understanding and management become part of your DevOps team’s culture.
D.M me if you are interested in knowing more about our approach to building cost efficient DevOps teams. You can reach me at danbennett@capacitas.co.uk