Disclaimer: I'm a co-founder of Qovery - but I guarantee that it's not a trap! Give it a try to Qovery if you are looking to get a very nice developer experience on top of your Kubernetes cluster.

Enter Qovery - an Internal Developer Platform that can be installed on any Kubernetes cluster to bring a delightful and simplified developer experience. But don't take my word for granted. In this quick step-by-step article, I will show you how to deploy one of my GitHub apps and a Postgres database on my Kubernetes cluster running on GCP. And what's really really cool is that I don't even need to understand how Kubernetes work!

Qovery: A Brief Overview

• What is Qovery? An Internal Developer Platform that abstracts Kubernetes complexities, empowering developers to focus on their code.

• Key Benefits:

  • Fast and easy installation on any Kubernetes cluster.

  • Intuitive open-source interfaces (Web, CLI, API, Terraform Provider) for efficient app deployment and management.

  • No Kubernetes expertise is required for developers.

  • Highly customizable for Platform Engineers.

  • No YAML to write for Developers ;)

  • Generous free plan (no credit card required).

• Who Uses Qovery? Over 60,000 developers and Platform Engineers, valuing its simplicity and efficiency.

Deploying an Application on Kubernetes with Qovery

Step 1: Set Up Your Qovery Account

Connect to console.qovery.com and sign in with GitHub, GitLab, or Bitbucket.

Then, give a name to your Organization and Choose the Free plan.

Once your organization is created, you should get this view:

I recommend familiarizing yourself with the basic concepts of Qovery to understand what an organization, cluster, project, or environment is.

Step 2: Connect Your GitHub Repository

You can skip this part if you signed up with your GitHub account. Otherwise, you can connect your GitHub account and permit Qovery to get access to your public and/or private repositories.

Go to your Organization settings > Git repositories access > then, pick the option you want to connect your GitHub account.

Step 3: Install Qovery on Your Kubernetes Cluster

To install Qovery on your Kubernetes cluster, you need to add a cluster into the Qovery interface:

Add your Kubeconfig:

Qovery will give you the commands and the generated helm configuration files you can download.

Then, you need to run the following on your Kubernetes cluster:

helm repo add qovery https://helm.qovery.com
helm repo update

helm upgrade --install -n qovery -f values-zXXX.yaml qovery

Congrats! 🥳 Your cluster is connected to Qovery. You can now deploy your apps.

Step 4: Deploy Your Application

Now, we can deploy our GitHub app on our Kubernetes cluster. Check out this short video and look how fast it is.

Here is what I did:

1. I created an Environment and then I created an Application.

2. I select my app from my GitHub repository

3. By default Qovery picks the Dockerfile at the root of my project but I can change it.

4. I set the CPU to 250m and the RAM to 256 MB

5. I declared my app port to be 5555 and I tick the expose publicly option -> So my app can be accessible from outside.

6. I deployed my app and it's accessible publicly (end of video)

This is pretty cool right? It's not over! 😎

Step 5: Manage and Monitor Your Application

Qovery provides everything you need to manage (start, stop, restart, redeploy, delete) and check out your applications logs - directly streamed from your Kubernetes cluster. Yes!

Do you want to use Datadog or any third-party solutions? No problem... Everything compatible with Kubernetes is compatible with Qovery.

Step 6: Leverage Advanced Qovery Features

I'm pretty sure you ask yourself, ok, that's great. But what about configuring your environment variables, your custom domain, or even deploy a database... Well, it's all covered :)

Imagine, you can even securely connect to your database with the Qovery CLI 😎

~ $ qovery auth
pening your browser, waiting for your authentication...
Info: Success

~ $ qovery port-forward -p 5556:5555
Info: Current context:
Organization | MyOrg
Project      | URL Shortener
Environment  | prod
Service      | DB
Type         | database


Info: Continue with port-forward command using this context ?
Please type "yes" to validate context: yes

Listening on 127.0.0.1:5432 => 5432

~ $ psql $DATABASE_URL

psql >

Powerful out-of-the-box features

Here are a list of cool features you get out of the box:

• Auto-deploy: if I do commit and push a change on my GitHub app - it will be automatically redeployed without any downtime

• Clone: this is my favorite feature! You can clone your app (or your complete environment) in one click. So, testing a new feature without impacting the original app is easily possible.

• Ephemeral Environment: For each Pull Request that I open for my app, Qovery will spin up a new environment

• RBAC, GitHub Actions (CI/CD) integration, Logs, Deployment pipeline, env var interpolation, env var as a file, helm deployment, multiple clusters...

There are so many cool features that I could write 10 other posts to talk about them exclusively. It's probably something that I'll do if you are interested to learn more about some of them :)

Conclusion

Qovery demystifies Kubernetes for developers, making it accessible and manageable without requiring deep expertise. Feel free to try it now on your Kubernetes cluster - it's free and will always be!

If you like the Qovery web interface - give a star ⭐ - it's open source and coded in React ✨

Additional Resources:

• Qovery Documentation

• Community Support and Discussions

What is an Internal Developer Platform (IDP)?

An IDP serves as the backbone of an engineering team, offering a toolkit for building, testing, and deploying applications. It aims to minimize complexities and accelerate the Software Development Life Cycle (SDLC).

Characteristics of an Internal Developer Platform:

• Self-Service Capabilities: Provides reusable tools and automated infrastructure operations.

• Developer Self-Service: Enables developers to independently access cloud environments and perform Day 2 operations.

• Transparency: Offers visibility into the underlying infrastructure, like CPU usage, dependencies, or Kubernetes setups.

• Flexibility: Adapts to changes, being loosely coupled from the underlying infrastructure.

Examples:

• Qovery: An IDP that cuts noise for developers by offering paved paths to production, testing, ephemeral environments, and actionable insights to improve software.

• Coherence: Specializes in unifying disparate systems into a single platform.

• Appvia: Focuses on automating cloud-native technologies.

What is an Internal Developer Portal?

An Internal Developer Portal serves as the user interface or the 'front-end' of the IDP. It allows developers to interact with the toolkit that the IDP provides.

Characteristics of an Internal Developer Portal:

• User Experience: Delivers a product-like experience for accessing resources.

• Software Catalog: Functions as a metadata store, offering essential data to operational staff.

• Workflow Automation: Enables operations to run workflows against the software catalog.

• API-First Approach: Evolves into a platform API, interacting with various components of the IDP.

