The document summarizes HomeDepot.com's transition from a monolithic architecture to microservices. It discusses how in 2011, the monolith had grown large and difficult to manage, with long release cycles. The objective was to increase the rate of change and number of developers. Key steps included breaking the monolith into domain-driven services, adopting continuous integration, using APIs for communication, and implementing feature flags and traffic routing. This allowed independent development of 30 apps by 2015 compared to just 1 previously, with weekly instead of monthly deployments. The presentation provides guidance on patterns for microservice communication, deployment, data management, and avoiding common pitfalls.

1. Monolith to Microservices
How HomeDepot.com made the switch
Christopher Grant
Sr Architect HomeDepot.com
cgrant
cgrant

2. Building the monolith

3. 1996

4. Its an old story
• Start out small
• Lean and ready to take on the world
• Add some new features
• One day suddenly you realize
…you’ve got a monolith

5. 2011
• 2 GB Java Deploy that took an hour
• Locking SCM (Clear Case) with no CI
• 3 Month long release Cycles
• 2-4 hour deploy outages
• Infrastructure drift (Pets) and config sprawl

6. Breaking Down the Monolith

7. Our Objective
• Increase the rate of change
• Increase number developers
• Maintain and enhance operations

8. Agile

9. Domain Spaces

10. Continuous Integration Tooling

11. APIs

12. Feature Throttles

13. Key Take Aways

14. Start with a vision
• Have a vision
• Understand your objectives
• Choose what matters
• Implement in stages

15. Culture change can be hard
Schneider Culture Model
http://agilitrix.com/2011/03/how-to-make-your-culture-work/

16. Iterative Architecture?

17. Changing the wheels while driving?

18. Evolutionary Architecture

19. Architect for Change
• Prepare for future changes
• Be proactive not reactive
• Delay until the last responsible moment
• Expect but minimize future rework

20. Domain Driven Design
Header
Imagery
Product Pod Buy
Box
BreadCrumb
Share This
Item Related Groups
Product Details
Certona
Footer

21. Decompose & Define Boundaries
• Understand business products & domains
• Identify people structures
• Review data models
• Look for the hard things

22. 8 fallacies of distributed computing
• The network is reliable
• Latency is zero
• Bandwidth is infinite.
• The network is secure
L Peter Deutsch and others at Sun Microsystems
• Topology doesn't change
• There is one administrator
• Transport cost is zero
• The network is homogeneous
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

23. Implement Safely
• Automate early and often
• Consider in-place and green-field
• Utilize feature switches and traffic throttles
• Encourage separation and independence

24. Result
2011 2015
Apps 1 30
Sales $1b $5b
Developers 170 300
Deploy frequency 3 month Weekly

25. 2015 began moving to
cloud & micro services
Butwait
Theres more!!

26. Microservices in the Cloud

27. Microservices for everyone
• Everyone’s trying to break down their monolith these days
• More maintainable
• Easier deployment
• More isolated concerns
• Not just for unicorns anymore

28. How is THD approaching it

29. Microservices Patterns
Chris Richardson
http://microservices.io/
Great resource &
Great way to talk about what we did

30. Core Patterns
• Monolith
• Microservice

31. Core Patterns
• Monolith
• Microservice

32. Microservces
• How big should they be?
• How many should we have?

38. Two Pizza Rule
If a team can’t be fed by two pizzas
then its too big
-Jeff Bezzos

39. 1 Microservice
per
two pizza team

40. Domain Services

41. • Code Base
• Dependencies
• Config
• Backing Services
• Build Release Run
• Process
• Port Binding
• Concurrency
• Disposability
• Dev/Prod Parity
• Logs
• Admin Process
http://12factor.net/
Cloud Native Apps

42. Communication
• API Gateways
• Discovery
• Server side
• Client Side
• Ambassador (proxy)
• Registration
• Self
• Third Party

43. Communication
• API Gateways
• Discovery
• Server side
• Client Side
• Ambassador (proxy)
• Registration
• Self
• Third Party

44. Ambassador Pattern
Registry
Client Instance
Service Instance
Client App
Local Proxy
Service App
Registrator
1. The new server registers itself in the registry
2. Registry updates all LB configurations
3. The client App calls a local proxy
4. The Local proxy routes to the new Service App
1
2 3
4

45. Deployment patterns
• Single Service Per Host
• Multiple Service Per Host
• Single Service Per VM
• Single Service per container

46. Deployment patterns
• Single Service Per Host
• Multiple Services Per Host
• Single Service Per VM
• Single Service per container

51. Immutable Architecture
• Assets are rebuilt, redeployed but never modified
• SSH is only for diagnostic uses
• Base images used for speed and maintainability
• Immutable application assets added separately

52. Registry Agent Registry Template Logs Collector
Java 8
productpage-1-5-5.jar
Proxy
product-app.yaml
sourceImage: java8-10141019
properties:
app_name: productpage
app_version: 1-5-5
Single Instance
Base
App
(java8-10141019)

53. Building with Hammer & Nail

54. Data Management
• One Database per service
• Event-driven Architecture

55. Data Management
• One Database per service
• Event-driven Architecture

56. Decoupling Strategies
DB1
App1 App2
Shared Database
DB1
Dom1
App2
Shared Domain
App1
Decentralized Data
DB1
App1
DB2
App2
Queue

57. 7 deadly sins of microservices
@danielbryantuk
Daniel Bryant
https://opencredo.com/the-seven-deadly-sins-of-microservices-redux/

58. Thank You