Back to basics with this first article in a new series. Let's take a look at how cloud computing works, its different architectures (public, private, hybrid), its many benefits for businesses, and the differences between cloud computing, edge computing and on-premise to help you choose the solution best suited to your needs.

Cloud computing: definition and origins

Cloud computing has profoundly transformed the way businesses and individuals access IT resources. The idea is simple but innovative: rather than owning and managing their own servers and data centres, users can now access IT services on demand, via a network. These services include computing power, data storage and sometimes even database management, offering unprecedented flexibility and accessibility. It's not an idea that dates back to yesterday...

How cloud computing has evolved over time

The concept of cloud computing, although widely popularised in the early 2000s, has its roots in the 1960s. At that time, computer pioneers were already considering the idea of making computing power accessible as a public utility. During the 1990s, network diagrams began to use the image of a ‘cloud’ to represent the Internet, symbolising the complexity and interconnectedness of the networks that today enable cloud computing to function as a global and flexible architecture.

The real strength of the cloud lies in its ability to provide remote and scalable computing resources, enabling businesses to simplify the management of their infrastructure, avoid wasting resources, and improve energy efficiency through three pillars:

• Unified billing: The cloud offers a single billing system that simplifies cost management for businesses. This transparency makes it possible to accurately track expenditure and optimise costs;
• Centralised, secure access: The cloud offers a single interface that simplifies access to services, while centralising management. IAM (Identity and Access Management) systems provide enhanced security, with auditability tools for improved compliance;
• A rich and diverse marketplace: The cloud provides a vast marketplace, giving businesses access to a wide range of products and services. This diversity promotes the flexibility and scalability of the solutions deployed.

How do you simply define cloud computing?

In simple terms, cloud computing is defined as remote access to shared computing resources, without the complexity of managing the underlying physical infrastructure. This approach enables businesses to make a long-term investment in the long-term management and hosting of their data, while giving them the flexibility to rapidly adjust their capacity as required. Clever Cloud, for example, automates the scalability, optimising resources in real time to meet demand.

How does cloud computing work?

Based on a network-based computing services model, the cloud enables businesses to access resources such as data storage, computing power and access to a catalogue of online applications, without the need to manage the hardware infrastructure directly. This approach offers greater flexibility, cost optimisation and operational efficiency, all of which encourage innovation.

The key elements of cloud operation

There are several fundamental elements that ensure the efficiency and scalability of the cloud. Here's an overview of the key elements.

The physical infrastructure

At the heart of the cloud is a physical infrastructure made up of servers, storage systems and interconnected networks. These infrastructures are located in data centres around the world, promising very high availability, enhanced security and optimum performance. Cloud providers like Clever Cloud invest heavily to maintain high quality standards, verified through various certifications.

Virtualisation

This fundamental principle enables the creation of virtual versions of physical resources, such as servers or storage systems. Virtualisation improves efficiency by enabling several users or applications to use the same resources in an optimised way: the famous Virtual Machines (VMs). This technology also simplifies management and reduces operating costs by disconnecting the hardware infrastructure from the user experience.

Access interfaces and APIs

Cloud service interfaces are designed to be secure and high-performance, making it easier to manage resources and deploy applications. APIs offer system administrators, DevOps and developers the possibility of automating and integrating cloud services into their own systems, maximising customisation, efficiency and flexibility and extending the range of possible functionalities.

The different cloud architectures: public, private and hybrid

Each cloud architecture has its own advantages and addresses different needs. The key is to choose the one that best aligns with your organisation's strategic objectives and operational constraints.

Public Cloud: simplified accessibility and scalability for data hosting

The public cloud is the most common architecture. Here, IT resources are hosted on servers belonging to cloud service providers, such as Clever Cloud. These services are accessible via the network, providing a scalable solution that can adapt quickly to changing business needs.

The public cloud offers different levels of service, from Infrastructure as a Service (IaaS) to Platform as a Service (PaaS), via Software as a Service (SaaS). This diversity means that businesses can choose the solution best suited to their needs, while benefiting from the fact that there is no initial investment in infrastructure.

Private cloud: controlled, secure data hosting

By definition, the private cloud is a solution dedicated to a single organisation. Unlike the public cloud, the customer's servers are dedicated to that organisation. This is often a hosting zone behind the customer's firewall, made available by a cloud provider. This architecture offers total control over data and enhanced security, which is ideal for sectors subject to strict regulations (financial, health, pharmaceutical, public, defence, legal, industrial, etc.). The private cloud allows greater customisation of the data hosting architecture, tailored to the specific needs of the business.

Hybrid cloud: don't put all your eggs in one basket

The hybrid cloud offers greater resilience by combining the advantages of the public and private clouds. By diversifying environments, businesses avoid putting all their eggs in one basket. For example, they can store sensitive data in a private cloud while using a public cloud for backups or less critical workloads. This means they can switch from one environment to the other depending on their needs in terms of performance, cost or security. However, with the high egress fees charged by hyperscalers, this approach can become costly.

In reality, the hybrid cloud is already common practice, often without companies being fully aware of it. Since the democratisation of SaaS, the majority of applications are no longer solely on-premises, but are based on a mix of public cloud, private cloud and SaaS services.

What are the different types of cloud computing?

Cloud computing is divided into several main categories: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Function as a Service (FaaS). Each type offers different levels of control, flexibility and management, so you can choose the one that best suits your needs.

Infrastructure as a Service (IaaS) for maximum customisation

Infrastructure as a Service (IaaS) is historically the most widespread model of cloud computing. With IaaS, businesses rent IT resources such as servers, virtual machines, storage and networks directly from a cloud service provider.  Customers take care of maintaining their OS, databases, runtimes, etc. in operational conditions, using system administrators, either in-house or from an outsourcer. This allows companies to have a specific architecture that meets their needs. 

Platform as a Service (PaaS) for rapid deployment and automatic updates

