Deck Title

It's all about resilience

APIDays 2014

@_dmartin_

David MARTIN

Consulting Director

Overlooked aspects of your API

We all know API must follow a set of rules
(right use of media types, hypermedia relations, ...)

Huge popularity?
Critical business responsibility?

BUT... Are we ready to face:

In other words...

scale (up/down)?
gracefully deal with problems?

Is our API ready to:

Uh... Let me think about it...

We HAVE the solution

The Cloud will save us:
scalability and redundancy

TADA!!! Job's done

Thank you for your attention

The End

No, life is not that simple!

Your API is more complex than a
single autonomous application

Maybe a single load balancer
is not really what you want/need

So what?

1. You can simply cross your fingers
and close your eyes to avoid problems

2. You can build your own genius
platform and tools from scratch

3. Or you can rely on existing
and proven solutions and just adapt
and configure them

I don't know about you...

But I clearly prefer #3

(self-preservation advice)

Let's introduce one of these solutions

Netflix Open Source Stack

About 50 projects

netflix.github.io

Reminder: I don't work for Netflix, I just like the way
their solutions work

Protip:
The cloud is part of the answer
It will bring the scalability

But your API must be ready to embrace it

Sadly, things are not simple

Your API may be more complex than a
single autonomous application:

dependencies with other API or services
how many of them?
which instances are ready when needed?
how to load balance requests among them?

Uh... Are you sure?

#1 EUREKA (1/2)

A (multi nodes) service registry
A client component

Register an API/service
Renew periodically this registration
Fetch server registry and keep a local copy

Clients:

#1 EUREKA (2/2)

If a client fails, the server will unregister it

If the server registry fails, the clients
can still work with their local registry

Ok, why not...

But where is my load balancer?

#2 RIBBON

Inter Process Communication component
with built in load balancer mechanism

Round robin
Response time weighted
Random load balancing
Your own mechanism

And it can use Eureka client data
to route requests

But what if a dependency just slows down
(load, network latency, ...) or throws errors?

How to handle this?

#3 HYSTRIX (1/2)

Circuit Breaker implementation

run()
fallback()

Wraps your requests and decides, depending on
previous errors, a current error, which method to execute:

#3 HYSTRIX (2/2)

"Are we done yet?"

-"No, just a last thing"

-"Hurry up David: time flies!"

Resilience is also
the ability to cope with change

You may (should) want your
public API to be decoupled from
your internal API and services

(Answer: YES!)

#4 ZUUL

Edge (public entry point) service application
A gateway service with cool super powers

handle authentication and security
dynamically route requests
serve static content
protect the system with thresholds
... do what you want with your own filter

Acts as a filter chain to:

Enough for now!

Just sum things up

Last slide!

Thank you

David Martin

@_dmartin_