I've been building multi-cluster Kubernetes for some time and things like External DNS and Ingress controllers per app are just non-starters. They always felt kludgy having K8S orchestrate things external to the cluster and their anti-patterns IMO.
I love how this post, almost to a fault, just jumps right in. No BS set up. Not even context set up. Just what you expected after reading the title. That's an art.
As for the context of the article, maintainability is almost always worth the cost of the function lookup. The proof here that the cost is almost non-existent means to me the maintainability is always worth the perceived (few cycles) impact unless this is real-time code.
Claude Code is pretty good at Swift + Swift UI. I created and have been iterating on a menubar app for myself that I plan to share with a small team. I'd prefer to do this native than go through a 3rd party solution.
I do have prior experience developing for iOS but that was pre-swift.
I'm also just working on my first iOS Swift app (Mostly for myself, don't know yet if I'll make it public as it's just a clone of Swarm / Gowalla but based on OpenStreetMap data) and it works really well with Claude Code.
I'm not using the Xcode integration and so there's still some rough parts where build errors show up in Xcode and I then have to paste them into my Terminal.
When you are used to backend work...it's kinda fun to see an app come to life and run on your phone though.
why are you using the xcode UI at all? you can ask claude to run the build via CLI, which will return build errors that claude can read and fix itself until it works. it can even take screenshots from the simulator to debug the app UI.
Mostly because I'm still very new to it and I use it to publish the app to my phone. There's probably a way to do via CLI but for now it's easier to see progress and flip some config values in the UI if you don't know yet where all the files are.
xcode's new AI using claude is not performing as well as claude code for me. I've tried a couple times and quickly fall back to using vscode with xcode sitting in a window beside. I don't mind the copypaste of warnings and errors since my workflow is less vibe and more directed/iterative.
This is absolutely untrue. Code from JDK 8 runs fine on JDK 25 (just released LTS). It is true that if you did something silly that locks you into certain dependency versions, you may be stuck, but this is not the majority of applications.
Using Lambda functions stored in ECR has no impact on performance from my experience. AWS Lambda uses Firecracker under the hood, which builds a VM from a container image. It's likely that non-ECR image based Lambdas are actually packaged as a container image before being launched into a Firecracker VM.
What’s more interesting to me than the NPS scores are the free form comment section below the 0-10 rating.
Never mind that anything below X is considered neutral or a detractor. You asked a user / customer/ etc to rate you on a scale of 1-10 and then tell you why.
Want to know what you’re truly screwing up on? Take the feedback on your 1-6 scores seriously and you can find the low hanging fruit to take a product from mediocre to a great user experience.
That’s the true NPS value. It’s all about how you handle the feedback.
The same functionality could have been accomplished by just allowing us to specify the max number of concurrent instances of a function that can be active at a time. With proper request queuing the problem would be solved. As usual, AWS solves a problem they failed to design for by charging for an overly complex solution. Flame me if you want but there are K8s serverless frameworks that address this out of the box.
Oh the "service bus" <strike>xml</strike> json is coming back... its called lambda architecture.
And again nothing new except someone else takes care of some server software for you with the promise of reduced price and maintenance but the reality eventually becomes tight proprietary coupling and eventual price gauging.
Amazon's own Lambda is that, yes. But the Lambda architecture it inspired is the opposite: a de-facto standard (based on the way Amazon's works, but probably eventually an open standard) for servers any org can use to stand up their own public or private FaaS cloud, which developers can deploy Lambda functions onto rather than having to build an entire container/VM just to slot it into OpenStack.
I doubt it will ever be a standard. Amazon loves vendor lock in. Plus most of the cloud services love to do their own thing for each service type. The main exception seems to be Kubernetes. Google has it in GCE, and Amazon has said they are working on their own Kubernetes service. If that happens, I bet Azure will follow if they aren't already working on it.
I (and others) are not so much imagining a standard between cloud vendors, as we're imagining a standard "FaaS server function API" (sort of like how the web has a standard DOM API) supported by several FOSS FaaS server implementations (sort of like how the web has several FOSS Javascript engines.)
Given such a standard API and compatible servers, you'd then deploy a FaaS server cluster to your public/private cloud of choice, the same way you deploy e.g. a Kubernetes cluster, or a Riak cluster.
There would likely by small public clouds attempting to be "FaaS native" by exposing only such servers in a multitenant configuration (like small public clouds like Hyper are currently doing with CaaS.) Their implementations wouldn't always be exactly compatible, and might have some lock-in.
However, once FaaS "caught on" with the enterprise, a FaaS server would likely make its way into the OpenStack architecture.
At that point, you'd see medium-sized public cloud providers like OVH and DigitalOcean set up their own multitenant FaaS clusters as well, probably with custom code, but built to be compatible with the OpenStack FaaS tooling, to allow enterprises the freedom to move FaaS functions freely between public and private clouds.
And, eventually, the other major cloud providers would feel the need to support the API.
---
This path has already been followed: it's what happened to Amazon S3—first cloned (but not compatibly) in FOSS by tools like Riak CS; then standardized by OpenStack Swift; then cloned compatibly in FOSS by tools like Minio; then picked up by medium-scale clouds like Rackspace; and then, eventually, picked up by Azure and GCP as secondary APIs to address their equivalent offerings (that originally had quite different APIs.)
You can definitely do microservices that way but in reality they tend to be more granular both functionality wise and density-wise.
With old skool SOA you'd typically have a monolith app with a bunch of endpoints. With microservices, especially in a containerized environment they tend to be more lightweight.
Microservices is just SOA rebranded for the cool kids. The fact that modern orchestration and tooling makes it easier to have more granular services changes the equation for how you factor the services, to be sure, but it's an evolution not a revolution.
> Programming in C/C++, Java, Javascript, that's easy, anyone can write code. But having the skill of standing in a circle and saying what you've been working on, what you will be working on, and if you have any blockers, that takes pure talent.
