In this talk by David Ogren, Enterprise Architect at Lightbend, we draw from experiences helping our clients successfully create, migrate to, and manage cloud-native system architectures. We look at some of the common pitfalls and anti-patterns of modernization efforts, and some of the best practices for taking an incremental approach to transforming legacy systems. See the full post with video on the Lightbend blog: https://www.lightbend.com/blog/microservices-kubernetes-application-modernization

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. What is Application Modernization?
• Digital Transformation
– Do something new
• Be more Agile
– Speed up changes or make them less risky
• Move to the “Cloud”
– Reduce costs
– Be more elastic

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

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

7. 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
Broker-Dealers
Assets
Taxes
Clients
Corporate
Actions

8. Framing Project Goals
• Digital Transformation
– Do something new
• Be more Agile
– Speed up changes or make them less risky
• Move to the “Cloud”
– Reduce costs
– Be more elastic

9. Why Microservices?

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

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

12. 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

13. Amdahl’s Law & Gunther’s Law

14. Amdahl’s Law
Inventory
Shopping
Cart
Inventory
Shipping

15. Amdahl’s Law

16. Wheel of Doom

17. • 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

18. Wheel of Doom

19. • 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

20. Amdahl’s Law

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. Inventory
Gunther’s Law
Shopping
Cart
Shipping

23. Gunther’s Law

24. Wheel of Doom

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

26. Microservices are NOT just
small applications
Pitfall #1

27. • 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

28. State
Space
Time
Failure

29. • 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

30. • 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

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

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

33. • 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

34. Containerization

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

36. 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?

37. 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

38. 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

39. 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

40. Containers are NOT just
lightweight Linux boxes
Pitfall #2

41. 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

42. • 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

43. 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

44. Container Orchestration

45. Even Further Options

46. 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

47. 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

48. 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.

49. Strangler Fig == Events
Monolith
Users

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

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

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

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

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

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

56. Reactive Systems

57. 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

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

59. 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

60. 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

61. 67
Lightbend Platform
Products and Services that improve time to value and decrease project risk

62. 69
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

63. Next Steps

64. 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

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

66. David Ogren (Global Solutions Architect)
(919) 946-4847, david.ogren@lightbend.com
Frank Carvalho (Lightbend)
(617) 312-7915, frank.carvalho@lightbend.com
Reach out to Us

67. Thank You
Start Small
Think Big
Move Fast