Examples:

• Backstage: An open-source portal centralizing infrastructure tooling, services, and documentation.

• Port: Offers a no-code approach to creating customized developer experiences.

• Cortex: Provides data-driven insights to support better engineering decisions.

Relationship Between IDP and Developer Portal

The Internal Developer Portal serves as the "face" of the Internal Developer Platform. It allows developers to perform self-service operations and offers visibility into the infrastructure. The portal often evolves into a platform API, offering a unified interface for various interactions.

Why Both Are Essential

An Internal Developer Portal complements and enhances the Internal Developer Platform. While the Internal Developer Platform serves as the backend engine, the portal offers the user experience. Together, they optimize productivity, maintain quality standards, and streamline operations.

Conclusion

While an Internal Developer Platform like Qovery acts as the backbone, offering paved paths to production and actionable insights, the Internal Developer Portal serves as its front-end, facilitating interaction and visibility. Investing in both can significantly benefit organizations by maximizing developer productivity and operational efficiency.

Let’s start with a simple schema explaining what type of app auto-scaling exists today:

At Qovery, we’re using horizontal and vertical autoscaling on a daily basis for our production at different levels, and the result is excellent when the tuning is made after days/weeks of statistics, analysis, and configuration.

Horizontal autoscaling

Horizontal autoscaling is scaling up an application by adding more app instances to distribute the workload across all instances, allowing for increased capacity and improved performance.

Application autoscaling is different than cluster autoscaling, but it’s somehow related. In the context where your app runs on a cluster (E.g., Kubernetes), the more your app scales up the number of instances, the more your app is likely to consume cluster resources, and the more the cluster is likely to scale up nodes.

Horizontal scaling refers to automatically adding or removing instances based on predefined rules or metrics. When the workload increases, additional instances are dynamically provisioned to handle the increased demand. Conversely, excess instances are automatically terminated when the workload decreases to optimize resource utilization and cost.

Horizontal autoscaling offers several benefits, including:

• Improved performance: By distributing the workload across multiple instances, horizontal scaling can handle increased traffic or resource-intensive tasks more effectively, reducing response times and improving overall performance.

• Enhanced availability: Additional instances provide redundancy and fault tolerance. If one instance fails or becomes overloaded, the load can be automatically distributed to other instances, ensuring uninterrupted service availability.

• Scalability: Horizontal scaling allows for seamless expansion of an application or system by adding more instances. This flexibility enables businesses to accommodate sudden surges in traffic or increased demand without impacting performance.

• Cost optimization: Autoscaling allows you to allocate resources based on actual demand. Scaling up or down based on workload ensures efficient resource utilization, preventing overprovisioning and reducing unnecessary costs.

Vertical autoscaling

Vertical autoscaling is a way to make your application more resource-autonomous by upgrading the resources of a single application instead of adding more machines (and scaling horizontally). It’s like boosting your computer by increasing its CPU power, memory, storage, or network capacity.

With vertical autoscaling, you can improve your application’s performance without the need to manage many instances. It simplifies administration and reduces the complexity of handling a distributed system.

However, there’s a maximum limit to how much you can upgrade an instance before hitting hardware constraints. Also, scaling up or down vertically may require restarting or reconfiguring the machine, resulting in temporary downtime or disruption.

Vertical autoscaling is commonly used in traditional setups or when the workload can’t be easily distributed across multiple instances. It’s handy for applications that require a lot of computational power, memory, or specialized hardware configurations.

Although horizontal autoscaling has gained popularity with cloud computing and containers, vertical autoscaling still plays a role in optimizing the performance and resource utilization of individual instances in specific situations.

Multidimensional autoscaling (Google proprietary)

Multidimensional autoscaling is like having a super-smart system that automatically adjusts the resources of your application or system in multiple dimensions to handle changing demands. It’s all about ensuring your application has the right power and capacity when needed.

Think of it as a dynamic team of helpers that can scale up or down in terms of the number of instances and by upgrading or downgrading the resources within each instance. It’s like giving your application a turbo boost or dialing it down when the workload changes.

With multidimensional autoscaling, you don’t have to adjust resources or add more instances manually. The system takes care of it for you, continuously monitoring metrics like CPU usage, memory, network traffic, or any other custom-defined criteria.

When your application is experiencing high traffic or increased resource demands, multidimensional autoscaling will intelligently add more resources to ensure smooth performance and prevent any slowdowns or crashes. On the other hand, when the workload decreases, it will automatically scale down to optimize resource usage and save costs.

The beauty of multidimensional autoscaling is that it considers multiple factors to make the right decisions. It’s like having a super-smart teammate who knows when to boost your application and when to hold back to avoid wasting resources.

By employing multidimensional autoscaling, you can ensure your application stays resilient, responsive, and cost-effective. It’s like having a magical elastic system that expands and contracts as needed, effortlessly adapting to the ever-changing demands of your application.

Unfortunately, this feature is exclusive to Google Cloud and unavailable as an open-source project.

Conclusion

Tree solutions exist. The most common autoscaling is definitively horizontal autoscaling. A lot of large companies already use it, and it works well in a lot of situations. Vertical autoscaling is helpful, but limitations restrict a lot of its usage. And multidimensional may be the best, but it requires you to know your application very well when setting limits.

Tests are mandatory to ensure the behavior of the autoscaler is the one expected for your application!

What is Qovery?

Qovery is a cloud platform that simplifies the deployment of applications on Kubernetes. With Qovery, developers can focus on writing code and leave the infrastructure management to the platform. Qovery provides a better developer experience on Kubernetes by streamlining the deployment process, automating repetitive tasks, and offering an intuitive web interface and CLI for managing the deployment lifecycle.

Qovery is particularly useful for companies that want to leverage Kubernetes for their applications but don't have the expertise or resources to manage the infrastructure. Qovery enables companies to deploy their applications on Kubernetes with minimal effort, reducing the time and costs associated with infrastructure management.

Whether you're a junior, experienced, or senior developer, Qovery makes deploying your applications to the cloud using Kubernetes a breeze. Qovery abstracts away the complexity of Kubernetes, allowing developers to focus on writing code and delivering value to their customers. With Qovery, you can confidently deploy your applications, knowing that the platform takes care of the underlying infrastructure and provides the tools you need to manage your deployment. Qovery also allows access to your infrastructure and Kubernetes cluster if needed, giving you full control and flexibility over your deployment.

