izalutski

The payment processors are, at the core, specialist insurance businesses. They know how to underwrite transaction risk and counterparty risk and FX risk very well, better than generalist insurers, in part thanks to their scale. So these "billions" are actually a tiny fraction of the volume they process; counterparties are happily sharing a cut in exchange for peace of mind.

I believe that doing nothing, on purpose, especially for prolonged time (months, years), especially in solitude, is often _the_ most productive, highest leverage activity of all that an individual can be doing. The reason is that our subconscious is way more powerful than our conscious. The logical reasoning engine in our brain is really quite basic. Think a silly 8-bit console emulator running on an an actual modern piece of hardware (subconscious brain). And so relying on subconscious is somewhat like using hardware acceleration. The brain often knows better, but you cannot quite articulate what it is that needs to be done or why. And if you keep ignoring that signal, keep silencing it, keep forcing "doing the right thing" over what it's trying to tell you - that's a recipe for failure. You better listen. How? By doing nothing to the point of getting bored and looking how to "kill time". That's when your subconscious is finally heard. It keeps gently nudging you in the right direction without revealing the grander plan. Perhaps it doesn't have a plan; or perhaps it does but you're better off not knowing it. I also believe that procrastination is an acute case of the same. Your subconscious is screaming - hey human, this activity, this project, this job doesn't quite make sense. Again, you better listen. Otherwise you'll perhaps get more stuff done - but the wrong kind of stuff. Personally I'm looking back at my own timeline, and the gaps between jobs when I was up to nothing whatsoever as some of the most productive periods of my life. Not in a "I did X" way - more like, "I became more of what I want to be faster than at any other time".

Yep, backwards they did

(Disclosure: I'm from Digger and OpenTF so am biased)

Hashi's biggest miscalculation is that they put Terraform (an open language / ecosystem) into the same bucket as Vault and Consul, which are hostable backend applications.

BSL makes sense for Vault, just like it does for MongoDB. It is reasonable to prevent others from charging for hosting your code.

But with Terraform, the backend part (TF Cloud) was never even open source. And it's not required for Terraform to work.

Hashi shot themselves in the foot. Unlike with Vault or Consul, there is enormous vested interest in the community to keep Terraform truly open. Hashi trying to enforce everyone to use their non-oss backend with it will only result in Hashi losing the privileged (and well deserved) position among providers of commercial products in the Terraform ecosystem.

Yeah apologies we're in a little bubble here together with Spacelift, Scale, Env0 and Atlantis so starting to assume everyone knows the niche terminology lol

Yeah so basically TACOS are ci-like tools / control planes for Terraform. The OG one being Terraform Cloud.

The term TACOS was coined by Piotr Zaniewski here: https://itnext.io/spice-up-your-infrastructure-as-code-with-...

There's a fundamental difference Terraform's "server" was never open-source in the first place So you already cannot pull the move that AWS did with Elastic and Mongo The open-source part of Terraform is the CLI, the compiler, etc Extremely puzzling move

Yes indeed a puzzling move from Hashicorp's leadership perspective. Could be a miscalculation; or no calculation at all.

It looks like it boils down to being no longer able to "incorporate the source code or embed or distribute newer versions of Terraform." (From Spacelift's blog). For a piece of software that doesn't even have a server, this seems extremely restrictive. I wouldn't be surprised if Hashicorp takes a few steps back on this / provides clarifications for specific use cases

Indeed - but the Terraform community appears to be hit the hardest. Because unlike Consul, there's no open-source hostable anything. It feels just an arbitrary restriction for a language + CLI; the terms of the licence can be viewed as if whatever you ship has Terraform cli embedded, you're in breach. I can see the reason for SPL like Mongo did - it is indeed unfair for AWS to make money off hosted open-source mongodb. But this move by Hashi I'm struggling to wrap my head around

Atlantis was a great tool back in the day and still works well in most scenarios. The main issue with it is that it also takes on running the jobs (as in Terraform binary runs on the same VM it runs). Which makes it similar to Jenkins and other first-generation CI systems.

Companies that use Atlantis at scale (eg Lyft) felt the need to fork it and use a scalable compute backend instead, eg Temporal. At which point you've basically got a DIY in-house CI.

Our view is that it's best to keep matters separate. The CI part with compute, jobs, logs etc is a solved problem. What's unsolved for Terraform is state-aware logic when / how to run those jobs. It's all about the orchestrator really.

All valid points! Thank you!

We were initially completely backend-less; but then it increasingly became apparent that a central orchestrator is unavoidable.

Rationale here: https://diggerdev.notion.site/Why-digger-introduces-an-orche...

In hindsight, it makes sense that literally every single other tool in the space has a central backend that orchestrates jobs. There's a good reason for that.

To address security / access concerns, you can either self-host the orchestrator, or use OIDC, or both

Yeah naming is fun

The most fun thing is - Digger + Dagger could be a great combo! We haven't yet explored properly but in theory it shouldn't be anything different from adding another CI provider; we already support GitHub Actions, Gitlab CI and Azure DevOps

Thanks!! Great point; for now we're relying on S3+dynamo which many people prefer anyways; but state management is on the roadmap, we'll get to it soon

Tracking here: https://github.com/diggerhq/digger/issues/206

And btw contributions very welcome, we're a small team so every bit helps, even if it's just filing or labeling an issue

Indeed we did :)

Also blogged about it: https://medium.com/@DiggerHQ/we-rewrote-our-product-in-go-fr...

One of the founders here You could also use OIDC so no need to share keys

https://docs.digger.dev/cloud-providers/authenticating-with-...

A lot of the problem is gone after realising that productivity has little to do with efficiency and almost everything with prioritisation / focus. As soon as you become aware of your "attention flow" (what your attention span is spent on, like cash flow) it becomes hard to justify reading stuff like that.

Developers today have great tools to quickly launch small projects without thinking of infrastructure (Firebase, Vercel, Heroku). But these tools don't work for teams. Big tech companies that can afford dedicated platform teams tend to build self-service tools for developers on top of AWS / Azure / GCP to launch new services and manage environments. But smaller teams who can't afford it are out of luck. If they have DevOps expertise in the team then they'll write a lot of repetitive Terraform, and if they don't they'll often struggle for weeks learning all the AWS concepts and make lots of mistakes.

We thought this is wrong, and built Digger

Digger manages your cloud account, allows to create apps and microservices from templates (can be custom), generates and runs Terraform, and manages environments. So developers get modern Vercel-like experience while DevOps engineers still retain full control. Starting on AWS with Digger is just as simple as on Heroku, but cheaper and you get a future-proof stack with DevOps best practices.

Yes, Digger generates TF files and stores it in the dedicated "main" repository, separately for each environment. You can tweak these files directly, or override the defaults in the templates. So unlike black-box PaaS you retain full control of the infrastructure, Digger just makes this complexity optional.

Thanks @mz_data!

With Heroku you are stuck with what they offer, and it quickly gets unreasonably expensive compared to AWS / GCP / Azure.

Digger is just as easy to use, but you don't overpay for resource and if you want something more custom, you can always do it directly in the underlying cloud account. Digger helps with that as well by generating Terraform modules that you can tweak for your needs.

Copilot is great! But, it's intentionally only about ECS and a single service. Whereas Digger is operating at the entire stack level, and will support a variety of deployment targets, including other AWS services, other cloud providers eg Google Cloud Run, Kubernetes etc. ECS is just the first one supported.

With Digger we want to create a convenience layer to manage cloud infrastructure that will bridge the gap between paas that has great UX but quickly gets expensive and limiting, and major clouds that are cheaper and more flexible, but hard to figure.