Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How not to lose your mind with too many microservices - Architecture Gathering 2016

How not to lose your mind with too many microservices - Architecture Gathering 2016

If you have too many microservices (which might be something > 30) you need a structured way to know what's going on and where to get more information about your system. We show two approaches how E-POST and Zalando going to solve this problem.

Oliver Wehrens

October 12, 2016
Tweet

More Decks by Oliver Wehrens

Other Decks in Technology

Transcript

  1. HOW NOT TO LOSE YOUR MIND
    WITH TOO MANY MICROSERVICES
    OLIVER WEHRENS - E-POST - @OWEHRENS
    FELIX MÜLLER - ZALANDO SE - @FMUELLER_BLN

    View full-size slide

  2. ONCE THERE WAS A MONOLITH.
    ▸ One (big) codebase
    ▸ Many teams working on it
    ▸ Lots of communication
    overhead
    T H E MONOLITH
    = Team

    View full-size slide

  3. THEN YOU TRY TO SCALE YOUR ORGANIZATION…
    T H E MONOLITH

    View full-size slide

  4. THEN YOU TRY TO SCALE YOUR ORGANIZATION…
    T H E MONOLITH
    UPS!

    View full-size slide

  5. YOU DECIDE TO GO FOR MICROSERVICE ARCHITECTURE.
    ▸ Only one team works on
    service codebase
    ▸ Independent deployment of
    business functionality
    ▸ Less blocking communication
    = Microservice

    View full-size slide

  6. EVERYTHING IS
    AWESOME !

    View full-size slide

  7. EVERYTHING IS
    AWESOME ?

    View full-size slide

  8. MICROSERVICES MEAN …
    ▸ More Services.
    ▸ More Teams.
    ▸ More Communication.
    ▸ More Documentation.
    ▸ More of everything.

    View full-size slide

  9. PROBLEMS TO SOLVE
    ▸ What is available on the platform ?
    ▸ What does the whole platform look like ?
    ▸ Who is responsible for a service ?
    ▸ How to get more information about a service ?
    ▸ Which Software versions and licenses do we use ?

    View full-size slide

  10. STANDARDS OR
    DIE.

    View full-size slide

  11. … OR HAVE METADATA
    (IN ONE PLACE).

    View full-size slide

  12. W
    I
    K
    I
    HERE
    NFORMATION
    ILLS
    TSELF

    View full-size slide

  13. WIKI (RANT)
    ▸ Created once
    ▸ Rarely updated
    ▸ Nothing can be found
    ▸ If updated, nobody knows if this is up to date
    ▸ Developers just don’t like update Wikis
    ▸ Use the source Luke.

    View full-size slide

  14. … OR COLLECT
    METADATA.

    View full-size slide

  15. MANUAL
    AUTOMATED
    BUILD TIME (SHOULD)
    RUNTIME (ACTUAL)

    View full-size slide

  16. MANUAL
    THINGS THAT DON'T
    CHANGE OFTEN

    View full-size slide

  17. AUTOMATED
    EVERYTHING ELSE (AS
    MUCH AS YOU CAN)

    View full-size slide

  18. BUILD TIME
    ▸ Everything available at Code Level & CI System
    ▸ VCS information
    ▸ License & Dependency information
    ▸ Build chain information
    ▸ Code Stats (Age, Committer, Language)

    View full-size slide

  19. RUNTIME
    ▸ VM Level
    ▸ Network connections
    ▸ Setup Level
    ▸ Sizing

    View full-size slide

  20. META DATA @
    ZALANDO SE

    View full-size slide

  21. RADICAL AGILITY
    ORGANISATIONAL
    CHANGE

    View full-size slide

  22. RADICAL AGILITY
    ▸ Autonomous teams working towards purpose
    ▸ Individuals striving for mastery
    ▸ Technical:
    ▸ Microservices
    ▸ API First
    ▸ REST, Cloud, Software as a Service…

    View full-size slide

  23. STUPS COMES WITH AN APPLICATION REGISTRY
    ▸ Kio as application registry
    ▸ each deployed application has to be registered there
    ▸ every version also has to be registered there
    ▸ information like vcs root, owning team, ticket system…

    View full-size slide

  24. ZALANDO’S FUTURE SYSTEM
    WILL CONSIST OF THOUSANDS
    OF MICROSERVICES.

    View full-size slide

  25. API DISCOVERY

    View full-size slide

  26. API DISCOVERY
    ▸ A system to crawl and curate all deployed APIs.
    TWINTIP
    CRAWLER
    TWINTIP
    STORAGE
    SWAGGER
    UI
    APIS

    View full-size slide

  27. THAT’S NICE BUT
    MICROSERVICES ARE MORE
    THAN APIS

    View full-size slide

  28. FULL-TEXT SEARCH ON ALL TECH DATA

    View full-size slide

  29. INFORMATION MANAGEMENT

    View full-size slide

  30. ZALANDO’S TOOLCHAIN
    ▸ Aggregate metadata automatically
    ▸ Top-Down approach
    ▸ API Discovery via Twintip
    ▸ https://github.com/zalando-stups/twintip-crawler
    ▸ IT Portfolio Management via LeanIX

    View full-size slide

  31. META DATA @
    E-POST DEV

    View full-size slide

  32. SITUATION
    ▸ ~ 250 Source code repositories
    ▸ 40 Services
    ▸ 12 Teams

    View full-size slide

  33. STATUS QUO
    SERVICE REGISTRY
    BACK THEN …
    Klaus

    View full-size slide

  34. OUR REQUIREMENTS
    ▸ Every VCS root needs documentation
    ▸ Description
    ▸ Type
    ▸ Team name
    ▸ Owner
    ▸ VCS & CI Information

    View full-size slide

  35. IN THE BEGINNING (Q4/2014) - THE GOOD
    ▸ Started with Wiki
    ▸ Description in yaml file in the Source Code
    ▸ Executed during CI Run
    ▸ Automated Code Dependencies via Maven, Gradle, SBT
    ▸ Formatted to HTML and uploaded to Wiki

    View full-size slide

  36. IN THE BEGINNING (Q4/2015) - THE BAD
    ▸ Search was limited
    ▸ Data could not be queried for additional benefit
    ▸ We had a couple of other places where we distributed
    information about services, what they do, how they get
    deployed etc.
    ▸ No immediate benefit, no problem when outdated

    View full-size slide

  37. WE NEED
    SOMETHING BETTER.

    View full-size slide

  38. OUR REQUIREMENTS
    ▸ General: Team name, Owner, a short name, description, type
    ▸ Runtime: memory needs, cpu, machine type
    ▸ Service: what do I provide, which port, protocol, private/
    public
    ▸ Dependencies to other services
    ▸ Software Dependencies and Licenses
    ▸ Query DSL

    View full-size slide

  39. WHAT’S OUT THERE?
    System-Z
    Services
    Directory
    NOT OPEN SOURCE

    View full-size slide

  40. PIVIO
    HTTP://PIVIO.IO

    View full-size slide

  41. PIVIO
    ▸ A (simple) system to describe service meta data
    CLIENT SERVER
    (WRAPPER)
    WEB
    DB
    (ELASTIC-
    SEARCH)
    JSON JSON
    YAML

    View full-size slide

  42. WHAT DOES IT
    LOOK LIKE ?

    View full-size slide

  43. PIVIO YAML
    ▸ One pivio.yaml file in root vcs
    directory
    ▸ Format at: http://pivio.io/docs/
    #section-dataformat
    ▸ Extendable to your own needs

    View full-size slide

  44. ELASTIC SEARCH BASED QUERY

    View full-size slide

  45. OUR REQUIREMENTS
    ▸ General: Team name, Owner, a short name, description, type
    ▸ Runtime: memory needs, cpu, machine type
    ▸ Service: what do I provide, which port, protocol, private/
    public
    ▸ Dependencies to other services
    ▸ Software Dependencies and Licenses
    ▸ Query DSL

    View full-size slide

  46. DATA QUALITY
    ▸ … is key!
    ▸ Organisational changes not reflected sometimes
    ▸ Owners don’t benefit from quality
    ▸ Make use of the data that are relevant to the creator!
    ▸ You will have dirty data.

    View full-size slide

  47. USE CASES FOR E-POST DEVELOPMENT
    ▸ Machine sizing for Open Nebula
    ▸ Service names for Consul
    ▸ TBD: Firewall rules generation
    ▸ General information about all services
    ▸ Visualize dependencies of teams and bounded contexts
    ▸ Impact analysis of changing APIs

    View full-size slide

  48. SOFTWARE VERSION DEPENDENCY CHECK (60 LINES OF JS)

    View full-size slide

  49. SERVICE DEPENDENCY CHECK (284 LINES OF JS)

    View full-size slide

  50. CONCLUSION
    ▸ Big Picture with micro services is hard
    ▸ Metadata helps to understand the system
    ▸ Needs to be easily editable (e.g. in the IDE)
    ▸ Needs to be useful to the creator
    ▸ Metadata will be dirty
    ▸ Link build time and runtime information
    ▸ Build tools on top of it, have a Query Language!

    View full-size slide

  51. THANKS.
    QUESTIONS?
    HTTP://PIVIO.IO
    @FMUELLER_BLN
    @OWEHRENS

    View full-size slide