3 ms·
I like the idea behind this project. While designing https://stacktape.com https://stacktape.com, we were discussing a similar approach. But we eventually deci
by matus_congrady 4y ago
I like the idea behind this project.
While designing https://stacktape.com 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!