How Kubernetes is operated

Qovery uses a unique architecture to manage thousands of Kubernetes clusters with a single control plane. The control plane is a core component of Kubernetes that manages the state of the cluster and communicates with the API server to perform operations such as deploying and scaling applications. In Qovery's case, the control plane is written in Rust and Kotlin and handles API requests from Git providers and web and CLI interfaces. The control plane then interprets, transforms, and forwards the requests to the appropriate Kubernetes cluster.

The most significant part of the Qovery Control Plane is written in Kotlin, but we have satellite services (not represented here) written in Rust

On the customer side, Qovery runs a set of binaries, including the Engine and Agent, that handle requests from the control plane and execute tasks. Each Kubernetes cluster managed by Qovery is autonomous and does not rely on Qovery Control Plane. This means that in case of a failure of the Qovery control plane or any Qovery components, the customer infrastructure and Kubernetes cluster are not impacted.

Qovery Engine pulls tasks from the Qovery Control Plane and executes those tasks on the Kubernetes cluster. Note that the Qovery Engine initiates the connection to the Qovery Control Plane.

Qovery's unique architecture enables horizontal scaling out of the box, as each Kubernetes cluster is independent and only picks up instructions from the control plane to execute. This means that the Qovery control plane does not need to scale, and the only resource consumption on Qovery is the stream flow of events when a deployment happens.

Metadata is sent over gRPC/TLS

Qovery receives metadata on deployment information, which it handles to manage the state and report what happened to the user.

Handling Thousands of Kubernetes Clusters

When a deployment occurs, metadata is sent from the Qovery Engine and Agent to the control plane. This metadata includes information such as the application name, version, environment, and other details that are relevant to the deployment.

Thousands of Kubernetes clusters can be connected to the Qovery Control Plane

Here's an example of what the metadata payload looks like:

{
  "type": "info",
  "timestamp": "2023-03-02T07:59:44.405961310Z",
  "details": {
    "pool_id": "4ceb7649-ed84-4c52-a27b-e7fca06afaaa",
    "organization_id": "141c07cc-0dd9-4623-9999-3fdd61867555",
    "cluster_id": "a8ad0659-bbbb-4c83-ad77-092e97bb2cae",
    "execution_id": "fba2ac8b-6f78-4444-85c2-b137981056ff-65-1677743982",
    "stage": {
      "step": "PreCheck"
    },
    "transmitter": {
      "type": "Environment",
      "id": "fba2ac8b-6f78-430f-85c2-b1379810ffff",
      "name": "production"
    }
  },
  "error": null,
  "message": {
    "safe_message": "\uD83C\uDFC1 Deployment request fba2ac8b-6f78-430f-85c2-b137981056ff-65-1677743982 for stage 1 `first stage` has been sent to the engine",
    "full_details": null
  }
}

One payload like this represents one line into the Qovery deployment console (like below)

Deployment logs view from the Qovery Web Console

By managing thousands of deployments per day (and growing steadily), we receive hundreds of thousands of metadata like the one below, which is relatively compact. Despite the high volume of deployments, Qovery's control plane performance is not impacted, as there is no transformation on the control plane side. Simple ingestion.

Most of the Qovery Control Plane operations are handled by what we call the Core - written in Kotlin (JVM based). Here is the Core load average for the last 30 days. Each sliced color is a new release of the Core.

This means that Qovery can handle large-scale deployments with ease without worrying. Simplicity is key.

Core Control Plane configuration

Most of the Qovery Control Plane operations are handled by what we call the Core, written in Kotlin (I will explain why we decided to use it in a future article). The Core runs on an instance in the AWS us-east-2 region with 4GB of RAM and 4vCPU. This instance uses the v17 LTS version of the JVM (Java Virtual Machine) and Kotlin 1.8.

Qovery Control Plane Availability

Availability is one of the most important aspects of any cloud infrastructure, and Qovery is no exception. While Qovery's control plane is essential for managing Kubernetes clusters, it's important to note that the infrastructure still runs even if the control plane is unavailable.

Kubernetes clusters keep running without any downtime even if they no longer can connect to the Qovery Control Plane

When the Qovery control plane is unavailable, it's no longer possible to deploy applications or updates via Qovery. However, the infrastructure remains fully functional and independent since each Kubernetes cluster is autonomous and does not rely on Qovery.

Sometimes it's just better to wait and expect it will work again... 😅

To use an analogy, the relationship between a TV and a remote control is similar to that between Qovery and the remote Kubernetes clusters it manages. If your TV remote control has no more battery, your TV will keep running, but you won't be able to change the current channel until you replace the batteries. Similarly, if the Qovery control plane is unavailable, the infrastructure keeps running, but you won't be able to use Qovery to deploy new updates or make changes until the control plane is back up and running.

If you are curious about our reliability, check out our status page 😄

Wrapping up

Qovery is a robust platform that simplifies Kubernetes cluster management and empowers developers to deploy and update their applications easily. The unique architecture of a single control plane allows Qovery to handle thousands of autonomous Kubernetes clusters worldwide while maintaining cluster autonomy ensure that infrastructure remains operational even in the event of a control plane interruption.

By providing a seamless developer experience, Qovery enables developers of all levels to manage their applications easily. Its reliability and scalability give them peace of mind to focus on their code and development work.

Our upcoming article will explore how Qovery manages the upgrade and maintenance of Kubernetes clusters at scale. Stay tuned to learn more about how Qovery can help developers streamline their workflows and focus on what matters most - building great applications.

Resources:

• Qovery Engine code (GitHub)

• How we built Qovery - Part I

Let’s start with a simple schema explaining what type of app auto-scaling exists today:

At Qovery, we’re using horizontal and vertical autoscaling on a daily basis for our production at different levels, and the result is excellent when the tuning is made after days/weeks of statistics, analysis, and configuration.

Horizontal autoscaling

Horizontal autoscaling is scaling up an application by adding more app instances to distribute the workload across all instances, allowing for increased capacity and improved performance.

Application autoscaling is different than cluster autoscaling, but it's somehow related. In the context where your app runs on a cluster (E.g., Kubernetes), the more your app scales up the number of instances, the more your app is likely to consume cluster resources, and the more the cluster is likely to scale up nodes.

Horizontal scaling refers to automatically adding or removing instances based on predefined rules or metrics. When the workload increases, additional instances are dynamically provisioned to handle the increased demand. Conversely, excess instances are automatically terminated when the workload decreases to optimize resource utilization and cost.

