I use shuttle to deploy some side Rust projects for my web facing parts. I love it.
They are also planning to allow you to host it yourself via a docker setup, in your basement or cloud. For now I’m just doing it via their service and gladly pay for it.
If you’re well versed into DevOps related activities you might find it odd that there’s a need for it. But personally I’m a father of 3 kids, have been a developer and and hacker for last 12 years or so, and while I could do AWS, gcloud or a VPS myself, I honestly rather spend that time on my product then infra worries. So far I haven’t experienced any issues with them and they are very friendly folks, always ready to help. They’ll also be at EuroRust next week.
If you’re like me someone who likes to develop stuff but not so much the deployment side of things, then honestly this is nice.
There’s honestly no lock-in:
1. You’re service (project) can easily be converted into a regular project, as shuttle is in code only visible in a minimal way, so you can fairly easily refactor it out of your project the day you want to switch away
2. And like I said they’ll allow to self host soon enough.
So maybe you can give it a try. Might be the accelerator you need to help you start a project / business idea. Even if just to get you started.
Infrastructure from code is the least exciting development in the evolution of ops I've seen.
Helping manage complexity -- great. Pulumi, Terraform, the CDK, all of these infrastructure as code tools help manage complexity.
Hiding complexity behind a DSL, via comments attached to methods intermingled with code or annotations -- not great.
Some of these implementations are my business logic -> your DSL via annotations or comments -> <Some other IaC DSL> -> CloudFormation -> AWS. At some point the returns are diminished as you add more layers vs. the cost of operating what's generated and trying to debug issues.
"Infrastructure from code is the least exciting development in the evolution of ops I've seen"
The best things in programming are the things that are the least exciting. Stability and simplicity are huge selling points unless all you want is the new shiny.
Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages.
That said, the “infrastructure-from-code” idea is interesting. I’m not a big fan of coupling your code to your infra, but I’m intrigued by the idea of inferring infra dependencies from existing application code.
> Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages.
I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.
You got that right. What Shuttle is trying to do, among other things, is to extract the difficulties of getting started, especially in a language like Rust, so that you can focus on writing good code and moving fast (when moving fast is a requirement).
Rust is not a prototyping language. If you need something done quick&dirty, pick e.g. Python. Personally I don't feel like writing something in Rust would take significantly more time than any other language, provided you know Rust pretty well already.
Its not aimed towards fullstack anyway. You CAN write webapps, and leptos is an amazing tool! But developing in leptos is a huge bottleneck. It takes to build than angular, and that says enough
I've been surprised at how much I like Rust for backend work, but looking at the read me I have no idea what the case for this tool is. What do you use it for?
It let's you deploy apps quickly and manage infrastructure without having to battle the AWS console and/or config files. A simple server (via most Rust frameworks) can be deployed by utilizing an annotation and then running `cargo shuttle deploy` whereas adding a resource, like a Postgres database for example, is also a matter of adding an additional annotation.
Glad Im not the only one. I checked out their examples repo, and Im still very confused as to what the library does. The shuttle runtime trait has me very confused as the API is built on Rocket.
I would generally try to characterize Shuttle as "the Vercel of Rust", though I guess that might not explain much to people that don't know what Vercel does.
> We build and deploy every project in its own container. This gives you safe isolation from other users and all the other projects that are owned by your account.
So that's a "no". Containers are not strong security boundaries. Probably good enough between projects owned by your own account, but definitely not for between other users.
Disclaimer: I'm one of the co-founders of Shuttle. Also, I haven't used Pulumi so I don't want to misrepresent it.
However, as far as I understand, Pulumi is an infrastructure _as_ code solution, offering an SDK in various languages which wrap providers enabling you to define your desired infrastructure. In the context of a cloud provider like GCP, this means wrapping the existing GCP primitives and services (i.e. GKE) and enabling you to declare your desired infrastructure in your favourite programming language.
Shuttle is an infrastructure _from_ code solution. The infrastructure that is provisioned for you is defined implicitly by your application's code. Static analysis is done at compile time to figure out what you need implicitly (i.e. if you're using a database connection pool, you probably need a database). Furthermore Shuttle offers its own primitives (i.e. secrets management) without a necessary correspondence to an underlying cloud provider (although there are some, like AWS RDS).
It would be great if there are some kind of code snippet on the README that really demonstrate the "ship backends without writing infra" feature that I think is one of the unique feature of shuttle. I remember seeing one on the official website (https://shuttle.rs) that left me impressed.
We do a bit the same at windmill.dev except for python and typescript and we parse the parameters directly from the signature without needing to use macros/annotations. I wonder if the same could not have been done here where the macro would have been as a build processor.
That's what we do with Klotho [0], annotations are only used to close behavioral gaps that are not available in application code. (I'm one of the founders)
[+] [-] gdcbe|2 years ago|reply
They are also planning to allow you to host it yourself via a docker setup, in your basement or cloud. For now I’m just doing it via their service and gladly pay for it.
If you’re well versed into DevOps related activities you might find it odd that there’s a need for it. But personally I’m a father of 3 kids, have been a developer and and hacker for last 12 years or so, and while I could do AWS, gcloud or a VPS myself, I honestly rather spend that time on my product then infra worries. So far I haven’t experienced any issues with them and they are very friendly folks, always ready to help. They’ll also be at EuroRust next week.
If you’re like me someone who likes to develop stuff but not so much the deployment side of things, then honestly this is nice.
There’s honestly no lock-in:
1. You’re service (project) can easily be converted into a regular project, as shuttle is in code only visible in a minimal way, so you can fairly easily refactor it out of your project the day you want to switch away 2. And like I said they’ll allow to self host soon enough.
So maybe you can give it a try. Might be the accelerator you need to help you start a project / business idea. Even if just to get you started.
[+] [-] bckr|2 years ago|reply
[+] [-] hydroid7|2 years ago|reply
[+] [-] ctvo|2 years ago|reply
Helping manage complexity -- great. Pulumi, Terraform, the CDK, all of these infrastructure as code tools help manage complexity.
Hiding complexity behind a DSL, via comments attached to methods intermingled with code or annotations -- not great.
Some of these implementations are my business logic -> your DSL via annotations or comments -> <Some other IaC DSL> -> CloudFormation -> AWS. At some point the returns are diminished as you add more layers vs. the cost of operating what's generated and trying to debug issues.
[+] [-] postalrat|2 years ago|reply
[+] [-] wernercd|2 years ago|reply
The best things in programming are the things that are the least exciting. Stability and simplicity are huge selling points unless all you want is the new shiny.
[+] [-] mrits|2 years ago|reply
[+] [-] jetpackjoe|2 years ago|reply
[+] [-] jbotdev|2 years ago|reply
That said, the “infrastructure-from-code” idea is interesting. I’m not a big fan of coupling your code to your infra, but I’m intrigued by the idea of inferring infra dependencies from existing application code.
[+] [-] earthling8118|2 years ago|reply
[+] [-] dralley|2 years ago|reply
I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.
[+] [-] satvikpendem|2 years ago|reply
[+] [-] dohman|2 years ago|reply
[+] [-] FranGro78|2 years ago|reply
It’s a new startup by an ex-engineer on the AWS CDK team.
[+] [-] lucgagan|2 years ago|reply
[+] [-] sitkack|2 years ago|reply
Both of these comments contain zero worthwhile information.
[+] [-] qweqwe14|2 years ago|reply
[+] [-] ramon156|2 years ago|reply
[+] [-] brainbag|2 years ago|reply
[+] [-] dohman|2 years ago|reply
[+] [-] yuppiepuppie|2 years ago|reply
[+] [-] hobofan|2 years ago|reply
[+] [-] dohman|2 years ago|reply
[+] [-] eandre|2 years ago|reply
[1] https://encore.dev
[+] [-] turtlebits|2 years ago|reply
I'm not so keen on a single language only SaaS either. How many companies only deploy code in a single language?
[+] [-] kevincox|2 years ago|reply
> We build and deploy every project in its own container. This gives you safe isolation from other users and all the other projects that are owned by your account.
So that's a "no". Containers are not strong security boundaries. Probably good enough between projects owned by your own account, but definitely not for between other users.
[+] [-] lijok|2 years ago|reply
[+] [-] farmeroy|2 years ago|reply
[+] [-] oldpersonintx|2 years ago|reply
[deleted]
[+] [-] jeffypoo|2 years ago|reply
Curious how you see this stacking up against things like Pulumi?
[+] [-] openquery|2 years ago|reply
However, as far as I understand, Pulumi is an infrastructure _as_ code solution, offering an SDK in various languages which wrap providers enabling you to define your desired infrastructure. In the context of a cloud provider like GCP, this means wrapping the existing GCP primitives and services (i.e. GKE) and enabling you to declare your desired infrastructure in your favourite programming language.
Shuttle is an infrastructure _from_ code solution. The infrastructure that is provisioned for you is defined implicitly by your application's code. Static analysis is done at compile time to figure out what you need implicitly (i.e. if you're using a database connection pool, you probably need a database). Furthermore Shuttle offers its own primitives (i.e. secrets management) without a necessary correspondence to an underlying cloud provider (although there are some, like AWS RDS).
[+] [-] sbt567|2 years ago|reply
[+] [-] rubenfiszel|2 years ago|reply
[+] [-] ashiban|2 years ago|reply
[0] https://klo.dev
[+] [-] kjfarm|2 years ago|reply
I thought trends were changing so quickly I now miss them before I even know about them. Glad I still have a few years left of semi-keeping pace
[+] [-] dohman|2 years ago|reply
[+] [-] irf1|2 years ago|reply
full interview (38min): https://youtube.com/watch?v=GBT7yp17P4Y
highlights (10min): https://youtube.com/watch?v=TVco_9E9no8
[+] [-] TruthWillHurt|2 years ago|reply
[+] [-] willsmith72|2 years ago|reply
[+] [-] revskill|2 years ago|reply
[+] [-] akerr|2 years ago|reply
[+] [-] MichaelMug|2 years ago|reply
[+] [-] iio7|2 years ago|reply
[+] [-] nurettin|2 years ago|reply
[+] [-] toyg|2 years ago|reply