Microservices with Go
Gendo Ikari (aka Daniele Maccioni)
Monolithic App
The default scenario
What is a microservices architecture?
Let's gather few general ideas...
Split the monolith into different components
Components are small (single responsability)
Every component is a single independent service
Components as services
"Smart endpoints and dumb pipes"
Design for failure
Decentralization (functionality and data)
One language to communicate across microservices: RPC/IPC
One consistent and established contract of interaction
Redundancy of small services
Isolation (avoid chain reactions)
Components:
independently replaceable
independently upgradeable
Dumb pipes:
all the routing logic goes in the nodes
the "smart" part of the system is the endpoint not the connection
Happy example: internet
Design for failure:
No single point of failure
Failure will happen: code around it, isolate and handle it
Happy example: again, internet
Decentralization:
Functionality are structured in separated microservices (redundancy)
Separated machine and processes
Different databases: do not communicate through database but through APIs
Who's using microservices?
Amazon
Netflix
Ebay
Uber
Zalando
...
a shittons of companies
Why microservices?
Monolithic is not inherently bad
microservices
solve organizational
problems
microservices
cause technical
problems
Organization problems
Scalability
Reliability problems
Redundancy
Resiliency
Team problems:
teams too large
teams deadlocked
Deployment speed
Innovation speed
scale up vs scale out
Conway's Law
Functional Teams
Technical problems
System testing
API design
Communication
Deploy and post deploy testing
Overall complexity
Shared memory, shared databases: synchronization and coherency
Service scheduling
Caching
Monitoring, logging, telemetry...
...
Why Go?
Parallelism "for free"
Efficient goroutine scheduler
Huge and robust standard library
Fast and reliable
Amazing tools
Super easy deployment
Example
Spotlights
small
pulling (or service discovery)
moving the focus from common technology to common interfaces, APIs and protocols.
"buy" is better than "build"
using the right tool for every job
data consistency
stateless
filesystem
Some Guidelines
Microservice Guidelines
Sufficiently small to be design and maintained by a small team (one developer)
Single bounded context (one software for one well defined domain)
Single logical database per service
Continuos integration
Workers faster than producers
Watch out for bottlenecks
thank you
Questions?
Made with Slides.com