Horizontal autoscaling offers several benefits, including:

• Improved performance: By distributing the workload across multiple instances, horizontal scaling can handle increased traffic or resource-intensive tasks more effectively, reducing response times and improving overall performance.

• Enhanced availability: Additional instances provide redundancy and fault tolerance. If one instance fails or becomes overloaded, the load can be automatically distributed to other instances, ensuring uninterrupted service availability.

• Scalability: Horizontal scaling allows for seamless expansion of an application or system by adding more instances. This flexibility enables businesses to accommodate sudden surges in traffic or increased demand without impacting performance.

• Cost optimization: Autoscaling allows you to allocate resources based on actual demand. Scaling up or down based on workload ensures efficient resource utilization, preventing overprovisioning and reducing unnecessary costs.

Vertical autoscaling

Vertical autoscaling is a way to make your application more resource-autonomous by upgrading the resources of a single application instead of adding more machines (and scaling horizontally). It's like boosting your computer by increasing its CPU power, memory, storage, or network capacity.

With vertical autoscaling, you can improve your application's performance without the need to manage many instances. It simplifies administration and reduces the complexity of handling a distributed system.

However, there's a maximum limit to how much you can upgrade an instance before hitting hardware constraints. Also, scaling up or down vertically may require restarting or reconfiguring the machine, resulting in temporary downtime or disruption.

Vertical autoscaling is commonly used in traditional setups or when the workload can't be easily distributed across multiple instances. It's handy for applications that require a lot of computational power, memory, or specialized hardware configurations.

Although horizontal autoscaling has gained popularity with cloud computing and containers, vertical autoscaling still plays a role in optimizing the performance and resource utilization of individual instances in specific situations.

Multidimensional autoscaling (Google proprietary)

Multidimensional autoscaling is like having a super-smart system that automatically adjusts the resources of your application or system in multiple dimensions to handle changing demands. It's all about ensuring your application has the right power and capacity when needed.

Think of it as a dynamic team of helpers that can scale up or down in terms of the number of instances and by upgrading or downgrading the resources within each instance. It's like giving your application a turbo boost or dialing it down when the workload changes.

With multidimensional autoscaling, you don't have to adjust resources or add more instances manually. The system takes care of it for you, continuously monitoring metrics like CPU usage, memory, network traffic, or any other custom-defined criteria.

When your application is experiencing high traffic or increased resource demands, multidimensional autoscaling will intelligently add more resources to ensure smooth performance and prevent any slowdowns or crashes. On the other hand, when the workload decreases, it will automatically scale down to optimize resource usage and save costs.

The beauty of multidimensional autoscaling is that it considers multiple factors to make the right decisions. It's like having a super-smart teammate who knows when to boost your application and when to hold back to avoid wasting resources.

By employing multidimensional autoscaling, you can ensure your application stays resilient, responsive, and cost-effective. It's like having a magical elastic system that expands and contracts as needed, effortlessly adapting to the ever-changing demands of your application.

Unfortunately, this feature is exclusive to Google Cloud and unavailable as an open-source project.

Conclusion

Tree solutions exist. The most common autoscaling is definitively horizontal autoscaling. A lot of large companies already use it, and it works well in a lot of situations. Vertical autoscaling is helpful, but limitations restrict a lot of its usage. And multidimensional may be the best, but it requires you to know your application very well when setting limits.

Tests are mandatory to ensure the behavior of the autoscaler is the one expected for your application!

Qovery is a platform used by more than 22 000 developers to deploy their apps on their AWS accounts. It's the "Heroku-like" experience on top of AWS.

This is the final result 😎

Assumptions 👨‍🏫

• You have an application on Heroku
• You are familiar with Heroku basics, have a Heroku account and access to Heroku CLI
• You have sign in on Qovery
• You have set up your AWS account with Qovery

Costs 💵

• Qovery installs an EC2 instance (perfect for hobby project) or an EKS cluster (perfect for production) on your AWS account.
• Qovery is free up to 100 deployments/month (see pricing)

Migration Steps 🪜

1. Use Buildpacks or Create your Dockerfile
2. Create resources on Qovery
3. Configure Environment Variables and Secrets
4. Copy data from your Heroku databases to your AWS databases
5. Deploy your apps
6. FAQ by Heroku users

1. Create your Dockerfile or Use Buildpacks 🍃

Qovery supports two ways to build and run your application coming from Heroku:

1. Buildpacks
2. Docker

Both options build a container image that is runnable by a container engine (E.g. Docker). Qovery runs containers on Kubernetes.

I will explain how to use Buildpacks. Refer to the original guide to get instructions to use a Dockerfile.

Buildpacks automatically detects the language and the framework your application is using. Buildpacks builds and runs your app. Here is the list of supported languages and frameworks.

Supported languages

⚠️ We do recommend using Docker to keep the full control of what's going on behind the scene. Buildpacks is a great technology but difficult to debug when something goes wrong. You can try deploying your apps on AWS with Qovery with Buildpacks, if you do not succeed, we do recommend switching for Docker.

Limitations 👀

Here are some limitations due to our Buildpacks implementation:

• Qovery Buildpacks does not support Procfile with multiple commands at the moment.
• Qovery does not support custom Buildpacks.

Those limitations will be solved in the coming months.

2. Create resources on Qovery 👩‍💻

Application

Steps:

1. Connect to the Qovery console.
2. Create your Organization and your Project.
3. Create an environment with the name production (it can be changed after).
4. Create an application and give it a name (you can give the name of your repo if you have no idea)
5. Select your app repository from your GitHub, GitLab or Bitbucket.
6. Select the branch you want to deploy.
7. Select the Build mode for Buildpacks or Dockerfile according to what you want.
8. Specify the local listening port of your application.
9. Click on "create"

Congrats! Your application is created 🎉

⚠️ Your application is created but not deployed yet! You can configure the vCPU, Memory, Environment Variables... before deploying it. If you want to deploy it before finishing the configuration you can click on "Actions" > "Deploy".

If you deploy an app from a mono-repository, we have a must-read guide for you here.

Database ⚡️

Here are the steps to deploy your database:

Steps:

