Applying microservices principles with Byron
Who are we?
USPCodeLab's current president, undergrad student aiming for a master's degree, fullstack developer (mainly back-end). Also have a teacher's spirit.
USPCodeLab's co-founder and ex-president, worked at VTEX and QuintoAndar, fullstack developer (mainly front-end), technology hipster.
João F. Daniel
Leonardo Lana
"A microservices architecture is only necessary in a large, complex dev environment. Most shops would be better off just using simple monoliths following SOLID principles and reap benefits from frequent small deployments"
Monolith
Service Oriented Architecture
Synchronous Microservices
Asynchronous Microservices
Cloud Native
Reactive
BYRON
Monolith
Service Oriented Architecture
Synchronous Microservices
Asynchronous Microservices
Cloud Native
Reactive
BYRON
single codebase,
so not that complex
The Monolith
organized ways, such as Layered Architecture
sparses releases
waste of resources when scaling up
multiple devs leads to branching hell
The Monolith
All devs over the same repo, no good comes from that, right?
So you're scaling up, huh? Make a copy of the whole thing!
Monolith
Service Oriented Architecture
Synchronous Microservices
Asynchronous Microservices
Cloud Native
Reactive
BYRON
extensible, just add a new service
S. O. A.
services don't need to know about the others
"smart" ESB?
EBS smells, ugh!
Big Ball of Mud ¹
ESB is a bottleneck, problem scaling up
¹: more here https://joeyoder.com/PDFs/mud.pdf or the man himself
S. O. A.
So services don't need to know about the others... but how do they chat?
A wild ESB appears!
Monolith
Service Oriented Architecture
Synchronous Microservices
Asynchronous Microservices
Cloud Native
Reactive
BYRON
scalability on demand
Sync MS
optimises team division
problems with response time
services are highly coupled
indicates a connection
Sync MS
What if a service dies?
But there are problems even when things are working fine!
Monolith
Service Oriented Architecture
Synchronous Microservices
Asynchronous Microservices
Cloud Native
Reactive
BYRON
exchange messages through a "dumb" broker (but resilient as hell)
Async MS
services are highly decoupled
data replication
eventual data consistency
Async MS
The system works with a pub/sub mechanism
A demo: when one publishes an event, all subscribed receive it
Monolith
Service Oriented Architecture
Synchronous Microservices
Asynchronous Microservices
Cloud Native
Reactive
BYRON
Resiliency
Agility
Operability
Observability
Embrace failure instead of trynig to prevent them
Allow fast deliveries and quick iterations
Provide inner lifecycle control instead of relying on external tools
Provide information that answer questions about the state of the application
Cloud Native
Responsivity
Resiliency
Elasticity
Message Driven
Provide consistent and reasonable response times
Keep the system responsive in case of failure
Keep the system responsive under various load conditions, no bottleneck
Provide decoupling by exchanging async messages between components
Reactive
How can I build an event-driven async microservice?
Splitting into MS
- hard to define "the best" approach, trade-offs
- serverless is interesting, but quite off-topic for tonight
- from DDD, Bounded Context ¹
¹: more here https://martinfowler.com/bliki/BoundedContext.html
Splitting into MS
same entity
different views
Independence and autonomy
- services must be independent, decoupled
- from OO's SOLID ¹, Single Responsability applies
- data replication
- Event Sourcing to get data from other services
Independence and autonomy
A demo: the travel of an event of "new user", each service takes just what it needs from the event
And how does Byron work?
request
response
read
write
event
notification
request
response
read
write
event
notification
replays
messages
rebuilds the final state
- disposability of local cache
- Single Source of Truth
- Data Lake
Notes:
A little bit of our journey up to now
Byron Framework
By João Daniel
Byron Framework
A talk created to be presented at PagSeguro
