5 ms·

AWS Chalice

55 points by jacky2wong 2y ago

danfritz 2y ago
It seems dead? https://github.com/aws/chalice/issues/2067 https://github.com/aws/chalice/issues/2067
- abrichr 2y ago
  > It seems aws focus is now at https://github.com/aws-powertools/powertools-lambda-python https://github.com/aws-powertools/powertools-lambda-python
  - jacky2wong 2y ago
    Surprised to see the list of companies using AWS powertools
  - kapilvt 2y ago
    its not quite the same, roughly 60-70% of chalice code by volume is actually helping auto provision. power tools is about 70-80% code by volume is integration with other services/capabilities in aws (tracing, logging, metrics, etc). the overlap is the event routing shims/decorators.
- tedmiston 2y ago
  Not a huge surprise. It filled a weird niche, which was very easy to use for basic use cases, but Chalice only supported a small subset of Lambda features and didn't get much attention from AWS either. As soon as you tried to do slightly more than was possible with it, it become unviable to manage all of the Lambdas and you end up having to use Terraform or similar anyway. If I were doing lots of new Lambdas today, I'd probably just use a third-party Terraform module for all of it.
- tedivm 2y ago
  Yup! I used to use it, but was very disappointed in how little support it got and ended up dropping it. It's a great idea but never got enough resources to take off.
bdcravens 2y ago
Discussed here a number of times since it was announced in 2016, including the launch post which has the most discussion https://news.ycombinator.com/item?id=12074388 https://news.ycombinator.com/item?id=12074388
boole1854 2y ago
Hilariously, "chalice" is a strong swear word in Quebec French, so there the name of this product is roughly equivalent to "AWS Fuck". https://en.wikipedia.org/wiki/Quebec_French_profanity https://en.wikipedia.org/wiki/Quebec_French_profanity
- u32480932048 2y ago
  I think that was the codename for their billing module.
- abtinf 2y ago
  What a bizarre phenomenon. Per that article, the word chalice does mean chalice, but is treated as a swear word precisely because it doesn’t have any profane association and has sacred overtones? How then would one discuss these topics at all? Is this an attempt to wipe out all the words entirely?
  - geodel 2y ago
    The way I see. 1) Get rid of this urge to find any word is used as swear word in one of 100s languages used across the world. People who are looking to get offended will get offended with certainty. 2) Over time euphemisms become dysphemisms and vice versa. So if new words are added to swear word categories surely old ones are falling off that list. One can possibly keep track and use those.
  - sirtoffski 2y ago
    In Quebec French, the general motif for swear words is to use church related terms [0]. Common examples: * câlice [kɑːlɪs] (calice): "chalice" * ostie [ɔs.t͡si] (hostie): "host" - as in sacramental bread * tabarnak [ta.baʁ.nak] (tabernacle): "tabernacle" [0]. https://en.wikipedia.org/wiki/Quebec_French_profanity?wprov=sfti1# https://en.wikipedia.org/wiki/Quebec_French_profanity?wprov=...
  - nebezb 2y ago
    The swear words in Quebec originate from old religious principles, yes. You can differentiate between "good" and "bad" (swear) use of it purely from written context or verbal cues. The verbal cues are a lot easier to pick up on. Sarcasm, angry face, crass conversation amongst friends, etc.
walthamstow 2y ago
My last company were huge users of this. It's quite limited in terms of the resources it can deploy. To add additional resources that it doesn't work with, you need to write some Terraform. I summarised the pattern we were using here https://github.com/elgrove/terroir https://github.com/elgrove/terroir I'm not surprised the project is dead. AWS want everyone using the CDK for Python or CloudFormation
anonymousDan 2y ago
Anyone here actually developing Python apps on AWS Lambda? If so do you use Serverless Framework or something else? I am part of a research project that is developing techniques for identifying security vulnerabilities in serverless apps so would be interested to understand what people are actually using for deployment and why.
- jjtheblunt 2y ago
  I'm pretty darned sure i used AWS's own boto3 python library for lambda, when working for Amazon a few years ago. https://boto3.amazonaws.com/v1/documentation/api/latest/index.html https://boto3.amazonaws.com/v1/documentation/api/latest/inde...