1. Go to your production environment.
2. Add your database by clicking on "Add" > "Database".
3. Select the database (PostgreSQL, MySQL, MongoDB, Redis..) and the version you want to deploy.
4. Select Managed or Container mode for your database.
5. Select Public accessibility (set Private if you don't want to restore your data from an existing Heroku database).

Congrats! Your database is created as well 🎉

If you use MongoDB Atlas, or an existing database on AWS that you want to connect to your application deployed by Qovery. Check out our tutorial about VPC peering and how to securely connect to your existing database.

3. Configure your Environment Variables and Secrets 🛡

Qovery makes the difference between an Environment Variable and a Secret. Basically, a Secret is similar to an Environment Variable but the value is encrypted and can't be revealed. Both are injected as environment variables during the build and the run of your applications.

To extract your environment variables from Heroku, we recommend using the Heroku CLI and exporting all the environment variables and secrets in an .env (dot env) file. Qovery supports the import of a dot env file via the Qovery web interface and the Qovery CLI.

⚠️ If you use Buildpacks for one of your app AND you have indicated a local listening port of your application, you will need to add an environment variable PORT with the value of your port to make your application starting properly. Otherwise, Qovery will fail to deploy your app!

Export your environment variable via the Heroku CLI with the command:

# To install Heroku CLI: https://devcenter.heroku.com/articles/heroku-cli
heroku config

GREETINGS: hello world
STRIPE_API_KEY: xxx-yyy-zzz
IS_PRODUCTION: true

Then you can create your environment variables via the web interface (watch the video below)

Or via the Qovery CLI:

# auth yourself
qovery auth

# selection the app where you want to import your environment variables
qovery context set

# import your Heroku environment variables
heroku config --app <your_heroku_app_name> --json | qovery env import --heroku-json

Qovery: Heroku environment variables import from JSON
? Do you want to import Environment Variables or Secrets? Environment Variables
? What environment variables do you want to import?  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
  [x]  GREETINGS=hello world
  [ ]  STRIPE_API_KEY=xxx-yyy-zzz
> [x]  IS_PRODUCTION=true

Qovery: ✅ Environment Variables successfully imported!

⚠️ Import sensitive data (E.g. API keys, credentials...) as Secret and not Environment Variable.

Connect your frontend app to your backend app

To connect your frontend app your backend app we will create an [environment variable alias][docs.using-qovery.configuration.environment-variable#alias-environment-variable].

Here is how to create a frontend app:

And now how to connect your frontend app with your backend app:

You can also take a look at this forum reply to learn how to do it.

Connect your backend app to your database

Same as connecting your frontend app to your backend app, you can create an environment variable alias DATABASE_URL for the built-in secret finishing with _DATABASE_URL_INTERNAL.

⚠️ Create an alias on _DATABASE_URL_INTERNAL and not _DATABASE_URL

4. Copy data from your Heroku databases to your AWS databases

Coming soon with Replibyte

5. Deploy your apps!

We are finally ready to deploy my applications on AWS!

Watch the final result 😎

https://www.loom.com/share/da31c21f9c104eae9270e4c4db59055e

FAQ by Heroku users

How to create a custom domain?

Check out the documentation on how to configure your custom domain.

How to monitor my apps?

We do recommend using Datadog or any other monitoring products for monitoring your apps deployed by Qovery. Check out our tutorial on how to install Datadog

Do you have Heroku "Review App" equivalent?

Yes, it's what we call Preview Environment

How to rollback?

Check out the app rollback documentation

How auto-scaling works?

Check out the app auto-scaling documentation

How to manage database migration?

Check out our forum reply

Is it possible to get a shell / connect to my app?

Yes, with the Qovery CLI and the command qovery shell. Check out the documentation.

Can I use Terraform and Infrastructure as Code?

Absolutely, we have a Qovery Terraform provider available.

How can I connect my app to MongoDB Atlas?

If you use MongoDB Atlas check out our tutorial about VPC peering and how to securely connect to your existing MongoDB Atlas database.

How can I connect my app to an AWS service not managed by Qovery?

If you want to connect your app to an AWS service not managed by Qovery, check out our tutorial about VPC peering and how to securely connect to this AWS service.

If you have a common question about Qovery, we have a more general FAQ section available.

Wrapping up 👋🏼

Congrats! You have migrated from Heroku to AWS. Feel free to check out our forum and open a thread if you have any questions.

Join me if you want:

1. To learn to code in Rust.
2. Contribute to building an ambitious and useful project.
3. Spend a good time.

My schedules:

• During the weekend.
• Some day during the week.

Here is my Twitch.

I can't wait to see you there. Let me know in the comment what you would like to learn about Rust.

The most complex integration that we faced when supporting a new CSP is the database*. A database needs to be performant, resilient, and available 24/7. Each CSP has its own constraints and way to make it works. They do not support the same number of features and the same quality of service.

*I am talking about Open-Source databases like PostgreSQL, MySQL, and Redis. Not proprietary ones like Google Big Query and AWS DynamoDB.

For instance, we recommend using AWS RDS in production for PostgreSQL because the reliability and quality are excellent. On the other hand, we prefer to recommend Digital Ocean when the database is for the development or non-mission-critical projects - because it is reliable enough and cheaper than AWS RDS.

Note: Kubernetes is doing an amazing job to abstract the compute part - this is the standard defacto to run stateless applications - meaning, applications without data. However, running applications with data in a homogenous way across CSPs is still a huge challenge.

So, how can we make database management simpler for the next decade? Let me first show you how applications are built in 2021.

How applications are built in 2021

If you look at the last tech topics in the last 10 years on Hackernews, Hashnode, and Reddit, you will massively hear about API, jam stack, serverless, NodeJS, Django, Rails, and other fancy names. Do you know what they have in common? The Web! Today, most developers are "web developers". We spent time building web API (GraphQL, REST, or Soap for the oldest :)), and we expose those APIs to other services.

We live in a world where developing an application means consuming and providing web APIs.

To build our applications, we also consume APIs like Stripe for payment, Auth0 for authentication, Chargebee for subscription, Intercom for customer support, Sqreen for app security, Datadog for monitoring, and Qovery for app deployment. We live in a world where developing an application means consuming and providing web APIs. So why do we still build backend applications like if we were in 2010?

Nothing has changed in the last 10 years

When I started to work as a system engineer in 2010 and today as a developer in 2021, I saw a lot of things that have changed like:

• how we deploy an application with Docker and orchestrate it in the Cloud instead of using VMs with on-premise servers.
• how the frontend is now so powerful that you don't even need to rely on a backend to build a powerful website - static website and framework is the new norm.
• how you can scale almost to the infinite your compute workload in the Cloud.

This is crazy how things have changed - and for a better developer experience and productivity for companies. But on the other hand, I don't feel that the backend world has changed so much.

We are building backend applications in 2021, like building back-end applications in 2010.

We have new fancy frameworks like Quarkus in Java that make you able to build native code from the JVM; we have the functional programming that has gained in popularity in the last 8 years, we have NoSQL that was "supposed" to replace SQL, microservices, reactive programming and a few other fun concepts. But in the end, we are building back-end applications in 2021, like building back-end applications in 2010. Some of you probably think it is wrong, but let me explain why it is not.

What is the problem with databases

I never built a back-end application that did not require using a database in my developer's life. To be honest, it happens once. When I had to create an API gateway to send push notifications to Apple APNS and Google FCM, 🙄 that's it. And I think most of us as backend developers are 99% of the time using a database to fetch and store data.

Databases like PostgreSQL, Redis, MongoDB, MySQL, SQLServer are robust product with tons of engineering behind. They are reliable, highly performant, and stable for most businesses. However, those databases have been designed before the Cloud was a thing. Do you remember when you had to rack your servers? :) Yes, that was the time most of the databases that we are daily using were designed. Those databases require to have a dedicated container/VM/server instance to run perfectly. My concern is: why in 2021 we do we need to dedicate CPU, memory, and storage to a database while we build web applications that will store a limited amount of data? As said before, does your app need an authentication system? Use Auth0 (now Okta). Does your app need to accept payments? Use Stripe. Does your app need to store photos? Use AWS S3... In the end, it only remains your business data in your database. So, do we need a sledgehammer to kill a gnat? 🤔

