Continuing me research around #microservice #devex does anybody know how https://monzo.com/blog/2022/06/24/redefining-our-microservice-development-process/ worked out at Monzo? 2 year old post, nothing since directly related.

I think I'll thread my research here

Redefining our microservice development process

Monzo
In 2021 Lyft wrote a series of blogposts starting with https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-1-a2f5d9a77813 that document what feels like a very common story.
Decomposed #monolith, initially doing "all services on one box", finding the issues with that and then evolving to an #EnvoyProxy mesh setup.
This feels very simlar to Uber's SLATE (https://www.uber.com/en-GB/blog/simplifying-developer-testing-through-slate/), but hooking into staging not production
Scaling productivity on microservices at Lyft (Part 1)

Late in 2018, Lyft engineering completed decomposing our original PHP monolith into a collection of Python and Go microservices. A few years down the road, microservices had been largely successful…

Lyft Engineering

This post from the Canva engineering team in 2015 would have felt so bleeding edge if I read it then https://www.canva.dev/blog/engineering/standardizing-the-development-environment/

Some interesting notes on tooling for building "all on one box" setups.

Standardizing the development environment - Canva Engineering Blog

How we've built a Standard Development Environment (SDE).

canva.dev
@coldclimate Do you already have a lot of microservices and are trying to wrangle them, or are you looking at starting to build a lot of microservices?
@jonty we have 30 and I want to wrestle it into a good devex before hellscape emerges more
@coldclimate You should simultaneously push back on adding more, and consolidate into chunkier services. Actual "micro" services are a really *really* bad idea for almost everyone.
@coldclimate Also, you already need tracing more than you realise.
@jonty I often talk about "chonky services" rather than "microservices"