Developers are the kingmakers. Millions of decisions made by tens of thousands of developers are ultimately responsible for the triumph or tragedy of IT. Developers for commercial vendors, open-source projects, cloud and software as a service (SaaS) solutions, managed service providers (MSPs), and internal teams make most technology decisions far upstream from IT pros. This essentially defines ops’ role as the crew who finds a way to make washing machines fly in formation. Though IT pros have become experts in doing so, this downstream path eventually impacts organizations’
cost containment options.
The resulting challenge isn’t about IT’s partnership with dev or that DevOps isn’t a panacea to heal all things in production. The challenge is the latency between developer’s decisions and follow-on operations years or decades later. There’s a space-time barrier to direct feedback from long-term operations back into development of the past. This is why—like it or not—developers have a responsibility to think about operations cost containment, ideally shortly after the creative moment.
We’re now beginning to see the effect in cloud-native projects. You’d think the accelerated pace of cloud development and some truly breakthrough enabling tech would maintain a certain minimum learnings latency. Aren’t developers right there, embedded into all high-performing teams of modernity? Some are, and you’ve likely seen their engineers on stage in a tech conference. In reality, however, cloud native isn’t new anymore. It’s becoming another mainstream enterprise strategy among many. As a result, cloud native is increasingly inheriting enterprise expectations, including longevity and cost containment.
It’s Not the Developer’s Fault
Don’t hate the developer. Because you’re talking about me. Well, you’re talking about where I came from. First and foremost, most senior developers and architects aren’t selecting technical approaches based on what’s cool or to simply play with new technology. This enduring stereotype misrepresents professional developers. Sure, you’ll still find a few bleeding-edge sectarians, and young developers may need to get a framework out of their idea queue at some point. That includes me. Actually, it may be why I recommend considering something existing first.
For developers, “old” is necessarily boring. And “boring” won’t get you hired into a cool new startup. Rejecting proven technologies is a tested method to highlight future-focused thinking. Unfortunately, it’s also financial incentivization to reject technologies representing the bulk of most enterprises’ operations. You will, however, find plenty of experienced developers who choose to make
serious bank remodeling Java for... banks.
Developers are also rarely responsible for long-term business decisions. Once code is out of their hands, they often have little to no stewardship of their work over time. The business will make some of the most critical
IT cost optimization and containment decisions about their code, language, and toolchain epochs later. Developers focus on the now and the near future. That’s the job. Hours of envisaging the one winning outcome of 10,000 possibilities years later won’t get code out the door or achieve the delivery goals of their managers.
Learning the Hard Way
Senior enterprise technologists can recount many examples of “if only I knew then what I know now.” For me, it was a session at DevOpsDays about cloud-native transformation for legacy in-house applications. The CISO of a Fortune 100 company was sharing success stories and techniques they’d used to wrangle and secure creaky codebases into their cloud environment. Cost containment of recurring billing was a recurring theme.
Over and over during his talk, I had the same reaction you may have had listening to similarly harrowing tales. “Oof, that’s painful!” “It costs
how much to keep that going?” “Lift and shift or reimplement clean? Rocks and hard places, I feel for you.” Then, he got to an app that had been running since the 90s, developed by some kid on a business unit dev team. As soon as he outlined its function, I was horrified.
I’d been the kid who developed it.
I’d left behind a roadmap, architecture for a far more supportable v2, plus proof-of-concept code in a more modern language. Of course, the cost to migrate now was high. Virtualization—much less cloud native—didn’t exist back then. How had v1 been maintained so long? I’d left an executive summary, with pictures and everything. The current
migration cost wasn’t my fault. I swear!
Cost-Fifth Cloud Native
To be clear, cost containment shouldn’t be the first priority of cloud-native development. Assuming cost isn’t wildly out of control, innovation, resiliency, security, and
digital user experience should all come first. Transformation, nimbleness, and flexibility are the leaderships goals driving cloud-native adoption. However, developers have an often-overlooked opportunity to be fondly remembered as verified sages by legions of grateful enterprise IT pros.
The key is to include the gears to activate cost containment support during initial development. If their work is good, it’ll endure, and extended support will eventually be necessary. An easy first step is to adopt the foundation of reliable operations. Ensuring new and modernized applications include solid cloud-native monitoring from the outset not only helps DevOps and SRE teams but benefits the business, who’ll own those applications for the long run.
Integrating ops-focused monitoring is also an organic process that identifies sustainable approaches based on experience rather than most futurism. For example, if an application relies on platform-managed serverless or orchestrated containerization, there’s no shortage of opportunity to provide rich performance data for both developers and operations. Set aside R&D time to experiment with at least a few different technologies, including FOSS and commercial cloud-native monitoring options. The current team will (as always) appreciate data and visibility richness. And down the line, the ops team will immensely appreciate the cost insights from sustained measurement.
Developers are in a unique position to leverage their expertise with dependency analysis, code maturity, and ease of integration to quickly get a sense for tool durability. If most engineers on the team can quickly plug logs, metrics, and signals into a framework operations can just as easily uptake and maintain, it’s a good sign. If an
IT operations management solution can just as easily combine cloud-native application performance details with infrastructure performance, user experience, and OpEx billing data, it’s even more likely the solution has the momentum to help manage cost in the long term.
The Great Circle of Dev
With experience, most professional developers focus on business needs before landing yet more Node.js promise reverse double somersaults with a half-twist. (Though I’ll admit the callback queue is deep magic that’s a joy to play with and fun for the whole family.)
Some developers include support concerns because they’ve had the pleasure—ahem—of hammering once-bleeding-edge choices into more sustainable forms when cost containment became a leading concern. Others may have had good fortune in DevOps teams, where the goals of operations were closely aligned with their own. A few have even noticed business leaders take note in presentations with a cost management and long-term support slide, and their suggestions have gained additional influence.
Regardless, the accelerating enterprise cloud-native transition offers unique opportunities for cost containment. Leadership is rapidly evolving their definition of application suitability and quality to include all aspects of application ownership, from launch to sunset. And they must. In an OpEx world, development investments, required infrastructure resources, operations support, and almost everything else is billed at time of service. Headroom to tuck occasional unexpected cost into routine CapEx is shrinking.
Perhaps this is the lesson of modern development in respect to cost containment. Considering sustainable cost containment at design time is not “old,” “boring,” or unrewarding. On some teams, it’s seen as a new dimension of senior developer maturity. Not only will the business thank them for doing so now and later, when they become “The Business” one day, they’ll be glad a developer like them did.
