I'm glad someone is doing this. It's a very difficult problem to solve, but I see it as similar to JSX in that the business logic and the underlying infra are often tightly coupled. There are certain kinds of data integration problems where I could see this being intuitive and useful.
Speeding up Azure development by not using Terraform
41–50 of 87 posts
Re: Speeding up Azure development by not using Terraform
#42Earlier quoted context omitted.
Bicep is fantastic. But it compiles to ARM, so it's still limited by ARM's weaknesses and gaps, in addition to the underlying general instability of Azure and the inconsistencies from the Resource Providers. As well, Bicep is declarative- which is elegant in theory, but the stateful design of Terraform can cover up some of those underlying ARM/Azure gaps in practice. The deployment stacks approach on Azure should hel…
This just makes it even more asinine that they had to invent their own language. I'm sure I'd be just as productive with Nix and builtins.toJSON. At least they didn't do jsonnet, eh?
MS/Azure just seems to have this weird obsession with Not-Invented-Here-ing things that didn’t need to be nih-ed, and their solutions are often…extraordinarily Microsoft.
“Use our weird language, to interact with our awful, slow API’s, nobody else uses it, our support probably doesn’t know it exists, and it’ll be full of weird, MS culture specific idioms and eldritch code that compiles down into our previous failed experiment”
Like, no? No thank you, can’t you just be normal?
Re: Speeding up Azure development by not using Terraform
#43I'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 th…
Azure Bicep does essentially this, and there are some projects in the pipeline to make the language cloud-agnostic and multi-vendor.
Re: Speeding up Azure development by not using Terraform
#44Earlier quoted context omitted.
This just makes it even more asinine that they had to invent their own language. I'm sure I'd be just as productive with Nix and builtins.toJSON. At least they didn't do jsonnet, eh?
MS/Azure just seems to have this weird obsession with Not-Invented-Here-ing things that didn’t need to be nih-ed, and their solutions are often…extraordinarily Microsoft. “Use our weird language, to interact with our awful, slow API’s, nobody else uses it, our support probably doesn’t know it exists, and it’ll be full of weird, MS culture specific idioms and eldritch code that compiles down into our previous failed e…
Do they support ed25519 ssh keys yet? Just hard to take 'em seriously.
Re: Speeding up Azure development by not using Terraform
#45What 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.)
I had a laugh at that last bullet point!
I suddenly had a mental image of something like a Discworld novel poking fun of corporate America by having a company called Standard Magic Inc that commercialises wizardry to the chagrin of the University wizards.
Re: Speeding up Azure development by not using Terraform
#46I'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.
[deleted]
Re: Speeding up Azure development by not using Terraform
#47It's all fun and games until you want to do something even semi non-standard. Nitric even calls this out: > If you wanted to be able to completely customise your infrastructure, using IaC can be practical. However, it is rare that an application requires any level of customisation beyond the default. I'm assuming this project is targeting rapid prototype/"entrepreneur" market because I can assure you that basically e…
It's a valid point, Nitric isn't a good fit in some cases. We've been working on improvements to the underlying provider implementation to allow for easier extension for non-standard cases. Nitric is a gRPC API under the hood, so alternate implementations can be built to satisfy the APIs when customization is needed.
Re: Speeding up Azure development by not using Terraform
#48I'm glad someone is doing this. It's a very difficult problem to solve, but I see it as similar to JSX in that the business logic and the underlying infra are often tightly coupled. There are certain kinds of data integration problems where I could see this being intuitive and useful.
Thanks, that's the way we see it too. We think people mistake "separate files" for "separation of concerns", but many applications have inherent coupling to their infrastructure.
Re: Speeding up Azure development by not using Terraform
#49Separation 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 exists within Nitric: https://nitric.io/docs/reference/providers/custom/building-c... (this is the same way we build our own deployment providers).
With Nitric the primary goal is to increase cohesion between an application and its running infrastructure without increasing coupling to that infrastructure. With current IaC application and infrastructure cohesion is inherently very low, while giving the appearance of low coupling (despite it being quite high).
Re: Speeding up Azure development by not using Terraform
#50As a heavy user of Pulumi for C# projects this looks highly promising, and the Azure ecosystem has a large number of .NET / C# focused developers that are either fighting with bicep or terraform (or Pulumi), who would also find this very useful. Apart from the fact that C# examples seem to be lacking from the documentation at the moment, I’d also be interested to know if there is, or will be support for managed ident…
Thanks Junto, for function deployment we use matched files as the entrypoint for containers rather than exported functions or something similar. This lets you group many message consumers, route handlers, etc. together in a single container.