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 ¹

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

Made with Slides.com