Slides from the October 2016 meetup presentation of the Massachusetts Microservices Meetup group. Kenzan Twitter: @kenzanmedia Linkedin: www.linkedin.com/company/kenzan-media Blog: techblog.kenzan.com Facebook: www.facebook.com/kenzanmedia/

1. Massachusetts Microservices Meetup, October 2016
Darren Bathgate
Technical Architect
Architecting for Microservices

2. 2
● Founded in 2004, Kenzan is a software engineering and professional
services company with 4 offices in RI, NYC, Los Angeles and Denver
● More than 150+ architects, developers, QA Engineers, project managers
● Full service solutions provider. Some of our services include:
○ Application development
○ Platform as a service
○ Cloud virtualization
○ DevOps
● Clients include: Thomson Reuters, Charter, Starz, HBO, AMC, and
Cablevision
About Kenzan
Overview

3. 3
2010-2011
● Developed interactive television applications
● Built and maintained monolithic full stack web applications
2011-2012
● Architected and built first small scale microservice stack
● Around 15 microservices deployed on datacenter hardware
2013-2014
● Adopted cloud and AWS
● Assisted client with peeling a monolith into microservices
2015-Present
● Helped client reach thousands of instances in AWS running microservices
History Leading Up to Microservices
About Kenzan

4. 4
History
● Graduated with a Bachelor’s in Software Engineering in 2010
● Started as a developer at Kenzan in 2011
● Promoted to Technical Architect in 2013
Specialties
● Java backend development
● AWS cloud and platform development
● Cassandra and RDBMS databases
Other Interests
● Really hyped about Docker and container related technologies
● Computer hardware enthusiast
About Me

5. 5
What is a Microservice?
¯_(ツ)_/¯
A really small service?

6. 6
● N number of modular components joined together via the network
● Decomposed by units of business or functionality
● Combined makes up an entire backend system
Microservices
Overview

7. 7
● Smaller development teams
○ Scales development velocity
○ Teams build domain ownership of services
● Scalability
○ Adds independent scalability to units of business
○ Each service can scaled as needed to meet demand
● Resource isolation
○ Each service can be assigned fixed resources using virtualization
○ Services do not affect other systems when resources are exhausted
Microservices
Benefits

8. 8
● Deployed on datacenter hardware using VMWare
● Java/Tomcat microservices
● Single and multi-tenant deployments per VM
● Nginx and Varnish used for routing traffic and caching
● Cassandra and Memcached NoSQL stores used for temporary
storage
Early Microservice Adoption
Overview

9. 9
Routing
● Directs traffic to microservice based on requested path
● Edge side caching and auth-n gating (am I logged in?)
Edge Service
● Accepts requests from user input
● Drives business logic
● Enforces auth-z rules (do I have access to this resource?)
Middle Service
● Data tier abstraction
● Simple CRUD style operations
Data Tier
● Databases data stores
● External services
Early Microservice Adoption
Components

10. 10
Early Microservice Adoption
Example Diagram

11. 11
● Tight coupling of components
● Deciding what to split off first
● Stateful behavior
● Use of OS level dependencies like filesystem and network
● Supporting monolith and microservice during transition
Splitting the Monolith
Challenges

12. 12
Splitting the Monolith
Example Monolith

13. 13
● Decouple components
● Organized into functional divisions of business logic
● Move stateful in-memory stores into shared datastores
● Put router in front of the monolith to smooth rollout transition
Splitting the Monolith
Prepping the Monolith

14. 14
Splitting the Monolith
Prepping the Monolith (Diagram)

15. 15
● Start working from the bottom up
● Split up databases
● Peel out data access modules into Middle Services
● Peel out Edge modules into Edge Services
● Use Router to toggle redirection to new Edge Services
Splitting the Monolith
Peeling Components into Microservices

16. 16
Splitting the Monolith
Peeling Components into Microservices (Diagram 1)

17. 17
Splitting the Monolith
Peeling Components into Microservices (Diagram 2)

18. 18
Maintaining Visibility

19. 19
● More microservices become harder to trace and debug
● Each network hop increases complexity and latency
● Caching adds to the confusion (where did my data come from?)
● 500+ Microservices work for Netflix but is not right for everyone
● Netflix devotes time to understand failures
Maintaining Visibility
Overview

20. 20
Death Star Topology
Image Source: https://contiv.github.io/articles/2016/03/06/scaling-microservices.html

21. 21
● Start simple (<10 microservices)
● Define organization wide patterns for teams to follow
● Incorporate monitoring tools early
● Store logs and allow developers to search logs
● Use distributed tracing to track requests
● Circuit breaking
Maintaining Visibility
How Do I Maintain Visibility?

22. 22
● Edge and Middle tier service pattern
● Pattern reduces network hops to a maximum of 5
● LB >> caching >> router >> edge >> middle >> data
Edge Tier
● Only connects to Middle services
● Never talks to another Edge service
Middle Tier
● Middle only talks to databases and data stores
● Never talks to more than 1 source of data
Microservice Design
How We Designed Microservices in the Past

23. 23
Microservice Design
Predictable Failure

24. 24
Microservice Design
Unpredictable Failure

25. 25
Microservice Design
Unpredictable Failure

26. 26
● Even the Edge and Middle design can be a bit confusing
● Currently exploring better alternatives to decoupling microservices
● Edge service becomes the orchestrator connecting middle services
● Reduced number of Edge services
Alternative Design
Overview

27. 27
Alternative Design
Example Diagram

28. 28
Alternative Design
Spinnaker
Image Source: http://cloudacademy.com/blog/netflix-spinnaker/

29. 29
● Necessary with increased network communications of microservices
● Prevents cascading failures when one system is down
● Keeps other features running that do not depend on the downed system
● Every microservice should defend itself from its surrounding dependencies
Circuit Breaking
Overview

30. 30
Circuit Breaking
Diagram

31. 31
● Use the Dashboard!
● Hystrix circuit breaking generates useful metrics
● Not collecting and displaying them greatly reduces visibility to outages
● Metrics also help optimize circuit breaker settings
Circuit Breaking
Hystrix Dashboard
Image Source: http://techblog.netflix.com/2012/12/hystrix-dashboard-and-turbine.html

32. 32
● “Are microservices a prerequisite to the cloud?”
● Independent scalability is greatly improved with microservices in the cloud
● Microservices use less server resources, and work well with affordable
instance tiers
● Easier to achieve resource isolation (microservices with dedicated CPU,
Memory, Storage, and Network)
● Ease of provisioning new microservices
Microservices in the Cloud
Benefits

33. 33
● Immutable Hardware becomes necessary in a dynamically scaling cloud
environment
● Release artifacts are an OS image with the microservice provisioned
● OS Image is deployable to any environment
● Microservice redundancy can be scaled up and down as needed
● Containerization is another way to achieve immutable hardware
#dockerhype
Microservices in the Cloud
Immutable Hardware

34. 34
@kenzanmedia
www.linkedin.com/company/kenzan-media
techblog.kenzan.com
www.facebook.com/kenzanmedia/
Want to learn more?
Follow Us!