Skip to main content

Welcome to Raftt

What is Raftt?​

Raftt allows fast code iterations and debugging over complex Kubernetes environments. You can connect to environments orchestrated by existing tools (ArgoCD, Flux, or anything else), or you can use Raftt to orchestrate the environments for you. Either way, you get the optimal development experience - iterations that take under a second, OOTB debugging of your code as it runs in the cluster, easy introspection, and more.

Who Should Use Raftt?​

We're here to help developers who are stuck with no good options - either they forgo testing their code in an environment similar to where it will run in production, or they do, but each change has to go through CI, and it takes over 15 minutes to understand if it works.

Raftt allows using your preview / test / staging environment for development, giving you a full development experience including code syncing and hot reloading, and OOTB debugging in your local IDE.

What Can You Do With Raftt?​

  1. Create a smooth dev experience on top of existing K8s dev envs, including live-reload and out-of-the-box debugging.
  2. Develop on complex environments without running Kubernetes locally and overloading your machine.
  3. Iterate on your code inside the containers in which it runs.
  4. Easily create a consistent dev environment for the whole team.
  5. Develop and debug your microservices in a production-like environment without any of the container-related pains.

The Challenges of the Current Solutions​

Local Machine Development​

Most devs handle the challenges of developing a microservice environment by running the main processes of the containers as processes on their local machine. There are several drawbacks to this approach -

  1. Setup and maintenance - devs dedicate a lot of time and resources to maintain an environment. Moreover, the env requirements keep changing, so the maintenance work is never done.
  2. Drift between dev environments - devs tend to adjust their environment and do whatever it takes to make things work. This creates the "works for me" phenomenon - having different dev environments causes different behavior between devs.
  3. Context switching is hard - switching to a different branch often breaks the environment due to local non-committed dependencies.
  4. Different from the production environment - running outside of containers can change the env behavior.

Locally Orchestrated Environments​

Many developers work on their micro-services environments locally, using Docker Compose, Minikube, or similar tools. This approach can be more helpful, as it gives the user lots of control over the environment while enforcing some consistency between team members. However, this approach also has several drawbacks -

  1. Limited resources - good dev computers might have lots of CPU and RAM, but running a complex environment composed of many containers can be a heavy task, even for high-end computers.
  2. While reduced, environment drift is still a problem - dependencies and hacks that are not a part of the containers still create drift.
  3. Singleton environment - the environment is still a single instance, so context or branch switching that requires changes at the environment level is expensive - the containers need to be rebuilt and restarted.
    Using persistent volumes aggravates the problems since it's even harder to switch between states of the storage.

Remote Machine Development​

A newer approach that tries to tackle the challenges of running your environment locally is using a cloud machine as a dev machine. This approach does deal with the limited resources drawback, but the rest of the issues (drift, multi-environments) remain problematic.

Remote Kubernetes Dev-cluster​

Another modern approach is having a pipeline that creates dev/preview envs on a remote dev cluster, usually having each spawned env in a namespace. Envs are either created by manual triggers or as a part of a GitOps workflow, e.g. on every PR. This approach does enjoy some of the benefits of remote dev envs, such as less limited resources and the ability to be more similar to production, but it lacks in some other important criteria for dev-envs -

  1. Long dev-loop - it's easy to create envs, but it's not easy to use them for actual development. Quick iteration is a critical part of the dev lifecycle. Being able to modify code, see the effects of the change and reiterate must take seconds. In most cases, deploying changes requires re-running the pipeline which can take between minutes to an hour. In most cases interactive debugging is out of question, which causes another hit on dev velocity.
  2. Maintenance costs - maintaining the env spawning system can be expansive, and the more features are added to it, the more expansive it gets. This leads in many cases to under-maintenance which leads to rot, which hurts the dev-velocity even harder.