Distributed Data and Apps: What About Your Infra?

Technological and operational shifts are required to accommodate the shift to distributed data and apps

You’ve read how modern companies are disrupting their legacy peers by pursuing a data-driven culture …

1. Chick-fil-A’s edge use case allows the company to transform its fast-food restaurants.
2. An industry-first, software-only mobile infrastructure by Rakuten Mobile.
3. Tesla Autopilot functionality getting ever so close to Level 5, with new features and enhancements pushed to vehicles almost bi-weekly.

There are myriad, but the common thread is this: These are software-first companies in their categories. And why are they software-first? They are data-driven.

Their secret sauce is the continuous pursuit to process and extract insights from data to drive their business decisions and operational efficiencies. So if that’s the recipe, why aren’t incumbents doing it?

Distributed Data & Apps, Oh My!

The Trend

Data is becoming increasingly distributed in the enterprise, and for multiple reasons, including:

• Digital transformation of business processes wherever they’re needed—at the branch, the factory, the store … even the car or plane.
• The distribution of workloads and clusters themselves due to modern app architecture and deployment trends, including microservices, containers and multi-cloud.

As a result, distributed apps and data in the enterprise typically require the following:

• Real-time responses.
• Hyper-localization (aka edge).
• Near-zero downtime.
• Intelligent management and security.

To address the above, there are technological and operational shifts required. Those changes can be summarized below:

What if We Have Legacy Infrastructure in Place?

To recap: Apps are changing, driven by critical business needs. ← Read above.

These changes have a significant impact on enterprise architectures in where apps run and how those apps and data are connected, secured and operated. The properties for dealing with the requirements of distributed apps and data are driving the following shifts:

1. WHERE — Multiple Clouds and Edge
   Data gravity for performance reasons, risk reductions, edge AI use cases, etc.
2. HOW — Hybrid Applications
   Containerization of apps and serverless environments, as well as the need to connect/discover legacy apps are driving new architectural, network and security challenges.
3. HOW — Layer 3 (Network) → Layer 7 (App/Proxy/API)
   Connectivity is changing from traditional network-level (IP) access to app-to-app communication using REST/gRPC APIs which are usually delivered over HTTPS (TCP/443).

Apps Have Changed. So Have the Required Capabilities for Networking and Securing Them

• App-2-App Networking: Microservices and containers communicate to each other in addition to the end user and over wider locations, making reliability/performance an even greater consideration.
• Higher-layer Security: App-to-app and microservices architectures require zero-trust at the API layer because that’s how they communicate.
• API-first: Apps are written to be API producers and consumers on day 1. This has fundamental implications on how those APIs are delivered, connected and secured.

To summarize: There are several technical and architectural trends (driven by business needs) around the types of applications, their locality and the means of how they are delivered/accessed. As they converge, it is creating major challenges for traditional networking, security and app services infrastructures.

Why Today’s Infra Is Obsolete for Modern Apps

Legacy Vendors, Limited Approaches = Mixed Results (at Best)

OK, I’ll write what you’re thinking: Your router/switch vendor is obsolete. Your firewall is obsolete. Your load balancer/ADC is obsolete. The operational tools and services to manage this at scale are obsolete.

When it comes to distributed apps and the need to process distributed data, traditional networking and security tools (and their operations) are unsustainable.

Your Load Balancer/ADC Isn’t in Kansas Anymore …

Legacy application delivery controllers or ADC (aka “the modern load balancer”) were designed to efficiently and securely deliver web-based monolithic apps directly to end users with the highest performance possible. They were:

