3 ms·

I love the idea of developers working on code, and not infrastructure, and so I love open source projects that solve this problem (by automating infrastructure)

by MCRed 11y ago

I love the idea of developers working on code, and not infrastructure, and so I love open source projects that solve this problem (by automating infrastructure). But I will never support anything that locks me into a particular vendor. There are many reasons, from geopolitical to economic, that any open source infrastructure effort should be vendor neutral.

banku_brougham 11y ago
I'm ok with using AWS for now. The trade off is this limitation you are pointing out, vs. saving dev ops effort. Anyway what is novel this year at AWS becomes industry standard and commoditized later.
deleted 11y ago
[deleted]
wahnfrieden 11y ago
Would be nice to see something like Apex that can work on Lambda or within some kind of deployable service, so that the environment it actually ran on was abstracted, avoiding vendor lock-in. I haven't seen any projects yet that try to make the Lambda interface portable though.
tjholowaychuk 11y ago
Depending on what you use it's not much lock-in. In most cases you'd delegate the handler to some package/library anyway so you're just interpreting the Lambda "event" and "context", much like writing the bulk of your HTTP handlers inline is usually a bad practice.
untog 11y ago
Fair. But there is no open source implementation of Lambda right now, as far as I'm aware. Hopefully if there were such a thing Apex would support it.
taurath 11y ago
You can very quickly build wrappers around Lambda code to be able to use its functions in a traditional webapp (at least in node). If you need to use a different vendor you can change it relatively quick.
yazaddaruvala 11y ago
tl;dr: You would need a relatively simple Node.js/Express based backend for Apex, compared to its current AWS API Gateway + AWS Lambda backend. Maybe TJ could correct any inaccuracies here: It sounds very much like the Node.js shim used for local testing or other languages could be enhanced to listen to a TCP port rather than use stdin/stdout. At which point, instead of just using the shim for local testing, you could deploy Apex + Shim to any VM and port. No more lock in.

by MCRed 11y ago

banku_brougham 11y ago

I'm ok with using AWS for now. The trade off is this limitation you are pointing out, vs. saving dev ops effort. Anyway what is novel this year at AWS becomes industry standard and commoditized later.

deleted 11y ago

[deleted]

wahnfrieden 11y ago

Would be nice to see something like Apex that can work on Lambda or within some kind of deployable service, so that the environment it actually ran on was abstracted, avoiding vendor lock-in. I haven't seen any projects yet that try to make the Lambda interface portable though.

tjholowaychuk 11y ago

Depending on what you use it's not much lock-in. In most cases you'd delegate the handler to some package/library anyway so you're just interpreting the Lambda "event" and "context", much like writing the bulk of your HTTP handlers inline is usually a bad practice.

untog 11y ago

Fair. But there is no open source implementation of Lambda right now, as far as I'm aware. Hopefully if there were such a thing Apex would support it.

taurath 11y ago

You can very quickly build wrappers around Lambda code to be able to use its functions in a traditional webapp (at least in node). If you need to use a different vendor you can change it relatively quick.

yazaddaruvala 11y ago

tl;dr: You would need a relatively simple Node.js/Express based backend for Apex, compared to its current AWS API Gateway + AWS Lambda backend. Maybe TJ could correct any inaccuracies here: It sounds very much like the Node.js shim used for local testing or other languages could be enhanced to listen to a TCP port rather than use stdin/stdout. At which point, instead of just using the shim for local testing, you could deploy Apex + Shim to any VM and port. No more lock in.