All is not completely rosy in microservice-land. It’s often a sign of an architectural approach’s maturity that anti-patterns begin to be identified and classified alongside well-established principles and practices. Daniel Bryant introduces seven deadly sins from real projects, which left unchecked could easily ruin your next microservices project. Daniel offers an updated tour for 2016 of some of the nastiest anti-patterns in microservices from several real-world projects he’s encountered as a consultant, providing a series of anti-pattern “smells” you can sniff out and exploring the tools and techniques you need to avoid or mitigate the potential damage. Topics include: Pride: Selfishly building the wrong thing, such as the "Inter-Domain-Enterprise-Application-Service-Bus” or a fully bespoke infrastructure platform Envy: Introducing inappropriate intimacy within services by creating a shared “canonical” domain model Wrath: Failing to deal with the inevitable bad things that occur within a distributed system Sloth: Composing services in a lazy fashion, which ultimately leads to the creation of a "distributed monolith” Lust: Embracing the latest and greatest technology without evaluating the operational impact incurred by these choices

1. The Seven (More) DEADLY SINS OF Microservices
Daniel Bryant
@danielbryantuk
OpencRedo / Spectolabs

2. Previously, AT Devoxx UK & QCON NYC 2015...
16/10/2016 @danielbryantuk
https://www.infoq.com/presentations/7-sins-microservices

3. The Seven (more) Deadly Sins of Microservices
1. LUST - Using the (Unevaluated) latest and greatest tech…
2. GLUTTONY - Communication lock-in
3. GREED - What'S Mine is mine (within the organisation)…
4. SLOTH - Getting lazy with NFRs
5. WRATH - Blowing up when bad things happen
6. ENVY - The shared single domain (and data store) fallacy
7. PRIDE - testing in the world of transience
16/10/2016 @danielbryantuk

4. @danielbryantuk
• Chief Scientist at OpenCredo, CTO at SpectoLabs
ü Transforming organisations through technology and teams
ü Agile, Lean, Architecture, CI/CD, DevOps
ü Microservices, cloud, Containers, Java, Go, Docker, Kubernetes
• London Java Community Associate
• Adopt OpenJDK and JSR
• InfoQ Editor, DZone MVB, VOXXED, O'Reilly
16/10/2016 @danielbryantuk

5. So, What is a microservice?
“Loosely coupled service oriented architecture
with bounded contexts”
Adrian Cockcroft
“Applications that fit in your head”
James Lewis
16/10/2016 @danielbryantuk

6. 1. Lust - Using THE LATEST and Greatest Tech…
16/10/2016 @danielbryantuk

7. New technology is great... Until it isn'T
16/10/2016 @danielbryantuk
developers with new tech be like
F**king new technology...
Credit to Michael Hausenblas
This has been me
many times!

8. Evaluation is a critical skill
• Systematic, transparent, and thorough (Fit for purpose)
• Open source makes this even more important
– Plethora of open source technologies and tools
– Easy to try and move on (for better or worse)
– Open source knowledge must also be evaluated
16/10/2016 @danielbryantuk

9. Evaluation - are Microservices A good fit?
• Not understanding principles (Cargo-culting)
– Not building around business Functionality
– Creating Mini-monoliths (no twelve factors)
• “our 'mode TWO' apps are Microservices”
– SOE evolution limited by SOR
– Lipstick on the pig
• No Well-defined DevOps / SRE / Ops
– Deployment/ops free-for-all
16/10/2016 @danielbryantuk

10. 18/10/2016 @danielbryantuk

11. Evaluation - are Microservices A good fit?
17/10/2016 @danielbryantuk
speakerdeck.com/acolyer/making-sense-of-it-all http://www.slideshare.net/dbryant_uk/ctos-in-london-the-challenges-
of-evaluating-development-technology-within-the-csuite

12. Evaluation of tech - Fitness functions
• Great for evaluation and documentation
– Platforms / Language
– Middleware
– Data stores
• Microservices as an Evolutionary Architecture
– Neal Ford and Rebecca Parsons
16/10/2016 @danielbryantuk

