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

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

Transcript

1. HOW NOT TO LOSE YOUR MIND WITH TOO MANY MICROSERVICES OLIVER WEHRENS - E-POST DEVELOPMENT FELIX MÜLLER - ZALANDO SE
2. ONCE THERE WAS A MONOLITH. ▸ One (big) codebase ▸ Many teams working on it ▸ Lots of communication overhead T H E MONOLITH = Team
3. THEN YOU TRY TO SCALE YOUR ORGANIZATION… T H E MONOLITH
4. THEN YOU TRY TO SCALE YOUR ORGANIZATION… T H E MONOLITH UPS!
5. YOU DECIDE TO GO FOR MICROSERVICE ARCHITECTURE. ▸ Only one team works on service codebase ▸ Independent deployment of business functionality ▸ Less blocking communication = Microservice = Team
6. EVERYTHING IS AWESOME !
7. EVERYTHING IS AWESOME ?
8. MICROSERVICES MEAN … ▸ More Services. ▸ More Teams. ▸ More Communication. ▸ More Documentation. ▸ More of everything.
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 ?
10. STANDARDS OR DIE.
11. … OR HAVE METADATA (IN ONE PLACE).
12. W I K I HERE NFORMATION ILLS TSELF
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.
14. … OR COLLECT METADATA.
15. MANUAL AUTOMATED BUILD TIME (SHOULD) RUNTIME (ACTUAL)
16. MANUAL THINGS THAT DON'T CHANGE OFTEN
17. AUTOMATED EVERYTHING ELSE (AS MUCH AS YOU CAN)
18. BUILD TIME ▸ Everything available at Code Level & CI System ▸ VCS information ▸ License & Dependency information ▸ Build chain information ▸ Code Stats (Age, Committer, Language)
19. RUNTIME ▸ Service Level ▸ Network connections ▸ Setup Level ▸ Sizing
20. META DATA @ ZALANDO SE
22. RADICAL AGILITY ORGANISATIONAL CHANGE
23. RADICAL AGILITY ▸ Autonomous teams working towards purpose ▸ Individuals striving for mastery ▸ Technical: ▸ Microservices ▸ API First ▸ REST, Cloud, Software as a Service…
24. STUPS
25. OVERVIEW
26. 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…
27. ZALANDO’S FUTURE SYSTEM WILL CONSIST OF THOUSANDS OF MICROSERVICES.
28. API DISCOVERY
29. API DISCOVERY ▸ A system to crawl and curate all deployed APIs. TWINTIP CRAWLER TWINTIP STORAGE SWAGGER UI APIS KIO (APP REG)
30. SWAGGER UI
31. THAT’S NICE BUT MICROSERVICES ARE MORE THAN APIS
32. LEANIX
33. FULL-TEXT SEARCH ON ALL TECH DATA
34. INFORMATION MANAGEMENT
35. 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
36. META DATA @ E-POST DEV
37. SITUATION 2013 2016 VCS Roots 120 250 Services 30 ~80 Teams 14 10
39. STATUS QUO SERVICE REGISTRY BACK THEN … Klaus
40. OUR REQUIREMENTS ▸ Every VCS root needs documentation ▸ Description ▸ Type ▸ Team name ▸ VCS & CI Information
41. IN THE BEGINNING (Q4/2014) - THE GOOD ▸ Started with Wiki ▸ Description in yaml file in the Source Code ▸ Executed during CI Run ▸ Automated VCS root ▸ Automated Code Dependencies via Maven, Gradle, SBT ▸ Formatted to HTML and uploaded to Wiki
42. 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
43. WE NEED SOMETHING BETTER.
44. OUR REQUIREMENTS ▸ General: Team name, Owner, a short name, description, type ▸ Runtime: memory needs, cpu, machine type, network zone ▸ Service: what do I provide, which port, protocol, private/ public ▸ Dependencies to other services ▸ Software Dependencies and Licenses ▸ Query Language - do something with the data
45. WHAT’S OUT THERE? System-Z Services Directory NOT OPEN SOURCE
46. PIVIO ▸ A system to describe service meta data CLIENT DB (ELASTIC- SEARCH) SERVER (WRAPPER) JSON YAML JSON WEB CMD LINE
47. PIVIO - TECHNOLOGY ▸ Java ▸ Server in Spring Boot (~2k LoC) ▸ Executable command line client in Spring Boot (~1k LoC) ▸ Elasticsearch for document storage and Query Language
48. WHAT DOES IT LOOK LIKE ?
49. PIVIO YAML ▸ One pivio.yaml file in root vcs directory ▸ Contains all information we need for running the service, information and services ▸ Flexible data format, extendable
50. CHECKIN / CI RUN
51. OVERVIEW
52. DETAIL
53. DETAIL (II)
54. FEED
55. ELASTIC SEARCH BASED QUERY
56. MAIN FEATURES ▸ General information ▸ Ownership ▸ Service information ▸ Who do I need? ▸ What do I offer? ▸ … ▸ Dependencies & Licensing ▸ Deployment information, Sizing
57. DATA QUALITY ▸ … is key! ▸ Organisational changes not reflected sometimes ▸ Infrastructure changes (new network zones) ▸ Owners don’t benefit from quality ▸ Make use of the data that are relevant to the creator! ▸ You will have dirty data.
58. USE CASES FOR E-POST DEVELOPMENT ▸ Machine sizing for Open Nebula ▸ Service names for Consul ▸ General information ▸ Visualize dependencies of teams and bounded contexts ▸ Impact analysis of changing APIs
59. SOFTWARE VERSION DEPENDENCY CHECK (60 LINES OF JS)
60. SERVICE DEPENDENCY CHECK (284 LINES OF JS)
61. 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 (or necessary) ▸ Metadata will be dirty ▸ Link build time and runtime information ▸ Build tools on top of it, have a Query Language!
62. http://pivio.io http://github.com/pivio
63. THANKS. QUESTIONS? HTTP://PIVIO.IO @FMUELLER_BLN @OWEHRENS