Developers and digital transformation speed

We are living in challenging and unexpected times. COVID-19 transformed our professional and personal lives in a matter of days. There is a new standard for where we work, where we can go and how we interact with just about everyone. The rapid shift needed to cope with our new normal has fueled a departure from established initiatives, dramatically increasing the rate at which businesses must adapt and respond.

A central theme that kept coming back up since the beginning of the pandemic is speed. Speed to adapt, speed to respond, speed to market. Speed is the key for digital businesses and organizations that want to survive through these difficult times. So how can organizations unlock speed? The answer: developers.

Developers need to run... safely. Time to market and feature velocity are critical to the success of digital business, and organizations can’t let developers get bogged down by process or complex technology choices. Instead organizations must empower them to pick tools and stacks that let them deliver code to customers as quickly as possible. We sat down with Rob Whiteley, VP of Marketing at NGINX, following the company’s NGINX Sprint virtual event where they released a new toolset aimed at unleashing developer speed without sacrificing the governance, visibility and control that infrastructure teams require. Read on for Whiteley’s thoughts on how organizations can empower developers. 

ADM: Why are developers so integral to companies’ digital transformation initiatives?

Whiteley: In an increasingly competitive landscape, digital business is no longer a ‘nice to have,’ but a critical element to meeting customer expectations, becoming more agile and increasing time to market. Over the last decade, consumers application expectations have dramatically increased, as their tolerance for poor UI & UX has become so low that one in three customers say they would drop a brand they love after just one bad experience.

Developers and digital transformation speed

The answer to keeping pace with the growing digital world and meeting customer expectations: developers. Developer teams are the core engine driving the business and it’s important to not only empower them but take care of them. Developers control time to market and feature velocity, which are both crucial to the success of digital businesses. Many industries are facing existential threats as tech companies and startups are finding lower barriers to enter. Uber disrupted taxis. Airbnb disrupted hotels. Amazon is disrupting pretty much every other industry. In order for organizations to compete, they need to empower developers to release compelling digital products and services to attract and retain customers – especially in an era when switching brands is as easy as a few swipes or clicks. 

ADM: What should developers care more about: speed (development time) or stability (application uptime)?

Whiteley: If the COVID-19 pandemic has taught us anything, it’s that businesses need to be able to quickly respond and adapt to new challenges and environments. The same goes for developers. Speed is key for modern organizations that not only want to survive – but thrive – now and into the future. Development speed benefits companies in more ways than just one:

• Faster time to market drives competitive advantage. Companies that are innovation leaders achieve approximately four times the number of new product sales.
   
• Faster applications drive better customer experiences. 40% of customers are prepared to pay more for faster service.
   
• Faster resolutions reduce operational costs. By 2024, organizations will lower operational costs by 30% by combining new technologies with redesigned processes.

That said, speed will only go so far on a shaky foundation. Microservices and the evolution away from monolithic architectures balances this equation. If you architecture your app correctly, you can isolate the rapid changes that developers make to small portions of your app. If a developer makes a mistake or introduces an unintended outcome, then a good microservices architecture greatly reduces the risk of downtime or a poor customer experience. It’s the essence of fail fast as you make changes – quickly – in  

ADM: Would you say that the main challenge developers face is balancing feature velocity with the need for governance and security?

Whiteley: Ideally, yes. But many developers don’t balance these priorities. It’s expected that developers focus on feature velocity and infrastructure and operations teams focus on visibility and control. However, today’s threat landscape is too prodigious to ignore and developers need to take some accountability in security in order to launch and maintain their applications safely. We need to create security tools as part of the coding and continuous development/continuous integration (CI/CD) environments. This is often referred to as “shifting security left” – embedding security responsibilities earlier in the software development lifecycle (SLDC). Leveraging infrastructure-as-code (lightweight, API-driven tools deployed as part of the application stack) and SaaS solutions provide an easier-to-consume option for developer teams looking to access app and security capabilities while still retaining necessary feature velocity.

ADM: Developers often implement their own tools or cloud services as an easy workaround to infrastructure bottlenecks. Are there longer-term risks to this and what should IT leaders do to combat rogue developer behavior?

Whiteley: If developers are not presented with easy-to-use, capable tools, they will often take matters into their own hands. This type of shadow IT is nothing new, however, it presents increasingly significant risks as technology stacks become more complex and security threats more intelligent. Shadow IT can lead to severe data breaches, as well as compliance issues and regulation violations that run the risk of fines. Furthermore, developers are often making short-term focused technology decisions – pick the tool the solves the problem now. This can lead to technical debt and a more brittle or less portable longer-term application architecture.

