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

61–70 of 87 posts

Re: Speeding up Azure development by not using Terraform

#61

Post by 0xbadcafebee »

tkiolp4 wrote: post #34

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. Fro…

Most tech goes through the hype cycle in about 5-10 years. We're about at the trough of enlightenment with Terraform. https://en.wikipedia.org/wiki/Gartner_hype_cycle

Re: Speeding up Azure development by not using Terraform

#62

Post by lijok »

tholm wrote: post #49
lijok wrote: post #30

Separation of concerns thrown out the window. Nobody show this to Bob Martin.

One of the co-founders of Nitric here, and I'll bite on this one :) I hear the separation of concerns between IaC and application code argument quite a bit, but always see an inherent coupling between the two. If changes to your IaC require changes to your application code for your application to continue working then where is the separation of concerns? If its just deployment and runtime, this separation still exist…

Application code sets infra requirements, not vice versa. If infra shapes your application, it suggests tech limitations or significant mistakes.

And I'm sorry, but without some concrete drawings you can't just claim current IAC creates low cohesion and strong coupling without making people suspect you don't know what those terms mean.

What would be very useful is an article covering the points of how testing works with Nitric, exactly how it saves you time and why the cost/benefit analysis of adopting Nitric makes sense.

Re: Speeding up Azure development by not using Terraform

#63

Post by rk2 »

arcticfox wrote: post #8
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.

It looks like it's letting you put your application code and Pulumi code in one spot. Why...not really sure, outside of a very short "Hello World".

Not quite,

Nitric infers the necessary cloud runtime by building a spec based on the resources you've imported into your application code.

At deployment time Pulumi is used to provision the resources (because we think it is an awesome tool).

Note that we could have also opted for any other IaC like CDKTF, and that you could either modify our providers or implement your own providers using your IaC of choice.

Re: Speeding up Azure development by not using Terraform

#64

Post by RajT88 »

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…

Another consideration is the release of new features.

You use ARM templates, that support comes with a feature GA. Terraform has to wait for the updated GO SDK, and then you have to wait for them to build it into Terraform.

Bicep in theory carries a similar risk, but I have not heard any complaints so far. Maybe product teams release ARM and Bicep functionality at tbe same time?

Re: Speeding up Azure development by not using Terraform

#65

Post by tholm »

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…

Thanks for the insight, your last point on reducing context windows for AI is exactly what Nitric is trying to achieve for humans as well reduced cognitive complexity for 80% of the work (from your second point).

I can see a path forward for Nitric as platform engineering solution where standardization of architecture is achieved (with the aid of AI as well), through building Nitric custom providers: https://nitric.io/docs/reference/providers/custom/building-c...

Re: Speeding up Azure development by not using Terraform

#66

Post by tekla »

tholm wrote: post #49
lijok wrote: post #30

Separation of concerns thrown out the window. Nobody show this to Bob Martin.

One of the co-founders of Nitric here, and I'll bite on this one :) I hear the separation of concerns between IaC and application code argument quite a bit, but always see an inherent coupling between the two. If changes to your IaC require changes to your application code for your application to continue working then where is the separation of concerns? If its just deployment and runtime, this separation still exist…

> increase cohesion between an application and its running infrastructure

> without increasing coupling to that infrastructure

These are contradictory. I don't know what people are doing to fuck up their TF so much, but I've never seen an issue where TF and application code were coupled in a way that wasn't trivially solvable.

Of course, that depends on people not being really dumb.

Re: Speeding up Azure development by not using Terraform

#67

Post by tekla »

hobs wrote: post #55
JohnMakin wrote: post #28

Earlier quoted context omitted.

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.

You can't stop people from doing dumb things if they don't want to learn.

Re: Speeding up Azure development by not using Terraform

#68

Post by keltex »

abound wrote: post #40
BarryMilo wrote: post #32

Earlier quoted context omitted.

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…

Well written ORMs let you express queries without the operations happening in the business logic. For example C# and Linq. You can express pretty much any query using the linq language and that's then converted into SQL automatically.

Re: Speeding up Azure development by not using Terraform

#69

Post by tholm »

lijok wrote: post #62
tholm wrote: post #49

Earlier quoted context omitted.

One of the co-founders of Nitric here, and I'll bite on this one :) I hear the separation of concerns between IaC and application code argument quite a bit, but always see an inherent coupling between the two. If changes to your IaC require changes to your application code for your application to continue working then where is the separation of concerns? If its just deployment and runtime, this separation still exist…

Application code sets infra requirements, not vice versa. If infra shapes your application, it suggests tech limitations or significant mistakes. And I'm sorry, but without some concrete drawings you can't just claim current IAC creates low cohesion and strong coupling without making people suspect you don't know what those terms mean. What would be very useful is an article covering the points of how testing works w…

100% agree with your point on application code shaping infra, that's the standard pattern that tech like this is trying to achieve, by providing a standard by which those infrastructure requirements can be automatically understood.

Fair point on the second, can I ask what you specifically mean by concrete drawings? I'd really like to understand your perspective on separation of concerns between IaC and application code better.

Thanks for content takeaway as well I really appreciate the feedback. The closest thing we have right now is a published customer use-case: https://nitric.io/case-studies/dropbio but I don't think this hits the mark for what you're after.

Re: Speeding up Azure development by not using Terraform

#70

Post by CuriouslyC »

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.

There are a lot of queries that are just harder to represent in an ORM, or don't fit into the table -> line of business object mapping. ORMs are more a crutch and rails for people that don't know SQL well than a true improvement over sql.
Post reply on HN