Is It the End of Abundance in Tech?

After 15 years working on SQL Server and believing the world revolved around databases, I came to SolarWinds where I could learn more about operational technology and its role in full-stack observability. I've had fun watching these two industries collide, delivering on the promise of better value for businesses.

I recently read “End of Abundance in Tech” by Ben DeBow, and it encouraged me to think about what the next big market shift will mean for my industry. Because what the cloud promised us 10 years ago - the idea of never-ending scale and compute - may be ending. That has a huge impact on how we build and support technology today.

The end is nigh: Scaling on the cloud

We build applications in the cloud because we've been sold this idea of infinite scale. You build and deliver an application to the business, and it’s reasonable for workloads to multiply and the data supporting those workloads will balloon. But don’t worry, simply collect all the data, build any application any way you want, and the cloud will support you forever. But the cloud is not infinite, and neither is your technology budget. There will come a time when we simply cannot keep adding more resources because it is either physically impossible or financially impractical to do so.

When businesses commit code for applications, most will never know how many resources the code uses or how much it costs once it's in production. Many developers never know if they’re building code to be called once or 10 million times, nor do they understand the implications of the code on other parts of the technology stack. DevOps and automation processes have given us a starting point to tackle these issues, but it’s still a problem in most organizations. We should be worried about what impact exponential business growth will have on the efficiencies of our systems over a decade or more of use.

How much is this going to cost me? Cost projecting software

When scoping software development projects, your finance leader ultimately wants to know two things: how much the product will cost to build and what is the cost projection of maintenance. Thanks to new frameworks in project management and product development, we're better at predicting sprint lengths and build times, but the maintenance cost projections still seem to be cobbled together with duct tape and guesswork. In the book, DeBow outlines a typical maintenance cost project process:

"The answer it seems is to first ask your director of technology (about maintenance costs) who in-turn asks the managers of the application team or the data team. They then ask the subject matter experts (SMEs) who examine their respective servers. They pull data from their SME tool and identify areas of concern through busy, color-coded dashboards that simply infer that capacity. Then everyone runs that information up the chain of command."

This doesn't surprise me. I know database technologists struggle with capacity planning and performance predictions, so why would software development be any different? The challenge is: cloud computing is expensive and maintaining poorly written applications is a losing strategy.

Code efficiency and observability

Is the solution to the tech abundance problem as simple as having the right data and insights ready for business decision-makers when they need it?

This is where the future of observability can play a key role in adding context and meaning to reporting data. We must move from prescriptive dashboards to contextual reporting. And we must go beyond the question of ‘are we meeting performance goals?’, to ‘how efficient are we as we’re working toward those goals?’ It’s exciting to think our tools will bring context to the overall health of technology systems and advise on how to make those systems more efficient and functional.