See the full presentation here: https://www.lightbend.com/blog/digital-transformation-kubernetes-containers-microservices In this talk by David Ogren, Principal Enterprise Architect at Lightbend, we draw from experiences helping our clients successfully create, migrate to, and manage cloud-native system architectures.

1. Microservices, Kubernetes
And Application Modernization
Using Reactive Microservices to be Successful
Moving to Modern Environments
David Ogren, Enterprise Architect

2. Agenda
• Why Modernization
• Microservices
• Containers
• Kubernetes
• Modernization Approaches
• Reactive, Lightbend, and Reactive Launch
• Q&A

3. Why Application Modernization?

4. Application Modernization Buzzwords
• Digital Transformation
• Continuous Delivery
• “Cloud Native Systems”

5. Characteristics of a Monolith
• Deployed as a unit
• “Big Bang” releases – long and carefully coordinated
• Single shared database
• Communicate with synchronous method calls
• Deep coupling
• Batch

6. Technical Reasons for Modernization
• Scaling a monolith is hard
– Concurrency
• How to deal with data science?
• Codebase becomes large and hard to
understand – “fun” with merge conflicts
• Teams become large and hard to coordinate
• Moving to cloud is hard
Inventory
Shopping
Cart
Shipping
Payment
Personalization

7. Business Reasons for Modernization
• Performance
• Serious failures in one component can bring
down the whole application
• Have to buy infrastructure for worst case
• Deep coupling leads to inflexibility
Inventory
Shopping
Cart
Shipping
Payment
Personalization

8. Business Value
• Revenue
• Cost Savings
• Reduced Risk
• (Compliance)

9. Business Value
Technical
Goals
Business
Goals
Business
Value

10. Not explicitly tying technical
goals to business goals
Pitfall #1
(Increased revenue, cost savings, reduced risk)

11. Framing Project Goals
• Digital Transformation
– New Revenue
• Continuous Delivery
– Reduce Development Costs/Development Risks
• Move to the “Cloud”
– Reduce Operational Costs
– Be more elastic

12. Why Microservices?

13. Small autonomous services that work
together, modeled around a business
domain.
What is a Microservice?
Sam Newman
Author of Building Microservices

14. • Single Responsibility (do one thing …)
Duck Typing a Microservice?

15. There are only two hard problems in distributed systems:
• 2. Exactly-once delivery
• 1. Guaranteed order of messages
• 2. Exactly-once delivery
—Mathias Verraes?
Distributed Systems

16. Amdahl’s Law & Gunther’s Law

17. Amdahl’s Law
Inventory
Shopping
Cart
Inventory
Shipping

18. Wheel of Doom

19. Amdahl’s Law

20. • The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
8 Fallacies of Distributed Systems
—L Peter Deutsch
• Topology doesn't change
• There is 1 administrator
• Transport cost is zero
• The network is homogeneous

21. • The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
8 Fallacies of Distributed Systems
—L Peter Deutsch
• Topology doesn't change
• There is 1 administrator
• Transport cost is zero
• The network is homogeneous

22. Wheel of Doom

23. • The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure
8 Fallacies of Distributed Systems
—L Peter Deutsch
• Topology doesn't change
• There is 1 administrator
• Transport cost is zero
• The network is homogeneous

24. Inventory
Gunther’s Law
Shopping
Cart
Shipping

25. Gunther’s Law

26. • Single Responsibility (do one thing …)
Duck Typing a Microservice?

27. Wheel of Doom

28. Microservices are NOT just
small applications
Pitfall #2

29. • Isolation between services
– Services deployed independently
– Independent data
– Loose coupling of components
• Agile Deployment
• Distributed/Elastic Deployment
• Single Responsibility (do one thing …)
Duck Typing a Microservice

30. State
Space
Time
Failure

31. • All access to a service’s state must got through its API
• This allows the service to evolve internally
• This allows the service to survive failures in other services
Independent Data
Inventory
Service
Shipping
Service
Inventory DB
Shipping DB

32. • Shared nothing (except integration protocols)
• Logic inside services, communication is asynchronous “dumb pipes”.
• Based on the assumption that change is required and infrastructure automated
Microservices Implement Bounded
Contexts
ShippingInventory
Shipping DBInventory DB
Payment
Payment DB
Search
Search DB
API Layer
Event Bus

33. • Isolation between services
– Services deployed independently
– Independent data
– Loose coupling of components
• Single Responsibility
• Agile Deployment
• Distributed/Elastic Deployment
Duck Typing a Microservice