To combat this rogue developer behavior and enhance productivity, IT leaders can enable self-service pipelines that provide developers with the necessary infrastructure and tools to keep driving initiatives forward, while reducing time spent manually building or configuring infrastructure, which often delays projects. This self-service approach was made popular by AWS and other large-scale public cloud providers. But organizations are finding they need to develop apps across multiple clouds, including on-premises private cloud. Self-service mirrors the simplicity of cloud provisioning but enables enterprises to provide tooling that doesn’t tightly couple the application to its underlying infrastructure. 

ADM: Service mesh. Kubernetes. Istio. API gateways. Ingress controllers. These are just some of the technologies in the container space. What are they and should developers care about any of them?

Whiteley: It depends on your adoption profile. Are you an early adopter that leans on technology to drive competitive advantage? Then, yes, your developers need to understand all of these technologies in the container space. If you’re not, then chances are you prefer more tried-and-true technologies. Usually, this means the technology has matured to the point where a DevOps or infrastructure team will own it, freeing your developers from having to learn container “plumbing.” To better determine, we need to examine each technology.

Kubernetes is the keystone of modern application architectures, emerging as the de facto way to orchestrate container environments. Yet many organizations struggle to deploy Kubernetes in production. Why? Traffic management, security, and visibility constraints make Kubernetes difficult to operate at scale. If you’re a forward-leaning developer, you’re looking to Ingress controllers to handle traffic in and out of your Kubernetes cluster, and API gateways to manage the specific API calls used to connect on application (or microservice) to another. Both provide similar functions – load balancing, proxying, security, authentication – but for very specific points in the container networking path. Both are critical technologies for running Kubernetes in production. However, in order to deploy rock-solid Kubernetes environments, teams need adequate tools that allow them to customize control and provide a layer of security, like an advanced WAF.  

Service meshes have emerged as the leading pattern for providing east/west traffic management, observability, and security in large-scale Kubernetes environments. You’ll still need Ingress controllers and API gateways, but the primary addition in a service mesh is the sidecar proxy. This provides the traffic management and security in and out of each container. Every time you spin up a new container, you automatically inject a corresponding sidecar proxy to handle traffic. Istio is the leading service mesh solution. It’s an open source framework that adds control plane capabilities to a fleet of side cars. Istio deployments are ideal for companies that operate at significant scale. That said, while some companies have found the overhead of Istio too much, there are emerging services available on the market to offer alternate solutions that are a still lightweight, fast, and intelligent. 

ADM: How can organizations empower developers to build applications without sacrificing governance, visibility and control?

Whiteley: Empowering developers comes down to equipping them with the right tools while providing a manageable degree of autonomy and access. On the flip side you can’t let them run rogue as that opens your organization up to security risks, missed launches, etc. There’s a fine line that’s achievable with the right approach and tools.

Think of when you’re first learning to bowl. If you’re anything like me, every nerve in your body wants to sling as many balls as fast as you can with no regard to the lanes next to you. While that sounds satisfying, it will only lead to chaos. That’s why bowling alley’s created lane bumpers to provide some control/safety over reckless adolescent minds. Just like lane bumpers, organizations need to institute some guardrails on their developers without sacrificing speed and freedom. Constrain too much and developers become fed up and take matters into their own hand. Constrain too little and you’re having to pay for damaging the pinsetter.

Self-service tools that provide developer teams with load balancing and proxy capabilities, application security, richer analytics, role-based access controls, and more not only enable developers to build with as little friction as possible, but also gives IT leaders insights and authority into their workflows. These technologies have come a long where why there are often open source, treated as code, and configurable via a declarative API. This greatly reduces developer friction and, as we discussed, mirrors the simplicity of the public cloud. Done right, we give developers the tools to succeed because they are the engine of digital business – but without taking on more risk than the enterprise can tolerate.

About Rob Whitely

Rob is responsible for marketing at NGINX, now part of F5. He oversees brand, demand generation, digital, web, content, product, and technical marketing for NGINX’s software and services. Rob joins NGINX from Hedvig, where he built the marketing function and helped launch the company from stealth. Prior to that, Rob was at Riverbed, where he held various marketing and operations roles, including GM of Riverbed’s Storage Delivery Business Unit. Before Rob got started in marketing, he spent 10 years in various analyst and executive roles at Forrester Research. When he left in 2012, Rob was responsible for 400 members of the research staff.