My journey through microservices so far…

Preview:

Citation preview

My journey through microservices so far…

Phil Calçado h:p://philcalcado.com @pcalcado

Zeroth IteraBon: ThoughtWorks

What the client’s architect oGen wanted

WebSphere

Monolith.ear

Tomcat

TomcatTomcat

TomcatTomcat

TomcatTomcat

Tomcat

What we wanted to build

.war .war .war .war

.war .war .war .war

What we oGen built

.jar .jar .jar .jar

.jar .jar .jar

WebSphere

.jar

First IteraBon: SoundCloud

Small European company fighBng the giants of the music industry.

"We used to deliver features at light-speed, growing the team has slowed us down!"

Old value chain

Amongst other changes

New value chain

h:p://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html

Second IteraBon: DigitalOcean

Small New York startup fighBng the giants of cloud compuBng.

"We know exactly what we need to deliver. All we need is to hire more people."

No new product in years.

! "

#

Control Panel Group Internal Tools Group

Back-end Group

Control Panel Microlith Internal Tools Microlith

Back-end Microlith

Amongst other changes

In Conclusion

Engineering is the bo:leneck

Legal/Product is the bo:leneck

Engineering is the bo:leneck

Legal/Product is the bo:leneck

Fin.

…or is it?

server

client

server

client

🔥 🔥 🔥

🔥

wait

☺😰

🔥 🔥

wait

☺ 😰

🔥

server

client client client client client client

🔥

wait

☺😰

🔥 🔥

wait

☺ 😰

🔥

🔥

wait

☺ 😰

🔥 🔥

wait

😰 ☺

🔥 🔥

wait

😰 ☺

🔥 🔥

wait

😰 ☺

🔥 🔥

🔥

🗑

"I know, let’s have all circuit breakers share state”

"I know, let’s have all circuit breakers share state”

Answer to the question “how did my application ended up importing a Zookeeper library again?"

server

client

🔥 🔥 🔥server server serverserver

🔥 🔥 🔥 💩

🤔

Which instance should we talk to?

DNS be like…

*

Circuit breakersTimeouts

This is your code on microservices

Biz Logic

Timeouts

Telemetry

Distributed state

Client-side Service Discovery

The dirty li:le secret no microservices

evangelist tell you:

Google/SoundCloud/Twi:er/Nedlix/Facebook/etc. have more

engineers working on their internal tooling than the total number of employees at your workplace.

i.e. microservices are complicated af

Third IteraBon: Buoyant

Circuit breakers

Timeouts

Biz Logic

Timeouts

Telemetry

RPC code

Distributed state

Client-side Service Discovery

SDK

Historically, this complicaBon leaks into your service

Sidecars to the rescue

Circuit breakers

Timeouts

Biz Logic

Timeouts

Telemetry

RPC code

Distributed state

Client-side Service Discovery

SCARY OUTSIDE WORLD

Sidecars to the rescue

Circuit breakers

Timeouts

Biz Logic

Timeouts

Telemetry

RPC code

Distributed state

Client-side Service Discovery

SCARY OUTSIDE WORLDSidecar

Sidecars form their own network

ApplicaBon

Transport

Internet

Network

Circuit breakers

Telemetry

RPC code

Distributed state

Client-side Service Discovery

} TCP/IP

} ?

One way to think about it

Two examples of Service Mesh

• All-in-one • ProducBon ready

• Next-generaBon • For Kubernetes

It’s not that these pa:erns aren’t used anymore, it’s just that the

dumb work moved down the stack.

New, optmised, protocols are quite opaque (e.g. gRPC and friends)

Works be:er with metadata-rich protocols

It makes it even harder to fully replicate producBon earlier in the development cycle

Coupled to the pladorm

Not everything will be part of the mesh, i.e. the network sBll isn’t homogeneous

Leaky abstracBon

Q&A

Recommended