Skip to main content

Welcome to Raftt

What is Raftt?​

Raftt creates modern, flexible environments synced with existing tools, features, and workflows to help developers explore and develop freely. Our cloud-based platform liberates developers from the limitations of their hardware and local environments, allowing them to spawn an unlimited number of environments and collaborate and share without sacrificing stability or performance.

You can switch, branch, and share environments without changing tools or altering existing workflows. Concentrate on coding with our environment-friendly solution. Built by world-class experts and professionals, Raftt helps developers spend more time on innovation.

Who Should Use Raftt?​

We're here to help developers who are tired of drift, decay, and overhead from their local development environment and are exhausted from spending too much time stabilizing and maintaining it.
Unlike other remote or browser-based dev environment solutions, Raftt focuses purely on the development process. With Raftt, debugging is easy, and environments can be shared via URL with anyone.

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. Run multiple environments without overloading your machine.
  3. Write code that runs remotely, but feels as if it is 100% local.
  4. Collaborate with your team and external stakeholders by sharing access to your environments.
  5. Easily create a consistent dev environment for the whole team.
  6. 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.