The cost of memory, CPUs, motherboards, network cards, and other technology hardware, continue to rise due to the demand for power-hungry AI data centers and hyperscalers.
According to zdnet, “AI data centers use two types of RAM—High Bandwidth Memory (HBM) and LPDDR5X. A single server rack can consume 20TB of HBM3E and 17TB of LPDDR5X, and that’s enough LPDDR5X for a thousand laptops. And that’s just one server rack out of the thousands that you’ll find in a single data center.”
The 2026 war in Iran is also playing its part in straining the supply chain, with minerals and parts that are crucial for the semiconductor industry being delayed. The impact is being felt not only in America, but worldwide. Octave Klaba (CEO, founder, and chairman of the France-based cloud operator OVH) recently issued a warning that the company will soon hike the price of server rental by up to 87%. According to an article from The Register, he also blames “the hyperscale buying frenzy sparked by the AI boom” for the increase.
Per the article, “OVH recently received quotes for RAM and disk prices and argued the company must pass on its increased costs by hiking the prices for new servers as it brings them online.” Other companies may follow suit in the coming months.
It may be tempting to try and build a DIY cloud stack, but costs can quickly add up from the developer time spent managing infrastructure, deployments, and environments instead of building the product.
Kevin Downs, head of marketing at Sevalla, believes companies should rethink how much time and money they’re spending managing infrastructure. Downs has helped companies drive growth by turning complex products into clear, compelling stories. With experience in enterprise SaaS, cloud, and observability, he’s built product marketing teams, launched high-impact campaigns, and helped close more than $100 million in revenue.
Sevalla’s mission is to give developers an easier way to run production applications without managing cloud infrastructure themselves. The company offers a developer-first platform that removes infrastructure complexity while keeping the control, visibility, and production-ready capabilities teams need.
What are the hidden costs of running a DIY cloud stack?
You can see the cloud bill, but a significant hidden expense is the engineering time needed to set up and maintain the infrastructure. Running your own stack means taking on many ongoing tasks, such as managing deployments, networking, permissions, security, monitoring, scaling, database maintenance, upgrades, incident response, and environments. Each task is normal on its own, but together, they never really stop.
There’s also a knowledge cost. Over time, deep infrastructure knowledge often becomes concentrated among a small number of senior engineers. This creates dependency on those individuals, making onboarding and incident response harder while increasing the impact when experienced engineers leave.
So, the real cost of cloud infrastructure isn’t just about compute, storage, and networking. It’s about the engineering team that must run and support everything else.
What is driving these costs, and are companies aware of this?
One of the main reasons is that complexity builds up over time. Cloud providers offer teams a lot of flexibility. This is helpful when the infrastructure is a key part of the business strategy. However, each new service a team adds means there is one more thing to set up, secure, monitor, maintain, and learn about.
The complexity tends to build gradually. First, a database is added, then caching, queues, load balancing, monitoring tools, CI/CD [continuous integration/continuous deployment], more environments, extra permissions, and more automation. Each choice makes sense on its own. Over time, a team can effectively find itself operating its own internal hosting platform.
Cloud spend is easy to see, because it appears on a bill. The harder part to see is the engineering effort behind it. Over time, that operational work can become a meaningful cost without showing up as a separate line item.
What are the trade-offs in developer time between managing infrastructure instead of building products?
Since engineering resources are limited, any time spent maintaining infrastructure means there’s less time to work on the product. It also matters whose time is being used. Infrastructure issues often require senior engineers, since they know the architecture best. But these are the same people you want working on tough product challenges, performance, mentoring, and planning.
The bigger concern is the gradual loss of momentum. When senior engineers spend more time keeping systems running, less of their time is available to improve the product. Eventually, infrastructure can stop being an advantage and start consuming a meaningful share of engineering time. As an engineering leader, you must ask if the control you get from owning infrastructure is really worth the product development time you give up.
When should organizations rethink this approach?
There are a few practical warning signs to watch for. For example, if senior engineers often leave product work to fix deployments, adjust infrastructure, handle upgrades, or deal with operational problems, that is one. Another is when only a few people truly understand how the production environment works.
You can also see it when infrastructure starts getting in the way of normal development work. Deployments become harder to trust, environments are less consistent, and more engineering time goes into keeping the application running rather than improving it.
These issues don’t mean the original infrastructure decision was a mistake. Company needs change over time, and what worked when the application was first built might not be the best choice years later. Instead of asking, “Does our current stack work?” because it probably does, it’s more helpful to ask, “Would we choose to build it this way again today?”
How can Sevalla help address this issue?
Sevalla reduces how much of the infrastructure layer the application team must own. With Sevalla, engineers do not have to build and manage infrastructure on their own. Sevalla handles much of the infrastructure work behind the application, including deployment workflows, runtime infrastructure, databases, networking, scaling, and observability.
The main advantage is not more infrastructure capability. It is less infrastructure responsibility for the engineering team. Engineers can spend less time on tasks such as maintaining cloud deployment systems, managing permissions and networking, or keeping multiple cloud services running smoothly together.
The application team still manages the application. They can monitor, debug, and control how it runs, but they do not need to operate the platform underneath. For product companies, that means treating infrastructure as something the team consumes rather than another system it must build and maintain.
What do you see happening in the future with cloud costs and cloud infrastructure?
The cloud cost conversation will increasingly move beyond the size of the cloud bill. Companies will keep working to lower compute, storage, and data transfer costs. However, the bigger issue will be how much time engineers spend managing infrastructure.
As software teams build applications faster, infrastructure overhead becomes more noticeable. Speeding up development does not help much if engineers still spend a lot of time setting up, maintaining, and fixing production infrastructure.
More teams will start to carefully decide where they really need to control the infrastructure and where they can move to a higher level of abstraction. Large cloud providers will still be important for companies with unique needs, very large scale, or infrastructure that is part of the product itself.
But for many product teams, the better approach will be to own fewer infrastructure layers rather than continually getting better at managing more of them. Cloud infrastructure will not become less powerful in the future. Instead, fewer product engineers will need to manage it directly.