ledneb

Assuming serverless is out if the question for your use case, have you tried spending a couple of days investigating a managed Kubernetes cluster with node autoscaling enabled? EKS, AKS, GKE...

Honestly it sounds like you could be at the point where K8s is worthwhile.

What syntax did Go settle on, in the end?

How hyperbolic. I'm struggling to imagine what you may have experienced, exactly, to put discussing such issues in the UK alongside discussing Tiannamen Square in China.

I sometimes give feedback, but only if requested and, to be honest, only if the feedback request actually makes it through HR and to me.

What feels like a lifetime ago I went for an interview at Monzo, I think it'd recently renamed from Mondo. I thoroughly enjoyed the process - a kind yet thorough and revealing interview format. I didn't get the job - but it's not an exaggeration to say their feedback and the process changed my career. If somebody from there spots this; thanks :) (and I'm still sad I didn't get to work with you!)

I love it when I'm in a city with Citymapper. I've used it to get around Paris, Hamburg and Berlin. It's slick, fun to use and has nailed multi-modal transport - especially since it considers walking a thing which humans are capable of.

I still resort to instructional YouTube videos + ticket machines for tickets, though.

So, in a monorepo world, isn't it often that you have to deploy components together, rather than "it's easy to"? How are services deployed only when there has been a change affecting said service? Presumably monorepo orgs aren't redeploying their entire infrastructure each time there's a commit? Are we taking writing scripts which trigger further pipelines if they detect change in a path or its dependencies? How about versioning - does monorepo work with semver? Does it break git tags given you have to tag everything?

So many questions, but they're all about identifying change and only deploying change...

Microsoft have been pushing this kind of thinking for a while with Service Fabric. If you buy in completely and use both the framework and the infrastructure you get structures which are in-memory and replicated for you.

A couple of the .Net guys we hired preached that stateless architecture is a little old-fashioned - over time I've come to agree. A lot of things can be shoe-horned in to a stateless world but become much easier in a stateful one.

> Imagine sending out a command to the bus and not knowing when it'll get processed

I would love to hear how others are correlating output with commands in such architectures - especially if they can be displayed to users as a direct result of a command. Always felt like I'm missing a thing or two.

It seems the choices are:

* Manage work across domains (sagas, two phase commit, rpc)

* Losen requirements (At some point in the future, stuff might happen. It may not be related to your command. Deal with it.)

* Correlation and SLAs (correlate outcomes with commands, have clients wait a fixed period while collecting correlating outcomes)

Is that a fair summary of where we can go? Any recommended reading?

I discovered Chocolatey during a Windows stint at work ~3 years back and found their package quality to be very poor. I'd go as far as saying packages had a 50% chance of leaving you with a usable installation of software.

We ended up changing provisioning scripts to download .msi installers directly and run them with appropriate switches.

I also remember their website having a lot of "maintainers required" notices - I got the impression that the situation was a little desperate.

Has package quality improved? Is Chocolatey a genuinely reliable way to install software, now?

You wrote a great response! Assuming you genuinely want feedback on it; your writing style does detract a bit from what you're saying - the emphasis and braces don't read like native English. My advice is try not to use quotes, italics and braces at all - go cold turkey! Then you'll probably find yourself using them when you actually _need_ them. :)