Hi everyone, Ala here. I'm the co-founder of Klotho (https://klo.dev). We built a tool that allows you to write cloud applications without the complexities that exist with today's approaches.
Infrastructure-as-Code is the current state of the art, but the level of work needed to implement a cloud system with it is extremely high, to the point where teams and companies staff an entire organization to support the rest of the company in building features.
Klotho solves that by inferring the application architecture from the application source, with a bit of help from simple annotations that developers add. Then, it generates the IaC that the architecture implies.
For example, if you have a Node.js app with an fs/promises object, you can turn that into S3 persistence as simple as:
// @klotho::persist { id="imagestore" }
import fs = require("fs/promises")
Today, we support:
- multiple languages (JavaScript/Typescript on Node.js; Python; Go; more coming soon)
- IDE extensions for syntax highlighting
- AWS Lambda, ECS or EKS
- HTTP endpoints
- persisting data to S3, DynamoDB, Redis, and various ORMs
- secrets
- event-driven workflows
- static asset hosting
- and all of these include the various dependencies and "glue" resources, including network resources and IAM roles/policies
You're right, the developer (or operator) will still need to know how to troubleshoot. For this first stage we're focusing on improving development and iteration speed while maintaining status quo on operating & troubleshooting. One of our design principles is to keep the application debuggable, which means if there's a problem in the application it should be easy for the developer to use the tools and methods they're used to to figure out what's going wrong. Similarly for the infrastructure, since Klotho utilizes existing cloud providers, existing tools are still a good way to debug.
To make sure troubleshooting the code is as smooth as possible, we keep the transformed code as close to the original source as possible. It's important that the code for the application that is actually running in the cloud is recognizable to the authors that wrote it.
Later on, we do plan on trying to tackle this problem (easier to troubleshoot with less knowledge requirement).
7 comments
[ 3.3 ms ] story [ 28.7 ms ] threadInfrastructure-as-Code is the current state of the art, but the level of work needed to implement a cloud system with it is extremely high, to the point where teams and companies staff an entire organization to support the rest of the company in building features.
Klotho solves that by inferring the application architecture from the application source, with a bit of help from simple annotations that developers add. Then, it generates the IaC that the architecture implies.
For example, if you have a Node.js app with an fs/promises object, you can turn that into S3 persistence as simple as:
// @klotho::persist { id="imagestore" }
import fs = require("fs/promises")
Today, we support:
- multiple languages (JavaScript/Typescript on Node.js; Python; Go; more coming soon)
- IDE extensions for syntax highlighting
- AWS Lambda, ECS or EKS
- HTTP endpoints
- persisting data to S3, DynamoDB, Redis, and various ORMs
- secrets
- event-driven workflows
- static asset hosting
- and all of these include the various dependencies and "glue" resources, including network resources and IAM roles/policies
We're open source, so check us out on GitHub: https://github.com/klothoplatform/klotho. We're also on Discord (https://discord.gg/4z2jwRvnyM), and here of course.
To make sure troubleshooting the code is as smooth as possible, we keep the transformed code as close to the original source as possible. It's important that the code for the application that is actually running in the cloud is recognizable to the authors that wrote it.
Later on, we do plan on trying to tackle this problem (easier to troubleshoot with less knowledge requirement).