We’ve all heard the stories. It takes too long to makes changes to applications, right?
Well, until Covid-19 that was true, writes Rob Whiteley, vice-president of marketing for NGINX at F5 Networks.
Many enterprises have found that Covid has given them the will to find the way to move faster. As one customer recently relayed: “Before Covid it would take us six months to a year to rollout a new app, but with Covid it took just six weeks. An existential crisis will do that for you.”
Enterprises have always felt compelled to go faster, improve online experiences and bring new applications to market. But Covid ratcheted up the urgency, to put it mildly. All the process and politics were pushed out of the way, and companies just told their developers to run. Developers planned, prototyped, and pushed code into production in a fraction of the time.
The problem? These enterprise developers are running with scissors. We all recall our favorite kindergarten teacher telling us not to do so. But if you’re facing an existential crisis, do you really have a choice?
The fact of the matter is that a developer’s new code (the scissors) could break something, potentially taking down mission-critical applications, affecting the company’s reputation or its revenue, or even compromising customer data. However, if we yell at the developers to slow down and walk, then we risk revenues falling too precipitously.
Moving at that speed works fine for cloud-native companies built entirely on modern architectures. They have no legacy. They were architected from the get-to to roll out several changes per day.
But in normal times a large bank or insurance company might make the same number of changes per month, not per day. Like your favorite teacher, these enterprises prohibit their developers from running with scissors.
This leads to an almost diametric friction between the developers and the infrastructure teams whose job is to improve reliability and uptime and make sure the business doesn’t get breached.
Now that we’ve had Covid as a forcing function in the world, the time-to-market and time-to-change pressures are forever going to be too fast for manual governance processes. So companies need to resolve this tension.
They need to allow developers to run safely with scissors.
Luckily, all the team, tool, and technology know-how exists. We know that DevOps teams help automate the release process. We know that continuous integration and continuous delivery (CI/CD) and orchestration tools are mature.
And we know that technology shifts in containers, Kubernetes, and cloud-native architectures are production-ready. It’s really just a matter of pulling it all together.
At the epicenter of this is the concept of micro services: breaking an application down into small, discrete functions. Each is reusable and optimized for the teams, tools, and technologies described above. With micro services, if the developer breaks something, they’re breaking one small piece.
The vast majority of any given app – and therefore the business runs it – is not going to go down. Enterprises deploy these micro services environments alongside their legacy apps, creating a hybrid architecture.
For F5 customers, that means putting NGINX closer to the application as the delivery mechanism for micro services, acting as a complementary, abstracted layer above BIG-IP running application delivery for their legacy environment.
Decoupling from the architecture allows developers to self-service the capabilities they need to test and deploy new app features that require changes to traffic rules. They can conduct canary testing, blue-green testing and A/B testing without ever having to contact their infrastructure counterparts or opening up an IT ticket and waiting for a change window.
Like micro services, NGINX breaks these capabilities up into small instances of application delivery infrastructure, giving each team its own discrete NGINX instance and limiting developer’s app changes to that instance.
That ensures the underlying BIG-IP infrastructure stays stable since those discrete changes can’t break the potentially thousands of applications supported by the infrastructure as a whole.
Presto, right? But no. It’s a good solution, but it only takes you halfway. There is still the challenge of visibility and stitching the workflows together so everyone is on the same page.
For many companies with complex workflows, it almost doesn’t matter how quickly developers can move on a change — it still winds up in purgatory, waiting for a security person to audit the code or change a firewall rule.
It’s not uncommon that 50 separate app teams – each working on their own micro service – need to coordinate changes with security acting as a shared services team and, unfortunately, the new bottleneck. At least it’s not the network teams fault anymore.
Investing in the abstracted layer that sits above the application delivery infrastructure solves the software vs. network integration issue, but if those layers aren’t talking, then you’ve really just introduced another silo. You’ve moved the same problem out of the hardware and into the software. Half the equation can go fast, but the other half can’t.
If latency is how long it takes to complete a round trip, then think of this as human latency. As technologists, we love to measure application latency. We can take an app down from one hundred milliseconds to ten milliseconds and congratulate ourselves on a job well done.
But if your security team is still taking 60 days to approve code and implement new policies, then you still have over 5-billion milliseconds of human latency. Your 90% reduction in application latency only compressed a tiny portion of the problem.
To solve for the ultimate problem of human latency, there needs to be a way to provide visibility, orchestration and automation that removes the handoff points and the resulting friction across the different teams of Dev, DevOps, Infrastructure & Operations, and Security — just like cloud-native companies have done.
Previously, one way to solve this would be to get a vertically integrated platform that does it all for you. This is the approach that platform-as-a-service (PaaS) and infrastructure-as-a-service (IaaS) providers take.
The downside is you’ve coupled your application services to your underlying infrastructure. The simplicity of the all-in-one approach allows you to go fast in the beginning, but you may find later that you have hampered your ability to adapt.
If there’s a major change like an acquisition, for example, you can’t quickly merge systems, port to a new cloud, or repatriate an app back on-premises.
Think of this as vertical integration, where the app, the app services, and the infrastructure are all tightly coupled. Now consider a different approach where you horizontally integrate across your silos. There is more value in integrating left to right across people, as opposed to top to bottom across the technology stack.
The solution is to invest in new technologies, but in a way that provides visibility, workflows, and APIs across all the stages of the application lifecycle. Now you have a relay race where each team runs with scissors, enabling security to ensure it’s done safely.
Fortunately, the technologies to enable this model in an open, loosely coupled way are here today. For enterprises with legacy and hybrid infrastructures, your capability to go fast and compete with cloud-native companies has arrived, and you don’t have to hire a thousand Silicon Valley software developers to compete with cloud-native organisations.
By investing in the abstraction layer that automates and maintains application delivery and application security left to right across your organisation, you can encourage your developers to run faster. Take that, Mrs McGonagle. Kindergarten will never be the same.