4 ms·

My real problem with serverless (right now) is that it just destroys your ability to have an efficient development workflow. Unless you want to use the really s

by bpicolo 10y ago

My real problem with serverless (right now) is that it just destroys your ability to have an efficient development workflow. Unless you want to use the really specific nodejs serverless framework, you're really in trouble. (As far as I can tell, https://github.com/dherault/serverless-offline https://github.com/dherault/serverless-offline is the only offline-API-gateway). If AWS really wants to drive adoption of their more-proprietary cloud tech, they're going to have to drive harder on local dev workflows. Google is doing better here (e.g. https://cloud.google.com/functions/docs/emulator https://cloud.google.com/functions/docs/emulator and https://cloud.google.com/pubsub/docs/emulator https://cloud.google.com/pubsub/docs/emulator) As someone who cares greatly about productive developer environments (it's a reasonable portion of my day job), I wouldn't touch serverless right now. Things slow down way too drastically if you have to push to the cloud to test what you're building. I looked into starting a new app using serverless tech just yesterday. I don't really want to use nodejs on the backend (as I can use any language on the backend, and JS is not the pick of the litter), so that left me totally optionless unless I want to build up a bunch of infrastructure on my own (and sometimes I enjoy that, just not my goal right now). As usual, the death of devops is greatly exaggerated, the role will evolve like any other. As the boring stuff gets easy, application complexity will grow. There's really still a lot of boring stuff that isn't automatically solved for you.

jt2190 10y ago
> [Development] slows down... drastically if you have to push to the cloud to test what you're building. This is accidental complexity, not essential complexity: We can keep our source in the cloud and edit it there. We can move change sets between servers, not whole files. (I get it that my current process, and probably yours, rely on working locally, but that's just an artifact from a different time.) Amazon recently bought Cloud9, which is a browser-based IDE that edits remote files. [1] It's also possible to to use an old-fashioned remote-session. (It tickles me that eventually this will feel exactly like editing files in place on the production server.) [1] https://c9.io/blog/great-news/ https://c9.io/blog/great-news/
- bpicolo 10y ago
  > We can keep our source in the cloud and edit it there Even with this, it doesn't currently save you from code deployment for serverless functions. Editing in a remote-session doesn't help here, either. I have indeed developed via OSXFuse. That works fine (though none of the tools work quite properly together. Nothing detects file changes at the right time). There are many other issues, but remote debugging is also a massive pain point, and in my experience devs are already somewhat prone to painstakingly printline debugging where other tools would be far more efficient. (PHP is sadly kind of the best at this as an artifact of PHP debugging being generally miserable.)
- dbg31415 10y ago
  > I get it that my current process, and probably yours, rely on working locally, but that's just an artifact from a different time. You say this, but... it's more of situation, "Do I trust all time and experiences to date, vs. something relatively new?" Every dev has a local, with current setup. So, does ever dev need an instance of Lambda? It'll get crazy expensive to work on a team. We still need various environments for code review, QA, content entry, hardening, UAT, etc. All we're cutting out with Lambda is performance testing, right? (We trust AWS will be perfect and if it's not perfect we call them instead of trying to do anything about it ourselves.) Dev, QA, Prod... those are your three basic levels everyone is familiar with for every project. Seems like AWS just found a way to bill me for all three... Hooray! =P Said mostly tongue-in-cheek... I like the concept... but I'm hesitant to switch clients over to serverless until it's a little more mature. I pay for the cycles, right? What if one of the functions I upload to dev is just a poorly written loop? Whereas the dev would catch that on his local, now I think I have to catch it in my monthly bill... we still need tools to be able to verify the code we are putting out before it hits the cloud.
  - bpicolo 10y ago
    > What if one of the functions I upload to dev is just a poorly written loop Fwiw, timeouts are at least partly a solution to this already. Seems right now you pay for invocations (at least on lambda), and lambdas are capped at 60s
specialist 10y ago
Yup. I've been doing nodejs and lambdas. (Don't ask.) It's the worst. Note that I had totally bought into Java/Jini/JavaSpaces, I really thought that was the future, so have some preconceptions about all this stuff should work. (I never grokked JXTA; I should go back and try again.)
aries1980 10y ago
> My real problem with serverless (right now) is that it just destroys your ability to have an efficient development workflow. Unless you want to use the really specific nodejs serverless framework. What do you miss from Kong? My main problem with serverless is the unreplicable latency tests. The latency metrics are below the threshold so far but if not, I will have not much of an idea why.
- bpicolo 10y ago
  I have no experience with Kong, so I couldn't tell you. I'll give it a try at some point. It does look like a better alternative to API gateway. Thanks for the mention.
