OK my #platformengineering #devops friends, I have a question about (micro)services.

Other than Uber, writing here https://www.uber.com/en-GB/blog/simplifying-developer-testing-through-slate/ I can find very little about how companies are running a lot of services & not having a horrific developer experience with the trap of "I have to run 12 things on my local machine to dev".

There are cop out answers like "use devcontainers" and "tilt.dev solves this" but there's a *lot* of complexity for non-trivial architectures.

Who's open to share?

Simplifying Developer Testing Through SLATE

Modern-day technical system deployments generally follow SOA or a microservice-based architecture that allows for clearer separation of concerns, ownership, well-defined dependencies, and abstracts out a single unit of business logic. Uber has thousands of services coordinating to power up the platform that drives the company at scale. To offer a great experience to customers, developers have to ensure that their service is meeting its functional requirements. Building confidence in meeting functional requirements requires testing of a service.

Uber Blog
Please be gentle. Helping make these things happen is part of my job and it's freaking hard and complex. Asking in public is scary. Don't be a dick.
@coldclimate spin up the full environment in kubernetes, in branch tagged namespaces, with tiny resources, urls overridden by env or service discovery, and small on demand databases. Not easy, but once it's working well... Failing that, prebuilt staging envs that was be taken over.
@coldclimate my view is that it's a double edged sword. Pretty much THE only way a developer can set up a microservice playground is to use docker compose or minikube. The only meaningful comparison in my area is with #OpenText and their flagship product Content Server. It's a middleware for document storage and workflow where the db is typically Oracle/SQL Server but now PostGRESQL as well. It runs in Windows, Linux, and now in containers in a Kubernetes cluster.
@coldclimate #OpenText
I have done the set up for Kubernetes in a Google Cloud a few times. Overall what I've noticed is that the admin is now an order of magnitude harder for clients because whereas before, you could easily access logs, now you need to talk to your Kubernetes guy who knows nothing about Content Server. Perhaps though this is a lesson about legacy applications should be left as monoliths. Microservice architecture is best suited to net new applications in my view.
@coldclimate #OpenText I do have one IM-ish issue with the MS architecture, and that is this notion of each service having its own local copy of the data. To me, this violates the principle of single source of truth. If you have a microservice app with multiple services, supposedly a massive advantage is that the site can at least partially function even if one of the services is down. That's a double edged sword.....
@coldclimate #OpenText ... If one part is not functioning, is there any value in keeping the rest of the site up? I've seen web sites where the site responds but some functionality is broken. Do you want your site being used if a critical part is not working, or is it better to disable all access until everything is fixed?
@hfinyow I have thoughts here but I'm just back from swimming and shattered. Reply I the morning.
@hfinyow were blessed to be reasonably new but grow crazy fast, so we're playing catch up in some areas.
@coldclimate I know Monzo like to chat about how they run like 1500 micro services. https://monzo.com/blog/2022/06/24/redefining-our-microservice-development-process this kinda cover some I think?
Redefining our microservice development process

Monzo
@seanhood ohhh, that's good. I thought they had written about it but couldn't find it

@coldclimate I think the only thing I’ve seen is Docker Compose bringing up everything (or most things), or a shared dev environment where you’re hitting “live” services.

I’ve worked with a load of clients with both setups and I dunno, seems bad, mostly.

@coldclimate IMO _every_ service (from a micro- you coded in-house to DBs to tracing etc) must have an in-memory version, or at least a one-liner to start up a simple dev instance.

On top of that, the vast majority of tests must be func tests for that service, never the ones it calls. Keep orchestrated integration tests to a minimum.

Fail to do these well and half your dev salaries go to waiting on builds.