The document discusses Martin Buhr's views on API strategies and technologies. It contains three rants about serverless, GraphQL, and microservices. In the rants, Martin argues that these technologies are often overused when simpler solutions would suffice. He believes serverless is best for prototypes and simple tasks, GraphQL introduces complexity by coupling services, and microservices should only be used when strict requirements for scale and availability demand it. Martin advocates for solid, boring design practices and stripping domains into microservices only when needed rather than taking a microservices-first approach.
10. 3 /
Boring is dependable…
• Large talent pool
• Well distributed seniority
• Increased supply = affordable
• Widespread best practice
• Boring is good for team churn
27. 3 /
So what does the grumpy one say?
Serverless is great for:
• Throwaway prototypes
• Repeated reporting tasks
• Nano-services
28. 3 /
And what is the boring way?
A server-less, can be a server more
As Lambda and cloud FN do not bore
But solid design
Yes, SOLID design, will be forever!
Generic abstractions to the dark side lead
And there the sharks of lock-in feed
So take the step, but choose wisely
For to shrink your bill is mighty unlikely…
31. Tyk
6 /
Add a SQL layer in front of your decoupled services
to recouple the decoupled layer into a single
interface to make interface developers happy…
32. Tyk
6 /
Add a SQL layer in front of your decoupled services
to recouple the decoupled layer into a single
interface to make interface developers happy…
39. Tyk
DB 1
Svc 1 Scv 1 Svc 2
DB 2
Svc 3
GW GW GW GW
A simple microservice setup…
40. Tyk
DB 1
Svc 1 Scv 1 Svc 2
DB 2
Svc 3
GW GW GW GW
A simple microservice setup…
41. Tyk
DB 1
Svc 1 Scv 1 Svc 2
DB 2
Svc 3
GW GW GW GW
Now with GraphQL
GraphQL Query Proxy
42. Tyk
DB 1
Svc 1 Scv 1 Svc 2
DB 2
Svc 3
GW GW GW GW
Now with GraphQL!
GraphQL Query Proxy
43. 1 /
You gone messed up now!
• GraphQL Proxy introduces a single point of failure
• You now have duplicate data schemas!
• If a service fails, the whole query will fail
• Why are you treating your services like a database?
• You can’t predict all code paths!
50. 1 /
Ok… so… what?
This is a shopping cart, that requires:
• Two database types
• Two programming languages
• A distributed schema
• Hopefully consistent?
WTF are you using Microservices for this??
51. 3 /
So what does the grumpy one say?
• Do you have insane scale?
• Is your availability really that bad?
• Do you have the resource to dedicate a
*team* per service?
• Have you hired a microservice expert to help
you?
52. 3 /
What is the boring way?
There is nothing new here:
• Build a monolith, but build it well
• Strip away domains into Microservices
when you *really* need it
• Don’t run microservice-first, because you
will triple your GTM time