6 ms·

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

by aidos 6y ago

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.

reissbaker 6y ago
I'm not the OP, but I can give you some examples from when I worked at Airbnb a few years ago: * 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.
closeparen 6y ago
Without being too specific, the gateways I have in the codebases in front of me: Data: - Canonical data repositories for each of: order, transaction, customer, feedback, geography, privacy opt-in/out. - Hadoop SQL facade. - Support contact analytical service for a particular type of issue. Business operations: - Core order fulfillment service (orders populate into repository when complete). - Support contact operational services: ingestion, routing, and auto-resolution. Product infrastructure: - Machine learning model serving engine. - Map drawing service. - Translations service. - Dynamic configuration service. - A/B test service. - Server-Sent-Events hub service for our mobile apps. - Facades for each of: voice, SMS, mobile native pushes, email. - Marketing campaign service (dumber but more convenient facade to the previous). Basic infrastructure: - Column store. - Secrets service. - Cache service. - Blob storage service. - Workflow engine. - Timer service (technically a subset of a workflow engine). - Message queue. Each one of these is backed by a team of 2-10 people. I have been inside 2 or 3 of them to fix bugs that affected me.

by aidos 6y ago

reissbaker 6y ago

I'm not the OP, but I can give you some examples from when I worked at Airbnb a few years ago: * 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.

closeparen 6y ago

Without being too specific, the gateways I have in the codebases in front of me: Data: - Canonical data repositories for each of: order, transaction, customer, feedback, geography, privacy opt-in/out. - Hadoop SQL facade. - Support contact analytical service for a particular type of issue. Business operations: - Core order fulfillment service (orders populate into repository when complete). - Support contact operational services: ingestion, routing, and auto-resolution. Product infrastructure: - Machine learning model serving engine. - Map drawing service. - Translations service. - Dynamic configuration service. - A/B test service. - Server-Sent-Events hub service for our mobile apps. - Facades for each of: voice, SMS, mobile native pushes, email. - Marketing campaign service (dumber but more convenient facade to the previous). Basic infrastructure: - Column store. - Secrets service. - Cache service. - Blob storage service. - Workflow engine. - Timer service (technically a subset of a workflow engine). - Message queue. Each one of these is backed by a team of 2-10 people. I have been inside 2 or 3 of them to fix bugs that affected me.