weitendorf

Over the past year I've started thinking a lot more about design and UI work, and I think it's basically impossible to design things, or create design systems, that appeal broadly to different types of users in a cross-platform way.

I personally love dense UIs and have no expectation of doing certain kinds of work on a phone or low-powered device like a chromebook, phone, or bottom-barrel laptop. But if you're a company trying to sell products to a broad user base, you want to try to design in a way that works for those kinds of users because they still might be end-users of your product. And there's a good chance that those platforms may be where someone first evaluates your product (eg from a link shared and accessed on a mobile device) even for the users who do plan on using more powerful desktop devices to do their work.

So instead we get these information poor, incoherent (because it turns out proper cross-platform, cross-user design is much more difficult than just getting something that works cross-platform for all users on its surface) interfaces. I guess I'm writing this just to add, web/mobile have complicated things partially because more than just requiring their own distinct patterns, they each represent a distinct medium that products try to target with the same kind of design. But because they're different mediums, it's like trying to square a circle.

Agreed, the type of person who can say "I'll just build my own CMS" is not usually the type of person spending a significant portion of their job time using a CMS.

And you might say, well if they're somewhat technical (which is much more likely, think about eg technical writers or product managers or marketing teams) they can use AI to add more features. But when you actually have something at stake security-wise, that means you need to either put them on rails with something much more prescriptive (a "trad-CMS" lmao) or spend a bunch of time reviewing/fixing their code (which, since they're not the same kind of person as you, may not even be something they have any interest in doing, and kind of just gets in the way of them getting their message out on your site as intended).

That said, I think most tech companies will still roll their own internal tools to do this rather than buy it off the shelf, just because buying it through a vendor and fully setting up in a way that's secure and integrated with your business processes involves more work than rolling it yourself, and has a lot of ways it can go wrong.

IMO what you really want is some kind of FOSS CMS that works really well off-the-shelf for a small team, and has a strong ecosystem of integrations to add on SSO and visual editors and stuff like that as you grow, where you can also probably just hire someone to do that part since that would probably coincide with your business getting too busy for spending your time on an internal CMS to be the most effective use of your time. Which is literally wordpress.

It's just that wordpress is a death-by-a-thousand-cuts of mediocre quality/over-complicated stuff, and the core technology has some bad abstractions/shows its age, and that emanates out into everything else it touches. Also, while it's true that a static site is much better for most people, SOMEONE has to actually run a web-server for those files, and that does actually cost money to provide, so I've softened my thoughts on Wordpress doing that. It's not actually free for Cloudflare to do that for you, it's just a loss leader they can afford to give away because they have economies of scale and privileged access to the Internet.

Yes, I completely agree. The thing is, this kind of customer just doesn't want to bother themselves with the technical details, and has no frame of reference to understand or even care why Wordpress isn't actually a good fit for hosting their site.

They also usually don't want to self-serve. IMO this became abundantly clear once I saw who was using bolt.new and Lovable and what was being built. You'd think these would be perfect fits for non-technical business owners, but after talking to them more it turns out they just don't have the time or interest to spend hours on building some little marketing site, and want it to be someone else's responsibility. Conversely, I would never build something with Framer and have no interesting in allowing some fly-by-night agency hold my site hostage, but they do a lot better at actually delivering value to end users without making them spend their time on tech stuff they don't care about.

Conversely, the kind of person spending hours building a site on Lovable for some SaaS product nobody will ever use has an abundance of time and doesn't really want to pay for anything. Most of the time they won't even put their own name on the site lol. You just don't want to deal with that kind of person IMO. Cloudflare and Github allow it because there's a small chance that a small portion of that kind of person ends up actually making something valuable, and because they have a different cost structure due to their affiliations with massive infrastructure holders.

I got very, very close to launching a vertical static site hosting product a few months ago but eventually realized this was kind of a market for lemons. Our own site is on a Lovable-like platform we built that uses our own svelte-baesd FOSS static site generator called Statue. But in using it to try to make some visualization on our own site, and vibe-debug stuff like a non-technical customer would (this thing on this page is broken in this way) I realized that this wouldn't actually feel like magic to someone who values their time, or isn't getting paid a salary to be a web developer and doesn't understand/care that it's still quite labor-intensive to do this.

