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

1. Microservices from the
Trenches
Adrian Bolboacă
A preachy stream of consciousness about
business, analysis, architecture and code

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. There is no silver bullet
There is no recipe
There can be guidelines.

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. 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. Risks with microservices
● Dependency hell, when not architected well
● Increased operational costs
● Difficult debugging
● More complex security
● Distributed systems

7. Exercise - 5 minutes
Draw your system as it would tell a story about what it does
No technical terms allowed, only business.

8. Traps

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. 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. Some Theory

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. 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. 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. Microservices hype made
programmers more aware of
methods to modularise large
monolithic systems, because of
stricter component boundaries

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. 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. 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. Thank you