- jbmsf 2y ago
  We deploy lambda using container images. We configure lambdas using terraform and deploy using GitHub actions. We never considered using serverless or anything else because we also have ECS services, RDS databases, React frontends, and a lot more. It requires some knowhow to get a good setup, but it's hard to imagine anyone more opinionated framework doing what we want.
- ZiiS 2y ago
  CDK; don't love it, but it works.
  - ZiiS 2y ago
    tbf; with `aws_lambda_python_alpha.PythonFunction` in a Poetry based project, we do get a lot for free. I like small layer based deployments (so we can use things like `aws_lambda.ParamsAndSecretsLayerVersion` etc). Gets a bit more hacky when you try and enable IPv6, but that is just AWS.
- tedmiston 2y ago
  If you try to use serverless (the framework) for Python, you very quickly learn that its support is a second-class citizen vs building in TS/JS. Adjacent concern but: It also makes for unholy large Docker images to combine an entire JS toolchain with an entire Python toolchain. Zappa is a better (more native) choice. Terraform modules provide a decent Python Lambda experience. AWS also has multiple semi-overlapping projects in the space. Chalice, SAM, and Powertools specifically to name a few. CDK more generally as well.
Locutus_ 2y ago
I've built a couple of systems for customers using this, and the development comfort and Flask-like-ness is quite nice. But it's really just completely dead by now, which is a bummer as this leaves a large complexity gap between this and jumping ahead to just doing full Lambda+CDK/Serverless/Terraform setups.
madamelic 2y ago
Spin something up in an hour; spend a week fixing it when the magic inevitably breaks. Maybe I am just incredibly jaded but I can't stand all these shortcut frameworks. It just ends up locking you into an ecosystem, especially AWS, and decouples you from building technical understanding of the system where if you go down the path long enough, you have no abort button besides an entire re-build because your code is enmeshed with the framework. Do it right the first time: build it simple & iterate as you go. You don't need to be thinking about scaling to 1M concurrent users when you have 0 users.
- deleted 2y ago
  [deleted]
- poshmosh 2y ago
  Every framework have worked on for the last 12 years has bugs, breaks in certain situations. Every system in fact, i have worked on in 12 years has bugs and breaks. That is just the nature of software development. You should be using frameworks instead of trying to reinvent things. It takes away decision fatigue and makes it easier for most teams to follow conventions that are already established.
  - madamelic 2y ago
    Not advocating for inventing your own thing but no need to get complicated if the needed solution is simple. These magic-included frameworks are great to work with until you deviate from their prescribed path or just run out of road where the maintainers haven't gotten to that. There's really no need for a magic-included Lambda framework that makes AWS SDK calls as decorators, you are just asking for lock-in when that framework gets abandoned or you need a feature from a downstream dependency they haven't gotten around to implementing yet. If you kept it simple, you could 'just' bump your AWS SDK version and be on latest. If you pick frameworks that are generally low 'magic', you can build your own road and it can be integrated into the rest of the application tightly. If you did this in a magic-included, it will generally be bolted on and imminently fragile to even slight framework changes (because the maintainers don't know or care about your hack).
  - 2y ago
kapilvt 2y ago
as a previous contributor and user, I would not recommend. as a project in the GitHub aws organization, it can not accept non amazon external maintainers. as a project, it has a single maintainer, doing on average, an hr every few months. as a result of both of those , its not able to keep up, or reach critical mass on community. it has fallen fairly far behind current lambda feature set. for a simple throw away, its okay, but if you want to grow something or take advantage of new features in the underlying service capabilities or integrations, this is a dead end. I filed this ticket a few years ago https://github.com/aws/chalice/issues/2067 https://github.com/aws/chalice/issues/2067
- deleted 2y ago
  [deleted]
fabiofzero 2y ago
Everyone in Quebec goes CÂLISSE DE TABARNAK
remram 2y ago
How does that work? That code works partly at deploy time, to register the serverless app with SQS/..., and then it runs partly in the serverless invocation?