IMO the real money is in actually being willing to take accountability/responsibility for building someone's site, and building real tooling around it that works for non-developers AND developers, which is what we're building towards now. It's historically been treated as a kind of low-prestige/uninteresting/unscalable business doing agency web stuff, but if you can figure out how to make it scalable and give people beautiful websites, and not make people who value their time wade through slop, there's immense opportunity.

I built the same thing and then just realized that I built a marketing funnel for Cloudflare lol. It's why Cloudflare is trying a bunch of different approaches to the same thing, they're the only ones that actually benefit from it because you can't actually build a business off hosting millions of sites on cf pages, it's a loss leader for them to convert you to a paid product if you end up one day getting a lot of traffic

Hosting a static site isn't free, they just don't charge you for it early on

It's more complicated than that. Small specialized LLMS are IMO better framed as "talking tools" than generalized intelligence. With that in mind, it's clear why something that can eg look at an image and describe things about it or accurately predict weather, then converse about it, is valuable.

There are hardware-based limitations in the size of LLMs you can feasibly train and serve, which imposes a limit in the amount of information you can pack into a single model's weights, and the amount of compute per second you can get out of that model at inference-time.

My company has been working on this specifically because even now most researchers don't seem to really understand that this is just as much an economics and knowledge problem (cf Hayek) as it is "intelligence"

It is much more efficient to strategically delegate specialized tasks, or ones that require a lot of tokens but not a lot of intelligence, to models that can be served more cheap. This is one of the things that Claude Code does very well. It's also the basis for MOE and some similar architectures with a smarter router model serving as a common base between the experts.

I built a product solving this problem about a year ago, basically a serverless, container-based, NATed VScode where you can eg "run Claude Code" (or this) in your browser on a remote container.

There's a reason I basically stopped marketing it, Cursor took off so much then, and now people are running Claude/Codex locally. First, this is something people only actually start to care about once they've been bitten by it hard enough to remember how much it hurt, and most people haven't got there yet (but it will happen more as the models get better).

Also, the people who simultaneously care a lot about security and systems work AND are AI enthusiasts AND generally highly capable are potentially building in the space, but not really customers. The people who care a lot about security and systems work aren't generally decision makers or enthusiastic adopters of AI products (only just now are they starting to do so) and the people who are super enthusiastic about AI generally aren't interested in spending a lot of time on security stuff. To the extent they do care about security, they want it to Just Work and let them keep building super fast. The people who are decision makers but less on the security/AI trains need to this happen more, and hear about the problem from other executives, before they're willing to spend on it.

To the extent most people actualy care about this, they still want to Just Work like they do now and either keep building super fast or not thinking about AI at all. It's actually extremely difficult to give granular access to agents because the entire point is them acting autonomously or keeping you in a flow state. You either need to have a really compatible threat model to doing so (eg open source work, developer credentials only used for development and kept separate from production/corp/customer data), spend a lot of time setting things up so that agents can work within your constraints (which also requires a willingness to commit serious amounts of time or resources to security, and understanding of it), or spend a lot of time approving things and nannying it.

So right now everybody is just saying, fuck it, I trust Anthropic or Microsoft or OpenAI or Cursor enough to just take my chances with them. And people who care about security are of course appalled at the idea of just giving another company full filesystem access and developer credentials in enterprises where the lack of development velocity and high process/overhead culture was actually of load-bearing importance. But really it's just that secure agentic development requires significant upfront investment in changing the way developers work, which nobody is willing to pay for yet, and has no perfect solutions yet. Dev containers were always a good idea and not that much adopted either, btw.

It takes a lot more investment in actually providing good permissions/security for agent development environments still too, which even the big companies are still working on. And I am still working on it as well. There's just not that much demand for it, but I think it's close.

> In reality you could host the entire thing for well under $50k/year in hardware

I could pay Anthropic $400 to write more code than you have in your entire lifetime.

Sure, you're able to operate a website acting as essentially the most important and highest volume venue for sharing academic research in the world, but come on, why couldn't I just ask Claude Code or some web developer in a foreign country to do the same thing?

