The way in which communication is handled within a cloud native application has changed over the past few years. Kubernetes has become the de facto platform infrastructure, and inter-service communication is now handled via a service mesh. This session will explore how to integrate the open source Ambassador Kubernetes API gateway and the Consul Connect service mesh into your Java apps.
Learn about Kubernetes ingress and inter-service communication
Understand the tradeoffs of using different technologies to implement cloud native communication
Explore how these technologies integrate well – or not – with new and existing Java applications
Hear about lessons learned in production, at 3 a.m., with lots of coffee
2. tl;dr
▪ Moving to cloud and containers (cloud native) brings benefits and challenges
– Ingress and service-to-service communications change
▪ API gateway handles ingress traffic: you don’t control the client
▪ Service mesh handles service-to-service comms: you influence the client
▪ You can implement new comms 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
Java Champion, avid reader, conference tourist
@danielbryantuk
4. Motivations: Acceleration
▪ 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)
11. 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
▪ You don’t control the client
17. “Service mesh”, you say?
https://twitter.com/cesarTronLozai/status/1175327326218915840
https://twitter.com/wm/status/1173350339946274816
18. 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
▪ You generally control the client (or at least can influence this...)
27. Typical Problems
▪ No clear use case
▪ Not working with the ops team…
▪ Turtles all the way down
▪ NFR-handling implemented
multiple places in stack
28. 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… :-)
31. Conclusion
▪ Moving to cloud and containers (cloud native) brings benefits and challenges
– Ingress and service-to-service communications change
▪ API gateway handles ingress traffic: you don’t control the client
▪ Service mesh handles service-to-service comms: you influence the client
▪ You can implement new comms via two patterns
– Outside-in, using an API gateway
– Balkanization, using a service mesh on a segment of services