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.
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
This is kind of a harsh assessment, but maybe it's just not for me.
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.
https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
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.
Sorry, I thought you were talking about Npm there :)
This isnt unique to Devops
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.
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.
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.
It’s a new startup by an ex-engineer on the AWS CDK team.
Both of these comments contain zero worthwhile information.
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.
I'm not so keen on a single language only SaaS either. How many companies only deploy code in a single language?
> 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.
Curious how you see this stacking up against things like Pulumi?
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).
[0] https://klo.dev
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
full interview (38min): https://youtube.com/watch?v=GBT7yp17P4Y
highlights (10min): https://youtube.com/watch?v=TVco_9E9no8
[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 codeFor 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.
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.