devonkim 10y ago
I'm no IBM shill but OpenWhisk is at the least open source and can let you host your functions locally for the sake of testing and you can try to do some unit and integration tests using them. Devops as we know it isn't going to die any more than sysadmins weren't exterminated by "devops." However, if you're still doing sysadmin like it's the 90s your business is probably too slow to compete against more agile, cost-effective players and you'll wind up being forced to exit or wind down. Furthermore, businesses that iterate very slowly hopefully have customers that will continue to be able to afford to pay them for such slow turnaround. However, I've noticed the traditional large, behemoth enterprises used to multi-year cycles for what takes most competent companies a few weeks are all coming under business pressures to iterate or lose customers.
intrasight 10y ago
I'm doing some serious kicking of tires with serverless, and totally concur on the lack of efficient development workflow. I told a colleague last week that my productivity is about on par with assembly language programming in the 80s, or even punched car programming in the 70s (I've done both). I know that part of this is my needing to create new workflow, but I am concerned that part of it is implicit in underlying model. I hope that I am wrong and that it's just growing pains. The good things about serverless are great indeed.
shshhdhs 10y ago
You can use other languages besides Node.js with Lambda - you can also use Python, Java, and C#. Just an FYI
- bpicolo 10y ago
  Yeah, I know that part, but there's no offline API gateway that supports any language other than Node that I've found.

by bpicolo 10y ago

jt2190 10y ago

> [Development] slows down... drastically if you have to push to the cloud to test what you're building. This is accidental complexity, not essential complexity: We can keep our source in the cloud and edit it there. We can move change sets between servers, not whole files. (I get it that my current process, and probably yours, rely on working locally, but that's just an artifact from a different time.) Amazon recently bought Cloud9, which is a browser-based IDE that edits remote files. [1] It's also possible to to use an old-fashioned remote-session. (It tickles me that eventually this will feel exactly like editing files in place on the production server.) [1] https://c9.io/blog/great-news/ https://c9.io/blog/great-news/

bpicolo 10y ago
> We can keep our source in the cloud and edit it there Even with this, it doesn't currently save you from code deployment for serverless functions. Editing in a remote-session doesn't help here, either. I have indeed developed via OSXFuse. That works fine (though none of the tools work quite properly together. Nothing detects file changes at the right time). There are many other issues, but remote debugging is also a massive pain point, and in my experience devs are already somewhat prone to painstakingly printline debugging where other tools would be far more efficient. (PHP is sadly kind of the best at this as an artifact of PHP debugging being generally miserable.)
dbg31415 10y ago
> I get it that my current process, and probably yours, rely on working locally, but that's just an artifact from a different time. You say this, but... it's more of situation, "Do I trust all time and experiences to date, vs. something relatively new?" Every dev has a local, with current setup. So, does ever dev need an instance of Lambda? It'll get crazy expensive to work on a team. We still need various environments for code review, QA, content entry, hardening, UAT, etc. All we're cutting out with Lambda is performance testing, right? (We trust AWS will be perfect and if it's not perfect we call them instead of trying to do anything about it ourselves.) Dev, QA, Prod... those are your three basic levels everyone is familiar with for every project. Seems like AWS just found a way to bill me for all three... Hooray! =P Said mostly tongue-in-cheek... I like the concept... but I'm hesitant to switch clients over to serverless until it's a little more mature. I pay for the cycles, right? What if one of the functions I upload to dev is just a poorly written loop? Whereas the dev would catch that on his local, now I think I have to catch it in my monthly bill... we still need tools to be able to verify the code we are putting out before it hits the cloud.
- bpicolo 10y ago
  > What if one of the functions I upload to dev is just a poorly written loop Fwiw, timeouts are at least partly a solution to this already. Seems right now you pay for invocations (at least on lambda), and lambdas are capped at 60s

specialist 10y ago

Yup. I've been doing nodejs and lambdas. (Don't ask.) It's the worst. Note that I had totally bought into Java/Jini/JavaSpaces, I really thought that was the future, so have some preconceptions about all this stuff should work. (I never grokked JXTA; I should go back and try again.)

aries1980 10y ago

> My real problem with serverless (right now) is that it just destroys your ability to have an efficient development workflow. Unless you want to use the really specific nodejs serverless framework. What do you miss from Kong? My main problem with serverless is the unreplicable latency tests. The latency metrics are below the threshold so far but if not, I will have not much of an idea why.

bpicolo 10y ago
I have no experience with Kong, so I couldn't tell you. I'll give it a try at some point. It does look like a better alternative to API gateway. Thanks for the mention.

devonkim 10y ago

I'm no IBM shill but OpenWhisk is at the least open source and can let you host your functions locally for the sake of testing and you can try to do some unit and integration tests using them. Devops as we know it isn't going to die any more than sysadmins weren't exterminated by "devops." However, if you're still doing sysadmin like it's the 90s your business is probably too slow to compete against more agile, cost-effective players and you'll wind up being forced to exit or wind down. Furthermore, businesses that iterate very slowly hopefully have customers that will continue to be able to afford to pay them for such slow turnaround. However, I've noticed the traditional large, behemoth enterprises used to multi-year cycles for what takes most competent companies a few weeks are all coming under business pressures to iterate or lose customers.

intrasight 10y ago

I'm doing some serious kicking of tires with serverless, and totally concur on the lack of efficient development workflow. I told a colleague last week that my productivity is about on par with assembly language programming in the 80s, or even punched car programming in the 70s (I've done both). I know that part of this is my needing to create new workflow, but I am concerned that part of it is implicit in underlying model. I hope that I am wrong and that it's just growing pains. The good things about serverless are great indeed.

shshhdhs 10y ago

You can use other languages besides Node.js with Lambda - you can also use Python, Java, and C#. Just an FYI

bpicolo 10y ago
Yeah, I know that part, but there's no offline API gateway that supports any language other than Node that I've found.