The nature of containerized, cloud-native applications is rapidly advancing with a fundamentally different architecture that will rely on service meshes with smarter proxies, traffic management, and enhanced observability for cooperating microservices, serverless functions, and complex workflows. In this session we will highlight the features that characterize this architectural transformation in the Docker cloud-native ecosystem.

1. Tony Pujals
Sr. Developer Advocate
AWS Container Services
Docker,
Microservices, &
the Service Mesh

2. ● Developer Advocate @AWS
○ Container Services [ ECS | EKS | Fargate ]
● Docker Captain & Certified Docker Associate
○ Organizer/presenter for Docker Mountain View meetup
○ Currently authoring a Docker course for UC Davis /
Coursera
● Go and Node.js programmer
○ Generally fanatical about containers, microservices,
cloud computing
● Live in Mountain View, California
About me
@tonypujals

3. v
of object / actor / component / service
abstraction & innovation for effective, reliable
message passing
Over 50 years

4. Simula
● Objects
● Message passing
● Inspires Smalltalk
1960s

5. Smalltalk
● Everything is an object!
● Objects only communicate
through messages
1970s

6. C++
● Popularizes object-oriented
programming
Erlang
● Everything is an Actor!
● Distributed processes
● Asynchronous message
passing
● Let it crash!
1980s

7. Distributed object
models
● DCOM
● CORBA
● Java RMI
1990s

8. Service Oriented Architecture
(SOA)
● Simple Object Access
Protocol (SOAP)
● Over Web standards
REST APIs
● URI-based resources ("objects")
● Standard HTTP methods for
messages
2000s

9. The essence of Object Oriented Programming (OOP)
● Has been a significant, fundamental programming abstraction for half
a century
● Involves invoking some function or procedure through (some form of)
message passing to an object
Objects and Messages

10. Technique for sending a message to an object (actor, process)
● synchronously or asynchronously
● directly or indirectly
● and relying on the process and supporting infrastructure to route
and deliver the message to invoke target code
Message Passing
Paraphrased from Wikipedia: https://en.wikipedia.org/wiki/Message_passing

11. An enduring theme for the past fifty or so years has
been innovation around ways to program the
operation of a system through objects and
messages, while keeping communication details
out of application code.

12. The point of all this is that as programmers we want
to focus on the objects of our problem space and
the information they communicate through
messages.

13. But we don't want to have to write the code (or be
tied to a specific language, library, or runtime) to
manage low level communication details,
communication policies, visibility, and resiliency of
the application.

14. ● Characterizes an architectural style meant to contrast monolithic
architecture
○ Physical units of deployment are partitioned along functional
boundaries
○ Each unit focused on a smaller, logically related problem space
● Independent application components provide flexibility for separate
○ development & evolution
○ deployment
○ scale
Microservices
Independent application components

15. The ability to package and repeatedly deploy our
microservices anywhere and have confidence that
they will work as expected in every environment as
when we developed and tested them is a natural fit
for container technology.

16. ● Are well-suited as the fundamental object in distributed systems1
● Provide isolation boundaries
○ the way objects protect privacy of internals through encapsulation
● OOP popularized building applications from collections of modular
software components
○ Docker provides an industry-standard, repeatable mechanism for
packaging and distributing these components (and all of their
dependencies) in a universal binary format
● Containers make large-scale microservice adoption pragmatic
Containers
1
"Design patterns for container-based distributed systems," Brendan Burns and David Oppenheimer,
Google, 2016. Brendan Burns is a co-founder of the Kubernetes project.
https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
Abstracting the node

17. How do I run and manage all my containerized services across a
fleet of machines?
● Automated provisioning of containers
● Scheduling of workloads to appropriate compute resources
● Service discovery so services can find and communicate with each
other
● Load balancing
Orchestration
Abstracting the infrastructure

18. ● When I need end-to-end visibility and insight to troubleshoot?
● When I need to enforce various types of policies?
● When I need to shift traffic for updates?
microservices + Docker + Kubernetes
What happens when I deploy larger applications...
● Challenges remain
○ Traffic management
○ Service identity and security
○ Policy enforcement
○ Telemetry

19. ● Dedicated, configurable infrastructure layer for service-to-service
communication management
● Moves burden of managing highly dynamic service environment and
complex topology out of application code
● Think of it as a really smart network layer
Service Mesh
Intelligent runtime for distributed applications

20. You can think of it as a really smart network layer. In
reality, the service mesh consists of a number of
active agents that sit between the network and our
application services that makes it appear really
smart.

21. This is done is with a rich set of adapters that create
configurations pushed throughout the cluster and
that manage and monitor traffic through the use of
lightweight proxies injected as sidecars into our
service pods. These are used to enforce policies and
to complete the feedback loop of the system.

22. It's important to note that a service mesh doesn't
actually introduce new functionality; rather it shifts
that functionality to its own layer, just like the
orchestration layer.

23. In a monolithic app there is no need for a mesh since
communication routes are very simple. But as we
move to more and more microservices, there is
something of a combinatorial explosion in complexity
in managing all of the distributed pieces.

24. This is especially apparent in a dynamic, HA
environment, where stateless services are
ephemeral, are started and restarted frequently, and
managing and tracing traffic flow through all of the
hops becomes extremely challenging.

25. https://istio.io/
Istio
An open platform to connect, manage, and secure microservices

26. Istio, a service mesh designed to address these
challenges, reached 0.8 LTS two weeks ago
● Intelligent routing and load balancing
○ Traffic control with dynamic route configuration
○ A/B tests, canaries, gradual red/black deployments
● Application resilience
○ Independent of language
● Fleet-wide policy enforcement
○ Pluggable for various backends, such as authorization, quotas
● In-depth telemetry
○ End-to-end visibility of traffic, distributed tracing
○ Pluggable for various backends, such as logging and metrics

27. Demo
https://github.com/subfuzion/istio-test-drive

28. So, is 2018 indeed the "Year of the Service Mesh"? I
think it's still too early to call it.

29. For the benefits you can get today if you're using
Kubernetes, you should definitely consider gaining
exposure now.

30. We don't have any 1.0 service mesh implementations
yet. Although quite promising, Istio made pretty big
changes as it evolved to 0.8 two weeks ago.

31. There needs to be a bit more stability and education
before we see a huge groundswell of adoption.

32. We still have half a year remaining to see major cloud
provider support in terms of seamless integration
into managed environments and deep mixer support
into their rich observability facilities.

33. The future for service mesh looks quite promising.
Stay tuned, and for the real benefits you can get
today, particularly if you're using Kubernetes,
definitely consider gaining exposure now.

34. Repo for the demo
https://github.com/subfuzion/istio-test-drive
Share your thoughts -- chat with me!
Twitter (open to private DMs)
https://twitter.com/tonypujals (@tonypujals)
Email
pujals@amazon.com
Thank You
@tonypujals