API Gateways and Service Meshes:
Opening the Door to Application Modernisation
Daniel Bryant
Product Architect, Datawire

tl;dr
▪ App modernisation is often about incrementally decoupling apps from infra
– An API gateway and service mesh can help with this migration
▪ API gateway handles ingress traffic
▪ Service mesh handles service-to-service comms
▪ You can decouple apps via two patterns
– Outside-in, using an API gateway
– Bulkanization, using a service mesh on a segment of services

Product Architect at Datawire
Freelance Tech Consultant and Writer
@danielbryantuk

Why App Modernisation?
▪ Lead time
▪ Deployment frequency
▪ Mean time to restore (MTTR)
▪ Change fail percentage
CIOs: “We want to go faster, and not fall over
(and if it breaks we want to detect and fix it fast)”

App Modernisation
▪ Refactoring, repurposing, or consolidation of “heritage” software to align it
more closely with current business needs
▪ Decoupling applications from infrastructure
– Moving workloads to take advantage of cloud-based (AI) services
– Retiring old systems (saving infra/hosting costs)
– Reducing operational burden (e.g. toil and security patching)

App Modernisation: What’s Involved?
▪ Microservices!
▪ Cloud!
▪ Containers!
▪ Kubernetes!

App modernisation: Not an overnight thing

Decoupling Infrastructure Strategies
▪ Bring the cloud hardware to you:
– AWS Outposts; custom hardware that is fully managed by AWS.
▪ Bring the cloud experience to you:
– Azure Stack; run hybrid applications across the Azure cloud and their own
on-premises hardware.

Decoupling Infrastructure Strategies
▪ Bring the cloud software to you:
– Google Anthos; software abstraction (VMware -> k8s/GKE, Istio, Stackdriver)
▪ Bring the cloud traffic management to you
– API gateway + service mesh; dynamically route traffic across any
infrastructure (which is routable via the network)

Software-focusedHardware-focused
Small commitmentBig commitment
Complete access to
cloud primitives
Small subset of
abstractions
Decoupling Infrastructure Strategies

Outside-in migration: API gateway

Outside-in migration: API gateway

Outside-in migration: API gateway

API Gateway: Edge proxy, ingress, ADC...
▪ Exposes internal services to end-users (often via multiple domains)
▪ Encapsulates backends: k8s, VMs, bare metal etc
▪ Focused on managing ingress (“north-south”) traffic
▪ Engineer-driven product release (often) happens here
▪ You don’t control the client

API Gateway: Self-Serve Routing & Security
▪ Self-serve routing
– Traffic routing, splitting, and shaping (to dynamic backends)
– Release functionality (A/B, canary, dark launch etc)
▪ Security
– End-user authentication/authorization
– TLS termination, rate limiting, WAF, DDoS protection, etc

API Gateway Options

Ambassador config

Bulkanization: service-to-service comms

“Service mesh”, you say?
https://twitter.com/cesarTronLozai/status/1175327326218915840
https://twitter.com/wm/status/1173350339946274816

Service Mesh: Proxy mesh, Fabric model...
▪ Exposes internal services to internal consumers
▪ Encapsulates service infra: across k8s, VMs, bare metal etc
▪ Dynamic routing for service-to-service (“east-west”) traffic
▪ Ops apply “sane defaults” and top-level platform monitoring
▪ You generally control the client (or at least can influence this...)

Service mesh architecture: Envoy

Service Mesh: Three Pillars
▪ Observability
– “Golden signals”: latency, errors, traffic, saturation (USE, RED)
– Both global and service-to-service
▪ Reliability
– Abstracting health checks, retries, circuit breakers etc.
– Providing sane default to protect system
▪ Security
– Authn/z propagation, mTLS, ACLs, network segmentation

Service Mesh: Three Pillars
▪ Observability
– “Golden signals”: latency, errors, traffic, saturation (USE, RED)
– Both global and service-to-service
▪ Reliability
– Abstracting health checks, retries, circuit breakers etc.
– Providing sane default to protect system
▪ Security
– Authn/z propagation, mTLS, ACLs, network segmentation
https://www.infoq.com/podcasts/

Service Mesh Options

Consul config

Migration tactics
▪ Outside in
– Start with a gateway
– Identify a endpoint/service
▪ Balkanization
– Start with a service mesh
– Identify a service segment
▪ Easy install
▪ Conceptually easy to understand
▪ Less intrusive for all platforms
▪ (Potentially) higher blast radius
▪ Less new functionality
▪ Potentially high value functionality
▪ “Easy” to deploy in Kubernetes
▪ Can support multi-cluster (beta)
▪ Operationally complex
▪ (Potentially) challenging to unwind
▪ Expectation management… :-)

bit.ly/2mr58C1
Learn more

Explore in browser
https://instruqt.com/hashicorp/tracks/sock-shop-tutorial
Hat tip to:
Todd Radel, Nic Jackson & Eric Veld!

Conclusion
▪ App modernisation is often about decoupling apps from infra
– One way to do this incrementally is via an API gateway and service mesh
▪ API gateway handles ingress traffic
▪ Service mesh handles service-to-service comms
▪ You can decouple apps via two patterns
– Outside-in, using an API gateway
– Bulkanization, using a service mesh

References
▪ Context:
– https://www.infoq.com/articles/api-gateway-service-mesh-app-modernisation/
▪ Reference:
– https://www.getambassador.io/user-guide/consul-connect-ambassador/
– https://www.getambassador.io/user-guide/consul/
– https://www.consul.io/docs/platform/k8s/ambassador.html
– https://www.hashicorp.com/blog/hashicorp-consul-supports-microsoft-s-new-service-mesh-framework
Experiment in an Instruqt sandbox: https://instruqt.com/hashicorp/tracks/sock-shop-tutorial
Code examples: https://github.com/emojify-app

Copyright © 2019 HashiCorp
Thanks!
@danielbryantuk