How to bring a better database experience for backend developers

I am obsessed with simplifying the lives of developers. Building and deploying applications should be simpler than what it is today - and for anyone. One true source of inspiration to me in terms of developer experience was Vercel. Vercel turns developer experience (DX) from the app development to the deployment for frontend developers so smooth that even developers freshly out of Bootcamp know about their products. So here is my plan on how to bring a better database experience for backend developers.

Database as a library

Using a database should be as easy as using any external library. Using your favorite dependency manager, and then you are ready to go.

# Install PostgreSQL for NodeJS
npm install postgresql-server

# Intall PostgreSQL for Python
pip install postgresql-server

No code change

Once the library is installed, you can use the driver to connect to your local in-memory database without any change.

const { Pool, Client } = require('pg');

// URI to connect to your PostgreSQL instance
const connectionString = 'postgresql://postgres:postgres@localhost/postgres';

const pool = new Pool({
  connectionString,
});

// ...
// exec postgresql requests
// ....

Built for the Cloud

The Cloud allows your applications to be run anywhere and in a very scalable way. That's why my vision for the future database is to automatically discover the neighbor instances to share data and scale horizontally. And persist the data into an object storage service that is S3 API compatible like AWS S3, Digital Ocean Spaces, Scaleway Object Storage, Google Cloud Storage, etc... A good example of this kind of implementation is Grafana Loki, where all logs are stored into the Object Storage of your choice. You can read their interesting design doc.

Consistent testability

Getting a database as a library will provide consistent behavior. Where your app runs, your database is accessible. So on your laptop, your teammate computer, your smartphone, and in the Cloud.

This is a dream, but this dream can be a reality. That's why I have initiated a project called RedisLess, to see how we can build a better database experience for modern backend developers.

An experiment: RedisLess - a Key/Value store library - Redis API compatible

RedisLess is an experiment for the database of the future.

RedisLess is an experiment to provide a fast, lightweight, embedded, and scalable in-memory Key/Value store library compatible with the Redis API. This project aims to check the feasibility of the principle listed above, and in a few days of works we succeed to have:

• Transparent for the developer
• No Redis server required

The remaining steps are:

• Supporting auto-discovery.
• Supporting data sharing between instances.
• Supporting persistence.

As a developer, you don't need to change a single line of code to use RedisLess. And this is only the beginning. What about creating the same abstraction for PostgreSQL, MySQL, and most popular databases?

Special thanks to our contributors ❤️

Why all of that matters

I believe in the idea of building backend applications without having to think about how data are stored, backed up, available across multiple instances. Can't we bring for the next decade a simpler way to design databases for modern applications? This is my obsession, and if you are interested in learning more and contributing somehow, please contact me on my discord.

Better understanding of memory management

I remember the time I used to learn to program in Python. Memory was managed by the language, and I didn't need to understand how things work. Grasping algorithmic and all basic concepts when you are a beginner takes time. So spending time thinking about how to manage memory allocation is meaningless. But once you are fluent in programming and it is now so easy that you can focus on business value, it is maybe time to dig into how to build more efficient programs.

For a long time, the efficiency of a program was about lower cost and performance. But in 2021, we can add a third dimension - power efficiency 🌎.

Heap vs Stack

Java, Python, Javascript, Typescript, Go, Haskell, C# are managed programming languages. You don't need to think about memory allocation - does this variable x is allocated on the heap or on the stack? (read more about Heap vs Stack). On the other hand, programming languages like C, C++, and Rust forced you to think about how you want to memory allocate your variable x.

# Python - Stack x memory allocation
x = "hello world"

// Rust - Stack x memory allocation
let x: &str = "hello world";

Those two var assignations look similar, right? They are! They are allocated on the Stack. The difference is that with Rust, we have more fine-grained control on the memory allocation. For instance, to allocate "hello world" on the Heap:

// Rust - Heap x memory allocation
let x: String = String::from("hello world");

Heap allocation is not explicitly possible with Python - The interpreter manages it for you.

To summarize: Stack is used for static memory allocation and Heap for dynamic memory allocation, both stored in the computer's RAM. Variables allocated on the stack are stored directly to the memory, and access to this memory is very fast. The Heap memory allocation is slower than the Stack memory allocation.

Reference vs Value

In Python, you don't even need to think about whether your function variables are passed by reference or value.

# declare a function "sum"
def sum(a, b):
  return a + b

sum(2, 1) # the result is 3

In this situation, values 2 and 1 are passed to the function sum by value.

# declare a function "sum" accepting a list object
def sum(elements):
  accumulator = 0
  for e in elements:
    accumulator += e

sum([2, 1]) # the result is 3

