[HN Gopher] Show HN: Shuttle - Build and ship backends without w...
___________________________________________________________________
Show HN: Shuttle - Build and ship backends without writing
infrastructure files
Author : dohman
Score : 149 points
Date : 2023-10-04 11:51 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| TruthWillHurt wrote:
| Good luck competing with AWS! went great for my serverless
| platform startup (and everyone else..)
| iio7 wrote:
| Yes, let's have even more of people just writing code and not
| knowing anything about how anything works! Just what we need more
| of.
| nurettin wrote:
| In my younger days, a successful compilation step was reason
| for shipping it. Has that changed?
| toyg wrote:
| Wrote any assembly recently?
| 0xbadcafebee wrote:
| HN bingo card for the comments thus far: [x]
| mentions Rust [x] mentions Go [x] misunderstanding
| the word DevOps [x] compares product to Heroku [x] "I
| just want to write code and make/run a product and not know how
| that works" [x] something about scaling [x] the
| solution to any problem is to write more code
| ForHackernews wrote:
| Ctrl + f "Heroku" => yours is the only result?
| [deleted]
| c0balt wrote:
| I think everytjing is one ppint except that this page doesnt
| mention Go(lang) anywhere.
| quadcore wrote:
| He got ya.
| brainbag wrote:
| 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?
| dohman wrote:
| 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.
| yuppiepuppie wrote:
| 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.
| dohman wrote:
| Out of curiosity, what was the first impression you've got
| and/or what were you expecting to see?
| ctvo wrote:
| That it's for toy projects. Using annotations to provision
| infrastructure hides complexity from you, but that complexity
| is what's required to actually manage and resolve
| infrastructure issues in production. In a prototype or toy
| project, sounds great.
| openquery wrote:
| This argument can be made at any level of abstraction I
| think.
|
| For example, you can make the same case for AWS Lambdas
| abstracting the infrastructure away from you, or VMs that
| run on-top of a hypervisor abstracting away the bare-metal
| servers.
|
| IMO it really boils down to the quality of the
| implementation of a product and also designing your product
| such that if users need to debug (which hopefully isn't
| often) you offer that visibility into the internals.
| michaelmior wrote:
| > IMO it really boils down to the quality of the
| implementation of a product
|
| I think this is true. But I can understand why people are
| more skeptical of Shuttle than Lambda. Running a function
| is a fairly simple task and since lambdas are stateless,
| it's relatively easily to feel confident about this
| abstraction. I'm less confident that I won't need to
| worry about the details of how my database is
| provisioned, configured, and maintained.
|
| This still seems great for hobby projects. It also seems
| like it would be relatively easy to transition to
| something more manual if the need arises.
| hobofan wrote:
| 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.
| kjfarm wrote:
| My brain read this as "Build Back, Ends Fast."
|
| 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 wrote:
| Haha, yeah, HackerNews corrects 'Backend' to 'Back End'
| automatically.
| willsmith72 wrote:
| Maybe the title should specify "rust backends" or "rust
| applications"
| rubenfiszel wrote:
| 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.
| ashiban wrote:
| 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)
|
| [0] https://klo.dev
| eandre wrote:
| If you like the concept but prefer Go over Rust for backends,
| check out Encore [1]. Disclosure: I'm one of the founders.
|
| [1] https://encore.dev
| gdcbe wrote:
| 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.
| bckr wrote:
| Is there a reason to use this over, say, Render?
| gdcbe wrote:
| No. It's just another alternative. I'm not a web developer in
| my day job. So I'm not aware of all options out there.
|
| Render does look awesome. More mature and all. It's not as
| easy as shuttle though.
|
| - shuttle comes with a cli that allows you to run your app in
| similar fashion as the cloud version
|
| - with shuttle you don't need to configure the storage (eg
| db) and such yourself
|
| That said. The price you pay is tighter coupling to the
| system. On top of that Render looks a lot more mature.
|
| For now I'll stick with shuttle for those projects. But I do
| thank you for telling me about render. Might switch to it,
| away from shuttle, if I my project's needs ever outgrow
| shuttle's capabilities
| lucasyvas wrote:
| I'm wondering this same thing - my current assessment is no
| and that a YAML config is superior to compile-time macros. If
| I used Shuttle, I'd probably be using cfg-if and type aliases
| anyway to stop it from infecting the majority of my code. The
| proposed benefit of having a compile-time validated config is
| not a tangible one in my opinion. I don't think the
| abstractions are that beneficial either.
|
| This is kind of a harsh assessment, but maybe it's just not
| for me.
| lijok wrote:
| Now this is how you turn a language mainstream.
| farmeroy wrote:
| I'm really excited to see more adoption of Rust in web
| development, Shuttle seems like at least a positive sign things
| are moving that way
| oldpersonintx wrote:
| [dead]
| ctvo wrote:
| 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.
| jetpackjoe wrote:
| Technically, the infra comes from Rust macros, not comments.
| postalrat wrote:
| The devops answer to complexity is always more complexity.
| BerislavLopac wrote:
| That's pretty much the fundamental theorem of software
| engineering. [0]
|
| https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar.
| ..
| [deleted]
| [deleted]
| rewmie wrote:
| > The devops answer to complexity is always more complexity.
|
| I don't think this is a valid take. The main responsibility
| of DevOps is automation. You cannot automate without writing
| code, which by definition means introducing complexity. You
| either introduce complexity by writing low-level scripts, or
| by adopting a tool/framework which allows you to write high-
| level code by hiding the low-level code in their entrails.
|
| I feel your comment implies that DevOps mindlessly adds
| complexity, when the truth of the matter is that it greatly
| simplifies everything at the expense of surfacing all the
| complexity that forced the world to treat all the cattle as
| fragile little pets.
| mrits wrote:
| 2030: Siri, setup infrastructure for me and remind me to delete
| next month
| throwjdn wrote:
| [dead]
| jbotdev wrote:
| 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.
| FranGro78 wrote:
| If you find the "infrastructure from code" idea intriguing,
| then maybe take a look at https://www.winglang.io
|
| It's a new startup by an ex-engineer on the AWS CDK team.
| notnmeyer wrote:
| this is wild
| dohman wrote:
| 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).
| satvikpendem wrote:
| The type system makes development much faster than with a
| language that doesn't have a strong type system.
| earthling8118 wrote:
| My productivity in rust is so much higher because of the help I
| get on correctness. It's not even remotely a competition.
| irf1 wrote:
| interviewed the CEO on the OSS founder podcast earlier this year
| :)
|
| full interview (38min): https://youtube.com/watch?v=GBT7yp17P4Y
|
| highlights (10min): https://youtube.com/watch?v=TVco_9E9no8
| akerr wrote:
| Oh, "build backends fast".
| oldpersonintx wrote:
| [dead]
| jeffypoo wrote:
| Not sure if being so opinionated about Rust is a good idea, but
| very cool nonetheless. Looks well done, excited to tire kick it.
|
| Curious how you see this stacking up against things like Pulumi?
| openquery wrote:
| 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).
| lucgagan wrote:
| From my experience with Rust, there is nothing fast about
| developing with it.
| qweqwe14 wrote:
| 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.
| steve_adams_86 wrote:
| I prototype with Python despite being fairly familiar with
| rust. Arguably less familiar with Python. I really abuse
| Python, like a kid cramming plato together and shoving
| toothpicks and googly eyes on it. If someone asked me to make
| something well with Python I'd need to take a breather and
| really think about it.
|
| I can do the same thing with rust, but making changes to that
| monstrosity would be relatively hard. With Python I can rip
| something out and replace it without a whole lot of fuss.
| After doing that for a few days or weeks, I might know what I
| should actually build.
|
| At this point, building with rust is pretty quick but it's
| only because I've got a clear target and a somewhat sensible
| design to follow, if I squint at it. Then I can drop kick the
| Python part and pretend it never happened.
|
| But I've never worked with anyone who works at the same speed
| in Rust from the start. It doesn't seem to happen. On the
| other hand, I've watched people struggle with it for days and
| weeks on end over things that seem trivial.
| vmfunction wrote:
| Personally it is better to prototype with es6 above or
| /typescript. Python is great, but don't like the
| indentation format. Sometime I just want a line of code to
| be in certain level indentation if I'm just prototyping. At
| this day and age just skip node use Deno for prototyping.
| oldpersonintx wrote:
| [dead]
| sitkack wrote:
| From my experience with Rust, there is nothing faster for
| delivering a solid system.
|
| Both of these comments contain zero worthwhile information.
| ramon156 wrote:
| 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
| the__alchemist wrote:
| I love Rust for embedded and building PC applications, but
| don't use it in this domain due to the lack rich frameworks.
| Ie that have DB ORM (Like Django or SQLAlchemy vice Diesel),
| auth, email, security, admin, templating etc. On the plus
| side, Rust has serialization and timezones down with best-in-
| class solution via Serde and Chrono .
| MichaelMug wrote:
| Is there anything like this for the Python/Django world?
| sbt567 wrote:
| 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.
| kevincox wrote:
| > Is Shuttle Secure?
|
| > 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.
| turtlebits wrote:
| Without infrastructure files means polluting your code with
| vendor specific lines. I'm not sure how much better that is.
|
| I'm not so keen on a single language only SaaS either. How many
| companies only deploy code in a single language?
| revskill wrote:
| The easy done right ! Rust + Postgres on a stateful server for
| CRUD apps.
___________________________________________________________________
(page generated 2023-10-04 23:01 UTC)