Microservices, Kubernetes, and Application Modernization Done Right
2 likes1,446 views
The document discusses the importance of application modernization through microservices and Kubernetes, emphasizing the need for agility, scalability, and cloud migration. It explains the challenges and benefits of microservices, containerization, and reactive systems, while introducing key concepts like the strangler fig pattern for transitioning systems. Additionally, it highlights resources for further learning and expert contacts for guidance in adopting these modern technologies.
![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](https://image.slidesharecdn.com/microserviceskubernetesandapplicationmodernizationv1-191122125449/85/Microservices-Kubernetes-and-Application-Modernization-Done-Right-37-320.jpg)
![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](https://image.slidesharecdn.com/microserviceskubernetesandapplicationmodernizationv1-191122125449/85/Microservices-Kubernetes-and-Application-Modernization-Done-Right-47-320.jpg)
Microservices, Kubernetes, and Application Modernization Done Right
- 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
- 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
- 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
- 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
- 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
- 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
- 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, [email protected] Frank Carvalho (Lightbend) (617) 312-7915, [email protected] Reach out to Us
- 67. Thank You Start Small Think Big Move Fast