We’ve all heard the stories. It takes too long to make changes to applications, right?
Well, until COVID-19, that was true.
Many enterprises have found that the global pandemic brought on by the novel coronavirus 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 roll out 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 processes 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 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, tools 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 microservices: breaking an application down into small, discrete functions. Each is reusable and optimized for the teams, tools and technologies described above. With microservices, 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 microservices environments alongside their legacy apps, creating a hybrid architecture.
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.
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 microservice, need to coordinate changes with security acting as a shared services team and, unfortunately, the new bottleneck. At least it’s not the network team’s fault anymore.
Investing in the abstracted layer that sits above the application delivery infrastructure solves the software-versus-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 100 milliseconds to 10 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 more than 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 and 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, in which 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 rather than 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 life cycle. 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 organizations.
By investing in the abstraction layer that automates and maintains application delivery and application security left to right across your organization, you can encourage your developers to run faster. Take that, Mrs. McGonagle. Kindergarten will never be the same.
