5 ms·

It's going to take a new kind of software engineer to build these fully distributed systems. You can imagine calls for "Senior Serverless Engineers". Will conve

by ipnon 6y ago

It's going to take a new kind of software engineer to build these fully distributed systems. You can imagine calls for "Senior Serverless Engineers". Will conventional serverful engineers be left in the dust, or will the serverless engineers just break away and pioneer the apps on a new scale?

deleted 6y ago
[deleted]
corty 6y ago
Frankly, there isn't much engineering to be done. This only works for embarassingly parallel tasks, so you can just start a loop, distribute data, start compute, collect results. Done. For anything else, this model breaks down. Need aggregation of results? Communication among nodes? Computation subdivision that is not strictly predeterminable? Sorry, not embarrasingly parallel, won't be doable like this. You may be able to extract some embarrassingly parallel part, like compilation of independent object files, but very often you still have a longish, complex and timeconsuming serial step, like linking those object files. This kind of recognising different parts of a program is already state of the art, no need to invent a new field...
- efnx 6y ago
  Speed and parallelism are good features but the killer app of serverless is the cost savings. You only pay for the time your function is running. Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself.
  - threeseed 6y ago
    For some use cases the cost saving is a big deal e.g. resizing an incoming stream of images. But for the majority of apps it doesn't save that much. And it still pales in comparison to the cost of the engineers. Which often spend significantly more time to build, debug, test etc a serverless app than one they just throw on an EC2 server.
    - efnx 6y ago
      “Apps” is a pretty vague description of an application, but if you’re writing a server it’s just as easy to “just throw” the app on lambda as it is on EC2. In general I ask myself if my new server can run on a lambda and if it can’t then I reach for something else. Most of the time it can.
  - tsimionescu 6y ago
    > Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself. And if you're storing things in DB, how long does it take for your lambda to start up now? In a project I was on, it could easily take 3s for a new request to be served, because we had a lambda that was doing and auth check with the DB, and then a different lambda that was doing the actual application stuff with another DB. So not only would we incur the cold start cost twice, but, since our lambdas needed a nic inside a VPC to talk to the DB, the cold start cost was huge. And of course, you pay that cost for each additional concurrent connection, not just once. Of course, if we had stored everything in some other managed service, and maybe used some managed auth scheme, this would have not been a problem. AWS likes it when they get you hook, line and sinker.
    - ElFitz 6y ago
      Was the first lambda waiting on the second's result before returning? If so, you really shouldn't rely on synchronously invoking à lambda from within another lambda. Also, things stored in the global scope (in Node.js functions) are kept between different invocations of a same container. If it can help...
      - tsimionescu 6y ago
        Not explicitly, this was orchestrated through the API Gateway authentication support. And yes, different invocations of the same container helped significantly (most importantly, the interface was already deployed in the private network), that is why I said that the problem was concurrent access. You could serve a pretty good number of users/second, but each user that happened to send a request while the already deployed containers were all busy would have to wait for up to 3s before we could give them any data from the backend. And of course, if two new users came in parallel, they would both have to wait, etc.
        ElFitz 6y ago
        Ok, I see. And the VPC explains the high cold start. Only "solution" I see would be to "keep your functions warm" (there's a feature now for that), but it's more of an inconvenient useful anti- pattern to me. Quite annoying. Sorry I can't be of any more help :/
threeseed 6y ago
Serverless has been around for many years now. It doesn't require a new kind of software engineer. It's just another software architecture to go alongside micro services, containerisation etc. And it hasn't changed the world because (a) it's the ultimate form of vendor lock in and (b) it makes even simple apps much more complex to reason about and manage.
- arcturus17 6y ago
  > much more complex to reason about and manage I really dislike the local dev experience and deployment for serverless. But otherwise the model is pretty clear: a file is a function, data goes in, data comes out, just like any other server function. If one instance is busy, spin off a new one. What’s hard to reason about?
  - flak48 6y ago
    Yep. Inversion of control has always been the norm with whatever server/framework you choose. If you have a /myroute handler defined in express or flask or even form.php or form.cgi in Apache,you never had to write the code to make user requests trigger your handler anyway even in the old days. That's the entire point of using a server instead of listening to a socket yourself With serverless the same thing still happens with someone else managing the path from a request to a handler and back. In fact, if you ever used a cpanel host with PHP like in the good old days (110mb.com anyone?), you already used 'serverless'. You just uploaded .php files to a directory and your website just 'magically' worked.
adev_ 6y ago
> It's going to take a new kind of software engineer to build these fully distributed systems. What your are selling here is nothing else than a new proprietary-scheduler-runtime to run embarrassingly parallel jobs ( the easiest kind of parallelism) There were already plenty of solution to do that, the only difference here is that you run on AWS lambda. Why would you need an entire new type of engineer to do that ? There is nothing new here excepted buzzwords. Are engineer nowadays a script-kiddies bind to a technology there entire career ? (Tip: of course no)

by ipnon 6y ago

deleted 6y ago

[deleted]

corty 6y ago

Frankly, there isn't much engineering to be done. This only works for embarassingly parallel tasks, so you can just start a loop, distribute data, start compute, collect results. Done. For anything else, this model breaks down. Need aggregation of results? Communication among nodes? Computation subdivision that is not strictly predeterminable? Sorry, not embarrasingly parallel, won't be doable like this. You may be able to extract some embarrassingly parallel part, like compilation of independent object files, but very often you still have a longish, complex and timeconsuming serial step, like linking those object files. This kind of recognising different parts of a program is already state of the art, no need to invent a new field...

efnx 6y ago
Speed and parallelism are good features but the killer app of serverless is the cost savings. You only pay for the time your function is running. Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself.
- threeseed 6y ago
  For some use cases the cost saving is a big deal e.g. resizing an incoming stream of images. But for the majority of apps it doesn't save that much. And it still pales in comparison to the cost of the engineers. Which often spend significantly more time to build, debug, test etc a serverless app than one they just throw on an EC2 server.
  - efnx 6y ago
    “Apps” is a pretty vague description of an application, but if you’re writing a server it’s just as easy to “just throw” the app on lambda as it is on EC2. In general I ask myself if my new server can run on a lambda and if it can’t then I reach for something else. Most of the time it can.
- tsimionescu 6y ago
  > Traditional server applications can be rewritten “serverless” so long as your pipeline is pretty functional, ie you’re not saving critical state in memory on the server process itself. And if you're storing things in DB, how long does it take for your lambda to start up now? In a project I was on, it could easily take 3s for a new request to be served, because we had a lambda that was doing and auth check with the DB, and then a different lambda that was doing the actual application stuff with another DB. So not only would we incur the cold start cost twice, but, since our lambdas needed a nic inside a VPC to talk to the DB, the cold start cost was huge. And of course, you pay that cost for each additional concurrent connection, not just once. Of course, if we had stored everything in some other managed service, and maybe used some managed auth scheme, this would have not been a problem. AWS likes it when they get you hook, line and sinker.
  - ElFitz 6y ago
    Was the first lambda waiting on the second's result before returning? If so, you really shouldn't rely on synchronously invoking à lambda from within another lambda. Also, things stored in the global scope (in Node.js functions) are kept between different invocations of a same container. If it can help...
    - tsimionescu 6y ago
      Not explicitly, this was orchestrated through the API Gateway authentication support. And yes, different invocations of the same container helped significantly (most importantly, the interface was already deployed in the private network), that is why I said that the problem was concurrent access. You could serve a pretty good number of users/second, but each user that happened to send a request while the already deployed containers were all busy would have to wait for up to 3s before we could give them any data from the backend. And of course, if two new users came in parallel, they would both have to wait, etc.
      - ElFitz 6y ago
        Ok, I see. And the VPC explains the high cold start. Only "solution" I see would be to "keep your functions warm" (there's a feature now for that), but it's more of an inconvenient useful anti- pattern to me. Quite annoying. Sorry I can't be of any more help :/

threeseed 6y ago

Serverless has been around for many years now. It doesn't require a new kind of software engineer. It's just another software architecture to go alongside micro services, containerisation etc. And it hasn't changed the world because (a) it's the ultimate form of vendor lock in and (b) it makes even simple apps much more complex to reason about and manage.

arcturus17 6y ago
> much more complex to reason about and manage I really dislike the local dev experience and deployment for serverless. But otherwise the model is pretty clear: a file is a function, data goes in, data comes out, just like any other server function. If one instance is busy, spin off a new one. What’s hard to reason about?
- flak48 6y ago
  Yep. Inversion of control has always been the norm with whatever server/framework you choose. If you have a /myroute handler defined in express or flask or even form.php or form.cgi in Apache,you never had to write the code to make user requests trigger your handler anyway even in the old days. That's the entire point of using a server instead of listening to a socket yourself With serverless the same thing still happens with someone else managing the path from a request to a handler and back. In fact, if you ever used a cpanel host with PHP like in the good old days (110mb.com anyone?), you already used 'serverless'. You just uploaded .php files to a directory and your website just 'magically' worked.

adev_ 6y ago

> It's going to take a new kind of software engineer to build these fully distributed systems. What your are selling here is nothing else than a new proprietary-scheduler-runtime to run embarrassingly parallel jobs ( the easiest kind of parallelism) There were already plenty of solution to do that, the only difference here is that you run on AWS lambda. Why would you need an entire new type of engineer to do that ? There is nothing new here excepted buzzwords. Are engineer nowadays a script-kiddies bind to a technology there entire career ? (Tip: of course no)