AWS Chalice

55 points by jacky2wong 2y ago

danfritz 2y ago

It seems dead? https://github.com/aws/chalice/issues/2067 https://github.com/aws/chalice/issues/2067

abrichr 2y ago
> It seems aws focus is now at https://github.com/aws-powertools/powertools-lambda-python https://github.com/aws-powertools/powertools-lambda-python
- jacky2wong 2y ago
  Surprised to see the list of companies using AWS powertools
- kapilvt 2y ago
  its not quite the same, roughly 60-70% of chalice code by volume is actually helping auto provision. power tools is about 70-80% code by volume is integration with other services/capabilities in aws (tracing, logging, metrics, etc). the overlap is the event routing shims/decorators.
tedmiston 2y ago
Not a huge surprise. It filled a weird niche, which was very easy to use for basic use cases, but Chalice only supported a small subset of Lambda features and didn't get much attention from AWS either. As soon as you tried to do slightly more than was possible with it, it become unviable to manage all of the Lambdas and you end up having to use Terraform or similar anyway. If I were doing lots of new Lambdas today, I'd probably just use a third-party Terraform module for all of it.
tedivm 2y ago
Yup! I used to use it, but was very disappointed in how little support it got and ended up dropping it. It's a great idea but never got enough resources to take off.

bdcravens 2y ago

Discussed here a number of times since it was announced in 2016, including the launch post which has the most discussion https://news.ycombinator.com/item?id=12074388 https://news.ycombinator.com/item?id=12074388

boole1854 2y ago

Hilariously, "chalice" is a strong swear word in Quebec French, so there the name of this product is roughly equivalent to "AWS Fuck". https://en.wikipedia.org/wiki/Quebec_French_profanity https://en.wikipedia.org/wiki/Quebec_French_profanity

u32480932048 2y ago
I think that was the codename for their billing module.
abtinf 2y ago
What a bizarre phenomenon. Per that article, the word chalice does mean chalice, but is treated as a swear word precisely because it doesn’t have any profane association and has sacred overtones? How then would one discuss these topics at all? Is this an attempt to wipe out all the words entirely?
- geodel 2y ago
  The way I see. 1) Get rid of this urge to find any word is used as swear word in one of 100s languages used across the world. People who are looking to get offended will get offended with certainty. 2) Over time euphemisms become dysphemisms and vice versa. So if new words are added to swear word categories surely old ones are falling off that list. One can possibly keep track and use those.
- sirtoffski 2y ago
  In Quebec French, the general motif for swear words is to use church related terms [0]. Common examples: * câlice [kɑːlɪs] (calice): "chalice" * ostie [ɔs.t͡si] (hostie): "host" - as in sacramental bread * tabarnak [ta.baʁ.nak] (tabernacle): "tabernacle" [0]. https://en.wikipedia.org/wiki/Quebec_French_profanity?wprov=sfti1# https://en.wikipedia.org/wiki/Quebec_French_profanity?wprov=...
- nebezb 2y ago
  The swear words in Quebec originate from old religious principles, yes. You can differentiate between "good" and "bad" (swear) use of it purely from written context or verbal cues. The verbal cues are a lot easier to pick up on. Sarcasm, angry face, crass conversation amongst friends, etc.

walthamstow 2y ago

My last company were huge users of this. It's quite limited in terms of the resources it can deploy. To add additional resources that it doesn't work with, you need to write some Terraform. I summarised the pattern we were using here https://github.com/elgrove/terroir https://github.com/elgrove/terroir I'm not surprised the project is dead. AWS want everyone using the CDK for Python or CloudFormation

anonymousDan 2y ago

Anyone here actually developing Python apps on AWS Lambda? If so do you use Serverless Framework or something else? I am part of a research project that is developing techniques for identifying security vulnerabilities in serverless apps so would be interested to understand what people are actually using for deployment and why.