13. Evaluation of tech - The’Spine Model
• Effective conversations make for effective
collaboration
• It's a TOOL Problem
– As a species, we have always been Tool users
and makers.
– We use _____ to get our work done
• People get stuck in a dilemma where equally
plausible options are available
• “Going up the Spine” breaks deadlock http://spinemodel.info/explanation/introduction/

14. Evaluation - It'S easy to be tricked
16/10/2016 @danielbryantuk

15. Evaluation - beware of bias and heuristics
16/10/2016 @danielbryantuk

16. 2. GLUTTONY - Communication lock-in
16/10/2016 @danielbryantuk

17. Rpc - not the devil in disguise
• Don'T rule out RPC (e.g. grpc)
– Sometimes the contract (and speed) are beneficial
– Human readability of JSON is over-rated
• Stick to rest (JSON over HTTPS) on the front-end
– Principle of least surprise
– Best support in Javascript/mobile
16/10/2016 @danielbryantuk

18. The ESB is dead - long live the esb!
16/10/2016 @danielbryantuk

19. The ESB is dead - long live the esb!
16/10/2016 @danielbryantuk

20. The ESB is dead - long live the esb!
16/10/2016 @danielbryantuk
• Is this an ESB?
• Or an API gateway?

21. The ESB is dead - long live the API Gateway!
16/10/2016 @danielbryantuk
• Watch for the API Gateway morphing
into an Enterprise service bus
– Loose coupling is vital
• But let me be clear...
– The API Gateway pattern is awesome
– Centralise cross-cutting concerns
– Prevent wheel-reinvention (plugins)
– Check out kong, apigee, Mulesoft etc

22. 3. GREED - What'S mine is mine... (within the organisation)…
16/10/2016 @danielbryantuk

23. Previously...
• Conway'S Law
• Microservices are about people, as much as they are tech
– Maybe more
– Particularly in a migration / transformation
16/10/2016 @danielbryantuk

24. We hear this a lot...
“We’ve decided to reform our teams around squads, chapters and guilds”
• Beware of cargo-culting
– Repeat three times “We are not spotify”
• Understand the practices, principles, values etc
16/10/2016 @danielbryantuk

25. Empathy - The Hidden ingredient in Good software development
16/10/2016 @danielbryantuk
www.ustream.tv/recorded/86154111

26. 4. SLOTH - Getting Lazy with NFRs
16/10/2016 @danielbryantuk

27. Getting lazy with non-Functional Requirements
“The driving technical requirements for a system should be identified early
to ensure they are properly handled in subsequent design”
Aidan Casey
Guiding principles for evolutionary architecture
16/10/2016 @danielbryantuk

28. Getting lazy with non-Functional Requirements
• The 'ilities' Can be (often) be an afterthought
– Availability, Scalability, auditability, testability etc
• Agile/Lean: Delay decisions to the ‘last responsible moment’
– NewsFlash - Sometimes this is up-front
• It can be costly (or prohibitive) to adapt late in the project
– Microservices don'T make this easier (sometimes more difficult)
16/10/2016 @danielbryantuk

29. Getting lazy with NFRs - security
16/10/2016 @danielbryantuk
www.slideshare.net/spnewman/appsec-microservices-velocity-2016 www.infoq.com/news/2016/08/secure-docker-microservices

30. Testing NFRs in the build pipeline
• Performance and Load testing
– Gatling / jmeter
– Flood.io
• Security testing
– Findsecbugs / OWASP Dependency check
– Bdd-security (OWASP ZAP) / Arachni
– Gauntlt / Serverspec
– Docker Bench for Security / AQUA
16/10/2016 @danielbryantuk

31. 5. WRATH - Blowing up when bad things happen
16/10/2016 @danielbryantuk

32. Previously - Bring in Michael Nygard (Or some monkeys)
16/10/2016 @danielbryantuk

33. When bad things happen, people are always involved
16/10/2016 @danielbryantuk | @oakinger

34. People Pain point - How does Devops fit into this?
• http://web.devopstopologies.com/
• @ matthewpskelton
• @beerops and @sigje
• Google SRE
16/10/2016 @danielbryantuk