Platform as a Service (PaaS) goes a step further than IaaS by providing an OS, middleware and a console for easy deployment of runtimes and even databases or third-party services, known as add-ons. The customer no longer has to worry about maintaining the system in operational condition (MCO), which is the responsibility of the cloud provider.

PaaS solutions make it easy to deploy applications quickly, while automatically maintaining and updating the infrastructure. With integrated development tools and a modular architecture, Clever Cloud simplifies the work of developers and DevOps teams by offering them a ready-to-use environment to accelerate innovation: deploy code, we'll take care of the rest! 

Software as a Service (SaaS) for greater simplicity

Software as a Service (SaaS) is the most common cloud computing model. SaaS applications are hosted and managed by service providers, enabling users to access them via the Internet, usually on a subscription basis. This model eliminates the need to install and maintain software locally, reducing costs and technical complexity.

SaaS is particularly useful for businesses looking to standardise their software tools without investing in IT infrastructure. For example, collaboration tools, customer relationship management (CRM) systems and office suites are often deployed as SaaS services for maximum simplicity.

Functions as a Service (FaaS) for greater agility

Functions as a Service (FaaS) is an evolution of the PaaS model that allows developers to create and deploy individual functions without worrying about server management. The cloud provider takes care of all the infrastructure, scaling and resource management, charging only for the time it takes to run the functions.

The functions are triggered by events defined in advance, enabling the function to launch its action (processing an image, converting a file, etc.) and therefore to switch on, be active for the duration of the action and then switch off. services for economic reasons. FaaS is often complementary to PaaS.

What are the advantages of cloud computing?

Whether in terms of scalability or security, the cloud offers a number of benefits for organisations that decide to adopt it.

Cost optimisation: a strategic approach rather than just savings

Cloud computing can be part of a financial strategy, in particular by transforming capital expenditure (CAPEX) into operational expenditure (OPEX). This budgetary transition enables companies to outsource their initial IT infrastructure costs (purchase of servers, data centre maintenance, fibre management, recruitment of a dedicated team, etc.). Organisations can adopt a pay-as-you-go model, adjusting their spending according to their real needs. Some hyperscalers will still offer to pay for reserved instances, which will have to be paid for even if they are not used, but this is not the majority of usage. 

Scalability: the cloud adapts to your needs

Whether you need to increase processing capacity during peak periods or reduce resources during off-peak periods, the cloud is flexible and scalable on demand, thanks to probes and orchestrators. This responsiveness ensures optimum use of resources and gives businesses greater agility to respond to changes in the market and in demand. At Clever Cloud, scalability is automatic, which means it adapts in real time to your needs, so you only pay for what you actually use.

Security: a key pillar for businesses

Cloud computing greatly improves the security of your data. Cloud providers invest, keep a constant watch and have the role of warning their customers or updating exposed areas. Storage in the cloud and its backups provide great resilience. Backed-up data can easily be accessed or a disaster recovery plan (DRP) or business continuity plan (BCP) can be launched. At Clever Cloud, we go even further: our Materia databases are automatically replicated to our three Paris data centres, giving you peace of mind. Another key point is that many security certifications may be required when hosting critical or personal data. Cloud providers undertake to comply with them. 

Accessibility: instantaneous response to new work trends

Cloud computing makes your data more accessible, enabling your teams to collaborate effectively, regardless of their location. Data and applications hosted in the cloud can be available 24/7. This facilitates teleworking, speeds up decision-making processes and improves team productivity, while guaranteeing real-time synchronisation of information.

Automatic updates and operational maintenance

With cloud computing, software updates and security patches are automatically managed by the supplier, without the intervention of the customer's IT team. This not only reduces the internal workload, but also ensures that the systems have no security holes.

Who uses cloud computing?

Cloud computing is now an essential component for businesses of all sizes and in all sectors. Its massive adoption is driven by the outsourcing of management and MCO, the unification of costs and access to a marketplace.  Whether it's for data storage and backup, Big Data analysis, mail server hosting or web application development and deployment, the cloud has become essential for meeting the growing demands of the market.

For example, organisations in the financial sector are using cloud computing to detect and prevent fraud in real time, using machine learning algorithms and predictive analysis. Healthcare companies, meanwhile, are exploiting these technologies to offer more personalised treatments, thereby improving the quality of care for their patients. The entertainment sector and video game creators are relying on the cloud to deliver their content to millions of users around the world, guaranteeing a fluid and immersive experience.

But this technology is not just for large companies: SMEs, start-ups, freelancers and private individuals are also adopting the cloud to benefit from a scalable infrastructure without having to bear the high costs associated with physical data centres. By opting for these solutions, they can concentrate on what they need.

What are the uses of cloud computing?

Cloud computing offers a multitude of uses for businesses and individuals, including the following.

Storing and backing up data

The cloud enables businesses to protect their information while benefiting from a large storage capacity, all the while retaining control over billing. Data can be easily accessed from any connected device, making it easier to recover in the event of a technical problem.

Hosting applications and websites

Hosting applications and websites is another key use of cloud computing, enabling applications to be created and deployed with a high degree of scalability. Developers benefit from a reliable solution that delivers a fluid, high-performance user experience.

Distributing software and content as a service

Cloud computing also facilitates the development of software and content as a service (SaaS). This model reduces the need for local installations and enables companies to offer regular updates without service interruption, accessible at any time and on any type of device. They can focus on the continuous improvement of their products while simplifying the management of software versions.

Data analysis and artificial intelligence (AI)

Data analysis and the integration of artificial intelligence (AI) are made possible by the capabilities and performance of cloud computing. Companies can centralise their data in cloud systems, such as datalakes or data warehouses, and use and train machine learning services to extract the desired elements. These technologies help to develop predictive models, automate processes, generate text or images, etc.

Application testing and development