jjtheblunt 2y ago
I'm pretty darned sure i used AWS's own boto3 python library for lambda, when working for Amazon a few years ago. https://boto3.amazonaws.com/v1/documentation/api/latest/index.html https://boto3.amazonaws.com/v1/documentation/api/latest/inde...
jbmsf 2y ago
We deploy lambda using container images. We configure lambdas using terraform and deploy using GitHub actions. We never considered using serverless or anything else because we also have ECS services, RDS databases, React frontends, and a lot more. It requires some knowhow to get a good setup, but it's hard to imagine anyone more opinionated framework doing what we want.
ZiiS 2y ago
CDK; don't love it, but it works.
- ZiiS 2y ago
  tbf; with `aws_lambda_python_alpha.PythonFunction` in a Poetry based project, we do get a lot for free. I like small layer based deployments (so we can use things like `aws_lambda.ParamsAndSecretsLayerVersion` etc). Gets a bit more hacky when you try and enable IPv6, but that is just AWS.
tedmiston 2y ago
If you try to use serverless (the framework) for Python, you very quickly learn that its support is a second-class citizen vs building in TS/JS. Adjacent concern but: It also makes for unholy large Docker images to combine an entire JS toolchain with an entire Python toolchain. Zappa is a better (more native) choice. Terraform modules provide a decent Python Lambda experience. AWS also has multiple semi-overlapping projects in the space. Chalice, SAM, and Powertools specifically to name a few. CDK more generally as well.

Locutus_ 2y ago

I've built a couple of systems for customers using this, and the development comfort and Flask-like-ness is quite nice. But it's really just completely dead by now, which is a bummer as this leaves a large complexity gap between this and jumping ahead to just doing full Lambda+CDK/Serverless/Terraform setups.

madamelic 2y ago

Spin something up in an hour; spend a week fixing it when the magic inevitably breaks. Maybe I am just incredibly jaded but I can't stand all these shortcut frameworks. It just ends up locking you into an ecosystem, especially AWS, and decouples you from building technical understanding of the system where if you go down the path long enough, you have no abort button besides an entire re-build because your code is enmeshed with the framework. Do it right the first time: build it simple & iterate as you go. You don't need to be thinking about scaling to 1M concurrent users when you have 0 users.

deleted 2y ago
[deleted]
poshmosh 2y ago
Every framework have worked on for the last 12 years has bugs, breaks in certain situations. Every system in fact, i have worked on in 12 years has bugs and breaks. That is just the nature of software development. You should be using frameworks instead of trying to reinvent things. It takes away decision fatigue and makes it easier for most teams to follow conventions that are already established.
- madamelic 2y ago
  Not advocating for inventing your own thing but no need to get complicated if the needed solution is simple. These magic-included frameworks are great to work with until you deviate from their prescribed path or just run out of road where the maintainers haven't gotten to that. There's really no need for a magic-included Lambda framework that makes AWS SDK calls as decorators, you are just asking for lock-in when that framework gets abandoned or you need a feature from a downstream dependency they haven't gotten around to implementing yet. If you kept it simple, you could 'just' bump your AWS SDK version and be on latest. If you pick frameworks that are generally low 'magic', you can build your own road and it can be integrated into the rest of the application tightly. If you did this in a magic-included, it will generally be bolted on and imminently fragile to even slight framework changes (because the maintainers don't know or care about your hack).
- 2y ago

kapilvt 2y ago

as a previous contributor and user, I would not recommend. as a project in the GitHub aws organization, it can not accept non amazon external maintainers. as a project, it has a single maintainer, doing on average, an hr every few months. as a result of both of those , its not able to keep up, or reach critical mass on community. it has fallen fairly far behind current lambda feature set. for a simple throw away, its okay, but if you want to grow something or take advantage of new features in the underlying service capabilities or integrations, this is a dead end. I filed this ticket a few years ago https://github.com/aws/chalice/issues/2067 https://github.com/aws/chalice/issues/2067

deleted 2y ago
[deleted]

fabiofzero 2y ago

Everyone in Quebec goes CÂLISSE DE TABARNAK

remram 2y ago

How does that work? That code works partly at deploy time, to register the serverless app with SQS/..., and then it runs partly in the serverless invocation?