Introducing Service Dependencies

At Clever Cloud, we've started using microservices before it was cool™. Today we're excited to launch service dependencies, to simplify microservices management.

The microservices graph

When you ditch your monolith and go full microservices, your application becomes a graph of loosely coupled microservices.

For instance, an typical service API can depend on:

• an auth microservice to validate requests
• a notification gateway to send notification

In turn, the notification gateway can depend on:

• an email gateway
• a push notification gateway

So you have a graph of services, each with its own lifecycle (eg dev, staging, production). So if you want to use a different email gateway from your staging API, you need to have in turn a specific notification gateway. To make a test in one project, you need to modifiy code in all its dependency chain. Uncool

Service dependencies

On Clever Cloud, you already know how to link applications to their dependencies on the fly, without touching code or fidling with config files: by linking an addon to your application, you let the addon inject its location and credentials so you don't have to handle it yourself. Service dependencies is just a generalization of the addon mechanism to any application.

Link applications

You can add dependencies to an application either from the CLI:

  clever service --alias api link-app notification-gateway

or from the console:

Exposed configuration

With addons, the exposed configuration is always the same. With applications, you can declare the configuration you want to expose to your dependents. To make an app expose configuration, you can either do it from the CLI:

  clever exposed-config --alias api set API_DOMAIN_NAME api.example.com

or from the console:

Note: every time you update the exposed configuration, dependent applications will be automatically redeployed.