The cloud is also a powerful tool for application testing and development. Thanks to the standardisation of test environments, it is now possible to obtain dedicated spaces in just a few clicks, saving time for teams of developers. Cloud infrastructures offer a high degree of flexibility for creating, testing and deploying applications, while facilitating continuous integration and continuous deployment (CI/CD). This approach accelerates the development cycle and enables companies to reduce their time to market.

Edge computing and cloud computing: the differences

Cloud computing and edge computing are two distinct architectures that meet different needs. Whereas cloud computing centralises resources and processing in large data centres, edge computing moves these operations closer to the data sources using small-scale infrastructures.

This approach enables edge computing to reduce latency and improve processing speed, which is essential for applications such as the Internet of Things (IoT), autonomous vehicles and augmented reality. The choice between these two technologies often depends on the context and on performance, security and connectivity requirements. Edge computing also makes it possible to offer a hybrid architecture, which can take over in the event of availability problems.

Cloud computing is distinguished by its ability to offer scalable, pooled resources, accessible via the Internet, making it an ideal solution for applications requiring high computing and storage power. By contrast, edge computing favours local processing for real-time responses, reducing dependency on network connectivity.

When should you choose edge computing rather than cloud computing?

Choosing between edge computing and cloud computing depends on several key factors:

• Reactivity and low latency: Edge computing is the best solution when instant response is crucial. For example, in industrial control systems or autonomous vehicles, every millisecond counts. Local processing of data by edge computing reduces delays and improves the reliability of operations;
• Volume of data to be processed: When the volume of data generated is too large to be transferred quickly to a central data centre, edge computing becomes essential. It enables data to be filtered and processed at source, minimising network traffic and optimising bandwidth use;
• Isolated environments or those with limited connectivity: In areas where the Internet connection is unstable or non-existent, edge computing ensures that data is processed without interruption. This makes it an ideal solution for remote sites, such as industrial facilities or critical infrastructures;
• Data security and confidentiality: Edge computing provides an extra layer of security by processing data locally, limiting its exposure to potential cyber threats. This is particularly important for sensitive sectors such as healthcare or financial services.

So, while cloud computing is suited to tasks requiring vast resources and global accessibility, edge computing is essential in contexts where speed, locality and data security are paramount.

On-premise and cloud computing: the differences

The evolution of IT infrastructures has led to two main approaches: on-premise and cloud computing. These two solutions differ fundamentally in terms of deployment, management, cost and scalability. On-premises involves purchasing, installing and managing hardware and software directly on the company's servers by a trained team, offering total control over data, network and security. Cloud computing, on the other hand, is based on outsourcing these tasks so that the company can concentrate on its core business.

When should you choose on-premise rather than cloud computing?

Opting for an on-premise infrastructure can be a strategic choice, from a budgetary, technical and HR point of view. If the company wants to pay for and amortise its investments, control the entire value chain and be able to recruit and retain its talent, the on-premise option may be just what it needs. If it wants to concentrate on its core business, it will find it easier to turn to cloud computing to outsource this work to a service provider whose job it is. 

The future of cloud computing

Cloud computing continues to evolve at lightning speed, and its potential continues to grow. We are at the dawn of an era where cutting-edge technologies such as artificial intelligence (AI), quantum computing and edge computing will redefine current cloud paradigms. This future promises increased integration of low-code and no-code platforms, as well as massive adoption of the Internet of Things (IoT), enabling businesses and developers to design innovative solutions without necessarily benefiting from advanced technical expertise.

Minor update, bigger consequences

The global incident started after we initiated a minor rolling maintenance upgrade of Apache Pulsar (3.3.1). It enabled a new balancer algorithm for bundles placement optimization which caused troubles. We quickly detected it, kept the 3.3.1 release and rolled back the defective configuration. 

The initial problem, although fixed, resulted in a metadata conflict. We had to stop all messaging brokers to start only one, preventing metadata conflict between them, and succeeded in getting back to a nominal situation. But after that our infrastructure experienced I/O and memory pressure, causing some hypervisors to crash.

The unavailability of the Apache Pulsar messaging layer has led to the buffering of some telemetry agents on the virtual machines (VMs) running on hypervisors (HVs). They started to buffer in memory while messaging service endpoints weren’t available.

Reach the limits of our smaller VMs 

For small VMs it reached a memory limit which triggered a lot of pressure on the kernel. When it happens, the kernel tries to flush memory and caches, remove processes from memory to load them instruction per instruction from disk. This is generating a lot of I/O disk pressure on the underlying hypervisor. A few minutes after HVs load increased, we started to see kernel panics on some of them.

Small VMs are spreaded globally among our Availability Zones, so we ended up having an overloaded server infrastructure. As we needed the scheduler to manage the situation, the control plane was performing suboptimally and the infrastructure struggled to provide available resources.

So we had to shut down all non critical services and our SRE team redeployed one by one the overloaded small VMs. Then we started to regain control over all hypervisors and were able to take our infrastructure back to its optimal state.

What’s next?

For non minor releases, we use a simulation process that emulates a full environment where we inject changes. This validates upgrades and changes by observing the infrastructure behavior before going to production. This process wasn’t used for minor maintenance upgrades or (apparently) small changes in the configuration profile.

This incident taught us a lot and we identified some progress areas regarding our images, tools configuration and integration, or small VMs setup. We’ve taken some immediate actions and will work on more deep topics in the coming weeks. 

We sincerely apologize for any inconvenience this incident may have caused. Your trust is paramount to us, and we are committed to providing you with the highest level of service reliability. 

You can learn more about the schedule and technical analysis of the incident in our public postmortem. If you have any questions or concerns, please don't hesitate to reach out to our support team.

Over the past few months, some customers have raised questions about CI/CD building to deploy from GitHub or GitLab. The two platforms differ significantly on the subject, but are the ones massively used to store code and collaborate.

At Clever Cloud, we're committed to providing a wide range of products and features to facilitate application deployment and maintenance. We aim to constantly improve our customers' experience as well. In this article, we detail how we have approached the subject of CI/CD to simplify deployments, regardless of where you store your code.

