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.
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.
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.
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.
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 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.