Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up Azure development by not using Terraform

nitric.io

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Speeding up Azure development by not using Terraform

#31

Post by smallnix »

abound wrote: post #19

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. You fundamentally cannot build abstractions that are both easier *and* as flexible as the thing you are abstracting away, and so tools like this, as other commenters have noted, are great for a simple happy path, but that's almost never what you need once you're outside the tutorial and building s…

I think it's an a less daunting 'journey' if you don't know anything. You start with something friendly and then carve the edge cases into the nice scaffolding. E.g. for AWS IaC using escape hatches and L1 constructs in CDK over cloudformation.

Re: Speeding up Azure development by not using Terraform

#32

Post by BarryMilo »

abound wrote: post #19

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. You fundamentally cannot build abstractions that are both easier *and* as flexible as the thing you are abstracting away, and so tools like this, as other commenters have noted, are great for a simple happy path, but that's almost never what you need once you're outside the tutorial and building s…

I'm not sure if ORM is a great example, as they tend to work for the vast majority of use cases. If you're not using an ORM, you're either working on something where performance is critical, or you're making a mess.

Re: Speeding up Azure development by not using Terraform

#33

Post by lkjaodifywefas »

SparkyMcUnicorn wrote: post #24
k8svet wrote: post #6

Why do people do this? I skim the article. I go wait "Nitric sounds like Pulumi". A few googles later, I find this : https://nitric.io/docs/reference/pulumi So, it's fast because it uses Pulumi... Does Pulumi no longer build on Terraform providers? (EDIT: looking, it seems like many Pulumi providers are still terraform wrappers...) Either way, it feels like this is just a Pulumi feature.

Pulumi doesn't rely on Terraform core at all, and Terraform providers use a bridge[0]. [0] https://github.com/pulumi/pulumi-terraform-bridge

No, most of the pulumi providers are wrappers around terraform providers.

The exception are native providers which use new stuff like AWS Cloud Control API.

Re: Speeding up Azure development by not using Terraform

#34

Post by tkiolp4 »

Terraform is probably the most recent tech that I have seen playing two different roles in such a short period of time (in the last 6 years):

a) guys, look at this! It’s called Terraform and you can define your infra with HCL and keep it in git. Cool, right? Let’s get rid of these old Ansible files!

Five years later

b) Guys, we are deprecating Terraform. Please follow this guide on how to use CDK/Nitric/etc.

Wow. From hero to zero in such a short time span.

Re: Speeding up Azure development by not using Terraform

#35

Post by aleksiy123 »

I'm curious if anyone has experience with writing their own mini terraform/pulumi and no persistent state.

What I'm thinking is abstract cloud resource APIs I need into unified CRUD interface + has_diff.

Then essentially exposing idempotent functions (ensure_exists, ensure_deleted, ensure_updated) based on the unified interface.

No saved state state means slower. But it could be added fairly easily.

Something like this for personal use like scripts instead of terraform etc..

Re: Speeding up Azure development by not using Terraform

#36

Post by simondotau »

abound wrote: post #19

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. You fundamentally cannot build abstractions that are both easier *and* as flexible as the thing you are abstracting away, and so tools like this, as other commenters have noted, are great for a simple happy path, but that's almost never what you need once you're outside the tutorial and building s…

> You fundamentally cannot build abstractions that are both easier and as flexible as the thing you are abstracting away

Easier doesn’t have to mean less configuration. It could be more sane defaults, better organised abstractions, clearer documentation, and/or handier tools.

For the very small environment which I have indirect responsibility for, I’d love a simple read-only GUI which could present the environment, its sources, and the connections between them.

Re: Speeding up Azure development by not using Terraform

#37

Post by tkiolp4 »

kgeist wrote: post #21

What if something breaks in production and it's not clear what's happening because it's hidden somewhere in the application code behind layers of magic

To be fair, that’s happening already.

My stack looks like this:

- framework magic (e.g., spring boot, or ror, or whatever)

- library magic

- terraform magic

- aws magic

- docker magic

- VM magic

- standard magic (OS, networking, decent stuff, etc.)

Re: Speeding up Azure development by not using Terraform

#38

Post by oneplane »

Until one of these advertisements also comes with a provider ecosystem and a universal three-way diff every run, it's a bit pointless to me. The only thing that does what terraform does is OpenTofu, and that's because it's a fork of... terraform.

Maybe if you are small enough to just build a single application with some resources in a single vendor's playground all of the other IaC variations make sense, but that's hardly the reality. Either you're going to be part of something bigger, you're big enough to need multiple services, or you're so small that you can go straight back to the 90's and clickops+screenshot your way through the day.

While there might not be a one-size-fits-all solution, there is definitely a cutoff where CDK-style or single-vendor tools just can't do what is required.

Re: Speeding up Azure development by not using Terraform

#39

Post by FridgeSeal »

sevagh wrote: post #20

After the Terraform relicensing ordeal, do yourself a favor, if you're starting greenfield, use your cloud provider's provided provisioning tools. I wish I had CDK/Cloudformation skills, and not Terraform skills.

Or, don’t, because the vast, vast majority of users are almost certainly not affected by the licensing change, and your life can continue on, literally unchanged.

Re: Speeding up Azure development by not using Terraform

#40

Post by abound »

BarryMilo wrote: post #32
abound wrote: post #19

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. You fundamentally cannot build abstractions that are both easier *and* as flexible as the thing you are abstracting away, and so tools like this, as other commenters have noted, are great for a simple happy path, but that's almost never what you need once you're outside the tutorial and building s…

I'm not sure if ORM is a great example, as they tend to work for the vast majority of use cases. If you're not using an ORM, you're either working on something where performance is critical, or you're making a mess.

I tend to either use just plain SQL [1] or sqlc [2] [3]. With sqlc, you write plain SQL and it generates the (in my case, Go) boilerplate bindings for you. I don't find these approaches to be a mess, but both linked projects are admittedly small. I've used a similar approach on (non-OSS) codebases with thousands of DB functions/SQL statements though.

I don't disagree with you, ORMs can be a great time-saver for your average CRUD app, where the SQL queries tend to be straightforward SELECT/UPDATE/DELETEs on primary keys, assuming you don't mind the overhead of learning the DSL. But as your querying requirements get more complicated, you either have to:

- Keep the DB queries simple and do the complicated stuff (joining, aggregating, etc) in the business logic, or

- Learn how to express your complicated SQL in the ORM's DSL, or

- Drop into the ORM's "raw" mode and write plain SQL

The first option might be fine for non-performance-sensitive stuff, but otherwise isn't making good use of the database, and the latter two options reveal the SQL behind the curtains, at which point the abstraction of the ORM is more or less totally broken.

[1] Raw SQL: https://github.com/bcspragu/stronk/blob/main/db/sqldb/sqldb....

[2] sqlc: https://github.com/bcspragu/logseq-sync/blob/main/db/sqlite/...

[3] https://sqlc.dev/

Post reply on HN