You Haven’t Modernized — You’ve Just Moved Your Problem from Hardware to Software

Apr 1st, 2019 6:00am by Sidney Rabsatt

Sidney Rabsatt is vice president of product management at NGINX, responsible for leading product strategy. Rabsatt is an experienced leader with a proven track record of building winning enterprise products across a variety of markets. He has also held leadership roles at Riverbed Technology and Packeteer, as well as technical roles at Hewlett-Packard and IBM.

My first job out of college was as a Network Engineer. I spent my days poring over hardware configurations, trying to figure out how to make changes without breaking anything. As the number of core features built into the hardware grew, because centralizing functionality made more economical sense (i.e., sweating the asset), so too did the risk and business impact of getting something wrong. That led to more rigor for any change made to that hardware which inevitably slowed things down.

But that was then, and well, “slow and steady” doesn’t quite cut it in the modern world. Today, a company’s survival, sometimes its very existence, might depend on the software that runs its business. Yes, processes and controls for improving and releasing software are important, but the successful organization must respond to market pressures, customer demands, and competitive threats quickly. Sometimes, new software features or application adjustments need to be rolled out yesterday without breaking what’s available today.

A truly modern, software-based solution enables near real-time deployment of new application versions, features, and updates. Why? For three primary reasons. First, it’s lightweight and easy to modify. That means rich and easily orchestrated functionality is packaged into a slim 1.5MB that can be installed on any server, container, or VM. Second, it’s portable. To be agile, businesses need software that isn’t confined to a specific OS or environment. Portability means it can run securely within your existing environment or any cloud. And most importantly, it integrates with key modern development and deployment processes. What’s worse than yet another piece of software that is siloed, requiring its own maintenance process? When a cleanly integrated software solution comes with well-tested and well-documented hooks into existing CI/CD, orchestration, and alerting/logging tools, it makes deployment and management a breeze.

NGINX is really about enabling a shift from “slow and steady” to “fast and ready.” Many of our customers know that to compete effectively, they need to be faster to market with their software. No, they can’t be sloppy. They still have tight reigns on change processes and rollouts. But many of them now have an infrastructure team that handles the common denominators like the core, durable functions the business requires to operate with the right security, uptime, availability, recovery, etc.; this team is separate from the application team that is thrilled to (finally) take control of the dynamic rules which govern how the software is intended to run. Who knows the rules better and sooner than those same applications (or DevOps) teams? This is a huge win. Our customers are those companies that have embraced this new working dynamic between infrastructure and application.

Yeah, there are options besides NGINX, options that promise to do the same thing, to facilitate the separation of infrastructure from software. And when you roll out their virtualized hardware solution or heavyweight infrastructure appliance packaged as software, they congratulate you for the move to their version of “modern.” But, really, that’s the same candy, different wrapper. To truly win at this, to truly take advantage of the benefits afforded by separate infrastructure and application functions, you need to evolve the operating model, not just the packaging. And one great way to do that is to separate the core, relatively static functions that apply, generally, to all applications from the dynamic functions that tend to be application specific. With that kind of separation, you end up with a solid core augmented by a dynamic application gateway layer that frees you to update, modify, and create applications independently in lock-step with business demands. Just imagine if you kept everything tied together? Tickets would be submitted for changes to a specific application (maybe by the DevOps team who wants to improve the application’s performance). These changes, though, aren’t applicable to any other piece of software in the stack. Yet, it’s the infrastructure team doing the modifications because they are the gatekeepers. And, unfortunately, those updates are in a long, long queue of changes to be made (which, of course, need to be tested against everything else). Are you pulling your hair out yet? Let me put it in a different way. If you were building a house, and there were some electrical problems, would you let the plumber fix them? No, you’d let the electrician do it because they have the most knowledge. It’s time to let your application teams and DevOps take care of the things they’re good at.

With a dynamic application gateway like NGINX, the individual rules that govern application deployment, operation, and performance can be controlled by your team members who are most knowledgeable about them.

Feature image via Pixabay.