Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

It's all about resilience
APIDays 2014
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
Reminder: I don't work for Netflix, I just like the way
their solutions work
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
#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?
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!)
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

Use a spacebar or arrow keys to navigate