6 ms·

I've been at my current company for maybe 6 years now, in an engineering role. In that time, the service-oriented code which has significantly outlasted anythi

by 015a 5y ago

I've been at my current company for maybe 6 years now, in an engineering role. In that time, the service-oriented code which has significantly outlasted anything else, with nearly no maintenance, has maybe surprisingly or unsurprisingly been: AWS Lambda functions. We have quite a few Lambda functions (written in Node) that I believe pre-date even my tenure at the company; the only modifications in the interim, maybe a few lines of obscure bug fixes, updating the lambda node version, we switched from JS to TS everywhere a few years ago, and keeping the CI updated on those repos (which is a rather ironic and wasteful investment of resources given they've only changed a half dozen times in something like six years). Checking in on those dozens of functions handling millions of invocations every month, and seeing them just chug along with no maintenance, has convinced me, personally, that if a problem domain can be solved in a FaaS-like way, its the way to do it. Not every problem can, and I'm not specifically advocating for Lambda vs Azure FaaS vs an open source kubernetes-based solution. More-so that, every deployment artifact has to draw an "operations" line, to the left of that is the rote, daily operations banality, and to the right is the ever-changing business problem space. The further right you can draw that line, to push as much as possible into operations, the better; it gives you optionality to outsource that left part, maybe to automated software, maybe to AWS, maybe to an in-house operations team. FaaS draws that line roughly as far right as I think a general purpose programming system can; further right would approach things like Excel, Retool, etc.

MathMonkeyMan 5y ago
I think the answer lies in your last paragraph, but your comment made me think: Perhaps Lambda functions are resilient because they're: - scope constrained - surrounded by APIs only (e.g. no cheating by having a whole POSIX system) - infrastructure is maintained solely by a giant company that you pay to not have to think about it I haven't used any "serverless" stuff, so I don't really know. Per the article's recommendation, I have noticed at work that resilient software is often a 400 line python script with no other dependencies; or, a medium sized piece of C++ infrastructure that depends only on the OS, the compiler, and a hand-written build system.
- Hendrikto 5y ago
  > hand-written build system. Please don‘t. It will be fine as long as a project is very small, but get out of hand quickly. Rewriting the build system after the fact will not be budgeted and likely never happen.
codesections 5y ago
> I've been at my current company for maybe 6 years now, in an engineering role. In that time, the service-oriented code which has [lasted the longest is] AWS lambda functions. We have quite a few Lambda functions (written in Node) that I believe pre-date even my tenure at the company. Interesting, AWS lambda only launched in November, 2014[0]. So those more-than-six-year-old functions must have been written for a brand new platform. [0]:https://en.m.wikipedia.org/wiki/AWS_Lambda https://en.m.wikipedia.org/wiki/AWS_Lambda
bombcar 5y ago
Things that get rarely touched but depend on external systems are some of the best candidates for extensive and continuous test suites - as they’re most likely to silently break.
Chyzwar 5y ago
AWS Lambdas are bane of my existance. Many of issues I was involved over years*. From issues with performance, deployments, cold start, api gateway integrations, arbitrary limits or just random failures. Debuging is difficult and whole thing is dog slow. Even today I have two outstanding issues that I need to investigate, lambdas fail to connect to redis and pino not logging correctly response times. Some of that can be blamed for misusing lambdas, but I hate FaaS concept. AWS ECS, google app engine and k8 where you deploy container are imo better and give you more control. Edit not hundreds but probably close to 70 in total.
- dd444fgdfg 5y ago
  they can be quite usable with something like the Serverless framework. really though, in my opinion that should be a part of the core AWS solution. Lambda itself is otherwise "low level".
  - fulafel 5y ago
    A big problem with Serverless in this context is that then you're Serverless which seems to be declining faster than Lambda now. Same for adding other abstractions on top, they're flavour du jour. I agree Lambda is too low level, but it probably also explains its longevity.
  - Chyzwar 5y ago
    Serverless framework is even worse. Debugging anything in serverless framework is hell. There is no way to print a fully generated CloudFormation template. In many, you need to brute force the solution by committing and re-deploying. The name “serverless framework” is idiotic and not googleable. It is like naming server side framework “api framework”. In my opinion, Lambda should only be for small, event based functionality between services. People that sold the idea of full-fledged app development to clueless architecture astronauts should have a special place in hell.
    - Dunedan 5y ago
      > There is no way to print a fully generated CloudFormation template. I'm no fan of Serverless Framework either, but accessing the generated CloudFormation template which will be used to deploy the AWS resources is actually pretty straightforward: sls package cat .serverless/cloudformation-template-update-stack.json
