Refactoring the way: Excelling on the Microservices Journey

Resources:
* Microservices Patterns: With examples in Java (https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543)
* Strangler Fig Application (https://martinfowler.com/bliki/StranglerFigApplication.html)
* How to break a Monolith into Microservices (https://martinfowler.com/articles/break-monolith-into-microservices.html)
* Migrating bajillions of database records at Stripe (https://robertheaton.com/2015/08/31/migrating-bajillions-of-database-records-at-stripe/)
* How to lose half a billion dollars with bad feature flags (https://blog.statsig.com/how-to-lose-half-a-billion-dollars-with-bad-feature-flags-ccebb26adeec)

Transcript

1. BY ZIKRIYE ÜRKMEZ Refactoring the Way: Excelling on the Microservices Journey
2. ABOUT ME 10 + years backend developer 5 different company experiences leader of a great team always team member linkedin.com/in/zikriye-urkmez-cengiz Engineering Manager twitter.com/ZikriyeUrkmez github.com/zikriyeurkmezcengiz navlungo
3. THE BENEFITS OF THE MONOLITHIC ARCHITECTURE simple to develop easy to make radical changes to the application straightforward to test straightforward to deploy easy to scale
4. SIGNS LIVING IN MONOLITHIC HELL complexity intimidates developers development is slow path from commit to deployments is long and arduous locked into increasingly obsolete technology stack scaling is difficult delivering a reliable monolith is challenging
5. explode nor be too restrictive do not create a distributed monolith do not share your database do not let functional silos hang around do not adopt microservices unless you’re ready do not let your tech landscape WELL KNOWN MISTAKES IN MICROSERVICE ARCHITECTURE
6. MICROSERVICE IS NOT A SILVER BULLET ARCHITECTURE
7. a Big Bang rewrite The only thing Martin Fowler guarantees is a Big Bang!
8. kitchen service delayed order service STRANGLER FIG PATTERN order service delivery service minimize changes to the monolith updates monolithic application systems -- known as the "big ball of mud" -- while still keeping them running in production better than a big bang rewrite immediate return on your investment team velocity steadily increases over time enables delivering the value earlier Food Delivery Application helps to get the business’s support for the migration effort
9. Service Service Service Service Service Service Service Service Service Service Service Service Service ... Service Service Service Service Service Service Service Service Service Service Service Service Service Service Strangler Application Time Monolith Monolith Monolith Monolith Monolith ... Monolith
10. STRATEGIES FOR REFACTORING A MONOLITH TO MICROSERVICES implement new features as services separate the presentation tier and backend extract busIness capabIlItIes Into servIces
11. Every increment must leave us in a better place in terms of the architecture goal. implement new features as services “If you find yourself in hole stop digging” - Law Of Hole
12. implement new features as services Microservices Patterns: With examples in Java
13. Smaller, independently deployable backend monolith Monolith containing presentation logic and backend business logic An API that is called by any future services Smaller, independently deployable presentation logic monolith separate the presentation tier and backend enables you develop, deploy and scale the two applications allows presentation developers to rapidly iterate allows to A/B testing
14. inbound adapters that implement API endpoints domain logic outbound adapters such as database access logic database Vertical slice contains; Refactoring the database CHALLENGES Splitting the domain model extract busIness capabIlItIes Into servIces
15. <Entity> Order <Entity> Restaurant <Entity> Order <Entity> Restaurant <Entity> Order <Entity> Restaurant RestaurantId <Entity> Order <Entity> Restaurant Object reference that spans service boundaries Object reference that spans service boundaries Splitting the domain model Monolith Delivery Service Monolith Delivery Service Monolith Delivery Service Monolith Extracted service ? ? Replace with primary key Replace the object references with primary key value Use DDD aggregates to achieve boundary issues minor change can potentially cause a large impact on the clients of the class
16. Refactoring the database when you extract a service from the monolith, you’re also moving data Split Table, Refactoring Databases by Scott W. Ambler Replicate data to avoid widespread changes extremely time consuming changes a huge barrier to breaking up the monolith significantly reduces the amount of work we need to do immediately. we can migrate code that uses the delivery-related Order entity fields or ORDERS table columns to Delivery Service It’s possible that we never need to make that change in the monolith
17. What services to extract and when WHERE YOU ARE GOING! KNOW be careful decide the sequence in which you extract services focus on the service that gives you largest benefit remember that this architecture is not set in stone
18. DECIDING SEQUENCE rank the modules of the application by benefit extraction Accelerates development If your application’s roadmap suggest that a particular part of your application will undergo a lot of development over the next year, then converting it to a accelerates development
19. DECIDING SEQUENCE rank the modules of the application by benefit extraction Solves a performance, scaling or reliability problem If a particular part of your application has a performance or scalability problem or is unreliable, then it’s valuable to convert in to a service
20. DECIDING SEQUENCE rank the modules of the application by benefit extraction Enables the extraction of some other services Sometimes extracting one service simplifies the extraction of another service, due to dependencies between modules
21. PICKING AN INTERACTION STYLE AND IPC MECHANISM REST GRPC SYNCHRONOUS ASYNCHRONOUS publish/subscribe
22. Delayed Delivery Service Rest Client Monolith Rest API request/response interaction style - Rest/gRpc - Monolith database GET/customers/{customerId} querying data by invoking a query API is simple main drawback is that it’s potentially inefficient. consumer might need to make a large number of requests, provider might return a large amount of data. reduces availability because it’s synchronous IPC
23. Delayed Delivery Service Event subscriber Monolith Rest API Database adapter publish/subscribe Monolith database avoids the overhead of repeatedly querying the data provider consumer keeps the replica up-to- date by subscribing to domain events published by the data provider. drawback of using a replica, though, is the complexity of maintaining it Service database Customer event channel Customer domain event update () the monolith publishes domain events, and an event handler implemented by the service updates the service’s database. need to modify the monolith to publish domain events.
24. new feature new feature Deploy Activate feature New Feature Feature toggles Application initial state Feature deployed in production but hidden New feature now accesible
25. Recommendations for Feature toggles SHORT DEVELOPMENT CYCLE SIMPLIFIED VERSION CONTROL TEST IN PRODUCTION DECOUPLE BUSINESS AND TECHNICAL DECISIONS FINE-GRAINED RELEASES Use them with measure. Feature flags can get out of control. Don’t ever, ever, ever repurpose a flag. Always create a new one for every change or risk making a half a billion-dollar mistake Minimize flag debt. Delete old and unused flags. Don’t let dead code linger. Unless you have a good reason not to, keep the feature flag lifespan short (weeks). Choose descriptive names for your flags. New-Feature-2 is NOT a good name. Consider having a way to view the state of all your flags. You can write an admin dashboard or an API for this.
26. end of fun!