Skip to main content

· 6 min read
Hassan Khajeh-Hosseini

When it comes to cloud costs, the relationship between the engineers who are responsible for purchasing infrastructure and the team leads, managers and FinOps who are responsible for the cloud bills is broken.

It turns out the closer you are to the code, the further you are from costs.

Broken feedback loop

Let’s look at an example product to production workflow and what happens when a company releases a new feature, which requires infrastructure.

· 4 min read
Ali Khajeh-Hosseini

We released a new dashboard summary table, support for team management, and introduced concepts for Repos and Projects. Upgrade to version v0.10.11 to pickup numerous bug fixes and the new features.

We've also joined the FinOps Foundation as Infracost Cloud is helping FinOps teams see all upcoming code changes and their cost impact from a central place. There are two use-cases here: the first is to see if a cloud cost increase was due to an infrastructure change, and if so what was the change, who made it and when. The second use-case is to set expectations that an upcoming change will increase cloud costs, so forecasts/budgets can be updated and alerts reset.

· 5 min read
Ali Khajeh-Hosseini

Two years ago we published our first blog titled Infracost - cloud costs for devs. Infracost is now used by thousands of engineers across many CI/CD systems, 3rd party integrations and even VSCode, so they can see how much their code changes will cost before resources are launched.

Today I'm excited to announce Infracost Cloud - our SaaS product that builds on top of Infracost open source and helps team leads, managers and FinOps practitioners see all code changes and their cost impact from a central place. This creates an immediate feedback loop of upcoming changes and costs across the organization.

· 5 min read
Ali Khajeh-Hosseini

In 2009 I started my PhD research to focus on the decisions that needed to be made for an organization to adopt public clouds. These included the benefits, the risks and the costs of using such systems. My aim was to create a set of vendor neutral tools that would assist decision makers during the process. At the end, I had developed three tools:

  1. Cloud Suitability Checklist: A set of questions to help asses the suitability of public clouds for a given application.
  2. Benefits & Risk assessment: A list of benefits and risks that provides a starting point for organizations to talk about cloud adoption.
  3. Cloud cost modeling: A tool that enables architects to design a system (compute, databases, storage, network etc) with built-in elasticity and growth, and create a 3-year cloud cost forecast using public cloud prices. This tool turned into a startup called PlanForCloud and was acquired by RightScale: