Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Próximo SlideShare
What to Upload to SlideShare
Siguiente
Descargar para leer sin conexión y ver en pantalla completa.

Compartir

2020 0116 Microservices from the trenches

Descargar para leer sin conexión

All the new architectures are based on microservices. It's a trend. It's a hype. Do we always need microservices? Why are they good? How can they be bad? You will also find a brief history of microservices and Conway's Law to understand how the idea started.
This talk will be a dialogue with the audience about architecture, and mainly microservices architecture.

Talk given at the Cloud Nativ Computing meetup in Bucharest https://www.meetup.com/Cloud-Native-Computing-Bucharest/events/267161640

Audiolibros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

2020 0116 Microservices from the trenches

  1. 1. Microservices from the Trenches Adrian Bolboacă A preachy stream of consciousness about business, analysis, architecture and code
  2. 2. Architecture - Strategy No strategy is perfect No strategy makes sense without the detailed tactics. Programming - Tactics Difficult to have an overview when being only tactical Common mistake: starting with tactics without having a strategy
  3. 3. There is no silver bullet There is no recipe There can be guidelines.
  4. 4. Microservices is a strategy useful for ● Parallelizing work for faster time to market (James Lewis) - - it needs more architecting and planning up-front ● Non-homogenous set of programming languages (James Lewis) - you can write each microservice is any language ● Increased scalability, especially with cloud computing (Adrian Cockroft) ● Parallel versioning (Fred George) ● Self-contained systems (Sam Newman) ● Self-healing systems
  5. 5. Microservices is a bad strategy when ● The boss wants the new hype ● There is no need to scale ● Only one portion of the big ball of mud (monolith) needs to scale ● The team is not proficient enough in architecture and domain modelling ● There is not enough organizational support for a paradigm change
  6. 6. Risks with microservices ● Dependency hell, when not architected well ● Increased operational costs ● Difficult debugging ● More complex security ● Distributed systems
  7. 7. Exercise - 5 minutes Draw your system as it would tell a story about what it does No technical terms allowed, only business.
  8. 8. Traps
  9. 9. Traps 1/2 ● Difficult to understand where to "cut" the domain ● May generate systems more difficult to work with than a monolith because of shotgun architecture ● Using any programming language and any technology can lead to having all of them in a few years, and nobody knows anymore how to change that (Spotify) ● Less focus on unit testing may lead to no automated testing, and relying on production testing (client testing)
  10. 10. Traps 2/2 ● Starting with no architecture (because we are agile), and rewriting the system every 2-3 years to fix it ● Macro-micro-services: not small enough -> all is dependent by all others ● Calling microservices directly instead of using events / messages ● Sharing data in-between microservices (not self-contained -> high coupling)
  11. 11. Some Theory
  12. 12. Conway's Law "organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations" Melvin Conway, “How do committees invent”, 1968 (Wikipedia) ● Microservices can take advantage of Conway’s law ● Complete decoupling => less communication => independent, parallel development ● Microservices enable developing a product with multiple teams in parallel
  13. 13. CAP Theorem “It is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency: Every read receives the most recent write or an error Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes” (Wikipedia)
  14. 14. CAP Theorem -> Eventual Consistency Basically Available: basic reading and writing operations are available as much as possible, but without any kind of consistency guarantees Soft state: without consistency guarantees, after some amount of time, we only have some probability of knowing the state, since it may not yet have converged Eventually consistent: If the system is functioning and we wait long enough after any given set of inputs, we will eventually be able to know what the state of the database is, and so any further reads will be consistent with our expectations (Wikipedia)
  15. 15. Microservices hype made programmers more aware of methods to modularise large monolithic systems, because of stricter component boundaries
  16. 16. Advice 1. Add more importance of principles like modularity, loose coupling, high cohesion, changeability, scalability, fault tolerance, resilience, testing, etc. 2. Never re-architect a system into microservices without making domain modelling first. Delete and repeat. A few times. Use Domain Modelling Kata 3. Always invite all the roles when modelling your domain architect, product, programmer, tester, security, ops, etc 4. Never re-architect at once the whole the system. Extract parts, one by one and always ask: is it enough? Can we stop? 5. Logging & Error Management: start having them from the very beginning
  17. 17. What's Next 1 Practice Architectural Kata - exercise your architecture post Domain Modelling Kata - exercise your modelling post Architecting Microservices workshop shameless promotion 2 Read Sam Newman - Building Microservices book James Lewis - Microservices Architecture article Eric Evans - Domain Driven Design book 3 Watch Martin Fowler - Microservices video James Lewis - Systems that are #neverdone video Chris Richardson – Microservice Patterns video
  18. 18. Adrian Bolboacă Blog https://blog.adrianbolboaca.ro Youtube https://youtube.com/adibolboaca Think. Design. Work Smart. https://www.youtube.com/channel/UCSEkgmzFb4PnaGAVXt K8dGA Works at https://mozaicworks.com Follow-up adrian.bolboaca@mozaicworks.com Follow-up https://twitter.com/adibolb VP of Innovation in Education and Technology @Mozaic Works
  19. 19. Thank you
  • CatalinTenescu

    Feb. 4, 2020
  • AndreiTimofte4

    Jan. 18, 2020

All the new architectures are based on microservices. It's a trend. It's a hype. Do we always need microservices? Why are they good? How can they be bad? You will also find a brief history of microservices and Conway's Law to understand how the idea started. This talk will be a dialogue with the audience about architecture, and mainly microservices architecture. Talk given at the Cloud Nativ Computing meetup in Bucharest https://www.meetup.com/Cloud-Native-Computing-Bucharest/events/267161640

Vistas

Total de vistas

362

En Slideshare

0

De embebidos

0

Número de embebidos

73

Acciones

Descargas

7

Compartidos

0

Comentarios

0

Me gusta

2

×