I think with Lambda there are a lot of downsides to either approach. When you build the Lambda as a monolith, you also give all the code executing from that monolith access to all the resources needed by every single route in the Lambda. When I was working with Lambda a lot, we had a lot of secrets that were only needed by a few routes, and which would have been very bad if someone misused those secrets from a different place.
But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.
I think there's a happy medium where you group lambdas by resource type or domain, but even still it can be tricky to enforce "least privileged access" for those when the content of the lambdas is constantly being added to. Eventually there is creep in the IAM permissions available to those lambdas.
I came up with a system that did incremental build/deploys for all of our lambdas based on the code changes since the last builds/deploys, but even so that came with some pain and definitely some hacks that I wouldn't do again (and relied on technologies it was difficult to get other people to engage with, like Bazel.) I also think Lambda (in particular of the FaaS options) is...not great for APIs, especially if you use a language with a long cold start time.
> But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.
Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster).
I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want.
I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high).
Nice, we evaluated their Seed product but didn't pull the trigger, which caused me to eventually roll our own. I'm pretty proud of what we ended up with but due to reasons we ended up with _hundreds_ of lambdas, for which a full re-build re-deploy took around 45m (Go lambdas).
We used Go and the Serverless framework (ugh), and if I had to do it all over I would probably just use AWS SDK since it would make doing the "diff" to redeploy dead simple, since everything is just a binary to build.
Your use case definitely makes sense for Lambda APIs though! I think my complaint is more directed at APIs that back frontends. We had a JVM lambda API there for a while that was horrificly slow startup unless you set provisioned concurrency, which gets expensive fast.
Yeah, I totally understand and agree with your "downsides" for lambdas. My use case just happens to gel perfectly with them but it's not a "one-size-fits-all".
I also looked at SEED and I would like to give them money but some of their methodology with SEED didn't fit with mine and since my deploys aren't horrible I left my system as-is. Also I understand they need to make money but I wish more tools geared towards serverless "scaled to zero". I'm happy to pay but my company has such bursty traffic that paying for a plan (on SEED or something like monitoring) that can handle our "peak" means burning money 70%-90% of the time while our app is scaled to zero but we still have to pay for tools around it.
Some monitoring tools, like New Relic, are based on usage but both NR and DataDog have absolute shit serverless monitoring solutions and their docs are a dumpster fire (at least around serverless). It's also unfortunate that most serverless monitoring means adding ~$10 per account per month (in increased AWS costs) just for their data pipelines to scan CloudWatch logs. This again sucks since we have an AWS account per client but each client is only active for ~1mo every year so it can get expensive fast.
Yes, and I usually find when I run into this that I should be doing something differently in our package/interface design. I think it's overall very helpful though also annoying to detangle if you the cycle is deep enough.
> - The City Council here is undoubtedly the worst part of the problem. They consistently buckle to NIMBYs, and allocate money in just unreasonably idiotic ways. ("No one riding the train that cost $1.1 billion? Easy fix! Spend $7 billion more!") They are making the change much more painful.
Are you referring to Project Connect here? Right now nobody rides the train, but the answer to that problem _is_ to spend more money. Currently the train stops basically nowhere useful unless you are commuting from Leander to downtown, or going to the soccer stadium. The answer to that is to put _more_ stops in, in more useful places. The Domain stop is a ~30 minute walk from all the large businesses in the Domain. The train stops running into town at 6pm, meaning if you stay a little late you miss the train at your Domain office, and its not useful at all if you're trying to go out drinking or something in the city.
Additionally, there are network effects associated with public transit usage, the same as road or bike lane usage. The more places you can get to by public transit, the more likely you are to take public transit to get there. The new rail corridors will make the city far more connected by transit, and thus potentially increase usage of transit.
They spent $1.1 billion on the first round of the train, and in FY2021 it brought in $55,000 in gross fares.
We won’t be able to spend our way to adoption at that rate. And people aren’t going to adopt public transit in a city built around cars (93.4% of Austin families own a vehicle).
Sounds like we both wish mass public transit was the reality, but sadly it’s just not realistic.
I've tried to use a "personal wiki" in professional life and found that I did not really use the functionality. What re-occurring concepts need to be linked back to? AWS? APIs? Perhaps I'm just not a very good professional note-taker, but my brief experimentation didn't really feel useful.
What I _have_found it very useful for is D&D notes. People, places, objects come up on a re-occurring basis and it is often useful to have a description, encounters, relationships to other people/places/things in a page, or even just a place to list all of those things! You can easily go from session journal -> a bunch of new pages about things, or updates to existing ones in a brief review after the session. It took me a while to actually do the organization but the upkeep is now easy, and I will have a place to recall the name of the inn we we stayed at in our first session in Fantasyville.
I started using one professionally and found it fairly helpful. Mostly I just type all my meeting notes and useful things I discover into my daily notes, and try to tag the top-level node with at least the name of the project and maybe the people I’m meeting with. Then I can go to the project page and see a history of the discussion, which has been helpful on numerous occasions: instead of “I think I remember someone saying that foo service is going to be deprecated soon”, I can tell my teammates “Alice from the baz team told me two months ago that foo service will be deprecated in favor of bar, here’s a link to the doc outlining the reasons”. Probably 80% of the benefit just comes from having searchable daily notes, but the linking is pretty nice too.
Also helpful in 1:1s with people, I can easily see a record of all interactions I’ve had with a person so it reminds me to follow up on things when we chat.
If you're deep into something like AWS at work, it seems useful to tag all the individual services you encounter in your work so you have a record of where you've used it or investigated using it. One tag for AWS doesn't sound useful. A tag structure like AWS-EC2 should let you search for every service without one overarching tag.
This kind of thing is best done in a collaborative tool, of course.
The 200 resources thing has been a really frustrating problem for us too. We've started migrating ours to separate API Gateways at a "service" level and then mapping paths to different APIs using the Custom Domain API Mappings.
> We've started migrating ours to separate API Gateways at a "service" level and then mapping paths to different APIs using the Custom Domain API Mappings.
Yeah, that was suggested to us too, but it felt like a dirty hack to me. What is the point of having an API gateway if you can’t have the single one (our microservices hook themselves up to that single gateway).
Our solution involves a custom CDK resource that keeps re-creating API gateways until it gets a root resource ID starting in the lower range of the alphabet, ensuring it’ll always be found by CloudFormation.
KTRU is legend even in Europe. The strongest radio station that times, then destroyed by Rice and politics, now online only. The most uncompromosing programming, in the most corrupt state. Still no mp3's, only Vinyl. Legendary DJ's. I'm sure you don't know 95% of what they play. They hate all the major labels. They have a huge blacklist.
"Real socialists" is definitely not a community with a homogeneous opinion on who to vote for, or even on whether a "real socialist" should vote. The argument on whether socialists should participate in liberal democracy has been one that has been ongoing since essentially the dawn of leftist politics. The theory of two revolutions, the idea that a revolution constructing a liberal democracy was a necessary step towards socialism, was probably the prevailing idea in many of the 19th and early 20th century revolutions (like the revolutions of 1848 and the Russian Revolution of 1905). There were obviously people who did not take this line, but it is not new or conciliatory that some leftists take a similar stance today.
Agreed, I think that everything else in the movie is rather pointedly aimed at revealing and satirizing the reaction of average Americans to a "foreigner", but the scenes involving the villagers lose that focus and reflect poorly on those involved with the movie. I don't think that discounts what the movie is successful at doing, though.
I think that the subject of the satire for most of the movie is intended to be American's perception of foreigners, and not foreigners themselves. I do agree that some of the depictions of Kazakhstan (the village in the movie is not actually even in Kazakhstan) do veer away from this toward something that at least feels like it is poking fun at the depicted culture and not Americans.
But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.
I think there's a happy medium where you group lambdas by resource type or domain, but even still it can be tricky to enforce "least privileged access" for those when the content of the lambdas is constantly being added to. Eventually there is creep in the IAM permissions available to those lambdas.
I came up with a system that did incremental build/deploys for all of our lambdas based on the code changes since the last builds/deploys, but even so that came with some pain and definitely some hacks that I wouldn't do again (and relied on technologies it was difficult to get other people to engage with, like Bazel.) I also think Lambda (in particular of the FaaS options) is...not great for APIs, especially if you use a language with a long cold start time.