Apps Are Becoming Distributed, What about Your Infra?

Introduction

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 them to transform their fast food restaurants; throwing jet fuel on top of their already impressive growth
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 a myriad of examples, 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 getting 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 micro-services, 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, as noted above, have a significant impact to 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 + Securing Them

• App-2-App Networking — micro-services 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 micro-services 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 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 together, 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 pubic cloud or private DC.
• Either hardware- or software-based, though recently evolved to software offerings like 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), don’t provide end-to-end observability across clusters, end-to-end policy management, etc.
• Limited or no API capabilities — while newer software versions may have limited API gateway capabilities, most don’t. And none have API auto-discovery & control. Your older ADC was a combination of hardware or software solutions focused on delivering apps at L4 up to L7 from a traffic mgmt 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 their existing and planned EV stations to collect HD mapping and process it at scale.

Let’s analyze the workflow and requirements:

1. EVs (taxis, ride share, and/or vehicles agreed to share & process data) drives in and a video sensor picks up on make, model, VIN, License Plate, etc. (any identifiable data).
2. Query a backend DB, typically hosted in a private cloud (for security and compliance reasons). Get the necessary credentials to access the vehicle’s local WiFi.
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, in-sourced 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 Edges).
• Application Mgmt — 1 x Vendor with inbuilt tooling for LCM of Apps
• Operational Model — different tooling across environments (Public, Private and Edges), different software/management systems for each vendor & 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?

Teams Collide — a Business Divided against Itself Cannot Stand

First things first — if you haven’t already watched Seinfeld’s The Pool Guy episode in Season 5 please stop reading this and watch, I’ll wait.

Welcome back. Now:

• Ask your developer to build a service/app using the above infrastructure.
• Ask your NetOps & DevOps teams to operate the above infrastructure on a continual basis (Day 2) — none of that POC/Day 1 junk to pass an annual KPI to meet some exec’s bonus plan.
• Ask your SecOps team to provide 100% visibility & audibility.

The Painful Reality

• Increased Friction Impacting Day to Day — the evolution of how teams react to this traditional enterprise architecture will impact their ability to meet the day to day operational needs of their business.

• Day 2 Operations — your business will have a rough time sustaining itself if it’s too busy running distributed infrastructure with varying tooling and operational models across NetOps, DevOps, and SecOps teams.

To summarize — traditional networking + security architecture, software vendors, tooling and operational models are challenging when a business requires distributed apps and data to be processed.

A new architecture, powered by a SaaS-first operational model while catering to the self-service nature of the different tooling needs of DevOps, NetOps, Dev and SecOps teams, is existential for a modern business to succeed.

Modern App Networking + Security for the Modern Enterprise

A new generation of infrastructure platform is 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.

At Volterra, we went back to the drawing board and identified 4 tenants that were needed to address modern app delivery. We put the following blueprint together:

• Integrated Layer 3-7 stack for network & security services — a high-performance network and security 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.

VoltMesh

An integrated Layer 3–7 stack for network & security services

Ok, I’m not here to shill — we have people for that. But I think we’ve built something nerd-worthy; and thus requires some explaining.

To summarize VoltMesh’s software stack: 

• Layer 3 (Routing, Firewall) — we took hardened open source projects. Tungsten Fabric (formally known as Contrail SDN) is used by Tier 1 Telcos around the world for delivering key Mobile Packet Core NFV functions. It has a centralized control plane with a distributed data plane for network security and firewalls. We’ve taken FRRouting (Free Range Routing) for a rich set of routing protocols needed for traditional CE route exchange. We’ve added additional functionality to be a SaaS-based software stack; zero-touch provisioning (ZTP) and portability across most environments (Public Clouds, Private DCs, Edge Devices, etc.). 
   
• Layer 7 (load balancer, proxy, WAF, API gateway, app security) — we built off the great work of the Envoy project since it’s highly performant and lends itself to production needs with its modularity and dynamic configuration updates. What we added in addition to the Envoy proxy was: API Gateway, Policy Agent for L7/L4 policy enforcement from our SaaS, WAF, enhanced metrics (over 20+ from standard 5 Envoy collects), optimized the hell out of the data path with native DPDK, and added customization of the data path with native v8 Chrome Javascript support.

SaaS-first Approach to Modern App Networking + Security

VoltConsole

A kick-ass stack doesn’t mean much if Day 2 is just as complicated for your DevOps, NetOps, and SecOps teams. This is where our SaaS-based management portal called VoltConsole comes in.

Let’s summarize:

• Full end-to-end observability — a single pane of glass for ALL teams to view metrics logs and alerts. From network metrics and statistics, load balancer/proxy stats per VIP, to the system learning applications’ API service to service flows and providing service-mesh graphs and recommended security policies and alerts to anomalous behaviors.
• Customer VoltMesh sites — each instance of VoltMesh provisioned via ZTP and admitted by the Enterprise tenant (regardless of environment) connects to the closest regional edges.
• Self-service, multi-tenancy, and intent-driven — once a site is registered everything is SaaS and magical. An optimized UX on VoltConsole for DevOps, Netops, SecOps and Devs kicks in. Whether it’s the NetOps team performing single site or mass site network configuration changes, to a DevOps admin configuring a load balancer, ingress & egress K8s gateways across various environments or a SecOps admin enabling enterprise security policies at the network and app level, i.e. network firewall filter.

The Oh Yeah! Moment — Real-World Example

Continuing from our real-world example, the following solution was proposed:

VoltMesh

• Public cloud/private DCs — VoltMesh’s integrated stack to provide the networking, firewall, load balancing, proxy, service discovery to legacy apps, and micro-services with K8s ingress gateway.
• EV locations — VoltMesh’s integrated stack to provide network, load balancing, proxy, ingress K8s and security needed.

VoltConsole

• A SaaS where each team can self-service their needs across the entire enterprise with NetOps, DevOps, SecOps and Dev persona tailored UXs.
• Full life-cycle management of their infrastructure and apps allowing for highly optimized truck rollouts. Visualize bringing up a site in minutes and it instantly gets networking, load-balancing, API Gateway, and advanced security policies applied.
• Single policy across all delivery layers.
• Full auditing capabilities.
• Fully multi-tenanted (for 3rd party sharing of the same infrastructure).
• API access to all VoltConsole metrics and configurations.
• 3rd-party integrations to alerting (i.e. Slack, PagerDuty), GitHub/GitLabs for GitOps driven models, log ins/metrics (Datadog, etc.)

The New Reality 

• Self-serve UX — a SaaS-driven application networking + security model and the ability to control how each role interacts with your infrastructure reduces the friction across your teams caused by the new architecture needed by modern apps.
• Day 2 Operations — with a SaaS-driven operational model your operations teams can focus less on the infrastructure, and more on business continuity, enhanced agility, and increasing the bottom line.

Why Volterra

Networking and security for modern apps requires a new kind of thinking. As apps become more distributed (for the right business reasons!), your architecture, infrastructure, and operations teams must adapt.

Here at Volterra, we’ve designed a comprehensive solution for networking and securing modern apps via a single SaaS-based service, VoltMesh. We feel it addresses the majority of new requirements for app-2-app networking and security. Below is a table of what we address when compared to traditional point load balancers and API gateways:

If you’re interested in seeing if these concepts work for your modern app environment…you can.

Volterra currently offers a freemium service of VoltMesh (including its unique globally-distributed load balancer/ingress-egress gateway + API gateway + API auto-discovery and control).

Check it out for yourself at volterra.io