While designing https://stacktape.com, we were discussing a similar approach. But we eventually decided to go with a lower-level, more standard one. If I remember correctly, most potential users said something along these lines:
1. Too much abstraction - while developing a real-world application, you are very likely to come across a use-cases that either can't be solved using this kind of high-level abstraction, or would be easier to solve without the aforementioned abstraction. It's also very hard to tell, if you will or will not run into such a use-case. This also makes planning very hard, and in some cases almost impossible. Usually it's something like "This will take 8-12 hours if I won't run into a not-supported use-case and possibly weeks if I do".
2. Too much magic - Developers usually understand how tools like Serverless framework transform the serverless.yaml into a Cloudformation template and understand how things work behind the scenes. Therefore they can make assumptions and workarounds more easily. I fear this would be way harder to do with "high-level abstractions tools" such as nitric.
3. Lowest common denominator problem - while being able to migrate my workloads between clouds seems very promising, it also means I can only use services and features supported by all of the clouds. So you either give a lot of "goodies" provided by your cloud platform, or (in most cases) you give up the portability.
That being said, I don't worry about individual developer adoption. What I do fear is that it will be very hard to convince a CTO / Engineering manager / Techlead to choose such a tool for their team, making monetization hard.
I hope I'm wrong and these "high level, infrastructure-from-code" tools will find their users.
An alternative that others might want to take a look at in this space is Dapr from Microsoft which is language neutral and a CNCF project. Website is dapr.io
Dapr is fantastic if you're using Kubernetes, but we've found people having trouble with the learning curve. Also, Nitric's main SDK right now is for Node.js, but the underlying implementation is in Go and uses gRPC like Dapr. We have other SDKs in the works for Go, Python, Kotlin and C#. There is a bit more detail in the docs https://nitric.io/docs/language-support
What about permissions? A hard part about developing on AWS was grtting the right permsission set that gave enough access, but nothing more. Im sure the other cloud providers have similar systems to IAM
You're not wrong, it's one of the most difficult parts and definitely something we're trying to solve with Nitric. Here is the overview doc about how we handle this problem https://nitric.io/docs/reference/access-control would love your feedback.
My one and only beef with frameworks like this is that one ends up learning the idioms of the framework to deploy as a first class citizen, then when faced with deployment issues, having to learn the basics of the target cloud platform as a second class citizen. I get why this is appealing, much in the way jQuery was appealing over raw DOM back in the day. However, I much prefer abstractions that are closer to the bare metal which still provide convenience and good DX such as CDK or Terraform.
I relate. I have had the 3 citizen problem of Azure + Terraform + Kubernetes on a project I worked on and yeah figuring out issues requires navigating all that.
The 2/3 citizen problem is everywhere in tech. Look out for it and avoid if you can. It is probably an innovation token. That is why I am less enthusiastic about things like Supabase (picking on the one I remember) and it’s ilk over just Postgres.
Maybe I am waffling on the basic point of: boring is good, at least as a default to be convinced from.
Hey Andrew, thanks for checking it out. I think that the tradeoff between control and convenience is super important. We've tried to focus on convenience for Nitric, but also make the plugins and APIs transparent so you can regain that control when you need it. That said, it's hard to balance. Have you checked out Pulumi? They're another great option we like if you want control like CDK or Terraform.
Yeah, there is a cognitive cost to frameworks like this. Ruby on Rails is the same, where there are conventions to learn and pitfalls to avoid, but like DHH said "look what I don't have to do".
I've worked at companies that have had bare metal DX and they used it to stab themselves. I mean, anyone can be contrarian, and that's not what I'm trying to do here, but there is value in "idk what the queue is or how it's implemented, but I know how to call it". If you're not using an abstraction layer for everyday engineers (on a project that has 20+ engineers on it), then that means either your building one yourself, or you're forcing your teammates to engage with DevOps themselves.
If I were to start a company from scratch, I'd use something like encore.dev, because even though there's a framework to learn, it's a DevOps-less, or less-DevOps approach to building software fast without boilerplate.
And I'm not sure what it is about express.js, but everyone seems to have their own way of doing it. It's cool to see paradigms solidify, like tRPC and Nest.js, and now this.
I don't see any value in developers not knowing anything about the inner workings of their app. None. The only value that it gives is that they can bath in ignorance.
Where is the value that when your devs push something that breaks, you need to rely on external people to un-break it?
It's a business model, it only gives value to the company that build the framework. It only gives debt to the people using it...
As always, it's a matter of where you draw the line around what counts as part of your app, and what you count as external dependencies. The level of abstraction that is safe to use changes by use case.
It wasn't all that long ago that it would be unusual for a programmer to not understand assembly code - and before that, to have an understanding of how transistors/vacuum tubes are assembled to make complex circuits.
But of course, nowadays for web development everybody trusts the CPU architecture to operate efficiently, the OS to do reasonable things, TCP/IP to remain reliable, browsers to support Javascript, etc etc. In the last few years we've even seen some stabilization even around the historically churny realm of javascript UI libraries - most developers don't even need to know how React works under the hood, let alone how V8 runs.
The reasonable level of abstraction has grown immensely, and the number of web developers who deeply understand the true stack is probably fewer than 10. For most use cases, a service that abstracts over the various cloud provider options is perfectly fine - and when its not, that's generally a "good problem" to have (because it means your app is having scale issues).
All business models are meant to give value to the business. The successful ones also give value to the customers.
I'll take a devil's advocate bite and offer: Onboarding. It's easier to get junior and mid-level devs started on a repo/project if they don't have to understand 100% of the full, entire stack. Maybe I'll bathe the babies in early ignorance to hook them and help them grow.
That said, if they stay in baby form and never grow...
I would argue that JS is not just a language, it's a mindset, and that mindset is, "I just want to write javascript, for the love of god don't make me learn more than I absolutely have to."
It's... unique, in the software dev world, I think. Node.js is not the right tool for this job, but god bless the folks who insist on using it here anyway.
With JavaScript you just have a lot of haters and lovers. Not many I don't mind ones.
You clearly fall on the hater category. That's not an issue, but the way you represent it is not true.
Thanks for checking it out. We've definitely gone with a convienience first approach for the framework but realize that's not suited to every scenario. By the way, the underlying tech is written in Go and we're adding support for other languages if Node.js is a big concern https://nitric.io/docs/language-support
Python doesn't have anything remotely close to this problem, as you can't (reasonably) write Python for the browser.
JavaScript has this problem because it's actually a somewhat attainable goal.
The main problem is that once you run into a problem not explicitly solved for by whatever Node.js framework that's holding your hand, you're in deep trouble, very quickly, unless you have a more "classical" software development background.
Well, the goal of software is to solve a problem or enable a usecase. It’s not to “write code”.
I am experienced in tons of software programming paradigms and languages, but I couldn’t care less about the details if it doesn’t enable me to output something useful.
After all, you don’t care about the details, as long as the language enables you to output something useful, and Brainfuck is Turing complete, so that checks your only box, yeah?
…or maybe using the wrong tools is a terrible idea, and you really ought to care more about the details.
I meant easy to use languages are better than hard to use but “technically better” languages. Brainfuck would be the last language to use for either scenario though.
JavaScript is decidedly not "easy to use" in any sense for building out and managing infrastructure.
There are AWS/GCP/Azure APIs where you can fully manage your infra if you'd like via JavaScript. Nobody does this, however, for a reason. Lots of reasons, actually.
That's what this submission is, a way to solve a problem in a much harder (and limiting) way than is necessary, given the other available tools that can be used to solve this problem.
You'd be much better off learning something like Terraform to solve the problems being addressed here. Not everything has to be solved in JavaScript, and that's a uniquely "JavaScript" community solution, given how seemingly attainable it is to newer coders (which a lot of JS programmers are).
While designing https://stacktape.com, we were discussing a similar approach. But we eventually decided to go with a lower-level, more standard one. If I remember correctly, most potential users said something along these lines:
1. Too much abstraction - while developing a real-world application, you are very likely to come across a use-cases that either can't be solved using this kind of high-level abstraction, or would be easier to solve without the aforementioned abstraction. It's also very hard to tell, if you will or will not run into such a use-case. This also makes planning very hard, and in some cases almost impossible. Usually it's something like "This will take 8-12 hours if I won't run into a not-supported use-case and possibly weeks if I do".
2. Too much magic - Developers usually understand how tools like Serverless framework transform the serverless.yaml into a Cloudformation template and understand how things work behind the scenes. Therefore they can make assumptions and workarounds more easily. I fear this would be way harder to do with "high-level abstractions tools" such as nitric.
3. Lowest common denominator problem - while being able to migrate my workloads between clouds seems very promising, it also means I can only use services and features supported by all of the clouds. So you either give a lot of "goodies" provided by your cloud platform, or (in most cases) you give up the portability.
That being said, I don't worry about individual developer adoption. What I do fear is that it will be very hard to convince a CTO / Engineering manager / Techlead to choose such a tool for their team, making monetization hard.
I hope I'm wrong and these "high level, infrastructure-from-code" tools will find their users.
Wish you all the luck!