Two platforms, one common principle

Clever Cloud provides a CLI for deploying and managing both applications and add-ons. So far, we've suggested that our customers use it to build their CI/CD. However, writing a pipeline, even with a facilitating tool like a CLI to connect to Clever Cloud, is a long and tedious task. Especially when you're busy developing your application.

Keeping in mind one of our founding principles, to make the work of developers and IT teams as easy as possible, we started to provide slightly more advanced CI/CD tools, both for GitHub and GitLab.

Deploying from GitHub: go further with review apps

Customers using GitHub are already familiar with our integration, enabling them to deploy from this platform. In addition to this integration, anyone could use the CLI to customize their pipeline.

Based on this configuration, we've provided a workflow template for deploying review apps from GitHub to Clever Cloud. This script performs the following actions:

1. Create and deploy an app on Clever Cloud from the branch where the PR is open, with a test domain name ;
2. Update the application with each new commit ;
3. Delete the application when the PR is closed.

A comment posts the link to the review app with each new deployment, and announces the deletion of the app once this job has been completed.

The script retrieves the environment variables and secrets added to your project from GitHub. It's possible to go further and add commands; for example, to connect the review app to a test database, you could add the command clever service link-addon <addon-name>.

This template is under constant development to progressively simplify your workflow and make it more efficient. Eventually, this Action should work solely with inputs rather than command lines. In the meantime, feel free to open an issue on the project according to your needs.

Deploying from GitLab

Our customers working on GitLab (as a SasS or self-hosted instance) have also expressed similar needs for automating their deployments. GitLab differs significantly from GitHub, with a much more DIY approach to CI/CD and different configurations. On GitLab, there are no variables for detecting the state of a Merge Request (open or closed), unlike GitHub. If we want to launch a job automatically when it closes, we' ll have to use the state of the environments instead, and not that of the MRs.

At Clever Cloud, we already had different deployment pipelines in place from GitLab for certain projects. We've unified and simplified them by creating pipeline components in the GitLab CI/CD catalog. The components replace GitLab's old template catalog, and enable a modular pipeline to be built using inputs. No need to manually customize a script file anymore.

Our contribution to the catalog currently comprises four components:

1. Deploy in production;
2. Creating a review app from a Merge Request;
3. Update review app;
4. Delete review app.

The input values have been predefined to save you time when using them. These components can be used both on gitlab.com and on your self-hosted instance. There's nothing to modify in the project, but a few configurations of your instance to check.

In both cases, we advise you to test the manual triggering of components on your project first. We'll be adding more components as our customers' needs change, and are open to your proposals, to be submitted directly on the project dedicated to them.

The best of both worlds: Heptapod

If you use the GitLab Community Edition fork hosted on Clever Cloud, you'll benefit from the advantages of a GitLab as a Service offering, as well as hosting on European servers managed by a French company.

The CI/CD pipeline catalog is already integrated into our Heptapod offer, enabling you to use the components directly in your project, with no instance configuration required.

A simplified pipeline

Clever Cloud integrates the build, install and run phases of your deployments. All you have to do is push your code, the process is automatic. By including deployment on Clever Cloud in your pipeline, you'll get logs of your application's deployment and its various stages directly in the runner's console. This means:

• You can skip the build job in your pipeline - our platform already takes care of that.
• You can monitor your pipeline and its logs directly from GitHub, GitLab or Heptapod, from start to finish.

Remember: if the deployment fails on Clever Cloud, your app will stay up with the last commit you pushed before your update. It won't crash and your users won't notice anything. We got you!

As both projects are in constant development, we plan to go even further in adding flexibility and agility to your deployment processes. We remain open to your suggestions!

To ensure a Clever Cloud application has enough resources allocated in our infrastructure, we use metrics to know when to scale up/down.Those metrics, along with those from our internal systems, are stored into a time series database which is growing at a pace of 2 TB per week. As we want to keep them for any further analysis, we had to set up a solution to automatically offload this data every month into our Cellar object storage.

Our metric infrastructure

With thousands of customer applications, and hundreds of internal applications, we needed a time series database capable of ingesting hundreds of thousands data points per second.

That’s why our customer-facing cluster,warp10-c2, in production since October 2023, is using Warp10. It effortlessly satisfies our performance requirements thanks to the underlying storage layer, FoundationDB. In its distributed version, it can handle ingestion spikes of over 500,000 data points per second while processing reads of over 5,000,000 data points per second.

Continuously growing cluster

Even though we could handle metric data efficiently, the growing rate of our database (2 TB per week) has put us in a challenging situation.At first, we were handling stability issues. To focus on one of them without having to deal with storage problems, we added more SSD nodes to our FoundationDB cluster.

Once this situation was handled, we had to deal with computing resources needs, find a good balance and how to gain storage capabilities without losing data.

In the end, we found a good way to achieve this: offloading those metrics in our object storage (HDD) service (Cellar) and once done, delete them in the hot (NVMe SSD) storage.

Offloading data can be done through various ways

First and naive way would be to select data points and send them into buckets in our own format. Our query system can handle millions of reads per second, but we are talking about billions of data points here. Even with dedicated  servers, it would have led to performance issues coming from our storage layer. In addition, we would have disk usage similar to  data in the hot storage.

A second way would have been to reduce the resolution of metrics, instead of having data points with seconds or minutes precision, we could re-process with their average value per hour or per day. This solution would leave us with more questions than solutions: “How to handle metrics extreme values ? An application running only a few seconds or minutes and not a day? What about our internal applications, do we re-process metrics on a case-by-case basis?” It would have been too much effort put in a flawed system.

The last and final way would have been to use Warp10 HFiles proprietary extension. It can be added on internal machines of our c2 cluster, and used to generate compact and data-efficient files, with encryption capabilities. This solution could lead us to a compression ratio that can take TB of data into a few GB, this is due to metrics that are mostly the same (e.g a CPU usage percentage has a finite number of values).