34. • Scales horizontally
• Fault Isolation
– Security Isolation
• Fits well with cloud/containers
• Encapsulation: scales complexity
– Flexibility: right tool for each job
Microservice Benefits

35. • Distributed systems are hard
– Hard to develop
– Hard to debug
– Hard to monitor
• Requires an API driven approach
• Nearly always requires TDD approach
• Assumes infrastructure is automated
Microservice Challenges

36. Containerization

37. In theory: any OS level virtualization
In practice: Docker and Open Container
Initiative competitors
What is containerization?

38. A layer on top of LXC based Linux Virtualization
• Lighter weight than VMs: containers share one kernel
• Combine the application and the platform into a unified image
Tools for building, managing and storing those container
images
What is containerization?

39. What is containerization?
Dockerfile
FROM registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift
COPY stage/* /opt/docker
EXPOSE 8080
ENTRYPOINT ["/opt/docker/bin/myapp"]
DEPLOY
SERVER(S)
BUILD
MACHINE
stage folder “image”
docker image build –t myapp:1.0 .
REGISTRY
docker image push myapp:1.0docker image run myapp:1.0

40. Repeatability of infrastructure
– If it runs on my laptop it should run on dev and it should run on prod: the
Dockerfile captures everything needed
Repeatability of deployment
– I don’t need to understand anything about the app to deploy it
Containers can be built out of layered building blocks
Quick deployments mean containerization fits with automation
(including CI/CD and our microservice requirements)
Benefits of Containerization

41. Avoid startup complexity and large containers
• One process per container
• Images should be “ephemeral”: easy to start, stop, Avoid
persistent state in your containers
– In theory you can store state in persistent volume
– But this defeats the purpose of immutability
• Images should be portable
– Don’t rely on details of your environment, for example
• Cattle vs pets
Principles of Containerization

42. Containers are NOT just
lightweight Linux boxes
Pitfall #3

43. No difference between application and platform: they are
fused into an image
• For example, no concept of “applying an OS patch” to a container. You rebuild the image from
scratch.
• This, however, also plays into the idea of containers being ephemeral: you should be recreating
your images by rebuilding them on top of patched base images via CI/CD
Single purpose images with single processes
Containers vs Hosts/VMs

44. • Lots of things we used to take for granted in the monolith based
world are difficult/impossible in containers
– And easy to find lots of published containers that violate best practices
• The focus on making container images immutable means that either
you:
– Push all of your state out of the container (bad for performance/scale)
– Manage all of the state yourself (difficult)
• Containerization (by itself) doesn’t actually help you
manage or deploy containers at scale
Challenges of Containerization

45. Containers by themselves are about running single images:
there is no concept in ordinary Docker of:
• If each container is one process, how do I define the relationship between the
parts?
• How do I horizontally scale my application?
• How do I monitor my application? And take action when something goes wrong?
• How do I upgrade my application in place? And take action when something goes
wrong with the upgrade?
• How do I control access to my containers?
As the name implies, container orchestration is about how we
coordinate all of the containers.
Container Orchestration

46. Container Orchestration

47. Regardless, each of these systems is a framework for defining the
orchestration.
• You don’t tell the framework what to do, the framework tells you what
to do.
• Once more, we are changing how we operate and a new mindset is
needed
Container Orchestration

48. You would think [a rewrite] is easy - just make the
new one do what the old one did. Yet they are always
much more complex than they seem, and overflowing
with risk.
–Martin Fowler
Migration
Old code has been used. It has been tested. Lots of
bugs have been found, and they’ve been fixed.
–Joel Spolsky

49. The Strangler Fig Pattern
An alternative route is to gradually create a
new system around the edges of the old,
letting it grow slowly over several years
until the old system is strangled.

50. Strangler Fig == Events
Monolith
Users

51. Strangler Fig == Events
Monolith
Users
Proxy
Shopping Cart Events
μService

52. Strangler Fig == Events
Monolith
Users
Proxy
Shopping Cart Events
μService
New Views

53. Strangler Fig == Events
Monolith
Users
Proxy
Shopping Cart
Commands
μService
New Views
Verify

54. Strangler Fig == Events
Monolith
Users
Proxy
μService
All Interaction
Event Bus

55. Strangler Fig == Events
Monolith
Users
Proxy
μService
All Interaction
Event Bus
μService μService

56. • Have a business sponsor, listen,
deliver new value
• Incrementally build trust
• Start small, think big
Rules of Thumb

57. Reactive Systems

58. Reactive Manifesto
http://www.reactivemanifesto.org/
RESILIENT
The system
stays
responsive in
the face
of failure
ELASTIC
The system
stays
responsive
under varying
workload
RESPONSIVE
The system
responds in a
timely manner
if at all possible
Asynchronous message-
passing ensures loose
coupling, isolation
and location
transparency
MESSAGE DRIVEN

59. Web Application Framework Concurrency Toolkit Runtime
Thin, powerful abstraction
Other curated tools, architectural principles and patterns
used for building reactive microservice systems

60. Asynchronous
& Non Blocking
Event Sourcing
Command
query
responsibility
segregation
Eventual
Consistency
Domain Driven
Design
(Bounded Contexts, Context
Maps, Aggregate Entities)
Service Locator
Discovery
Edge Service
Lagom Design Patterns
Key Patterns
Required
when building
distributed
reactive
microservice
systems
Circuit Breaker

61. Lagom Components
Akka – Persistence, PubSub, Cluster, Streaming Async Services
Play Framework – Web framework
Cassandra – managing data persistence
Guice – dependency injection
SLF4J & Logback – Logging
Typesafe Config – configuration
JSON Serialization – Play JSON (Scala) Jackson (Java)
Service Gateway
Message Broker - Kafka

62. 69
Lightbend Cloud Native Application Platform

63. 70
Lightbend Platform
Products and Services that improve time to value and decrease project risk

64. 72
Lightbend Reactive Launch
Reac i e La nch
S a Yo Reac i e P ojec Off Righ S a on Ta ge
A a complemen o o Ligh bend S b c ip ion he Reac i e La nch offe ing ill accele a e o adop ion of
he Reac i e pla fo m i h deepe collabo a ion b connec ing o domain e pe i h o Ligh bend Reac i e
e pe Collabo a e o e plo e he e ca e of o legac echnolog and o k oge he o define he a
fo a d
Benefi
● Ini ia e o eam o he la e a chi ec e and de ign app oache fo Reac i e S em and ge cla i
on hich one migh be applicable o o need
● De elop clea ie be een echnical o k and b ine o come
● E abli h p io i ie h o gh cla i of nde anding on a mp ion gap and i k
● Imp o e o eam kill b ilding he confidence and mo i a ion
O come
● Ha e a olid plan fo de igning con c ing e ing deplo ing moni o ing and caling o eac i e
ol ion
● So nd e ie ed em a chi ec e a mp ion challenged
● F nc ioning de elopmen eam i h ea l cce e nde i fee
● Recommenda ion on he a fo a d o en e and ppo cce
Me hodolog
● Incep ion p epa a ion and anal i o nde and o compan and domain
● da f ll ime in en i e kickoff o la nch on i e op ion e abli h ini ial ajec o
● Con in ed coaching and men o ing d ing da i e a ion a on a ge
● Facili a ion and men o ing in Reac i e Pla fo m de elopmen
● E pe e ie of o em a chi ec e and de ign i h ecommenda ion
● P od c anal i i h o p od c o ne and akeholde
● Acce e pe ad ice i h de elope foc ed ppo b c ip ion
● Reac i e La nch epo and ecommenda ion fo he f e
• Focused on enablement
• Holistic: develop clear ties between the
technical work and the business outcomes
• Prove the key technical points, establish a
sound system architecture

65. Next Steps

66. https://www.lightbend.com/free-academy
• Free for a limited time
• Online self-paced training
• From conceptual to hands-on
Free Academy

67. https://www.lightbend.com/ebooks
• Reactive Systems Architecture
• Domain-Driven Design Distilled
• Developing Reactive Microservices
• Reactive Microsystems: The Evolution of Microservices at Scale
• Reactive Microservices: From Prototype to Production Ready Systems
• And many more …
Free e-books

68. Akka: akka.io
Lagom: lagomframework.com
Lightbend Subscription:
https://www.lightbend.com/lightbend-subscription
Bla Bla Microservices Bla Bla: http://bit.ly/blabla_micro
First principles of microservices from Lightbend’s CTO
Links

69. David Ogren (Global Solutions Architect)
(919) 946-4847, david.ogren@lightbend.com
Reach out to Us

70. Thank You
Start Small
Think Big
Move Fast