And in this situation, the list with values 2 and 1 inside is passed to the function sum by reference. 🙄

It is not exactly true. In Python, "object references are passed by value" and not by reference. But I will not go into details here.

In Rust, you have to be specific if you want to pass a variable by reference or value.

// pass by value
fn sum(a: u16, b: u16) -> u16 {
  a + b
}

sum(2, 1) // the result is 3

Values 2 and 1 are passed to the function by value. To pass by reference, you have to use & explicitly.

// pass by reference
fn sum(elements: &Vec<u16>) -> u16 {
  let mut accumulator = 0;
  for e in elements {
    accumulator += e
  }

  accumulator
}

let values = vec![2, 1];
sum(&values) // the result is 3

We pass a list of values by reference to the function sum. And we can do the same by passing the value of the list by removing &

// move elements and consume them
fn sum(elements: Vec<u16>) -> u16 {
  let mut accumulator = 0;
  for e in elements {
    accumulator += e
  }

  accumulator
}

let values = vec![2, 1];
sum(values) // the result is 3

The difference is that Rust will consume the list and will remove it from memory. This is a specific behavior of Rust (read ownership ).

Passing variable by reference or value look anecdotal, but they are not when you need to build highly performant system like databases, embedded devices, and many others.

Build safer programs

As a programmer, when you start to build concurrent programs, you don't really realize how hard it is to write safe concurrent code. This is so abstracted and easy to write unsafe code that we all fall into the trap at least once, and even when we are more experienced. Let me show one unsafe Golang code that I saw one time from an experienced developer:

// golang example
m := make(map[string]string)

go func(m map[string]string) {
  m["gender"] = "male"
}(m)

go func(m map[string]string) {
  m["gender"] = "female"
}(m)

fmt.Println(m) // m["gender"] is male or female?

this is not the exact code, but the idea of concurrently modifying a hashmap was the same

So, the value of m["gender"] is male or female? 🤔

We can't know. This code is not deterministic due to concurrent writes. If you run this code multiple times, you will sometimes have male, sometimes female, and even sometimes fatal concurrent write errors 😨 To concurrently edit the hashmap m you have to make it thread safe. This kind of error happens all the time, even to experienced developers in more complex situations. This is where Rust helps developers to prevent this kind of mistake. Here is the equivalent in Rust:

let mut m: HashMap<&str, &str> = HashMap::new();

thread::spawn(move || {
  m["gender"] = "male";
});

thread::spawn(move || {
  m["gender"] = "female";
});

println!("{:?}", m);

And the compiler prevents you from doing nasty stuff.

error[E0382]: use of moved value: `m`
  --> src/main.rs:11:19
   |
5  |     let mut m: HashMap<&str, &str> = HashMap::new();
   |         ----- move occurs because `m` has type `HashMap<&str, &str>`, which does not implement the `Copy` trait