In February, we’ve chosen this approach. Still, we should implement this system, with automatic processing, so that our data team doesn't have to deal with this tedious task every month.

Building the automated process

Before diving into how we made this possible, a small introduction into HFiles is necessary to better understand why we did it this way. Then, we’ll dive into a workflow orchestrator we are using offload automatically. And finally, the figures from our first batch.

Introduction to Warp10 HFiles

HFile is part of the Warp10 HFiles extension. Its process is fairly simple. At first, it will fetch all `s matching a criteria, and for each of them, try to gather all the data points in a specified time range, while continuously compressing the data. This can take a lot of time, within our experiments, some generations could take days to be done (yes, really). But with proper optimisation, days could become hours. Those generations are synchronous, meaning we need to keep an open HTTP connection with the machine running the generation in order to succeed.

We mostly adjusted three parameters in order to optimize the processing time:

• Data points time range: it allows to only fetch data points between two dates
• Concurrency: running a single HFile generation is time consuming, so running multiple generations in parallel can save a lot of time
• Number of series: for each series, it will try to fetch its data points (even if it’s zero in the specified time range). Thus, optimizing the number of series can save a lot of requests into our storage layer, and then save time

What do "series" mean?

A series, called GTS (“Geo Time Series”) in Warp10, is composed of a metric name and one or multiple labels which gives context. For instance, a GTS to know the CPU usage of an application would be cpu.usage_guest{app_id='app_87e33fea-9dde-4a99-b347-674de382ff7b'}. In our c2 cluster , we got over 150 million of them.

Scheduling the offloading

Those generations required a tool that met the following constraints:

• Scheduling capabilities: to prevent having to trigger the action manually each month
• Retries and fail over: in case of failure of a HFile generation, it should be able to retry, or if a scheduling node fails, to run it again on another node
• Alerting, when retries aren’t enough, we must be aware of the failure
• Handle long tasks: as our generations can take several hours

We went through several workflow orchestration solutions, but our final bet went to Kestra. It’s an open source tool that answers the above constraints. Deployed as a Clever Cloud application, it helped us to create workflows that minimise generation time by using our optimised parameters for HFile generation.

At the end of February, we finished our HFile generation workflow (see above), and ran it for the first time on November metrics, without deletion. This test-run, once successful, gave us enough confidence in Kestra. We ran the deletion manually afterwards.

However, starting in March, the whole HFile generation and data deletion from hot storage has been automated. Although our need for this scheduler is limited to this use case, we intend to apply it for different scenarios in the future.

November's metrics offload

As said earlier, we ran our first month of offloading successfully, based on November data (we want to continuously have at least 3 months of metrics available from hot storage). This first month was special, as c2 entered into production at the end of October, and all Clever Cloud customers applications had to be re-deployed using it. It means that this month has a higher number of series and data points than any other.

Thus, last November, we offloaded over 22 billions data points from 33 millions series. These needed approximately 20 TB of data from hot storage. Once compressed, it fits in only…20 GB. An important thing to note here is that the data in the hot storage is encrypted, meaning the size is several times the actual data point or series size.

In conclusion, managing metric data efficiently, especially at a growth rate of 2 TB per week, presented challenges that required careful planning. By leveraging Warp10 HFiles' data compression capabilities and building an automated offloading system to Cellar object storage, we successfully optimised our storage resources.

If AI has been in the news recently, it's mainly through large language models (LLMs), which require substantial computing power for training or inference. Thus, it's common to see developers using them via turnkey APIs, as we did in a previous article. But this is changing thanks to more open and efficient models and tools, which you can easily deploy on Clever Cloud.

Indeed, while our platform was designed for a variety of uses, we always paid particular attention to its flexibility and the freedom it gave our customers. This means they can easily exploit it to address new markets, with minimum effort spent on adaptation.

To confirm this, we recently tried to deploy open source AI models such as those derived from LLaMA and Mistral. Their particularity is that they exist in lightweight versions, which don't necessarily require a GPU to run. As a result, they can be hosted as simple Clever Cloud applications, as long as they have been allocated enough memory.

Let's ollama (with a web UI) !

To do it, we've chosen to use ollama, an MIT-licensed project that lets you download models from a registry, or even your own. It works as a server that communicates via an API, and is very easy to host on our infrastructures.

• Create a Clever Cloud account (and get 20 euros in credits)

To get started, you’ll need a Clever Cloud account. You can create the application and follow the next steps using our web interface, the Console, but also through our open source CLI: Clever Tools. That’s what we’ll describe below.

We’ll assume that your machine is running git and a recent version of Node.js. If you haven’t yet installed Clever Tools on your system, type (with system administrator rights, or sudo if necessary):

npm i -g clever-tools
clever login

Once logged in, you can check that everything has gone smoothly with the following command:

clever profile

Next, we create a Clever Cloud application using Node.js. It will install ollama to download and run our models, adding a web interface (chatbot-ollama, also under MIT license) that will allow us to query the server from any browser, run from a computer or a simple smartphone.

This solution also offers local storage of chats in the browser. It therefore requires no database, but offers an import/export function. You can also choose between different models, set some of their parameters, configure system instructions, various prompts, and so on.

mkdir myollama && cd myollama
git init
curl -L https://github.com/ivanfioravanti/chatbot-ollama/archive/refs/heads/main.tar.gz | tar -xz --strip-components=1

clever create -t node myollama && clever scale --flavor L
clever env set CC_POST_BUILD_HOOK "npx next telemetry disable && npm run build"
clever env set CC_PRE_BUILD_HOOK "./ollama_setup.sh"
clever env set CC_PRE_RUN_HOOK "./ollama_start.sh"

echo "orca-mini" > models.list
echo "mistral" >> models.list
echo "codellama" >> models.list

The code above creates the application. We add a file containing the list of models we wish to fetch during startup. We've chosen an L instance, the minimum size for loading such models into memory. We also declare several environment variables for running scripts to install ollama, start the server and disable telemetry for the Next.js framework used to build the web interface after the dependencies have been installed.

Now add some scripts

Our application is almost ready. We still have to create two executable files:

touch ollama_setup.sh && chmod +x ollama_setup.sh
touch ollama_start.sh && chmod +x ollama_start.sh

ollama_setup.sh download the ollama binary and the models from our list. Open it with your favorite editor and insert the following content:

#!/bin/bash

# We define the folder (in $PATH), where the ollama binary will be placed
BIN_DIR=${HOME}/.local/bin
mkdir -p ${BIN_DIR} 

ollama_start() {
    echo "Downloading and launching ollama..."
    curl -Ls https://ollama.ai/download/ollama-linux-amd64 -o ${BIN_DIR}/ollama
    chmod +x ${BIN_DIR}/ollama
    ollama serve &> /dev/null &
    echo -e "Finished: \033[32m✔\033[0m\n"
}

get_models() {
    MODELS_FILE="models.list"
    MODELS_DEFAULT="orca-mini"

    # We check if the models file exists
    if [ ! -f ${MODELS_FILE} ]; then
        echo "File ${MODELS_FILE} not found, ${MODELS_DEFAULT} used by default."
        echo ${MODELS_DEFAULT} > ${MODELS_FILE}
    fi

    # Loop through each line and pull model
    while IFS= read -r line; do
        echo "Pulling ${line} model..."
        ollama pull "${line}" > /dev/null 2>&1
        echo -e "Finished: \033[32m✔\033[0m\n"

    done < ${MODELS_FILE}
}

# We start ollama, and wait for it to respond
ollama_start
if [ $? -ne 0 ]; then
    echo -e "\nError during ollama setup."
    exit 1
fi

count=0
MAX_TIME=10

while ! pgrep -x "ollama" > /dev/null; do
    if [ ${count} -lt ${MAX_TIME} ]; then
        sleep 1
        count=$((count+1))
    else
        echo "Application 'ollama' did not launch within 10 seconds."
        exit 1
    fi
done

get_models
if [ $? -ne 0 ]; then
    echo -e "\nError during models downloading."
    exit 1
fi

This code may seem a little long, but that's mainly because we've made it modular, logging only successful steps and any errors.

ollama_start.sh detects whether the ollama server is already present before starting the web interface. If it isn't, we launch it in the background (we'll see why below).

Open it with your favorite editor and insert the following content:

if ! pgrep -f "ollama" > /dev/null; then
    # If 'ollama' is not running, start it in the background
    ollama serve &
    echo "Application 'ollama' started."
else
    # If 'ollama' is already running
    echo "'ollama' application is already running."
fi

Once these two files have been created, we can deploy the application:

git add . && git commit -m "Init application"
clever deploy
clever domain

You'll then see the domain to access it (which you can customize).

Cache and quick (re)start

Using Clever Cloud not only means deploying such an application easily, with logs and monitoring, and being able to instantly change its horizontal and/or vertical scaling. It also means being able to turn it into an image ready for a fast redeployment.

In fact, every application we host is stored as an archive just before dependencies are installed. This means it can be stopped and restarted in this form, so we don't have to re-download the models every time. To do this, simply specify the folders to be added to the archive:

clever env set CC_OVERRIDE_BUILDCACHE "/:../.ollama/:../.local/bin/"
clever restart --without-cache --follow

The application will restart, but this time it will take the built web interface, ollama and models from its cache, as the CC_PRE_BUILD_HOOK and CC_PRE_BUILD_HOOK steps are not executed. This is one of the reasons why we need to make sure that we start the ollama server with CC_PRE_RUN_HOOK, but check that this hasn't already been done in a deployment where it is used to download models before running them.

Once this step is complete, you can stop the application and restart it whenever you like - it'll be much faster from now on. And you'll only be charged for the time you use it, by the second. If you wish to modify the list of models to use, do so in the dedicated file. A git push will be enough to rebuild the new cache.

# Stop/Restart the application
clever stop
clever restart

# After a modification in models.list, git push to recreate the cache
git add models.list && git commit -m "New models" 
clever deploy

You'll find the files you need for this project in this GitHub repository, with the environment variables ready to import (clever env import < .env).

And if you want to push things further, deploy other models and tools for your applications that require more power and/or GPUs, let us know!

Clever Cloud is today the main developer of Sōzu, a Reverse Proxy that was developped at Clever Cloud, in Rust, to meet the needs of our infrastructure for performance and hot reloading. Sōzu is used throughout Clever Cloud, paired with HAProxy, to route traffic to our customer's applications.

What we used to do:

Up until now, our Reverse Proxy Sōzu used to be managed by Clever Cloud by a closed source program that ran on the same machine and assumed two big responsibilities:

• Firstly, listen to a RabbitMQ topic and redirect requests to Sōzu (via its UNIX socket)
• Secondly, watch over a PKI directory (Public Key Infrastructure) to redirect TLS certificates to Sōzu (via its UNIX socket)

Turning open source

While working on a new Prometheus connector for Sōzu, we realized we could open source it. With this realization came the idea of porting the logic of the former Sōzu manager (described above) from its closed source state into new open source repositories.
What we ultimately aim to develop is an entirely open-source ecosystem around our Reverse Proxy Sōzu.
This blog post details what these new open source components are, and summarizes what they do.

Our open-source ecosystem around Sōzu

Sōzu Prometheus connector

Prometheus is a monitoring and alerting software suite.
This simple connector operates alongside Sōzu. It waits for HTTP requests on the /metrics route, queries Sōzu for its metrics, formats the metrics to be Prometheus-compatible, and sends them in the HTTP response.
This means that Prometheus metrics are readily available on the IP address of a Sōzu machine.

Sōzu Pulsar connector

Apache Pulsar is a highly scalable messaging platform. We use it extensively at Clever Cloud because of its distributed aspect and cutting-edge throughput performance.
The Sōzu Pulsar connector subscribes to a Pulsar topic and transmits messages to Sōzu. Sōzu uses these messages to perform hot reloading on the proxy, which is a key feature of our Reverse Proxy.
What it means for us and anyone using the Sōzu ecosystem: this connector enables updating traffic redirection in real time.

Sōzu PKI connector

PKI stands for Public Key Infrastructure, an omnipresent security framework on the Internet, typically used for securing connections with HTTPS (among other things). In the PKI framework, Sōzu functions as a TLS endpoint: it decrypts HTTPS traffic into HTTP traffic.
The Sōzu PKI connector runs alongside Sōzu, watches over a given directory in the file system, reads TLS certificates that were put there by either human or machine, and transmits them to Sōzu.
Then , what this ultimately means is: write a TLS certificate on the machine, Sōzu will have it.

Sōzu client

This is a code library used by all above connectors. It pools connections to Sōzu's UNIX socket and functions entirely asynchronously. All in all, it makes writing new connectors easier.

What's next
The best thing we wish is for the open-source community to join us in using and improving Sōzu as it goes. Our end-game is to build a web UI to manage a Sōzu instance in the navigator.

In a previous post, we explained why you should switch from Google Analytics to Matomo for your audience measurement. Some of our customers have decided to take this step, and Clever Cloud has helped them get to grips with the solution. Based on this experience, find out in this article how to maximize the use of our Matomo addon on Clever Cloud.

Selecting the optimal instance size

As soon as the Matomo addon is created, Clever Cloud deploys three optimized instances (a PHP runtime, a MySQL addon and a Redis addon). Initially, they are sized to the minimum server requirements in order to evolve according to your needs, thus ensuring cost optimization. If you need to make adjustments (for example, if you start to experience errors or slowdowns when launching some processes), our integrated Grafana is your best ally for monitoring your metrics and adjusting your resources accordingly.

Easy access to your metrics

Thanks to the intuitive dashboard for each application, you're provided with a clear view of it all. We've recently integrated a metrics tile into this dashboard, allowing you to track RAM and CPU consumption in real time from the console.

For a more in-depth analysis, a simple click on the Grafana logo from the tile gives you access to all your application's metrics.

In addition, Matomo's PHP instance logs are always there to provide you with additional information.

All about auto-scalability

Self-scalability on Clever Cloud is a major advantage, giving you peace of mind and flexible billing. With Matomo, this feature guarantees a smooth experience even in times of high demand. Keep in mind certain specifics, such as the occasional need for certain extensions, and you'll you make the most of this feature.

Perks from enabling auto-scalability on the PHP instance

With auto-scalability, you can use Matomo smoothly and adaptively, even during peak periods! Benefit from powerful on-demand resources, while paying only for the consumption/second. Once you've completed your intensive tasks, your instance returns to an optimal size, guaranteeing efficiency and savings. So there's no need to reserve a large infrastructure to meet occasional needs.

When to disable auto-scalability?

Clever Cloud provides a service that can be adapted to your needs, with the option of limiting or completely disabling instance auto-scalability. In some cases, it may be advisable to deactivate it from time to time.

As Matomo is a managed service, some configuration options are unalterable to guarantee optimal operation and performance. As part of Matomo's continuous improvement, we have integrated the Google Analytics data import extension in response to common customer requests. This extension, generally used for a one-off migration from Google Analytics to Matomo, is deactivated by default.

If you activate the extension and start importing data, and your application scales, your instance reboots and redeploys the application... with the default configurations. Restarting will therefore disable this extension and kill the import process at the same time. If you decide to use an extension that appears as disabled by default in our Matomo, we recommend the following procedure:

1. Disable auto-scalability for your Matomo PHP instance
2. Increase the instance size until the process is complete
3. Restart instance
4. Once the instance has been redeployed, activate the extension in Matomo

Now you're ready to use the extension, which will remain active until the next server restart.

Matomo, with its MySQL addon, is designed to grow with you. While the database is created with sufficient capacity at start-up, Matomo will quickly exploit its potential. To avoid surprises, why not set up Grafana alerts to monitor memory levels?

Creating alerts

Among its many features, Grafana lets you create alerts on the metrics of your choice. You'll find a tutorial here to show you how to create your alerts from Grafana to Slack, which you can also apply to other contact points like Discord, Teams, etc.

We recommend that you leave around 20% disk space available, as the MySQL instance will need disk to migrate.

Migrating the database

Although scalability has its peculiarities for databases, Clever Cloud provides a smooth and intuitive manual solution. When you receive the alert, a simple connection to the Console on your MySQL addon dashboard will enable you to launch our one-click migration tool. This operation can take from a few seconds to a few minutes, depending on the size of your database.

💡 Tip: Include a direct link to the migration tab in your Grafana alert message. This will give you instant access to the migration tool, making the process even easier.

Leveraging Matomo and Clever Cloud

Although a managed service is pre-configured, you have Matomo administrator status and can use it as such. Here are just a few examples of what you can do with Matomo and Clever Cloud.

Adding new Matomo users

All our managed services use Clever Cloud SSO, enabling you to access deployed addons from your platform credentials. Perhaps you'd like to add users to Matomo without giving them access to the platform.

Matomo lets you add users with different levels of permissions to the application. You can invite them by email directly from the Matomo interface. Users invited by this method will not have access to Matomo's system settings or extensions, unlike Clever Cloud users.

Elevating permission levels

If you have added a user from the Matomo interface, but now wish to add them to your Clever Cloud organization with the same email address, access to Matomo will be denied for security reasons, since this user already exists in the database.

To avoid duplication, simply delete the Matomo user from your database.

1. Launch your MySQL addon's PHPMyAdmin interface
2. Click on your database name (not schema)
3. Search by keyword user and choose the table matomo_user
4. Delete the user you wish to add to the Clever Cloud organization

Now you can invite the user to your organization with his email address, giving him administration rights on the instance.

Measure the audience of any application

On Clever Cloud, you can separate your collaborative environments by creating organizations to which you invite members. Organizations remain isolated, ensuring that no member has uninvited access to an organization's applications and addons.

Matomo makes it possible to track apps to which a simple script has been added to the head. So, even if an application is deployed within a different organization, Matomo offers a unified and complete view of its audience tracking as soon as the application contains this script.

Optimizing role separation

You can set up a dedicated organization for the Matomo administrator of your company or association. From this organization, the administrator can monitor the audience of applications hosted in other organizations, even if these are inaccessible to him/her.

To implement this configuration, the administrator simply provides the appropriate script to be integrated into the head tag of each application. Once integrated, the tracking data will be visible in Matomo. This process ensures that developers have no access to Matomo, while restricting the Matomo administrator's access to applications.

📢 New: Migrate Google Analytics data to Matomo

As we mentioned, you can now use the extension to migrate your Google Analytics data to Matomo. It might be challenging to determine the right database sizing , due to Google Analytics' opacity regarding its metrics.

With this in mind, we suggest you keep an eye on your database metrics and opt for a gradual increase in storage capacity. To facilitate this procedure, Matomo provides a detailed guide to migration.

Conclusion

Clever Cloud not only facilitates the deployment of on-demand applications and services in the form of add-ons. In addition, we include an integrated suite for all our customers, offering in-depth monitoring of application and database activity, as well as automatic and adaptive scaling capabilities.

Whether you've opted for Matomo or one of our other add-ons, we're always listening to our customers' needs, so we can continually improve the services we offer. We look forward to hearing from you!

When I started working at Clever Cloud, I spent some time messing around with the platform and its tooling. This blog post will present you how I managed to:

• create a simple Scala/Akka HTTP template application with PostgreSQL persistence
• link the application to a managed PostgreSQL
• deploy it
• try it!

Create a Scala/Akka HTTP template 🔨

Get the sources

Clone the project generated from Akka Github quick start template.

This service provides the ability to manage a simple in-memory user registry exposing 4 routes:

• List all users
• Get a specific user
• Create a user
• Delete a user

A thorough description of available the cURL commands may be found here.

Add extra features

A few functionalities have been added on top of the original example:

• store the registry into a PostgreSQL database (instead of in memory)
• read database parameters from environment variables
• add a hardcoded basic authentication

All parameters may be specified in the application.conf file:

• basic auth
• database parameters

Parameters are fetched from environment variables, or the specified default value if none is found

app {
  basic-auth {
    user = "foo"
    user = ${?BASIC_AUTH_USER}
    password = "bar"
    password = ${?BASIC_AUTH_PASSWORD}
  }
  routes {
    # If ask takes more time than this to complete the request is failed
    ask-timeout = 5s
  }

  db {
    host = "localhost"
    host = ${?POSTGRESQL_ADDON_HOST}
    port = "5432"
    port = ${?POSTGRESQL_ADDON_PORT}
    database = "postgres"
    database = ${?POSTGRESQL_ADDON_DB}
    user = "login"
    user = ${?POSTGRESQL_ADDON_USER}
    pass = "pass"
    pass = ${?POSTGRESQL_ADDON_PASSWORD}
  }
}

Run the application using Clever Cloud CLI 🚀

Create a Clever Cloud application

clever create --type sbt myakka --region par --org testorg

This command creates a new application

• of type sbt for Scala
• named myakka
• in Paris region
• inside my test organisation testorg

Enable a dedicated build instance for faster build (optional pro tip)

By default a newly created application will run an XS instance which are quite small for building Scala applications fast. One way to build faster is to use a dedicated build Instance: In the Clever Cloud console, got to your application -> options, and check the box [] Enable dedicated build instance This way you can keep your XS instance for running the application, but you can choose an XL for the build time. Or with the command line tool:

clever scale -a myakka --build-flavor XL

Create a PostgreSQL database

clever addon -l myakka create postgresql-addon myakkadb

This command orders a PostgreSQL add-on instance and link it to myakka, injecting the right environment variables into the application instance to contact the database.

Database creation and migration is performed using flywaydb tool. Those script may be found in the migration/db directory of the application resources.

Migration will be automatically called once you specify the proper build hook in the environment variables

CC_POST_BUILD_HOOK with value sbt flywayMigrate

clever env -a myakka set CC_POST_BUILD_HOOK "sbt flywayMigrate"

Configure basic auth environment variables

Basic authentication login and password can be specified as environment variables using the clever env command. If none is found, basic authentication will default to application.conf file values

clever env -a myakka set BASIC_AUTH_USER <YOUR_AUTH_USER>
clever env -a myakka set BASIC_AUTH_PASSWORD <YOUR_AUTH_PASSWORD>

Link your local repo with your Clever Cloud application instance

Retrieve your application id with

clever applications

Then link the local repository to the application (creating a .clever.json file)

clever link app_<UUID>

Deploy

You are now ready to deploy and run your code, just run

clever deploy

You are now able to follow the deployment process until it completes successfully

Your application is running now!

Try it

It's time to experiment with it using curl or your favorite GUI

Add a user

Adapt this command in order to insert a new user into the registry:

curl --request POST \
  --url https://app-<UUID>.cleverapps.io/users \
  --header 'Content-type: application/json' \
  -u '<YOUR_AUTH_USER>:<YOUR_AUTH_PASSWORD>' \
  --data '{
  "name": "Serge",
  "age": 42,
  "countryOfResidence": "Greenland"
}'

{
	"description": "User Serge created."
}

Get all users

Check that the user has been properly created, by getting the list of users:

curl --request GET \
  --url https://app-<UUID>.cleverapps.io/users \
  -u '<YOUR_AUTH_USER>:<YOUR_AUTH_PASSWORD>'

{"users":[{"age":42,"countryOfResidence":"Greenland","name":"Serge"}]}

It works, Success! 🎉

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.