JavaLand 2019, Brühl: Talk by Mario-Leander Reimer (@LeanderReimer, Principal Software Architect at QAware)
=== Please download slides if blurred! ===
Abstract:
Building microservice architectures is complex. Modern platforms such as Kubernetes address a lot of the complexity, they handle resource isolation and utilization, networking and deployments nicely. But still, handling the remaining complexities, like circuit breaking, rate limiting, observability or transport security, is usually left up to the development teams to implement. Using open source components to address these challenges is an option, but this quickly leads to excessive library bloat and suddenly your microservices are not quite so micro anymore.
Now, all this might seem acceptable if you are on a single, consistent development stack like Java EE or Spring Boot. But tackling these complexities becomes even more challenging if you are dealing with multiple stacks and multiple frameworks. Or you might even deal with legacy applications that you can't modify to retrofit these requirements.
Istio to the rescue. It is a so called service mesh that addresses many of the cross-cutting communication concerns in a microservice architecture. Think of Istio as AOP (aspect oriented programming) for microservice communication. Instead of implementing everything directly within your services, Istio transparently injects and decorates the desired concerns into the individual communication channels.
This session provides an overview of the Istio system and how it addresses the inherent complexities in microservice architectures. We will briefly discuss the conceptual architecture and the main building blocks of Istio. Then we will dive right into several showcases that are deployed on a Kubernetes cluster to demonstrate the different traffic management features, as well as diagnosability and security.
6. Essential Cloud-native Design Principles.
6
Design for Distribution: Containers; microservices; API driven development.
Design for Configuration: One image, multiple environments.
Design for Resiliency: Fault-tolerant and self-healing.
Design for Elasticity: Scales dynamically and reacts to stimuli.
Design for Delivery: Short roundtrips and automated provisioning.
Design for Performance: Responsive; concurrent; resource efficient.
Design for Automation: Automated Dev & Ops tasks.
Design for Diagnosability: Cluster-wide logs, metrics and traces.
Design for Security: Secure Endpoints, API-Gateways, E2E-Encryption
10. A polyglot microservice architecture suffers from severe
library bloat and bad maintainability in the long run.
10
Microservices mit Java und Go
Johannes Weigend,
Rotunde, 15:00 – 15:40
11. Istio is like AOP, but for
microservice communication.
13. Pods are the smallest unit of compute in
Kubernetes
Labels are key/value pairs used to identify
Kubernetes resources
Replica Sets ensure that the desired
number of pod replicas are running
Deployments are an abstraction used to
declare and update pods, RCs, …
Services are an abstraction for a logical
collection of pods providing DNS name
Ingress routes traffic from outside the
cluster to services and ports based on URL
patterns and host
Kubernetes Glossary.
13
16. 16
Envoy: Sidecar proxy per microservice that handles inbound/outbound traffic within each Pod. Extended
version of Envoy project.
Gateway: Inbound gateway / ingress. Nothing more than a managed Envoy.
Mixer: Policy / precondition checks and telemetry. Highly scalable.
Envoy caches policy checks within the sidecar (level 1) and within envoy instances (level 2), buffers
telemetry data locally and centrally, and can be run in multiple instances.
Mixer includes a flexible plugin model.
https://istio.io/blog/2017/mixer-spof-myth.html
Pilot: Pilot converts high level routing rules that control traffic behavior into Envoy-specific configurations, and
propagates them to the sidecars at runtime.
Watches services and transforms this information in a canonical platform-agnostic model (abstracting away
from k8s, Nomad, Consul etc).
The envoy configuration is then derived from this canonical model. Exposes the Rules API to add traffic
management rules.
Citadel: CA for service-to-service authx and encryption.
Certs are delivered as a secret volume mount. Workload identity is provided in SPIFFE format.
https://istio.io/docs/concepts/security/mutual-tls.html
18. Gateway configures a load balancer for
HTTP/TCP traffic, enables ingress traffic into the
service mesh
Virtual Service defines the rules that control
how requests for a service are routed within
the service mesh
Destination Rule configures the set of policies
to be applied to a request after VirtualService
routing has occurred
ServiceVersion aka Subset allows to select a
subset of pods based on labels
Service Entry enables requests to services
outside of the service mesh
Istio Glossary.
18
26. Istio has built-in support for service mesh diagnosability.
26
Diagnosability
Triangle
Metrics
LogsTracesService Graph
27. Not all Istio features are marked Stable yet, but Beta can
already be used in Production.
27
Istio v1.0.6 is deemed production ready.
Core: 3 Stable, 2 Deprecated, 5 Beta, 4 Alpha
Traffic Management: 6 Stable, 4 Alpha
Security and Policy Enforcement: 5 Stable, 2 Beta, 9 Alpha
Telemetry: 6 Stable, 5 Beta
The Service Mesh War has started.
Linkerd and Conduit
Consul Connect
See https://istio.io/about/feature-stages/
28. QAware 28
Article by Emily Jiang, IBM
https://www.eclipse.org/community/eclipse_newsletter/2018/september/MicroProfile_istio.php
29. QAware 29
Drop by our booth, have a chat and grab some swag!
Bare Metal K8S Cluster
- Cloud Native Java EE
- Istio Service Mesh Demo
- Diagnosability
5 Node Raspi Swarm
- Cloud Native Go Demo