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

51–60 of 87 posts

Re: Speeding up Azure development by not using Terraform

#51

Post by WinstonSmith84 »

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.

Well, to me it is. I've been working on a relatively large projects based on Node (Typescript), various Lambdas, some doing server stuff only, other serving Client ... It's a pretty complex and large application overall and the whole architecture was really well designed from the ground up, except one thing: typeorm. It was fine at the beginning when doing simple things, but it got really tricky after. Then, I've had always very complex "migrations" to add sometimes just a field. And eventually I've had an issue I logged in 2019, and it's not been resolved yet. Well there is no solution due to the abstraction layers of typeorm, and I've solved (i.e. workarounded) my problem by executing a proper SQL query instead ..

I mean there are 2k+ issues open https://github.com/typeorm/typeorm/issues/ - yes, not all of them are bugs and limitations, but if you filter the bugs, that's still more than 1000 ...

Re: Speeding up Azure development by not using Terraform

#52

Post by rk2 »

JohnMakin wrote: post #5

Sure, you can hide all configuration behind some abstraction, but that doesn't really change the fact that the configuration is still there. The moment you need to do something even slightly different than out-of-the-box, you're hosed. Additionally - IAC can work as documentation. "What's running in (environment)?" is a question that can usually quickly be answered by looking at the IAC itself, whereas this solution,…

The Nitric providers which handle the provisioning piece are IaC.

Rather than poking around bespoke IaC on a per-project basis, you have the opportunity to inspect modularized and tested IaC which in this case is written in Pulumi and maintained by either the Nitric team or your team if you need to customize and move away from "out-of-box".

I work with the maintaining team, we're happy to discuss more. If you're curious then hop into our discord.

Re: Speeding up Azure development by not using Terraform

#53

Post by tholm »

wrnch wrote: post #16
hobs wrote: post #3

Earlier quoted context omitted.

