HOW TO BUILD THE
STATUS API
OF YOUR MICROSERVICES ECOSYSTEM
nano vazquez @nanovazquez87
Today's Agenda
#1
Scenario
#2
solution DESIGN
#3
IMPLEMENTATION & TOOLING
In most projects, the biggest challenge to solve is not technology, it's communication
SCENARIO
THE COMPANY
Multiple offices
Employees & teams
1200+ customers
MuleSoft
A typical day in production
What if we
#1
Multiply teams & Services by 10x
#2
Add dependencies between teams & services
#3
INCLUDE EXTERNAL SERVICES
How can we quickly know all of this?
Use cases to cover
I want to know if..
the dependencies of my service are up and running
For everything else, there's
my service is up and running
... and my service can reach its dependencies
The SOLUTION
(one of them)
Solution's recipe
#1
/ping endpoint
#2
/READY endpoint
#3
/Status endpoint
?
#4
Status Service
to rule them all
/ping
?
200 OK
-
Checks if A SERVICE IS UP AND RUNNING (livenesS)
-
Lightweight & Public
-
Usage: load balancers and developers
/READY
?
200 OK-
Checks if A SERVICE CAN PROCESS REQUESTS (READiNESS)
-
Restricted access
-
Usage: WARM-up time, maintenance time, TBD
/READY
?
DOes NOT CHECK external dependencies
/STATUS
-
Checks readiness of service and dependencies
-
RESTRICTED ACCESS & RATE LIMITED
-
Usage: INFORMATIVE (service & CONNECTIVITY are working)
?
200 OK
200 OK
200 OK
{
status: 'ok'
deps: [...]
}
/STATUS
checks if a service can reach its dependencies
?
200 OK
200 OK
{
status: 'degraded'
deps: [...]
}
/STATUS calls /ready
DOes not check THE ENTIRE ecosystem
/status
/ready
/ready
/ready
/service-status
-
Checks STATUS oF A SERVICE & ITS DEPENDENCIES
-
PROTECTED & RATE LIMITED
-
USAGE: INFORMATIVE (status of the ecosystem)
STATUS Service
/status
/status
/status
?
STATUS service
Services
SUMMARY
check status of entire ecosystem
A service is up and READY
A SERVICE CAN REACH ITS DEPENDENCIES
#1
#2
#3
/ping & /ready
/status
Status Service
IMPLEMENTATION & TOOLING
Where we are
Design solution
Implement API specification
Implement specification in apps
Create new tools
& tune existing tools
But if you are here it means that the hard part is already done
API SPECIFICATION
3.0
API MODELING FRAMEWORK
RAML
OpenAPI Spec
separation of concerns
reuse - consistency
modeling
common descriptor
tools
platforms
RAML
#%RAML 1.0
title: Status API
uses:
StatusLibrary: status-library.raml
/ping:
description: The liveness endpoint of your service
get:
responses:
200:
description: The service is up
/ready:
description: The readiness endpoint of your service
get:
responses:
200:
description: The service can process traffic
/health:
description: The health endpoint of your service
get:
responses:
200:
body:
application/json:
type: StatusLibrary.Health
RAML
#%RAML 1.0 Extension
title: NodeConfAPI
description: The API of the NodeConf
extends: status-api.raml
/talks:
description: The talks of this conference
get:
description: Get the talks of this conference
responses:
200:
body:
application/json:
example:
[
{
talk: 'How to create the Status API
of your microservices ecosystem',
speaker: 'nano Vazquez'
}
]
Exchange
Implementation
node.js
Java
osprey
TOOLING
/STATUS
{ status: "thank you" }
@nanovazquez87
How to build the Status API of your microservices ecosystem
By Mariano Vazquez
How to build the Status API of your microservices ecosystem
There are a number of things you need to know after your service goes to Production. The most simple and important one: is it working? And if it's not, where is the problem? Since these questions apply to all the services in your ecosystem and how they interact with each other, you might want to know this quickly and easily. But, more importantly, you want to design & implement this in a simple and secure way. In this talk, I'm going to talk about real-life examples that made us realize why this is important. And some of the tools we are using (and building) to know this real-time.
