This document discusses how an API gateway and service mesh can help with incrementally decoupling applications from infrastructure during application modernization. An API gateway handles ingress traffic and exposes internal services to end users, while a service mesh handles communication between services and provides observability, reliability, and security at the service layer. There are two common patterns for decoupling applications: using an API gateway in an outside-in migration approach or using a service mesh within a segmented set of services in a balkanization approach.

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

2. 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
– Balkanization, using a service mesh on a segment of services

3. Product Architect at Datawire
Freelance Tech Consultant and Writer
@danielbryantuk

4. 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)”

5. 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)

6. App Modernisation
▪ Microservices!
▪ Cloud!
▪ Containers!
▪ Kubernetes!

7. App modernisation: Not an overnight thing

8. Decoupling Infrastructure Strategies
▪ Bring the cloud hardware to you
▪ Bring the cloud experience to you
▪ Bring the cloud software to you
▪ Bring the cloud traffic management to you

9. 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 via on-
premises hardware.

10. 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)

11. Software-focusedHardware-focused
Small commitmentBig commitment
Complete access to
cloud primitives
Reliance on abstractions

12. Decoupling Infrastructure Strategies
▪ Bring the cloud hardware to you
▪ Bring the cloud experience to you
▪ Bring the cloud software to you
▪ Bring the cloud traffic management to you

13. Outside-in migration: API gateway

14. Outside-in migration: API gateway

15. Outside-in migration: API gateway

16. 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

17. https://bit.ly/2NnUXt9
https://www.getambassador.io/resources/challenges-api-gateway-kubernetes

18. 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

19. 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

20. API Gateway Options

21. Ambassador config

22. Balkanization: service-to-service comms

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

24. 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...)

26. Service mesh architecture: Envoy Proxy

27. 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

28. 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/

29. Service Mesh Options

30. Consul config

31. Migration tactics: Outside-in

32. Balkanization: service-to-service comms

33. Migration tactics
▪ Outside in
– Start with an API 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 higher value functionality
▪ “Easy” to deploy in Kubernetes
▪ Can support multicluster (beta)
▪ Operationally complex
▪ (Potentially) challenging to unwind
▪ Expectation management… :-)

34. bit.ly/2mr58C1
Learn more

35. Explore in your browser
https://instruqt.com/hashicorp/tracks/sock-shop-tutorial

36. Conclusion
▪ App modernisation is often about decoupling apps from infra
– One way to do this 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
– Balkanization, using a service mesh

37. 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

38. Copyright © 2019 HashiCorp
Thanks!
@danielbryantuk