$30 off During Our Annual Pro Sale. View Details »

Refactoring the way: Excelling on the Microserv...

Refactoring the way: Excelling on the Microservices Journey

Zikriye Ürkmez

October 07, 2023
Tweet

More Decks by Zikriye Ürkmez

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. STRATEGIES FOR REFACTORING A MONOLITH TO MICROSERVICES implement new features

    as services separate the presentation tier and backend extract busIness capabIlItIes Into servIces
  8. 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
  9. 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
  10. 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
  11. <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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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.
  19. new feature new feature Deploy Activate feature New Feature Feature

    toggles Application initial state Feature deployed in production but hidden New feature now accesible
  20. 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.