Earlier quoted context omitted.
I work in a large microservices environment. It’s very important that IDEs don’t make it easy to reach inside other services. The whole point is to create cognitive barriers at the public APIs. The pain of coordinating changes across services is a feature: it is telling you that your architecture is wrong.
And what qualifies as a micro service in your environment? Can you give a few examples? How many people work on each micro service? Etc etc. Would love to hear more details so I can build a better mental picture.
* Each team (let's call it eight engineers per team on average) typically managed a few services.
* Services were typically ~thousands of lines of code to ~tens of thousands. Rarely, there were very small services that were hundreds of lines of code. There was a giant service -- the original Rails app -- called "Monorail" that had millions of lines of code, but was actively being dismantled. My understanding is that there is now a code freeze on Monorail, and the only changes allowed are changes that remove code from it and move it to a smaller service (either an existing one or a new one).
* Services communicated with each other over HTTP or Kafka, typically using Thrift, although also sometimes using JSON. Airbnb had an in-house "service mesh" (developed before the term service mesh existed) that abstracted away individual machines and was capable of operating at the HTTP or TCP layer.
A few classic examples of mostly-single-responsibility services:
* Prometheus (which I wrote) abstracted away reverse geocoding and correctly caching and manipulating results from geocoder APIs.
* Medusa abstracted away ranking and filtering listings by date/amenities/etc.
* Micasa abstracted away basic CRUD operations on individual listings.
Airbnb intentionally used codenames for services rather than calling them by what they did, which I wasn't a huge fan of; I forget most of the codenames now (and hardly anyone knew all of the codenames offhand even at the time). Some other example without the cute names were the pricing recommendation service (used to recommend prices to new hosts), the calendar management service, the experience CRUD service, etc.