The team behind the Encore backend framework writes about distributed systems, retries, queueing, Terraform and a Rust runtime for TypeScript.
HN commenters mention Encore as an open source Go and TypeScript framework for infrastructure-in-code, and compare other tools against it.
This is one of the more sophisticated and cool of the "Self Provisioning Runtime" concepts that have emerged in the last few years (https://swyx.io/self-provisioning-runtime). Some of the others:
- https://www.pulumi.com/docs/tutorials/cloudfx/
- https://www.serverless.com/cloud
- https://www.shuttle.rs/
- https://encore.dev
In general, while it's clear that somehow cloud complexity needs to be abstracted away from developers, I don't think it makes sense that new programming languages or frameworks are necessary to do this well. It makes migration of existing apps and backwards compatibility with the existing software ecosystem too challenging.
At Coherence (withcoherence.com - I'm a cofounder), we believe that a new category anchored by tools like replit, AWS CodeCatalyst, and our products is the solution to this problem, because it does not have the same issues. Instead, it offers best-in-class versions of the same workflows and toolchains that teams are using now, while radically reducing the investment required to get there.
It's an exciting time in the DevOps world!
FWIW, that's not what Go does. In your scenario, a Go binary ends up with a single copy of library X -- the 1.0.1 version. That's because library A is stating "I require at least v1.0.0 of X", and library B is stating "I require at least v1.0.1 of X". The minimal version that satisfies both of those requirements is v1.0.1, and that's what ends up in the binary.
That behavior is Go's "Minimal Version Selection" or "MVS". There are many longer descriptions out there, but a concise graphical description I saw recently and like is:
https://encore.dev/guide/go.mod
That's the default behavior, but a human can ask for other versions. For example, a consumer of A and B could do 'go get X@latest', or edit their own go.mod file to require X v1.2.3, or do 'go get -u ./...' to update all their direct and indirect dependencies, which would include X in this case, etc.
This is a biased representation of what Nitric can do for you.
The Terraform you've written out looks like a lot, but the Nitric code is doing a huge amount of lifting in this example.
Not to mention that Nitric is wrapping a Pulumi provider (granted they are using `pulumi-azure-native` unlike the `pulumi-azure` provider that's just a Terraform wrapper).
You can do this exact kind of Function Serialization in Pulumi anyway: https://www.pulumi.com/docs/concepts/function-serialization/#overview.
At the end of the day this article is abstracting a huge amount and whilst for startups it might be fine? When something goes wrong you'll want to be able to debug the random queue backlog in your stack.
For an example of this done beautifully in one language where they're managed close the loop with monitoring, I would checkout Encore: https://encore.dev/.
I could really recommend Encore https://encore.dev/ that works best when you use their PaaS offering https://encore.cloud/ (think of NextJS & Vercel combo).
One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.
You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.
wow very very interesting. I think we can discuss about it on hours.
1.) What would you think of things like hetzner / linode / digitalocean (if stable work exists)
2.) What do you think of https://sst.dev/ or https://encore.dev/ ? (They support rather easier migration)
3.) Could you please indicate the split of that 1 million $ in devops time and google cloud costs unnecessarily & were there some outliers (like oh our intern didn't add this specific variable and this misconfigured cloud and wasted 10k on gcloud oops! or was it , that bandwidth causes this much more in gcloud (I don't think latter to be the case though))
Looking forward to chatting with you!
Whether you build microservices or just services, distributed systems are undeniably here to stay. In today’s world there are very few products that can run on a single machine, whether it is for latency or availability or redundancy.
That said, the challenges of building such systems are real, and the developer experience is universally quite awful compared to our monolithic, single-server past.
It’s for that reason that I’ve been building [1] for the past four years. Would love your feedback if the OP resonates with you.
[1] https://encore.dev