Certainly, but Terraform also sucks at this! I have had all sorts of problems with providers that basically lie to your face about the guarantees they make, state files always getting funky and needing escalation, special things needing to be put in special files or "terraform will get mad" (the actual staff sre's comments) It's not a tool I have ever thought was great!

This tool is going to have the same problems as Terraform only worse. It's wrapping Pulumi and managing the state file for that. Yet another abstraction layer on-top of it all. I'd love to be proven wrong if they can output Pulumi code from their application code? Even then, I'm not sure what the monetization play here is? You're standing on the shoulders of Pulumi and you're open-source. If you go down the managed r…

Nitric doesn't wrap the state management for Pulumi, we actually encourage integrating directly with Pulumi's own cloud offerings to manage your infrastructure state. https://nitric.io/docs/reference/pulumi

Note this only applies to our OOTB providers which use Pulumi as our deployment engine of choice.

When you take away our providers Nitric becomes a communication layer between your application and any deployment engine that implements the Nitric deployment API: https://nitric.io/docs/reference/providers/custom/building-c...

This allows collecting a Bill of Materials of cloud concepts (e.g. APIs, topics, buckets, queues, policies etc.) and providing them however you like with code. This could be templating IaC, directly executing IaC, rolling your own solution or anything in between.

As for how we make money, currently we're doing consulting and dog-fooding our own tooling while working with existing teams struggling with more traditional deployment setups to make them more productive, their feedback is used to make own product even better :).

Re: Speeding up Azure development by not using Terraform

#54

Post by jcusch »

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 can definitely see your point, but we don't think cloud development has hit up agaist the limits of inherent complexity. It's still needlessly complex in many cases. Projects using Nitric typically write the bulk of the application using the abstractions and go direct for anything unsupported or specialized.

The point of Nitric isn't to avoid knowing how your infrastucture works, it's just to speed up development and improve cohesion.

Re: Speeding up Azure development by not using Terraform

#55

Post by hobs »

JohnMakin wrote: post #28
hobs wrote: post #26

Earlier quoted context omitted.

Well, maybe there's some terraform jedis out there but I have seen the same problem at four companies so far, and at this point I keep my nose right out of it because its always a chore treadmill.

Much of the consulting work I do surrounds terraform and most people are doing it very poorly or incorrectly. I do not think this is a fault of terraform. For instance, not going all in on IAC and having mixed/poor practice around automation and click-ops'ing things for "speed" is a great way to have inconsistent terraform states. As far as a flat out state corruption, I've only seen that one time in ~6 years working…

As a database person this pains me to say, but if the people keep using the tool wrong you may want to start fixing the tool.

Re: Speeding up Azure development by not using Terraform

#56

Post by paulddraper »

jcusch wrote: post #54
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 can definitely see your point, but we don't think cloud development has hit up agaist the limits of inherent complexity. It's still needlessly complex in many cases. Projects using Nitric typically write the bulk of the application using the abstractions and go direct for anything unsupported or specialized. The point of Nitric isn't to avoid knowing how your infrastucture works, it's just to speed up development a…

But I love reproducing 1990s network topologies in AWS VPC.

Re: Speeding up Azure development by not using Terraform

#57

Post by SparkyMcUnicorn »

lkjaodifywefas wrote: post #33
SparkyMcUnicorn wrote: post #24

Earlier quoted context omitted.

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.

I'm well aware of that, and what I said is still true.

You might want to look at the repo I linked, check out the source, or hear it directly from the folks at Pulumi if you're interested.

Re: Speeding up Azure development by not using Terraform

#58

Post by icedchai »

hobs wrote: post #25
wrnch wrote: post #16

Earlier quoted context omitted.

This tool is going to have the same problems as Terraform only worse. It's wrapping Pulumi and managing the state file for that. Yet another abstraction layer on-top of it all. I'd love to be proven wrong if they can output Pulumi code from their application code? Even then, I'm not sure what the monetization play here is? You're standing on the shoulders of Pulumi and you're open-source. If you go down the managed r…

I am not any of those things nor do I know anything about their product, just saying that when anyone is crap potting for Terraform it just has always sucked in every job I have ever worked at.

I've seen quite a bit of Terraform code over the past 8 or 9 years. Most of the problems are related to:

  1) Rampant copy-and-pasting instead of attempting any sort of code reuse
  2) Reinventing the wheel poorly: instead of bringing in an existing module, they'll attempt to build their own half-baked one.
  3) Poor ops practices like manually editing configuration through the console, then complaining about drift when TF overwrites their changes.
  4) Lack of systems and networking fundamentals, like DNS or load balancing. If you don't understand it, how can you hope to configure something properly?

Re: Speeding up Azure development by not using Terraform

#59

Post by rk2 »

ClassAndBurn wrote: post #14

Others' concerns are valid; the separation of concerns makes infra changes safer and easier to understand. Infra-tooling is slow because of the inherent risk of managing stateful services. Mixing the infra and application logic is the obvious path forward, though. Just as most applications don't need more than Rails and a single Postgres, most apps don't need customized infra. Simplifying the 80% unlocks cycles for m…

It is worth noting that the Nitric team (whom I work with) aren't suggesting that Nitric is an alternative for every Terraform project out there.

However, there are many use-cases without bespoke infra needs where it does suit.

Our hope is that people who genuinely are looking for assistance with their cloud deployment needs evaluate Nitric against their own projects requirements.

Re: Speeding up Azure development by not using Terraform

#60

Post by tholm »

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.

Hopefully this helps give a better idea of how it works under the hood: https://nitric.io/docs/reference/providers/custom/building-c...

Not just a feature of Pulumi, its just used as the IaC of choice for the out of the box deployment providers. This can be replaced with anything.

At its core Nitric is really a tool to collect infrastructure requirements from an application and those requirements are delivered to a server that is built using the Nitric deployment APIs.

Post reply on HN