Mindset, infrastructural and organizational changes
to adapt to microservices
Armagan Amcalar
DevOps Pro Moscow
November 16th, 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?
dashersw
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
dashersw
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
dashersw
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
dashersw
Best practices
Clear interfaces between services
Auto discovery
Dynamic (or zero) configuration
High availability
Scale and update single services
Favor cattle over pets
dashersw
Pitfalls
Wrong domain model
Error handling & circuit breaking
Fault-tolerance
Monitoring
Multiple points of failure
Hard to get the big picture
dashersw
CHANGE
is the essence of the game
dashersw
Code will rapidly change
Dependencies will change
Deployment & release processes will change
What will change?
dashersw
How can you adapt?
dashersw
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.
dashersw
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
dashersw
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
dashersw
Benefits
No vendor lock in
No secret sauce
No surprises
Migration is damn easy
Adopting new technologies is lightning fast
dashersw
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
dashersw
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!
dashersw
Conclusion
Microservices will supercharge your organization.
The future is bright and the game is afoot!
dashersw
thank you!
Let's keep in touch!
Armagan Amcalar