When you access a website or an online application, you most often do so in a "secure" way. This is for example the well-known green padlock that symbolizes HTTPS connections in your browser, which has become a standard these years thanks to initiatives like Let's Encrypt. 

This means that the data transferred to the server is encrypted, and that even if they are intercepted, they cannot be read by a third party. This protection has been provided by the TLS (Transport Layer Security) protocol for almost 20 years, whether it’s a personal site, an online shop or an access to your bank's services.

Over time, this critical technical brick on the Internet has evolved to strengthen the level of security it offers. In August 2018, its version 1.3 (the latest) was released. Meanwhile, versions 1.0 and 1.1 were considered to no longer offer a sufficient level of protection. They have been deprecated by the IETF (Internet Engineering Task Force) since March 2021 and have therefore been gradually removed from recent browsers such as Firefox, Chrome and its derivatives or Safari.

At Clever Cloud, we have seen our customers adopt TLS 1.2 and 1.3 gradually. On our load balancers, based on our in-house and open source reverse proxy Sōzu, the latest version accounts for over 90% of the requests processed each day. TLS 1.2 for just under 9%. TLS 1.0 and 1.1 for only a few tens of thousands of requests per day, less than 0.1% of our traffic.

While we have maintained these versions for compatibility reasons, this will no longer be the case as of June 30. We will of course inform the customers affected by this choice, and encourage them to switch to more recent versions, which will have advantages for them in terms of security, performance and SEO.

Several reminders will be sent between now and the final shutdown of TLS 1.0 and 1.1. If you have any questions on this subject, please contact our support team through the Console.

Hello 🖖, fellow humans and robots! Our engineering team is proud to announce a brand new Rust software development kit (sdk), also known as "clevercloud-sdk" on crates.io.

Some of you may have noticed that there are new repositories on our GitHub organization. Those repositories are named "clevercloud-sdk-rust" and "oauth10a-rust". Their goal is to provide a convenient way to interact with the Clever Cloud's API with interesting features that we will highlights in this blog post.

Built to be asynchronous

The software development kit and the oauth 1.0a client are mainly built on top of two crates that are well-known in the community. Those are hyper, and the asynchronous runtime that power it, named tokio.

The main idea behind using the hyper crate and by extension the tokio asynchronous runtime is to leverage the current ecosystem that gravitates around these crates and efforts to integrate a new kernel API called io_uring. Once this new kernel API will be integrated into the tokio runtime, this will lead to significant performance, enhancement according to the tokio's announcement blog post. We can’t wait for this enhancement that will give us a way to iterate faster! 🚀

Observability in mind

These crates are developed with the idea to be fully observable. It has been achieved through others well-known crates as log and tracing, or using community initiatives like the prometheus crate. Integrations of those crates are taking part of the compiler feature flags system provided by the cargo project.

Standard logging facade

First, you need to know that the standard logging facade is enabled by default. It will output useful information of internals behaviors of above crates, using the standard logger if it is defined. It will help you to understand how calls to the Clever Cloud's API are achieved with some debug information, if you need so.

if you want to disable it, you have to disable the default sets of enabled features. This could be achieved using the following syntax for the clevercloud-sdk crate in your Cargo.toml file.

clevercloud-sdk = { version = "^0.10.0", default-features = false }

Metrics-oriented

At Clever Cloud, we think that metrics are important. They help to understand systems by correlating things that doesn't seem to be related in the first place.

This is why we have launched Clever Cloud Metrics rather soon, some years ago. We recently added more features to it by providing more ways to query Clever Cloud Metrics, thanks to Erlenmeyer which is a time series query language proxy. You can find more details of how you could use it through this blog post.

Lastly, we have announced the Tardis product which empowers you to send us your metrics and we take care of the rest as we always do and more recently we have integrated pre-built Grafana's dashboards to help you to visualize your applications and add-ons state, you can learn more about it here.

Coming back to our crates. You can enable metrics collection using the prometheus crate, by enabling the metrics flags at crate-level in your Cargo.toml file. It could be achieved using the following syntax.

clevercloud-sdk = { version = "^0.10.0", features = ["metrics"] }

Once this feature is enabled, there isn't much more to do. You will need to expose metrics through an HTTP server or send them using the prometheus push gateway. This part is described in the prometheus crate's documentation or in its examples.

Tracing capabilities

Last but not least, a pillar of observability is tracing. According to the OpenTelemetry initiative and documentation, tracing is explained as such:

Traces track the progression of a single request, called a trace, as it is handled by services that make up an application. The request may be initiated by a user or an application. Distributed tracing is a form of tracing that traverses process, network and security boundaries. Each unit of work in a trace is called a span; a trace is a tree of spans. Spans are objects that represent the work being done by individual services or components involved in a request as it flows through a system. A span contains a span context, which is a set of globally unique identifiers that represent the unique request that each span is a part of. A span provides Request, Error and Duration (RED) metrics that can be used to debug availability as well as performance issues...

