O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
A Scribd passará a dirigir o SlideShare em 1 de dezembro de 2020A partir desta data, a Scribd passará a gerenciar sua conta do SlideShare e qualquer conteúdo que você possa ter na plataforma. Além disso, serão aplicados os Termos gerais de uso e a Política de Privacidade da Scribd. Se prefira sair da plataforma, por favor, encerre sua conta do SlideShare. Saiba mais.
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
marathon at km 30 ...
fat burning, extreme fatigue
decision about finishing the marathon
spaghetti party, eat and drink during the run
how to prevent?
„the man with the hammer“
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?
(Werner Vogels, CTO Amazon)
source: Adrian Cockcroft (Netflix) / Martin Fowler
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.
where to place resilience?
frameworks (Hystrix, Failsafe, MicroProfile Fault Tolerance)
– 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
„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
manage calls on layer 7 (application layer)
resilience, routing, security and telemetry
decentralized & transparent for services (implementation independent)
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?)
Service Mesh tools
comparison of Istio & Linkerd: https://abhishek-tiwari.com/a-sidecar-for-your-service-mesh/
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
as a sidecar transparent for service
service discovery, load balancing, resilience, health checks, metrics,
communication with Mixer (telemetry) und Pilot (policies)
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
--name istio --namespace
little „Big Ball of Mud“
training for marathon: start early in project to use tool for
integrate into CI/CD (zero downtime deployments!)
place resilience preferred into sidecar
integrate tracing/monitoring into existing infrastructure
establish new test strategy