Distributed applications like microservices shift some of their complexities into the interaction of services. Such a service mesh, which can have hundreds of runtime instances, is very difficult to manage. You will be concerned with some of the following questions: Which service will be requested by which other services in which version and how often depending on the request content? How can you test the interaction and how can you replace single services with new ones?
These and other questions will be discussed in this session. Tools to make your live easier with a service mesh will also be introduced.
Service Mesh - kilometer 30 in a microservice marathon
1. Service Mesh
kilometer 30
in a
microservice marathon
Michael Hofmann
Hofmann IT-Consulting
info@hofmann-itconsulting.de
2. marathon at km 30 ...
●
fat burning, extreme fatigue
●
decision about finishing the marathon
●
proper training
●
spaghetti party, eat and drink during the run
●
mental preparation
how to prevent?
„the man with the hammer“
3. km 30 at microservices?
●
microservice projects start small (greenfield, splitting a monolith)
●
at the beginning without version problems
●
multiple versions parallel in production
●
number of services increases
●
establishing a service chain
●
how to test the interaction over different versions?
●
creeping loss of survey: who with whom in which version?
5. what else at km 30?
●
complexity lies between services
●
fallacies of distributed systems
●
who cares about?
– container system?
– resilience frameworks?
should be transparent to the application!
The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.
6. where to place resilience?
●
frameworks (Hystrix, Failsafe, MicroProfile Fault Tolerance)
●
problems:
– suitable pattern recognized in production (another deployment!)
– framework dependant on progamming language
– mix of framework versions scattered over all services
– dependencies to other frameworks (service call → load balancing → service registry)
– service registry usable for other services? multiple service registries? (tight coupling
of service and infrastructure components!)
– Learning curve for different frameworks
●
alternative: Service Mesh tool
7. Service Mesh
„The term service mesh is used to describe the network of
microservices that make up such application and the interactions
between them.“ (istio.io)
you cannot manage a Service Mesh (big ball of mud) without
tooling!
requirements:
●
manage calls on layer 7 (application layer)
●
resilience, routing, security and telemetry
●
decentralized & transparent for services (implementation independent)
9. Service Mesh tool when?
●
high number of different services
●
invocation depth of services > 1
●
wish of uniform implementation of resilience
●
contemporary testing strategies: test in production (necessary?)
13. Envoy Proxy
design goal: „The network should be transparent to applications. When
network and application problems do occur it should be easy to
determine the source of the problem.“
●
container deployed together with service
●
„Man-in-the-Middle“
●
as a sidecar transparent for service
●
service discovery, load balancing, resilience, health checks, metrics,
fault injection
●
communication with Mixer (telemetry) und Pilot (policies)
17. automatic sidecar injection
heart of Istio:
automatic provisioning of sidecar (Envoy Proxy)
●
modification of ip-tables in pod
●
health checks through sidecar to service
●
restart pod if any of the two containers crashed
kubectl label
namespace my-namespace
istio-injection=enabled
helm install
install/kubernetes/helm/istio
--name istio --namespace
istio-system
28. recommendations
●
training for marathon: start early in project to use tool for
Service Mesh
●
integrate into CI/CD (zero downtime deployments!)
●
place resilience preferred into sidecar
●
integrate tracing/monitoring into existing infrastructure
●
establish new test strategy