rapind 5y ago
I've been moving more expensive operations into postgresql functions, Initially writing them has taken a good chunk of time, but they just kind of do the job, much faster too and with low to zero maintenance so far at least. I don't think I can only credit postgresql functions with the low maintenance though. I suspect that the additional overhead / time to write them has forced me to really make sure they are written correctly (and yet I'm sure there's a lot of optimization I could still do).

by 015a 5y ago

MathMonkeyMan 5y ago

I think the answer lies in your last paragraph, but your comment made me think: Perhaps Lambda functions are resilient because they're: - scope constrained - surrounded by APIs only (e.g. no cheating by having a whole POSIX system) - infrastructure is maintained solely by a giant company that you pay to not have to think about it I haven't used any "serverless" stuff, so I don't really know. Per the article's recommendation, I have noticed at work that resilient software is often a 400 line python script with no other dependencies; or, a medium sized piece of C++ infrastructure that depends only on the OS, the compiler, and a hand-written build system.

Hendrikto 5y ago
> hand-written build system. Please don‘t. It will be fine as long as a project is very small, but get out of hand quickly. Rewriting the build system after the fact will not be budgeted and likely never happen.

codesections 5y ago

> I've been at my current company for maybe 6 years now, in an engineering role. In that time, the service-oriented code which has [lasted the longest is] AWS lambda functions. We have quite a few Lambda functions (written in Node) that I believe pre-date even my tenure at the company. Interesting, AWS lambda only launched in November, 2014[0]. So those more-than-six-year-old functions must have been written for a brand new platform. [0]:https://en.m.wikipedia.org/wiki/AWS_Lambda https://en.m.wikipedia.org/wiki/AWS_Lambda

bombcar 5y ago

Things that get rarely touched but depend on external systems are some of the best candidates for extensive and continuous test suites - as they’re most likely to silently break.

Chyzwar 5y ago

AWS Lambdas are bane of my existance. Many of issues I was involved over years*. From issues with performance, deployments, cold start, api gateway integrations, arbitrary limits or just random failures. Debuging is difficult and whole thing is dog slow. Even today I have two outstanding issues that I need to investigate, lambdas fail to connect to redis and pino not logging correctly response times. Some of that can be blamed for misusing lambdas, but I hate FaaS concept. AWS ECS, google app engine and k8 where you deploy container are imo better and give you more control. Edit not hundreds but probably close to 70 in total.

dd444fgdfg 5y ago
they can be quite usable with something like the Serverless framework. really though, in my opinion that should be a part of the core AWS solution. Lambda itself is otherwise "low level".
- fulafel 5y ago
  A big problem with Serverless in this context is that then you're Serverless which seems to be declining faster than Lambda now. Same for adding other abstractions on top, they're flavour du jour. I agree Lambda is too low level, but it probably also explains its longevity.
- Chyzwar 5y ago
  Serverless framework is even worse. Debugging anything in serverless framework is hell. There is no way to print a fully generated CloudFormation template. In many, you need to brute force the solution by committing and re-deploying. The name “serverless framework” is idiotic and not googleable. It is like naming server side framework “api framework”. In my opinion, Lambda should only be for small, event based functionality between services. People that sold the idea of full-fledged app development to clueless architecture astronauts should have a special place in hell.
  - Dunedan 5y ago
    > There is no way to print a fully generated CloudFormation template. I'm no fan of Serverless Framework either, but accessing the generated CloudFormation template which will be used to deploy the AWS resources is actually pretty straightforward: sls package cat .serverless/cloudformation-template-update-stack.json

rapind 5y ago

I've been moving more expensive operations into postgresql functions, Initially writing them has taken a good chunk of time, but they just kind of do the job, much faster too and with low to zero maintenance so far at least. I don't think I can only credit postgresql functions with the low maintenance though. I suspect that the additional overhead / time to write them has forced me to really make sure they are written correctly (and yet I'm sure there's a lot of optimization I could still do).