RAM 파멸이 DevOps의 다음 전망… 끝은 아니다

출처: DevOps.com

As little as a decade ago, the software industry operated under the unspoken rule* ‘hardware is cheap, programmers are expensive*’. A saying that today’s software developers, who are currently navigating the RAMpocalypse, might look at and laugh at. Sure, back then, it did make sense. When apps ran slowly, developers could pull from a bounty of affordable hardware to plug memory leaks and solve the issues.

But we took Moore’s Law for granted. Back when it was coined in 1965, the future was full of hardware gains that could outpace any software inefficiencies. Moore couldn’t have predicted that we’d face such a sharp hardware shortage, with high prices set to be a mainstay for the near future at least. For today’s developers, that is now the reality – but it doesn’t mean we’re at the end of the line.

Instead, we could take this as an opportunity to embark on the next frontier. Development processes have shifted to prioritise speed, and while the growth of AI technology is boosting this, it’s also producing additional software instabilities. Even if we had the hardware to spare, we couldn’t patch every leak. Using the frustration of this RAMpocalypse, developers should spark a return to optimisation and streamline their software development. Partially because the shortages don’t leave many other options, but also due to the benefits for software performance that it could unlock.

The Silicon Ceiling

Either way, there’s no waiting around and waiting for these shortages to pass. As we begin to look further into the future, recent announcements from leading memory manufacturers have already made it clear that production will increasingly favour High Bandwidth Memory (HBM) in order to meet the demands set by AI chips. The immediate shortage might well ease, but prices will remain high – and resources will likely remain limited.

So developers will need to face these shortages head‑on, no matter what sector they work in or where in the development process they are. For those working on new products, they can either push launches back to buy more time or ship them on cheaper hardware, which could compromise the user experience they have worked so hard to create.

But it’s important to clarify that no developer sets out with the intention to create inefficient software. It’s merely a byproduct of the ever‑increasing push for speed and innovation. Teams are under more pressure than ever to create the ‘next big thing’, ideating impressive and unique proofs‑of‑concept for products. At this stage, the sky is often the limit, and teams pack these full of features and all the code that goes with them, without thinking about the knock‑on effect on developers.

By the time these proofs enter the similarly rushed production phase, developers are left to somehow squeeze all of this unoptimised code into a go‑to‑market product. Almost inevitably, time constraints lead to this code being shipped as is – normally propped up by hardware fixes to get it functioning. It’s never the development team’s intention – as we all know, no software development cycle is perfect. But with the ongoing shortages, these fixes are simply no longer an option.

Companies are already renegotiating RAM prices quarterly. So, while during development you might be able to source the 4.0 GB of RAM modules your software stack needs at a profitable price, by the start of production, that same module could have increased in price. Suddenly, you’ve got a product that is no longer financially viable.

Taking a Side Step to Move Forward

While these outside circumstances are out of the hands of any development team, there are changes that can be made internally to mitigate their effects. In a nutshell, developers need to reduce their reliance on hardware. Instead of letting hardware procurement difficulties force their hand, developers can address these issues proactively, bringing software efficiency to the forefront.

By now, we’re all familiar with the ‘shift left’ philosophy for the testing process. Well, now, we need to apply that same thinking to optimisation and performance. Optimising code at the development phase can drive incremental benefits, but the real change comes from applying it at the proof‑of‑concept stage too.

Core KPIs like speed normally occupy the position of highest regard during the development process, so why not put performance and memory usage up there too? Now, this might sound a little radical, but it’s already a widely followed process in embedded systems production. Any developer who has worked on an embedded system will tell you that hard caps on resources are a mainstay in every process. From day one, development teams are given clear boundaries and held to them. Not to restrict their creativity, but to ensure that they can actually deliver the concepts they are coming up with.

This way, the end product isn’t just profitable and optimised for the end user – but it actually matches that proof‑of‑concept idea.

A New (Old) Approach

In many ways, these changes are a return to the past. Just a decade ago, many of the big names had entire teams devoted entirely to optimisation day in and day out. Their sole focus was on improving software, making it run not just leaner, but better. But today, these teams are rare, and developers would struggle to pick up their work. Sure, most developers have some general optimisation skills, but they lack the in‑depth knowledge that allows them to spot and adjust those granular details visible only to a specialist – the changes that add up to the larger memory savings.

For those looking to expand their optimisation skills, a programming language could be the place to start. Most developers default automatically to Python for the convenience it unlocks, despite its high memory consumption. To act like specialists, developers need to take a more holistic approach, using a variety of languages to suit different needs across their software. Language agnosticism like this will prove essential for navigating these shortages.

It will take a while for developers to learn these optimisation skills, likely with some trial and error involved too, but these skills will be essential to carry them through these shortages and beyond successfully.

In the long‑term, optimisation doesn’t just represent a way around hardware constraints; it could be the path to improved software quality and performance overall. And with the AI boom creating plenty of temptation to build with quick but bulky AI‑generated code, it will only become more vital.

Ultimately, it’s up to developers to decide what to take from this RAMpocalypse. But if they choose to embrace the lessons it’s teaching us about optimisation and embed it as a core discipline with teams, they could reap the rewards. Those who take proactive action now will be the ones best placed not just to navigate this situation, but to face whatever comes next.

After all, good software is just as important as fast software.