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

3.
Monoliths in the age of stonehenges ;-)

4.
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!

5.
Amazon history

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

7.
Companies that have adopted microservices in a big way!

8.
The monolithic problem at Lendingkart!

9.
Contd...

10.
Change is important!

11.
The cost!

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

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

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

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

16.
Contd...

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

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

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

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

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

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

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

24.
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)

25.
Challenges in moving to microservices
● Distributed tracing and debugging
● Architect for failures
● Dependency and version management
● Reporting and analytics
● Operations overhead

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

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

28.
Dependency & version management
● Avoid cyclic dependencies
● Ensure dependencies form DAG (Directed Acyclic Graph)

29.
Dependency & version management
● Maintain backward compatibility
● Api versioning

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

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

32.
Contd...

33.
CI/CD

34.
Monitoring & Alerting

35.
Best Practices
● As Martin Fowler reportedly said, “the only thing a Big Bang rewrite
guarantees is a Big Bang!”

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

37.
Best Practices (Microservices Patterns)
● Aggregator
● Proxy
● Chained
● Branch
● Shared Data
● Asynchronous

38.
Aggregator Microservices

39.
Proxy Microservices

40.
Chained Microservices

41.
Branch Microservices

42.
Shared Data Microservices

43.
Asynchronous OR Event-Driven Microservices

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

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

46.
Thank You!