Mindset, infrastructural and organizational changes
to adapt to microservices
Armagan Amcalar
DevFest Siberia 2017
Sep 23rd, 2017
Who am I?
Armagan Amcalar
Head of Software Engineering @ unu GmbH
Founder @ Lonca Works
dashersw dashersw
AUTHORED ON GITHUB
Summary
Your team wants to adopt microservices.
Is your organization ready for the challenge?
What is not a microservice?
Async operations with queue (and other) systems
Having 50 different queue consumers (for notifications, logging, reconciliation services, e-mailing etc) doesn’t mean you have 50 microservices
Multiple programs running on a single machine and communicating over HTTP
What is a microservice?
If you are breaking down the fulfillment of a client request into multiple collaborating services that run in their own memory space, then you are doing microservices.
THE BASELINE
Microservices ctd.
Bounded contexts in domain driven design (at worst)
Request–response flow breakdown with
preferably many smaller pieces (with separate codebase)
A bug in a service doesn't bring down the whole app
Scales well, needs minimal additional resources
Supports event-driven architecture
Single responsibility, API interface
Best practices
Clear interfaces between services
Auto discovery
Dynamic (or zero) configuration
High availability
Scale and update single services
Favor cattle over pets
Pitfalls
Wrong domain model
Error handling & circuit breaking
Fault-tolerance
Monitoring
Multiple points of failure
Hard to get the big picture
CHANGE
is the essence of the game
Code will rapidly change
Dependencies will change
Deployment & release processes will change
What will change?
How can you adapt?
Mindset changes
Prepare for and own the change
Defer responsibilities
Increase visibility on dependencies and interfaces between software components
Architectural documents are back
DevOps movement
Integration tests are a lot more important
Controversy: decrease unit and functional tests and increase automated user acceptance tests.
Benefits
Increase in code ownership
Awareness of impact
Increase in communication
Reduced stress due to automation
Architecture is straightforward; reduces ambiguity for what implementation belongs in what class
DDD is more important, more straightforward
Infrastructural changes
Freedom to use the best tool for the job
Invest in a solid CI/CD process
Pipelined builds with several stages
Containerize your application
Invest heavily in monitoring
Benefits
No vendor lock in
No secret sauce
No surprises
Migration is damn easy
Adopting new technologies is lightning fast
Organizational changes
Team structure completely changes
Scrum teams will get an update
Release management becomes a first-class citizen
Hierarchy is eliminated
Find other ways to keep a consistent vision within the team
Benefits
Increased agility
Smaller teams lead to easier decisions
Helps with planning for impediments and dependencies; “blocked-by hell”
Increased happiness
Increased productivity
Fit for distributed teams!
Conclusion
Microservices will supercharge your organization.
The future is bright and the game is afoot!
thank you!
Let's keep in touch!
Armagan Amcalar