1.
June 2015 Tyk
Your API Strategy
Why Boring is Best
Martin Buhr
CEO @Tyk Technologies
https://tyk.io
@martinbuhr
lonelycode@fosstodon.org

2.
Tyk
4 /
Introduce yourself, Martin…

3.
Tyk

4.
June 2015 Tyk
Tyk API Management
APIs for the Modern Enterprise

5.
Tyk
4 /
Do the thing!

6.
Tyk

7.
Tyk

8.
Tyk

9.
Tyk
4 /
Varick says: Boring is good!

10.
3 /
Boring is dependable…
• Large talent pool
• Well distributed seniority
• Increased supply = affordable
• Widespread best practice
• Boring is good for team churn

11.
Tyk

12.
Tyk
6 /
Every team has one of these…

13.
Tyk

14.
Tyk

15.
Tyk

16.
Tyk

17.
Tyk
4 /
Rant #1: Serverless

18.
Tyk
6 /
Deploy your functions to a third-party
cloud and have them run only when needed,
then build you entire application this way…
What is it?

19.
Tyk
6 /
“Write once deploy anywhere”
A common phrase:
- Unnamed framework developer, 2009

20.
Tyk
Lock in?

21.
Tyk
Where have we heard that before?

22.
Tyk
Where have we heard that before?

23.
Tyk
Where have we heard that before?

24.
Tyk
6 /
… yes, yes they did.
Did someone say lock-in?

25.
Tyk

26.
Tyk
6 /
More like: buy more servers!
Serverless?

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…

29.
Tyk
So when it comes to serverless…

30.
Tyk
4 /
Rant #2: GraphQL

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…

33.
Tyk

34.
Tyk

35.
Tyk

36.
Tyk

37.
Tyk

38.
Tyk

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!

44.
Tyk

45.
3 /
So what does the grumpy one say?
GraphQL is great for:
• Interface developers
… no… no that’s all. Please stop.

46.
3 /
What is the boring way?
API Design is not application design
But!
Good application design can yield good API
design

47.
Tyk
4 /
Rant #3: Microservices

48.
Tyk
6 /
Increase the complexity of your application
and runtime environment by an order of
magnitude with this one simple trick!

49.
Tyk
An “ideal” microservice setup…

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

53.
Tyk
Thank you!
END /
Martin Buhr
CEO @Tyk Technologies
https://tyk.io
@martinbuhr
lonelycode@fosstodon.org