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.
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.
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.
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.
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.
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.
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.
We’re using a FastAPI stack, plus or minus Mangum, to selectively deploy to Fargate or Lambda depending on the workload requirements. Deploy using Terraform, ECS tasks just expose the local uwsgi and Lambda/Mangum just wraps the app entry point. It’s simple and lets us keep the codebases/libraries consistent.
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.
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.
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?
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.
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.
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).
Not to be that "hurr hurr durr everything was better in the past" guy but nothing beats a box somewhere that you scp your code onto with a little 10 line deploy script in terms of speed, maintainability, cost control and overall simplicity.
I long for the good old days of /cgi-bin
Can't get decision fatigue if there's no frameworks or cloud shits to decide on.
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?
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.
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.
I was told by a Canadian anglophone that the French Catholic tradition was strict about cursing, so what happened over generations was that actual Church words turned into the cussing words.. the example given was the French word of "Tabernacle" if you say it with loud outrage by itself, it is definitely cussing..