Every time I try to build a castle in my swamp, it gets to a certain height and then it just sinks?

STOP telling me about civil engineering, we fucking invented that shit. And NO, we have to build it in the swamp, it feeds us and keeps us safe, and I'm darned proud to say we invented that too.

Their 40 year old boss the will be younger than many of the 20 something, 30 something, 40 something entrepreneurs who already, now, at this moment (me included) would find the idea of moving to Active Directory and stocking the company with Wintel laptops equally farcical.

> A startup may be all-Mac. Eventually if it's successful though, it'll be too big to use 'consumer' tools only... likewise they have no realistic counterpart for Active Directory, nor business email or collaboration (at least Google has that though).

Between the two, they have those needs pretty much completely covered (also, Apple does have increasingly good support for MDM now). To me this reads more as a complaint that neither of them is trying to execute the same bundling/business model as Microsoft, or selling the same kind of security model as what makes sense for an old school IT shop that literally could never leave Microsoft products if it even wanted to.

Every single mobile device in "Enterprise" is using MDM provided and supported by those two companies for business users at multiple layers of the stack required to provide that functionality, they just don't make a business out of selling it directly as a Serious Enterprise Product to IT departments (the least important part of the stack, ie where a guy in a collared shirt with a web app takes a middle manager out for a steak dinner).

I set up MDM for the first time while standing in line for a flight at the airport, on my iphone and for my iphone. My company uses an enterprise IdP with a zero trust security model, which I saw executed firsthand by both Microsoft and Google for their own companies, neither of which made a fuss about giving me a mac device to work with. Somehow, it worked.

So far it's better for equivalent Qwen 3.5 workloads, and much less expensive. As you mention Qwen spends way too much time/tokens reasoning, so it ends up being more expensive than you'd think based on its model card (also IME, flaky).

I actually think this model is a Big Deal because there's a whole world out there of people building on top of Qwen and other Chinese models, and now Mistral has just released one of the best generalist FOSS models in its price/size range at an excellent price ($0.60/1M output is a steal). Mistral could potentially grab a lot of that.

Personally I am going to build off of it and invest in their ecosystem now, with this model, because it's definitely worth paying for at the current price. Whether Mistral or some other venture comes out with the next big thing in that category is anybody's guess, but I hope now that labs are starting to converge on more rapid release cycles, I'm hoping Mistral won't be far behind.

The main thing for me though is that for small model use cases, it just doesn't make sense to pay a ton for Haiku/Gemini and other expensive small models that you can't self-host or finetune or generally build upon. They cost too much and can't be tinkered with. Also, the range in which you'd want the incrementally better performance of something like Haiku over Mistral, but not enough to think about the benefits of tuning or self-hosting inference, are few for me. But at the same time, if you're going to invest in building on top of someone else's product, you want them to be trustworthy and long-term partners.

I'm excited to give them a shot

Very cool! I’ve been flirting with the idea of biting the bullet and moving more towards language extensions around protobuf/grpc vs just tools so it’s really great to see projects on the other side of that kind of decision shipping and what choices they made

Why the square brackets in particular? Notation is such an annoying part of this stuff, I’m actually leaning towards pushing a lot of structure to the filesystem

The people who pay for operating systems are paying for a private entity to decide what the operating system should do. They're paying for someone to compile it from source and get it to run on their computer and maintain it.

That's the whole point. Paying someone for that thing you also know how to do so they can consider that problem solved and focus on the things they know how to do.

The difference between a 10% agent and a 30-60% subcontractor is what's being purchased, and from whom. Actors and other famous creatives are selling their particular work, which is unique and demanded by clients mostly independently of details like who their agent is. When a client pays 2x to an agency that pays the subcontractor implementing the work 1x to complete it, what's being purchased is the agency's work - working directly with the client, finding developers to complete the work, and managing the process of delivery (and all the related bits: making sure their subcontractors know what they're doing and are appropriate fits for the project, keeping work on track, being accountable for delivery/operational execution to the client).

If that extra 20-50% were so easy/useless that it can be grabbed "without lifting a finger", why aren't you finding enough work on your own to keep yourself busy, or, why are you still working with that third-party company to begin with? Oh, you would, if you "had any interest" in doing that. That level of accountability to the client and attention to their needs is literally what clients are paying the agency for, and why they're the ones handling the demand for work rather than their subcontractors.