6  |     
7  |     thread::spawn(move || {
   |                   ------- value moved into closure here
8  |        m["gender"] = "male";
   |        - variable moved due to use in closure
...
11 |     thread::spawn(move || {
   |                   ^^^^^^^ value used here after move
12 |        m["gender"] = "female";
   |        - use occurs due to use in closure

Rust compiler is super smart, it prevents you from doing race condition, and there is no way to compile this kind of code because it is simply wrong. That's why so many developers said that Rust is frustrating. The Rust compiler is just honest with you and tells you the truth about your code. You were probably writing wrong code for long time, and you didn't know until now. I know, it's hard to change habits, and that's why in this kind of situation Rust is your best friend. It will always tell you the truth, even if it is not pleasant :)

A thread-safe code in Rust looks like this (don't use it in production - using .unwrap() here can block threads):

let mut m: Arc<Mutex<HashMap<&str, &str>>> = Arc::new(Mutex::new(HashMap::new()));

thread::spawn(move || {
  m.lock().unwrap()["gender"] = "male";
});

thread::spawn(move || {
  m.lock().unwrap()["gender"] = "female";
});

println!("{:?}", m);

Conclusion

I hope you liked this article, and it gives you the appetite to try out Rust. If you have no idea how to start learning it, I would recommend reading the official free ebook. Then, trying to reimplement some good old academic (or not) algorithms and data structures in Rust. If you want to put your hands into dirty stuff, I can recommend contributing to my project Qovery Engine and RedisLess as well.

Here is a shortlist of Rust projects that I recommend to read:

• Meilisearch : Algolia and Elasticsearch search engine alternative.
• Sonic : Lightweight Elasticsearch alternative.
• Sled : Storage engine written in Rust - alternative to RocksDB.
• IsomorphicDB : PostgreSQL clone - it is a good experimental project written in Rust.
• Raft-rs : Raft consensus protocol implemented in Rust by PingCap.
• RedisLess: RedisLess is a fast, lightweight, embedded, and scalable in-memory Key/Value store library compatible with the Redis API.
• Qovery Engine: Qovery Engine is an open-source abstraction layer library that turns easy apps deployment on AWS, GCP, Azure, and other Cloud providers in just a few minutes.

==========

I am hiring Rust developers for my wonderful company.

THIS PROJECT IS NOT PRODUCTION READY YET!!

Imagine a world where your database is nothing more than a lib in your app 🥰.

Imagine a world where using Redis is as simple as npm install redisless, and that's it!

If you dream of this world (as I do), then you will love RedisLess - and hopefully, be part of this journey 🥳.

What is RedisLess

RedisLess is a fast, lightweight, embedded, and scalable in-memory Key/Value store library compatible with the Redis API.

The project is still early, so don't take any of those words for granted at the moment.

RedisLess is written in Rust and export functions through FFI (Foreign Function Interface), making it usable from any language. I've started to write clients for NodeJS and Python.

How to use RedisLess

To use RedisLess, you only need to:

1. Install the RedisLess library for your favorite language.
2. Connect your favorite Redis client to redis://localhost:16379.
3. You don't need to change your code - RedisLess is Redis API compatible.

Under the hood, the RedisLess library starts a local Redis API compatible instance on port 16739 (you can change the port).

Python usage example

Here a simple example in Python

from redisless import RedisLess
import redis

redisless = RedisLess()

# start RedisLess embedded instance
redisless.start()

# Connect to RedisLess on localhost:16379
redis = redis.Redis(host='localhost', port=16379, db=0)

redis.set('foo', 'bar')
redis.get('foo')  # return bar 

# stop RedisLess embedded instance
redisless.stop()

As you can see, we are using the official Python Redis client to connect to RedisLess. Nothing else. Meaning, if you are already using Redis in your code, you can use RedisLess without changing a single line of code. Is it magic? No, it is not. Let me explain how it works.

Supported languages

• [wip] Python
• [wip] NodeJS
• [-] Golang
• [-] Java / Kotlin

Supporting a new language can be done in 5 minutes. Look at Python and NodeJS clients implementation for inspiration.

How RedisLess works

The main characteristic is that RedisLess runs inside your app, where Redis Server runs inside a dedicated service and instance. It is a considerable difference because RedisLess does not need any external dependency to work. The more you have apps running, the more your app is resilient to failure.

Here is a specs comparison table

Features highlight

Redis API

RedisLess is not 100% Redis API compatible. Meaning, some commands like CLIENT TRACKING, AUTH, and ACL LOAD are irrelevant. However, transactions are not available right now but will be in the future. It just takes time to implement features.

Built for the Cloud

Redis Server was built before the Cloud was a thing. If you want to use Redis Server properly, you have to set up an instance with local storage and do some fine-tuning to make it works properly for high and intensive usage. RedisLess does not need anything like this. No need to spend time managing servers. It works in memory within your app. It is much easier when your app runs in a Cloud-native environment (E.g. within a container / Kubernetes / function as a service) and needs to scale dynamically based on the workload.

Slower Cluster write performance

If you are familiar with distributed system, you probably know that it is impossible to have strong consistency, high availability, and high performance all at the same time. You have to choose. Redis Server Cluster lets you decide how you want to configure your cluster and then gives you a choice between performance and availability. With RedisLess, we make the choice of availability for writes and performance for reads with eventual consistency. It is not a definitive choice.

Contribution

RedisLess is in its early days, but I am serious about building a solid library to help thousands of developers.

It is never too soon to contribute and be part of a great project. If you are interested in contributing, join us on Discord.

Genesa of this project

One year ago, I started a company with Pierre Mavro. We wanted to make app deployment easy for any developer. Today, 2666 developers from more than 110 countries deploy their apps on AWS and Digital Ocean using our product. I saw firsthand how developers struggle during days (sometimes weeks 😨) to deploy their apps. But why is it so complicated? Deploying an app itself is not complex. But setting up all external dependencies to make it works is. What about configuring servers, databases, networks? Even with the Cloud, it is not so simple. That's why my team and I wanted to go further than app deployment and build the future of database management.

How to join the project

If you are interested in contributing (even if you don't know yet how). Comment on this post and indicate:

• What languages do you use?
• What is your experience: beginner, experienced, expert?
• Do you have experience in contributing Open-Source projects?
• A few words about you and why you are interested in RedisLess.

👉 Please support us with a Github star ⭐️.

Thanks to @pjeziorowski for his contribution to this post. ❤️

/// I am Rust code -- https://github.com/Qovery/engine
pub fn delete_stateless_service<T>(
        target: &DeploymentTarget, 
        service: &T, 
        is_error: bool
) -> Result<(), EngineError>
where
    T: Service + Helm,
{
    let (kubernetes, environment) = match target {
        DeploymentTarget::ManagedServices(k, env) => (*k, *env),
        DeploymentTarget::SelfHosted(k, env) => (*k, *env),
    };

    let helm_release_name = service.helm_release_name();

    if is_error {
        let _ = get_stateless_resource_information(kubernetes, environment, service.selector().as_str())?;
    }

    // clean the resource
    let _ = do_stateless_service_cleanup(kubernetes, environment, helm_release_name.as_str())?;

    Ok(())
}

This is art 😍

I used to play piano, produce electronic music, and play lego when I was young. Coding is perfect for expressing your creativity and much more than that...

Coding is fun, not dumb

Absolutely, coding is fun. Do you know CodinGame and Codewars? People like me are crazy enough to spend time doing coding exercises to improve their skills and their ability to resolve problems. I like new challenges and coding is perfect for that. What about coding in a new language a problem that you have solved 100 times in your day-to-day programming language? Did you hear about Object Oriented Programming or Functional Programming? They are two different ways of solving the same problems. It's like going back home from school but using a different path than usual. Your brain is a muscle, using it in a different manner helps to make it even stronger to solve a large variety of problems. This is so cool 🤯🤩

# iterative
a = []
for x in range(100):
  a.append(x*2)

# comprehension list
b = [x*2 for x in range(100)]

# functional
c = list(map(lambda x: x*2, range(100)))

# a == b == c

3 different ways of doing the same operation in Python

Coding is rewarding

I love brain teasers. Those games where I spend minutes to hours to find out what's the solution for them is so enjoyable 😄. Coding is about finding the most optimal solution to a problem. At Qovery (my company), our current main challenge is to turn app deployment seamless for developers on AWS, GCP, Azure... To achieve that, we need to solve tons of smaller problems. This is where I love my job 🍿Divide to conquer is rule number one.

Coding is like superpowers

In a digital world, being able to understand and talk the language of computers is divine. Even ordering your pizza is possible through web API.

curl 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer <JWT>" 
  -X POST 
  -d  
 '{
    "Flavor": "ABC", 
    "Crust": "XYZ",
    "Size": "XL", 
    "Table_No": 9
  }' 
  https://order-pizza-api.herokuapp.com/api/orders

🍕

Coding makes you better CEO in 2021

# I am Python code
prospects = [p for p in linkedin_profiles if profile.good_prospect()]
for protest in prospects:
  # this is how we make money right? :D
  prospect.sell_product()

It has never been so easy to launch a company in 2021. With almost no fund, you can start to build the company of your dream online. The only problem is if you have no coding skills, you will no go very far without asking for help from someone $$$ (yes, I know there are plenty of no-code tools -- but at some point, you'll need to code something -- if you have a CTO, you're safe then :)).

For instance, last week, I worked on scraping the data from a few sources to better know my users. And I didn't need to disturb my team to do so.

And the week before, I created our Community Call page.

You are never better served than by yourself. This is all about freedom.

I am a creative, maker, and entrepreneur. I love to be free, and not relying on anyone to achieve what you have in mind is gold! Happy coding 👋

Reads:

• Programming addiction
• Reward pathway in the brain (video)

And you? Are you a coding addict too?

-- Pssst: I am hiring 👨‍💻

Romaric.