The part they do not tell you about micro services

My session presented at Java one @017

Transcript

1. The part they do not tell you about microservices MUKTESH MISHRA mukteshkrmishra@gmail.com Capital One LLC mukteshkrmishra 2017
2. License u Creative Commons Attribution-NonCommercial- 3.1 unported u https://creativecommons.org/licenses/by-nc/4.0/
3. WHO AM I u Senior Software Engineer at Capital One LLC u Interested in open-source, cloud and technology evangelism u Experienced in various Full stack technologies (UI to backend with DevOps added latest in armory) u Technical conference and meetup junkie u Open source contributor to various open source and Apache products (eg: Hystrix, Spinakker, etc.) u Reviewer in various JSRs u President, founder and member of various organizations/groups • Sunnyvale Java User Group • San Francisco Java User Group • Google Developer Group (SF Edition) • Java Community Program u Twitter: • https://twitter.com/mukteshkrmishra u Linked-in • https://www.linkedin.com/in/mukteshkrmishra/
4. Warning!! u This presentation could be using all well established norms in microservice world, but you will find some new challenges and ways to tackle them. u So hang tight and enjoy. J
5. My objective u Is: o To get you excited about some aspects which are not covered while switching to microservices o To make microservice architecture more manageable u Isn’t : o Branding/forcing to use any particular product / tools
6. Agenda u Why microservices u Challenges in adapting microservice architecture : The hidden part u Service discovery u Maintainability u Containerization and monitoring u Fallback behavior and monitoring u Our solution : A secret home home grown free recipe u Code demo
7. Why microservices u More atomic u Easy to develop u Easy decoupling between logics (core and business) u Polyglot persistence (since each module becomes an entity) u Easy to maintain (since code base is small) u Distributed data u Resilient and scalable
8. Here comes challenging part u Who likes challenges (everybody does, but upto some extent. That is what the main purpose to develop/ adapt a technology. u Service discovery u Scattered u Monitoring and alerting u Security u Containers (new guests joining the party)
9. Monitoring: the hardest part u What to monitor (to many components involved: jvm, Circuit breakers, containers) u Everything is so distributed, how do I monitor? u Containers are always changing their identity (ip and ports)
10. API 1 API n API 2 … API 1 API n API 2 … API 1 API n API 2 … Turbine Continuous Pull of metrics data PULL MODEL Dashboard pulls data from turbine Traditional world : I need more control beforehand.
11. ECS Overcoming the challenge.. API 1 … API 2 API n EC2 API 1 … API 2 API n EC2 ECS ECS PUSH MODEL Pulls metrics data from SQS Pushes metrics data to SQS
12. Time to see results..
13. Code example u Github link : Will be shared after the talk.
14. Got questions ? This is the time to ask…
15. Thank You! u • https://twitter.com/mukteshkrmishra u : • https://www.linkedin.com/in/mukteshkrmishra/ u Please do not forget to rate this talk. J