If clients aren't seeking out your particular involvement in their project, you're the guy working the mic, not the movie star.

Thanks for mentioning them, we're doing quite similar debit-credit stuff as https://docs.tigerbeetle.com/concepts/debit-credit/ but reading https://docs.tigerbeetle.com/concepts/performance/ they are definitely thinking about the problem differently from us. You need much more prescribed entities (eg resources and skus) on the modelling side and different choices on the performance side (for something like a usage pricing system) for a cloud platform.

This feels like a single-tenant, centralized ACH but I think what you actually want for a multitenant, multizonal cloud platform is not ACH but something more capability-based. The problem is that cloud resources are billed as subscriptions/rates and you can't centralize anything on the hot-path (like this does) because it means that zone/any availability interacting with that node causes a lack of availability for everything else. Also, the business logic and complexity for computing an actual final bill for a cloud customer's usage is quite complex because it's reliant on so many different kinds of things, including pricing models which can get very complex or bespoke, and it doesn't seem like tigerbeetle wants calculating prices to be part of their transactions (I think)

The way we're modelling this is with hierarchical sub-ledgers (eg per-zone, per-tenant, per-resourcegroup) and something which you could think of as a line of credit. In my opinion the pricing and resource modelling + integration with the billing tx are much more challenging because they need to be able to handle a lot of business logic. Anyway, if someone chooses to opt-in to invoice billing there's an escape hatch and way for us to handle things we can't express yet.

> Cloud run and lambdas can not be incorporated with gcp service mesh, but only if it is managed through gcp as well

I'm not exactly sure what this means, a few different interpretations make sense to me. If this is purely a run <-> other gcp product in a vpc problem, I'm not sure how much info about that is considered proprietary and which I could share, or even if my understanding of it is even accurate anymore. If it's that cloud run can't run in your service mesh then it's just, these are both managed services. But yes, I do think it's possible to run into a situation/configuration that is impossible to express in run that doesn't seem like it should be inexpressible.

This is why designing around multitenancy is important. I think with hierarchical namespacing and a transparent resource model you could offer better escape hatches for integrating managed services/products that don't know how to talk to each other. Even though your project may be a single "tenant", because these managed services are probably implemented in different ways under the hood and have opaque resource models (ie run doesn't fully expose all underlying primitives), they end up basically being multitenant relative to each other.

