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

Made with Slides.com