35. Devops - the 'fullstack engineer' myth
“I'M sorry, but if you'RE not designing the computer chips and
writing the website, then I don'T wanna hear from you”
Charity Majors (@mipsytipsy), CraftConf 2016
http://www.ustream.tv/recorded/86181845
16/10/2016 @danielbryantuk

36. Devops - define responsibilities
• Do you really want to build an
entire microservices platform?
• Focus on what matters
– Ci/CD
– Mechanical sympathy
– Logging
– Monitoring
16/10/2016 @danielbryantuk

37. Open source PaaS
16/10/2016 @danielbryantuk

38. 6. ENVY - The shared SINGLE domain (and Data Store) fallacy
16/10/2016 @danielbryantuk

39. Previously - One Model to Rule Them All...
• One model…
– Breaks encapsulation
– Introduces coupling
• Know your DDD
– Entities
– Value Objects
– Aggregates and Roots
16/10/2016 @danielbryantuk

40. Context mapping (static) & event storming (dynamic)
16/10/2016 @danielbryantuk | @spoole167 40
www.infoq.com/articles/ddd-contextmapping
ziobrando.blogspot.co.uk/2013/11/introducing-event-storming.html

41. Choose (and use) data stores appropriately
• RDBMS
– Valuable for structured data
• Cassandra is Awesome
– but don'T treat it like an RDBMS!
• Don'T build a graph with RDBMS
– Use neo4j, Titan etc
• Beware of operational overhead
16/10/2016 @danielbryantuk

42. 7. PRIDE - testing in the world of transience
16/10/2016 @danielbryantuk

43. Previously...
• Local verification
– Consumer-Driven contracts
• End-to-end
– BDD-style critical path
• Remember the test pyramid
16/10/2016 @danielbryantuk
martinfowler.com/articles/microservice-testing/

44. Service virtualisation / API simulation
• Virtualise request/response of services
– Unavailable
– Expensive to run
– Fragile/brittle
– Non-deterministic
– Cannot simulate failures
https://dzone.com/articles/continuously-delivering-soa
16/10/2016 @danielbryantuk

45. Service virtualisation
• Classics
– CA service virtualization
– Parasoft virtualize
– HPE service virtualization
– IBM Test Virtualization server
• New (open source) kids on the block
– Hoverfly
– Wiremock
– VCR/Betamax
– Mountebank
– mirage
16/10/2016 @danielbryantuk

46. Hoverfly
• Lightweight Service virtualisation
– Open source (Apache 2.0)
– Go-based / single binary
– Written by @Spectolabs
• Flexible API simulation
– HTTP / HTTPS
– Highly performant
16/10/2016 @danielbryantuk

47. 16/10/2016 @danielbryantuk
• Middleware
• Remove PII
• Rate limit
• Add headers
• Middleware
• Fault injection
• Chaos monkey

48. Hoverfly JUnit rule
16/10/2016 @danielbryantuk

49. Right, Let'S Wrap this up...
16/10/2016 @danielbryantuk

50. The Seven (more) Deadly Sins of Microservices
1. LUST - Using the (Unevaluated) latest and greatest tech…
2. GLUTTONY - Communication lock-in
3. GREED - What'S Mine is mine (within the organisation)…
4. SLOTH - Getting lazy with NFRs
5. WRATH - Blowing up when bad things happen (txns and ops)
6. ENVY - The shared single domain (and data store) fallacy
7. PRIDE - testing in the world of transience
16/10/2016 @danielbryantuk

51. The Seven (more) Deadly Sins of Microservices
1. LUST - Using the (Unevaluated) latest and greatest tech…
2. GLUTTONY - Communication Lock-in
3. GREED - What'S Mine is mine (within the organisation)…
4. SLOTH - Getting lazy with NFRs
5. WRATH - Blowing up when bad things happen (txns and ops)
6. ENVY - The shared single domain (and data store) fallacy
7. PRIDE - testing in the world of transience
16/10/2016 @danielbryantuk

52. Bedtime reading
16/10/2016 @danielbryantuk

53. THANKS...
@danielbryantuk
daniel.bryant@opencredo.com
http://muservicesweekly.com/
(Credit to Tareq Abedrabbo for inspiration/guidance)
16/10/2016 @danielbryantuk