That being said, I don't see why you couldn't use mTLS to talk to Cloud Run instances, you just might have to implement it differently from how you're doing it elsewhere? This almost just sounds like a shortcoming of your service mesh implementation that it doesn't bundle something exposing run-like semantics by default (which is basically what we're doing), because why would it know how to talk to a proprietary third party managed service?

I guess my meta-point is that "marketing" shouldn't be such a dirty word, because done well enough, it's effective communication that gives people what they want/helps them AND makes them feel good. My own comment basically does the same thing I said he did, lol.

The point of calling it marketing is that this blog post is explaining hooks, basic content marketing (ie be entertaining or interesting), progressive disclosure, and understanding your target audience: standard marketing concepts. You can find a lot of info if you research them by those terms.

Gwern's audience, in an ironic twist of fate, think that being marketed to = being tricked or manipulated by an evil person, so here he is explaining basic content marketing concepts to the people his blog is marketed towards, who hate marketing and believe themselves immune to it.

AI does the same thing to you because 1. most of the web is marketing 2. why shouldn't it be nice to you AND help you? 3. you keep coming back for more, right? And is that necessarily a bad thing?

I highly recommend a deep dive into signalling theory if you're interested in learning more, it's completely changed how I think about communication and behavior, even my own.

It does have real tradeoffs/flaws/limitations, chief among them, Run isn't allowed to "become" Kubernetes, you're expected to "graduate". There's been an immense marketing push for Kubernetes and Platform Engineering and all the associated SAAS sending the same message (also, notice how much less praise you hear about it now that the marketing has died down?).

The incentives are just really messed up all around. Think about all the actual people working in devops who have their careers/job tied to Kubernetes, and how many developers get drawn in by the allure and marketing because it lets them work on more fun problems than their actual job, and all the provisioned instances and vendor software and certs and conferences, and all the money that represents.

Having worked on Cloud Run/Cloud Functions, I think almost every company that isn't itself a cloud provider could be in category 1, with moderately more featureful implementations that actually competed with K8s.

Kubernetes is a huge problem, it's IMO a shitty prototype that industry ran away with (because Google tried to throw a wrench at Docker/AWS when Containers and Cloud were the hot new things, pretending Kubernetes is basically the same as Borg), then the community calcified around the prototype state and bought all this SAAS/structured their production environments around it, and now all these SAAS providers and Platform Engineers/Devops people who make a living off of milking money out of Kubernetes users are guarding their gold mines.

Part of the K8s marketing push was rebranding Infrastructure Engineering = building atop Kubernetes (vs operating at the layers at and beneath it), and K8s leaks abstractions/exposes an enormous configuration surface area, so you just get K8s But More Configuration/Leaks. Also, You Need A Platform, so do Platform Engineering too, for your totally unique use case of connecting git to CI to slackbot/email/2FA to our release scripts.

At my new company we're working on fixing this but it'll probably be 1-2 more years until we can open source it (mostly because it's not generalized enough yet and I don't want to make the same mistake as Kubernetes. But we will open source it). The problem is mostly multitenancy, better primitives, modeling the whole user story in the platform itself, and getting rid of false dichotomies/bad abstractions regarding scaling and state (including the entire control plane). Also, more official tooling and you have to put on a dunce cap if YAML gets within 2 network hopes of any zone.

In your example, I think

1. you shouldn't have to think about scaling and provisioning at this level of granularity, it should always be at the multitenant zonal level, this is one of the cardinal sins Kubernetes made that Borg handled much better

2. YAML is indeed garbage but availability reporting and alerting need better official support, it doesn't make sense for every ecommerce shop and bank to building this stuff

3. a huge amount of alerts and configs could actually be expressed in business logic if cloud platforms exposed synchronous/real-time billing with the scaling speed of Cloud Run.

If you think about it, so so so many problems devops teams deal with are literally just

1. We need to be able to handle scaling events

2. We need to control costs

3. Sometimes these conflict and we struggle to translate between the two.

4. Nobody lets me set hard billing limits/enforcement at the platform level.

(I implemented enforcement for something close to this for Run/Appengine/Functions, it truly is a very difficult problem, but I do think it's possible. Real time usage->billing->balance debits was one of the first things we implemented on our platform).

5. For some reason scaling and provisioning are different things (partly because the cloud provider is slow, partly because Kubernetes is single-tenant)

6. Our ops team's job is to translate between business logic and resource logic, and half our alerts are basically asking a human to manually make some cost/scaling analysis or tradeoff, because we can't automate that, because the underlying resource model/platform makes it impossible.

You gotta go under the hood to fix this stuff.

We do basically this for our tests in statue: https://github.com/accretional/statue/tree/main/test/hermeti...

npm pack builds the file locally, then we expose it to the container filesystem where we do a build and check the outputs. You can move dependencies to bundledDependencies in npm to embed them in the image.

However, this is assuming you're rebuilding the static site generator itself every time. If you just want to build a site using an existing static site generator, it's much easier provided that the site generator itself is easy to use (for example, ours has a one-liner to take you all the way from nothing to a local static site running on localhost, see https://statue.dev)

If you aren't changing the SSG code itself between container runs you'd just mount the markdown to the container and pre-install the ssg in the Dockerfile itself. For statue.dev that would just be a Dockerfile almost exactly the same as the one we use already, except you'd use your own script, and RUN this in the Dockerfile itself: yes | npx sv create . --template minimal --types ts --no-add-ons --install npm && npm install statue-ssg && npx statue init && npm install

In your script you'd just npm run build then do whatever it is you want to do to send the files somewhere, and wherever starts the script, you'd do something like -v "pathtomymarkdown/foo:/test-package/" - not sure how to do this in github runners.

Depending on how interested you/other people are in doing this with statue.dev, we could prob get something like this (where the markdown is parameterized, not the npm package) working by Tuesday. We're building out the sandbox/build features on our cloud platform as we speak, this could be one of the first use cases/defaults.

I think I know the answer, but people don’t want to hear it. Gwern has a kind of formula/structure really effectively markets his blog to the HN audience, which is Not Bad Actually, just effective messaging + giving people what they want.

You can’t really separate the content from its medium, its contex, and its audience if you’re thinking about “why is this successful” (why does the medium express the content n a particular content that works for some particular audience). What the blog post is really about is not “writing” or creating good content per-se, but how to structure content for a blog-like/feed-based medium where you’re competing for clicks, views, attention, participation in external narratives, and relevancy/memorability with an audience mostly looking to be entertained or scratch some curiosity itch.

Gwern has a good formula for that which matched the HN context and audience:

1. Pique interest and grab attention. Give me a reason to click.

2. Let the reader in on the secret, you and me vs all these other idiots. Validate me.

3. Back it all up with sources/references and a post that articulates something the reader already was aware of but fundamentally agreed with. Teach me something but make me feel like “Finally someone who gets it” rather than challenged or threatened.

4. Do the work to actually deliver on the hook. Satisfy my curiosity and give me a reason to come back and share it.

None of this is even necessarily manipulative, it’s just the form that successfully competes in a click-driven market for attention and information (the context). Nobody has to click or read through or share or comment on the thing. Most likely very few will click through to the sources, but they might peep them or be interested to know that they exist. It’s very effective progressive disclosure.

The thing is, this audience REALLY does not want to believe that they can be marketed to or that their decision making is many ways pretty damn emotional/predictable. Gwern does an excellent job validating that for them AND successfully marketing to them anyway. I think that’s the part that’s missing from this post.

The context is completely non-captive, the audience wants to feel smart, and believes that they are “too smart to be marketed to”. Here they are scrolling through an attention market looking for interesting information that they need to be convinced to click, read through, share, and engage with. Why was the link shared and content created to being with, and how did it structure itself to fit its content/audience, and why does a particular structure/messaging work while others don't?

The word for all of that is Marketing. It's just a Good Thing when done right.

I generally agree although I think gRPC and using it with json is awesome, it's just that like with most of these tools, the investment in setup/tooling/integrating them into your work has to be worth what you get out of them.

I actually used to do FaaS at GCP and now through my startup am working on a few projects for cloud services, tooling around them, and composable/linkable FaaS if you're interested! A lot of this logic isn't in our public repos yet but hit me up if you want a try fully automated Golang->proto+gRPC/http+openapi+ts bindings+client generation+linker-based-builds.

A project we started for "modular monoliths" that need local state but not super high availability as databases is at https://github.com/accretional/collector, but I had to put it on pause for the past few weeks to work on other stuff and figure out a better way to scale it. Basically it's a proto ORM based on sqlite that auto configures a bunch of CRUD/search and management endpoints for each "Collection", and via a CollectionRepo additional Collections can be created at runtime. The main thing I invested time into was backups/cloning these sqlite dbs since that's what allows you to scale up and down more flexibly than a typical db and not worry as much about availability or misconfiguration.

If your agent is reasoning across service boundaries you should be giving it whatever you'd normally use when you reason across service boundaries, whether that's an openapi spec or documentation or a client library or anything else. I don't see it as any different than a human reasoning across service boundaries. If it's too hard for your human to do that, or there isn't any actual structured/reusable way for human developers to do that, that's more a problem with how you're doing microservices/developing in general.

> they have to do language translation on the fly in the generation, which is going to degrade attention 100%,

I'm not completely sure what you're alluding to but if you don't have an existing client for your target service, microservices/developers going to have to do that anyway because they're serializing data to call one microservice from another. The only exception would be if you starting calling the other application's code directly from the other's in which case again you're doing microservices wrong or shouldn't even be doing microservices at all (or a lead engineer/other developers deliberately wanted to prevent you from directly integrating those two applciations outside of the API layer and it's WAI).

None of these seem like "microservices are bad for agents" problems to me, just "what I'm doing was already not a good fit for microservices/I should just not do microservices anymore". Forcing integration against service boundaries that are independently built/managed is almost the entire point as far as I'm concerned

Of course there are plenty of situations where you don't need this and probably a lot of people optimize for "being able to scale independently" without understanding when they would even need that/why those two services don't even make sense to scale independently.

If your services are stateful/are being treated as persistent, IMO even more commonly than your example, you really want to make sure they're only bundled together if they directly interact at the application layer. Disk is unlike ram/cpu in that it generally increases montonically in the absence of explicit handling of its size, so if applications share disks unnecessarily you've basically made it so that each fails due to lack of disk space when any other applciation on the same disk fail, and any cleanup/management of eg pruning old data or wiping out logs or cleaning up some extra noisy/disruptive disk operation now has to be coordinate with each other application sharing those disks. Terrible situation to be in.

For stateless services the big reason you might want separable scaling is for cost-controls and operations. The problem is not necessarily that two stateless services are bundled, it's that giving permission for stateless service VeryImportantFoo to scale up aggressively also requires granting UnimportantBundledBar and all the other bundled services that same permission for aggressive scaling. If these APIs are exposed to the internet in anyway, (or if their usage patterns and availability requirements are completely different, eg one is some webhook plugin or old marketing demo and the other is your PayMeTonsOfMoney api) that's a really bad idea, because you've basically made it possible for someone to send a bunch of api requests and waste a lot of your money, or lowered your availability/scaling of your important stuff to prevent that.

Also, scaling applications independently is roughly synonymous with releasing them independently (eg keeping one truly constant and un-modified rather than rebuilding it and releasing it in the same push) which is again important if you have varying availability/reliability requirements (releasing the slack bot should not require rebuilding the main backend and pushing it again).

Let me be clear though, even though most developers think about microservices in terms of engineering considerations, these are ultimately all business requirements. If you don't need cost controls or to care about availability, or aren't worried that "kyle tried to push the slackbot and now prod is down" will happen, don't think you need to do all this stuff anyway because "it's what you should do". I'm mostly writing this because I think developers who are inexperienced or haven't used microservices before tend to not realize there are almost always business and coordination and operations problems being solved when companies (who know what they're doing) invest significant time and resources into microservices.

I have found mostly the opposite but partly the same. With the right tooling LLMs are IMO much better in microservice architectures. If you're regularly needing to do multi-repo PRs or share code between repos as they work, to me that is a sign that you weren't really "doing microservices" before adding LLMs to your project, because there should be some kind of API surface that you can share with LLMs in other repos, and cross-service changes should generally probably not be done by the same agent

Even if the same dev is driving the work, it's like having a junior engineer do a cross-service staggered release and letting them skip the well-defined existing API surfaces. The entire point of microservices is that you are making that hard/introducing friction to that stuff on purpose so things can be released and developed separately. IMO it has an easy solution too, just direct one agent per repo/service the way you would if you really did need to make that kind of change anyway and wanted to do it through junior developers.

> hey push the integration work onto another team so that developers can make it Not Their Problem

I mean yes and no, this is oftentimes completely intended from the perspective of the people making the decision to do microservices. It's a way to constrain the way people develop and coordinate with each other precisely because you don't want all 50 of your developers running amok on the entire codebase (especially when they don't know how or why that code was structured some way originally, and they aren't very skilled or conscientious in integrating things maintainably or testing existing behavior).

> so that developers can make it Not Their Problem

IMO this is partially orthogonal to the problem. Microservices doesn't necessarily mean you can't modify another team's code. IMO that is a generally pretty counter productive mindset for engineering teams where codebase is jealously guarded like that. It just means you might need to send another team a PR or coordinate with them first rather than making the change unilaterally. Or maybe you just want to release the things separately; lately I find myself wanting that more and more because past a certain size agents just turn repos into balls of mud or start re implementing things.

1. Principle of least privilege is very important if you are interacting with a large-ish number of third party APIs. It's not just about data ownership (ie one service per db) or even limiting blast radius (most likely you won't get hacked either way), it's eliminating a single point of failure that makes you a more attractive/risky target in case of a hack either directly on your infrastructure, or through a member of your team, or improperly wielding automation.

2. Having at least some level of ability ro run heterogenous workloads in your production environment (ie being able to flip a switch and do microservices if you decide to) is very useful if you need to do more complicated migrations or integrate OSS/vendor software/whip up a demo on short notice. Because oftentimes you may not want to "do microservices" ideologically or as a focal point for development, but you can easily end up in a situation where you want "a microservice", and there can be an unnecessarily large number of obstacles to doing that if you've built all your tooling and ops around the assumption of "never microservices"

3. If you're working with open source software products and infra a lot it's just way easier to eg launch a stalwart container to do email hosting than to figure out how to implement email hosting in your existing db and monolith. Also see above, if you find a good OSS project to help you do something much faster or more effectively, it's good for it to be easy to put it in prod.

4. Claude Code and less experienced or skilled developers don't understand separation of concerns. Now that agentic development is picking up, even orgs that didn't need the organizational convenience before may find themselves needing it now. Personally, this has been a major consideration in how I structure new projects once I became aware of the problem.

I believe that microservices (but under a different model than K8s et al expose) are posed to make a huge comeback soon due to agentic development. My company has been investing significantly in this direction for a while, because agents need better APIs/abstractions for execution and interaction with cloud environments.

Once Claude Code came out something new clicked with me regarding how agent coordination will actually end up working in practice. Unless you want to spend a time of time trying to prompt them into understanding separation of concerns (Claude Code specifically seems to often ignore these instructions/have conflicting default instructions), if you want to scale out agent-driven development you need to enforce separation of concerns at the repo-level.

It's basically the same problem as it was 5-10 years ago, if you have a bunch of logic that interacts with each other across "team"/knowledge/responsibility/feature boundaries, interacting with your dependencies over an API, developing in separate repos, and building + rolling out the logic separately helps enforce separation of concerns and integration around well-specified interfaces.

In an ideal world, Claude Code would not just turn every repo into a ball of mud, at least if you asked it nicely and gave it clear guidelines to follow to prevent that. That was always true with monoliths and trying to coordinate/train less experienced developers to not do the same thing when, and it turns out we didn't live in an ideal world back then so we used microservices to prevent that more structurally! History sure does rhyme.

That seems unlikely to me to be the actual explanation. It could very well be what you prefer or how you would do it, but I can definitely assure you that the Go/other infrastructure teams think about these problems and hear plenty of complaints about lack of union type support.

I’m pointing out that proto’s enums are wrappers around proto field numbers, which are numerical ids for proto message fields that enable forward/backward compatibility across proto message version changes. These field numbers are necessarily sparse but don’t even need to be assigned sequentially, and in fact, because of the leaked implementation details from the internal field number range you have to assume they are non-sequential. So field numbers are sparse, which makes them non-enumerable even though they’re represented with numeric tags.

Hence, proto enums are essentially non-enumerable wrappers around numeric values. And this is (almost certainly) why Golang’s enums are structured the same way, as transparent wrappers around values that are not necessarily sequential or enumerable.

Disagree. Enums are named for being enumerable which is not the same thing as simply having an equivalent number.

It’s incredibly useful to be able to easily iterate over all possible values of a type at runtime or otherwise handle enum types as if they are their enum value and not just a leaky wrapper around an int.

If you let an enum be any old number or make the user implement that themselves, they also have to implement the enumeration of those numbers and any optimizations that you can unlock by explicitly knowing ahead of time what all possible values of a type are and how to quickly enumerate them.

What’s a better representation: letting an enum with two values be “1245927” or “0” or maybe even a float or a string whatever the programmer wants? Or, should they be 0 and 1 or directly compiled into the program on a way that allows the programmer to only ever need to think about the enum values and not the implementation?

IMO the first approach completely defeats the purpose of an enum. It’s supposed to be a union type, not a static set of values of any type. If I want the enum to be tagged or serializable to a string that should be implemented on top of the actual enumerable type.

They’re not mutually exclusive at all, it’s just that making enums “just tags” forces you to think about their internals even if you don’t need to serialize them and doesn’t give you enumerability, so why would I even use those enums at all when a string does the same thing with less jank?

The problem is that this makes enums non-enumerable. They need to be represented as a range or union type to do that. I am pretty sure I know why/how Go ended up like this because it’s inherited behavior from proto, wrote a large comment later down the thread explaining why.