OpenTelemetry documentation

If you want to take a closer look to tracing, even if it is not in Rust, you can take a look at the OpenTelemetry GitHub organization. There are plenty of libraries, SDKs and documentation to help you to build your tracing solution or integrate with an already existing one. Besides, if you are using the rust language and maybe the tokio runtime, you can have a look at those blog posts which explain how tracing works in the above asynchronous runtime and how to visualize them using the console or using the OpenTelemetry connector which allow to send traces to more sinks, the list is available on the rust OpenTelemetry GitHub repository.

So how do we concretely enable the tracing feature using the clevercloud-sdk ? As mentioned above all features are driven using a feature flag, so to get tracing capabilities, you need to enable the trace flag.

clevercloud-sdk = { version = "^0.10.0", features = ["trace"] }

Once the feature flag has been enabled, you will need to collect and send traces using the above connector and sinks.

How does it look?

Let us look at a concrete example to illustrate what the clevercloud-sdk looks like. But before going through the usage of the clevercloud-sdk, I will introduce you to the dependencies and requirements you will need. The first thing you need to achieve is to declare crates in the Cargo.toml file.

[dependencies]
tokio = { version = "^1.17.0", features = ["full"] }
clevercloud-sdk = { version = "^0.10.0", features = ["metrics", "tokio", "trace", "jsonschemas"] }

We are now able to write a proper piece of software using the clevercloud-sdk. Here is an example of how to use the SDK:

...
use clevercloud_sdk::{
    oauth10a::{
        proxy::{self, ProxyConnectorBuilder},
        Credentials,
    },
    v2::myself,
    Client,
};
...

// See the full code at:
// - https://github.com/CleverCloud/clevercloud-sdk-rust/blob/main/examples/cleverctl
// - https://github.com/CleverCloud/clevercloud-sdk-rust/blob/main/examples/cleverctl/src/cmd/myself.rs
pub async fn get(config: Arc<Configuration>, output: &Output) -> Result<(), Error> {
    let credentials: Credentials = config.credentials.to_owned().into();
    let connector = ProxyConnectorBuilder::try_from_env().map_err(Error::ProxyConnector)?;
    let client = Client::builder()
        .with_credentials(credentials)
        .build(connector);

    let user = myself::get(&client).await.map_err(Error::Get)?;

    println!(
        "{}",
        output
            .format(&user)
            .map_err(|err| Error::FormatOutput(Box::new(err)))?
    );

    Ok(())
}

Another example of the sdk which interact with add-ons:

...
use clevercloud_sdk::{
    oauth10a::{
        proxy::{self, ProxyConnectorBuilder},
        Credentials,
    },
    v2::addon,
    Client,
};
...

// See the full code at:
// - https://github.com/CleverCloud/clevercloud-sdk-rust/blob/main/examples/cleverctl
// - https://github.com/CleverCloud/clevercloud-sdk-rust/blob/main/examples/cleverctl/src/cmd/addon/mod.rs 
pub async fn list(
    config: Arc<Configuration>,
    output: &Output,
    organisation_id: &str,
) -> Result<(), Error> {
    let credentials: Credentials = config.credentials.to_owned().into();
    let connector = ProxyConnectorBuilder::try_from_env().map_err(Error::ProxyConnector)?;
    let client = Client::builder()
        .with_credentials(credentials)
        .build(connector);

    let addons = addon::list(&client, organisation_id)
        .await
        .map_err(|err| Error::List(organisation_id.to_owned(), err))?;

    println!(
        "{}",
        output
            .format(&addons)
            .map_err(|err| Error::FormatOutput(Box::new(err)))?
    );
    Ok(())
}

You can find the entire source code of the command line interface example in the clevercloud-sdk project into the examples repository or you can follow this link.

What's next?

Let's have a look at the incoming features that are to be integrated into these crates.

Biscuit and oauth2 bearer token

At Clever Cloud, we are working on a new authentication and authorization token called Biscuit. More details about it in the introduction blog post.

This new authentication and authorization token will work with the OAuth 2.0 standard. One job of the SDK and the client under the hood is to ease the transition from OAuth 1.0a to OAuth 2.0 using Biscuit.

New features!

The Software Development Kit will grow to support the entire API. The next feature is the integration of the event bus in order to subscribe to events that happen on Clever Cloud's platform. You will be able to get notifications about a deployment of an application and so on...

Besides, those crates are used to build another software that you have discovered in another blog post. It introduce a Kubernetes operator that you may use on OpenShift, that exposes Clever Cloud's add-ons as Custom Resources.