Ledingkart Meetup #1: Monolithic to microservices in action
- 1. Monolithic to Microservices in Action Tech Talks @Lendingkart Gautam, Mihir, Dinesh May 19th, 2018
- 2. What are Microservices? ● While there is no formal definition of microservices, there are certain characteristics that help us identify the style. ● Microservices is a software development technique ● A variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services ● In a microservices architecture, services are fine-grained, deployable ● The communication protocols are lightweight (HTTP/REST with JSON) ● Each service runs a unique process
- 5. Monoliths in the age of stonehenges ;-)
- 6. History of microservices As Martin Fowler (UML, Design expert) points out, Netflix, eBay, Amazon, Twitter, PayPal, Soundcloud and many other large-scale websites and applications have all evolved from monolithic to microservices architecture. Amazon: “In 2001 the Amazon.com retail website was a large architectural monolith.” It was architected in multiple tiers, and those tiers had many components in them. However, they were all very tightly coupled together, where they behaved like one big monolith. Now they are completely using microservices architecture and for starters, they use 120 services to generate one product page in their ecom website!
- 8. Contd... Netflix: Netflix has a widespread architecture that had evolved from monolithic to SOA. It received more than one billion calls every day, from more than 800 different types of devices, to its streaming-video API. Each API call then prompts around five additional calls to the backend service. They offer 500+ services in total! Netflix took ten years to fully transition from monolith to microservices. In 2008, a database corruption due to a semicolon cost them huge headaches. AirBnB: The home-sharing service operates in 65,000 cities located in 191 countries. 2017 saw their four millionth listing. Last summer, 45 million guests stayed in an Airbnb listing, making a total of 200 million guest stays since 2008. In order to make this possible, they deploy 3500 microservices per week, with a total of 75 thousand production deploys per year.
- 9. Companies that have adopted microservices in a big way!
- 10. The monolithic problem at Lendingkart!
- 11. Contd...
- 13. The cost!
- 14. Why microservices? ● High Availability (Decoupled) ● Scalability ● Reliability ● Service Management ● Clean Code ● More Testable ● Clear Ownership ● Release Management ● Data Centric Development. ● Ability to scale/integrate individual services written in different frameworks/languages. ● Encourages Agile Methodologies
- 15. Initial Lendingkart Platform (monolithic)… ● Started with 2 Backend, 2 UI Developers, 1 QA ● As new developers joined the team, it was difficult to understand and maintain the monolithic ● Initial monolithic catered to customer & ops with minimal features. ● Lot of experiments carried out on Customer to improve self-serve and on Ops to reduce Turn around Time ● Stability was a major worry as we had to deploy features and bugs on a daily basis ● Vertical scaling of our database server on a regular basis
- 16. Contd... ● Lending involves 3 major pieces: Origination, Credit analysis, Loan management ● Our initial monolithic involved Customer, Origination and Credit analysis modules (Spring MVC) structured on the lines of SOA ● For Loan management we used a third party service to avoid re-inventing the wheel
- 17. Contd... ● First microservice was in the form of lead service (Dropwizard), followed by notification service ● Subsequent break of our monolithic to microservice happened in the form of customer, credit analysis, audit, reports, scheduler, webhooks, etc ● The greatest advantage was that since our requirements were changing fast, we could make the changes quickly on the microservice and make it more mature over time
- 18. Contd...
- 19. How to decide if you need microservices? ● If distributed systems are the way to go, do I use microservices or modularized applications? ● Do you have need to grow rapidly ? ● Do you have certain part of applications which needs special handling in terms of load or feature rollout or hardware specifications ? ● Do you have too many merge conflicts and repo issues ? Is it taking significant time and bandwidth of your developers? ● Is my business suitable for more monolithic? Do I have more batching and scheduling to do ?
- 20. How to decide if you need microservices? ● Do I have enough resources to build, scale and deploy dozens of services ? ● Is there an integration expert/architect that can lead the project and follow through? ● What if one of the service endpoints fail? How do I recover? How do I monitor all these effectively? ● How do I manage security settings and authentication across all the services? ● Would you need different technology stack for different applications or different features ?
- 21. How we moved to microservices architecture Monolithic to Microservice architecture UI MySQL DB Business logic Data Access Layer MySQL DB MongoDB MySQL Microservice Customer Microservice Ops Microservice Notification Microservice Credit Analysis Nginx UI UI UI UI
- 22. How we broke our monolithic (Lendingkart Platform as an Example) ● Leads ○ Developed using Dropwizard as it had some great out of the box features compared to Spring MVC ○ Worked well except since we didn’t have a system-wide monitoring & alerting it was tough to manage the same ○ MongoDB as lead data from partners is sparse and reduces load on MySQL DB
- 23. Contd... ● Audit ○ Use MongoDB to store audit data through CDC (mysql binlog & mongodb oplog reader) ○ Data available through REST APIs ● Customer ○ Customer service was the first to come out of the main monolithic as it had fewer APIs compared to Ops ○ Made it easier to identify issues ○ Increased fault tolerance and performance
- 24. Contd... ● Fixed Scheduler (Spring) ○ All scheduler tasks where moved to a separate service ○ Not a complete solution as it wasn’t distributed ● Scheduler API based (Quartz) ○ Ease of configuring scheduled jobs dynamically through REST APIs ○ Distributed ● Webhooks ○ APIs for third-party like Mixpanel, Survey Monkey, etc ○ Improved fault-tolerance as third-party API failure means difficulty in resolving the same
- 25. Contd... ● Notifications ○ SMS, Email ○ Capability to throttle email/sms between multiple third-party providers ● Search Service ○ Elasticsearch for faster querying ○ Reduces load on relational database
- 26. Contd... ● Authentication & Authorization ○ Central authority. Easier to track issues ○ Important service as security is central to any financial service ○ Using Shiro framework ○ Authorization is now better handled as each department had a different requirement. Now it is under one umbrella and we are solving it in a transparent manner with our Ops team. ○ Providing hierarchical roles with access to specific features along with fine-grained permissions (RBAC)
- 27. Challenges in moving to microservices ● Distributed tracing and debugging ● Architect for failures ● Dependency and version management ● Reporting and analytics ● Operations overhead
- 28. Distributed tracing and debugging ● Difficulty in debugging problems when a feature spans across multiple microservices ● Challenges in identifying latency issues Solutions: ● Centralized logging mechanism i.e ELK ● Inject requestId at the source ● Zipkin, spring-cloud-sleuth
- 29. Architect for failures ● Avoid failures by implementing change management strategies and automatic rollout ● Exception handling ● Timeouts ● Retries with limited attempts and exponential backoff ● Circuit breaker i.e Netflix Hystrix, Fallbacks ● Rate Limiting and client whitelisting ● Test for failures i.e Chaos-Monkey
- 30. Dependency & version management ● Avoid cyclic dependencies ● Ensure dependencies form DAG (Directed Acyclic Graph)
- 31. Dependency & version management ● Maintain backward compatibility ● Api versioning
- 32. Reporting and analytics ● Data spread across a number of isolated heterogeneous data stores ● Consolidation and aggregation becomes challenging Solution: ● Pull data from all microservices and store in centralized data store i.e Redshift.
- 33. Operations overhead ● Keep releases and deployment manageable ● Service monitoring and automation is required ● Containerization and running multiple services at single instance ● Devops is a must
- 34. Contd...
- 35. CI/CD
- 37. Best Practices ● As Martin Fowler reportedly said, “the only thing a Big Bang rewrite guarantees is a Big Bang!”
- 38. Best Practices ● Mark edge services like caching, authentication/authorizations, logging etc., and move it to microservices first. ● Decomposition: Business Use Case, Domain etc., ● CI/CD ● Monitoring & Alerting System.
- 39. Best Practices (Microservices Patterns) ● Aggregator ● Proxy ● Chained ● Branch ● Shared Data ● Asynchronous
- 45. Asynchronous OR Event-Driven Microservices
- 46. Best Practices contd... ● Don't Burn That Old Bridge Before Getting a New One in Place. ● Move any new features/product to microservices. ● Clear cut interface/contract to communicate between services. ● Service should be extracted in such a way that it can be easily tested and shipped to production. ● Service should follow single responsibility like OOPS object. ● Club closely related services together to avoid too many network calls.
- 47. Frameworks used in microservices ● Spring Boot with netflix oss, Dropwizard, Lagom, Play ● GraphQL: A great complement to REST APIs allowing for customized consumption of services ● CI/CD: Gitlab, Docker, Kubernetes ● Monitoring & Alerting: Telegraf, InfluxDB, Grafana, Kapacitor. ● Distributed Messaging Queue: Kafka
- 48. Thank You!
Editor's Notes
- #3: Primary: Gautam SOA is an architectural pattern in which application components provide services to other components. However, in SOA those components can belong to the same application.
- #6: Primary: Gautam
- #7: Primary: Gautam Amazon: In 2000, Amazon had the unenviable task of reconciling the in-process changes from hundreds of developers, resolving all the conflicts between them, merging them into a single version, and producing a master version that waits on the queue to be moved into production.
- #8: Primary: Gautam
- #9: Primary: Gautam
- #10: Primary: Gautam
- #11: Primary: Gautam
- #12: Primary: Gautam
- #13: Primary: Gautam
- #14: Primary: Gautam
- #15: Primary: Mihir High Availability: It’s easy to deploy individual service and have lesser downtime and also add more nodes to it then one big monolith! Also, in case of failure one service would not impact other. Reliability: a microservice fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith.
- #16: Primary: Gautam Lendingkart started as a monolithic. A monolithic application is built as a single unit. We had taken care of the traditional layers: database, a client-side user interface (HTML & Angular framework), and a server-side application. This server-side application was used to handle HTTP requests, execute some domain specific logic, retrieve and update data from the database, and populate the HTML views to be sent to the browser. It wa a monolith – a single logical executable.
- #17: Primary: Gautam
- #18: Primary: Gautam
- #19: Primary: Gautam
- #20: Primary: Mihir Appliance solutions Non-multi-tenant B2C: Micro-services Large Financial institutions are reluctant to move to micro-services due to compliance, security, processes hindering them Team larger than say 20, leads to merge conflict and causes more bugs as teams can’t work independently in a monolithic architecture Modular approach works fine but have to be aware of dependencies all the time and cannot use different versions of modules in same application but in microservices you can do. Failure in one module will bring down entire application but in microservices it will only impact one service and it’s consumers at worst!
- #21: Primary: Mihir
- #22: Primary: Gautam
- #23: Primary: Gautam Example (The micro-services in Lendingkart): Talk about Why, How, When, Challenges, Performance improvements, Productivity, etc
- #24: Primary: Gautam
- #25: Primary: Gautam
- #26: Primary: Gautam
- #27: Primary: Gautam
- #28: Primary: Dinesh
- #29: Primary: Dinesh Centralized monitoring and logging tools are needed to debug issues. Every service should data to a centralized data store i.e ELK. In order to debug root cause, we should be adding a request id and serviceid in logs to identify which service was faulty.
- #30: primary:Dinesh you deploy new code, or you change some configuration, you should apply these changes to a subset of your instances gradually, monitor them and even automatically revert the deployment if you see that it has a negative effect on your key metrics. We can adopt strategies like rolling or blue green deployment.
- #31: Primary: Dinesh We need to make sure service calls should not form a cycle else it might result into distributed stack overflow.
- #32: Primary: Dinesh
- #33: Primary: Dinesh
- #34: Primary: Dinesh As we add all this infrastrure like monitoring, alerting and orchestration tools, we need a dedicated devops team to manage infra.
- #36: Primary: Mihir
- #37: Primary: Mihir
- #38: Primary: Mihir
- #39: Primary: Mihir
- #40: Primary: Mihir Amazon/Flipkart ecommerce page (Aggregator), Ola/Uber ride options (Proxy), Payment Gateway (Chained), Shared Data: Antipattern, Centralized Log service is asynchronous.
- #41: In its simplest form, Aggregator would be a simple web page that invokes multiple services to achieve the functionality required by the application. Since each service (Service A, Service B, and Service C) is exposed using a lightweight REST mechanism, the web page can retrieve the data and process/display it accordingly
- #42: Proxy microservice design pattern is a variation of Aggregator. In this case, no aggregation needs to happen on the client but a different microservice may be invoked based upon the business need or rule. EXAMPLE:BOOKMYSHOW
- #43: Chained microservice design pattern produce a single consolidated response to the request. In this case, the request from the client is received by Service A, which is then communicating with Service B, which in turn may be communicating with Service C. All the services are likely using a synchronous HTTP request/response messaging. Important aspect to understand here is to not make the chain too long. EXAMPLE: payment gateway.
- #44: Branch microservice design pattern extends Aggregator design pattern and allows simultaneous response processing from two, likely mutually exclusive, chains of microservices. This pattern can also be used to call different chains, or a single chain, based upon the business needs Service A, either a web page or a composite microservice, can invoke two different chains concurrently in which case this will resemble the Aggregator design pattern. Alternatively, Service A can invoke only one chain based upon the request received from the client
- #45: It’s anti-pattern and should be used sparingly only during transition phase wherein you need to provide certain data for certain time. For ex, you are in transition phase and microservice is not fully autonomous but business need, pushes you to store or share data with some other service.
- #46: In this design pattern, Service A may call Service C synchronously which is then communicating with Service B and D asynchronously using a shared message queue Event Firehose: Due to IoT, social networks and real-time stream processing, event firehose use cases are becoming common
- #47: Primary: Mihir
- #48: Primary: Gautam