• Optimized for monolithic apps accessed directly by end users, whether SaaS and internet apps or enterprise web apps hosted in a public cloud or private data center.
• Either hardware- or software-based, though recently evolved to software offerings such as NGINX and Avi, which can be deployed in multiple clusters and public clouds.
• Limited in operational simplicity and end-to-end visibility when operating at scale in a distributed environment. They can’t be centrally managed (think SaaS) and don’t provide end-to-end observability across clusters, end-to-end policy management, etc.
• Limited or no API capabilities. While newer software versions such as NGINX may have limited API gateway capabilities, most don’t. And none have API auto-discovery and control. Older ADCs were a combination of hardware or software solutions focused on delivering apps at L4 up to L7 from a traffic management basis. Modern apps have moved beyond this, and so must your app networking and security infra.

Don’t believe me? Let me give you a real-world example to help calibrate where I’m coming from.

Above is an example architecture of an auto manufacturer looking to retrofit its existing and planned electric vehicle (EV) stations to collect HD mapping and process it at scale.

Let’s analyze the workflow and requirements:

1. EVs (taxis, rideshare and/or vehicles agreed to share and process data) drive in and a video sensor picks up on the make, model, VIN, license plate, etc.—any identifiable data.
2. Query a backend database, typically hosted in a private cloud (for security and compliance reasons). Get the necessary credentials to access the vehicle’s local Wi-Fi.
3. Offload the data to the EV station. Process locally what’s needed; the rest is sent to AWS for large-scale mapping analytics.
4. Now add to this requirement that EV owners for business reasons or regulatory reasons would like to lease that EV compute to other automotive companies, law/government enforcement to access the EV stations in a secure, multi-tenanted and auditable way.
5. Now multiply this need across 25,000 EV stations!

The Oh Sh*t! Moment — Real-World Example

There were multiple options and proposals put forward, insourced through various teams or outsourced through system integrators. Below is an example of one of those proposals:

Let’s Summarize:

• Infrastructure — 1 x public cloud vendor, 2 x private DCs, 5 x Software/Hardware Vendors (router/SD-WAN, firewall, load balancer, API gateway) across all locations (public, private and edge).
• Application Management — 1 x vendor with inbuilt tooling for LCM of apps
• Operational Model — Different tooling across environments (public, private and edge), different software/management systems for each vendor and service.
• Configuration Models — Different configurations for services and vendors to achieve a holistic outcome.
• Security/Auditing — Security across vertical software/vendor layers; along with horizontal visibility and management challenges (i.e. many locations).

I’ll let someone else make the TCO on why the above is a nightmare (or this can be a topic for another post), but let’s assume for a moment you find a business model that actually works in your favor because you have an army of lawyers to make sure the vendors (the ones with deep pockets) bear the burden. But is this really a positive outcome for your business, employees or customers?

Modern App Networking + Security for the Modern Enterprise

A new generation of infrastructure platform (aka “modern”) is what’s needed for networking and securing modern apps, and it must be more app- and API-centric than your traditional ADCs. This is similar to how ADCs were an evolution of vanilla L4 load balancers over a decade ago.

Here is a potential list of things to look for as you begin researching a modern infra stack and service for app networking and security:

• Integrated stack for Layer 3-7 networking and security — a high-performance service that can be used to deliver secure app-2-app connectivity.
• SaaS-first operations — everything from deploying a stack (site) to full lifecycle management of the software and its services. Think configuring a load balancer or reverse-proxy within minutes across 10,000 locations. Or a single pane of glass for your DevOps, NetOps, Dev and SecOps teams.
• Intent-based policy — a single expression of intent across all layers starting from Layer 3 → 7 → API. A user can configure (and enforce) network connectivity, network firewall, forward proxy, load balancing, service policies, WAF, API Gateway (AuthZ/AuthZ, API service-2-service policies), etc.
• End-to-end and bottoms-up observability — a single pane of glass for all teams to view metrics, logs and alerts from networking, firewalls, load balancers, API Gateway, etc.

Here’s another example:

Finishing Up

To circle back, networking and security for modern apps requires a new kind of thinking … aka modern (or cloud-native) infrastructure. As apps become more distributed, your architecture, infrastructure and operations teams must adapt … and that includes modern app networking and security.

This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America