Problems you’ll face in the microservice world: configuration, authentication... - rubyC 2017 Kiev
•Download as PPTX, PDF•
1 like•625 views
Ok, Everybody know it, microservice is great. I am confident on this too, for 5 years the all Clever Cloud architecture is based on it. But, as all the new trendy buzzword, it’s not a silver bullet, and there is several problems to manage. One is the authentication, distributed authentication is hard, and there is many ways to achieve it. Configuration is the second issue to be managed when dealing with distributed micro application strategy. This talk is a concrete return of experience to build a strategy on microservice and problems we will have to deal on this occasion.
Recommended
Recommended
More Related Content
More from Quentin Adam
More from Quentin Adam (20)
Recently uploaded
Recently uploaded (20)
Problems you’ll face in the microservice world: configuration, authentication... - rubyC 2017 Kiev
- 1. Problems in the microservice world: Authentication, communication, configuration and boundaries Quentin ADAM - @waxzce
- 2. Who am I ? Quentin ADAM from the Clever Cloud @waxzce on twitter – github- soundcloud – instagram ….
- 3. My day to day work : , the IT automation company
- 4. Keep your apps online. made with node.js, scala, java, ruby, php, python, go… Cloud & on premise
- 5. And learn a lot of things about your code, apps, and good/bad design…
- 6. Give back to the community NEVER GONNA LET YOU DOWN clever-cloud.com
- 7. The beginning How Clever Cloud start? How the roadmap was define.
- 10. Dog container
- 11. We are happy
- 12. Multiple stacks
- 13. Scaling
- 14. Evolution
- 15. Team management
- 16. Architecture as a playground Lego FTW
- 19. Server -> Server • Authenticated • Encrypted • Auditable/logged 🔪
- 20. Loosely coupled
- 21. Routing is a problem
- 22. Message box
- 25. HTTP for all?
- 26. Messages brokers • RabbitMQ • FR: https://www.youtube.com/watch?v=VBUQXM96hpw • EN: https://www.youtube.com/watch?v=15mzY2MfDgM • Kafka • Redis? • 0MQ? • Warp10 / time series DB📬
- 27. The right size? What is the boundaries of a microservice
- 29. Beware of (massive) RPC (Remote Procedure Call)
- 30. Network is two problems: Fragile and Slow
- 31. 📦 Micro services is not Workload Distribution 👁 akka, project orleans, Erlang OTP, hadoop…
- 32. One service do have to actually provide a service by itself
- 33. Fat monoliths
- 34. Micro service creating too much lib?
- 35. Why theses two functions are in the same services? Or can I 👁 it?
- 36. Does we have a common data store?
- 37. Does this features need the same scaling agenda?
- 39. Configuration on multiple spots
- 41. Zk, etcd, consul… So many possibilities
- 42. Simpler way, never change on runtime Immutable infrastructure (FR) https://www.youtube.com/watch?v=WrZCbgQsPVU
- 43. Agnostic solution: Environment variable
- 45. No over engineering on configuration, when you need to configure the configuration injector, you are too far 🖇
- 46. Who the hell are you? Distribute Authentication
- 47. Distribute Identity and ACL
- 48. Common solutions (or not)
- 49. Shared data repository Redis Service A (php) Service C (java) Service B (nodejs)
- 50. Authentication using a proxy Request Reverse Proxy + Database call + Business code + Authentication Service A Service B Service C Authenticated request with user identity data
- 51. Central API call to authenticate request Request Via reverse proxy Service A Service B Service C Authentification API
- 52. We need more tools 👁 🔧 🔩 ⛏ ⚒ 👁
- 53. JWT
- 54. Macaroons
- 55. Keep hackable and pluggable playground to enforce innovations
- 56. Maintenance
- 57. Clean legacy code on regular basis Why and how bookkeepers f***d up IT FR https://www.youtube.com/watch?v=0ip1FoBsLB4 EN https://www.youtube.com/watch?v=OngWRJ8txps
- 59. No dogma, full developer hapiness oriented architecture
- 60. Thank you find me on twitter @waxzce Gift coupon for clever-cloud.com: rubyc17roxx
Editor's Notes
- Exemple à Clever Cloud
- The first idea to many developer is to share the access to a database with the session data (memcached or redis), and read access to the ACL database (SQL or something) Issues on this : - change to the data model require to edit all the series - impose rude connection and pooling to the databases, which is an OPS problem - creating a SPOF - impose lots of code rewriting in each micro service
- Good part is : - centralisation of authentication and code related to it Issues : - Very complicated to mock on developer laptop : you need to launch the proxy on dev computer - Security vision is optimistic - The user infos add by the proxys aren’t requested by service, so it’s standard or convention between proxy and service - proxy is a spot mix several mission on the proxy : routing, load balancing, authentication, session hydratation… PERFORMANCES
- Central authentication API called by services In this architecture, service take request directly and call an API to authenticate the request, serializing verb, resources and headers and asking for extra info they will need (user infos), the authentication API respond authentication and user info requested by the service. Good parts : - easy to mock and work on developer part, no need to start on developer computer - centralisation of the authentication - security is better handled and there is less possibility to breach the system spoofing requests - services request additional infos, more simple to do Issues : - authentication API is a spof
- Signature