4 ms·

One big reason I always bring up and which I never ever see spoken of is reuse. Our microservices are reusable. We have lots of user-facing apps -- different w

One big reason I always bring up and which I never ever see spoken of is reuse. Our microservices are reusable. We have lots of user-facing apps -- different web sites, each with their constellation of services required -- that all use an overlapping set of microservice backends. If we have a new app, we are usually able to write it entirely as a front end. We pick and mix those backends we need. For example, we have microservices for: Identity/auth/authorization; messaging (SMS, email); image processing; geocoding and various other GIS operations; event logging; site map management; and so on. One of most important services manages data as documents, with data in Postgres and queries through ElasticSearch, with a fine-grained security system. All our apps use it, and many of the microservices are layered on top of it. With a monolithic architecture we would have been forced to write this stuff as libraries, and forced our apps to use a single language. (Our microservices are written in Go, Ruby and JavaScript.)

seanp2k2 11y ago
I mean no disrespect by this, but those things sound more like modules / libraries than services with their own infrastructure.
- lobster_johnson 11y ago
  You can be forgiven for thinking that. But these microservices require configuration and often multiple running processes. For example, our image scaling pipeline runs multiple processes per machine, all coordinated through RabbitMQ. Ideally we'd scale deployment automatically based on the number of queued-up tasks, but we don't have the infrastructure set up for that at the moment. There's also language issue, as mentioned: A library-oriented design would require everything to be written in the same language (modulo anything you can do with C bindings and such — no thanks!). We have stuff written in three different languages, and it's actually very nice to be able to do that, and not worry about language-level compatibility. For example, we are in the process of writing a completely new data backend in Go (the old one is Ruby). We have that choice because no app needs to care what it's written in. Having each microservice be its own app also forces you into a different and, in my opinion, healthier "shared nothing" mindset. You're not allowed to cheat by bypassing the API and tightly coupling yourself to the internals of the implementation, which in turn forces you to design good distributed APIs.

seanp2k2 11y ago

I mean no disrespect by this, but those things sound more like modules / libraries than services with their own infrastructure.

lobster_johnson 11y ago
You can be forgiven for thinking that. But these microservices require configuration and often multiple running processes. For example, our image scaling pipeline runs multiple processes per machine, all coordinated through RabbitMQ. Ideally we'd scale deployment automatically based on the number of queued-up tasks, but we don't have the infrastructure set up for that at the moment. There's also language issue, as mentioned: A library-oriented design would require everything to be written in the same language (modulo anything you can do with C bindings and such — no thanks!). We have stuff written in three different languages, and it's actually very nice to be able to do that, and not worry about language-level compatibility. For example, we are in the process of writing a completely new data backend in Go (the old one is Ruby). We have that choice because no app needs to care what it's written in. Having each microservice be its own app also forces you into a different and, in my opinion, healthier "shared nothing" mindset. You're not allowed to cheat by bypassing the API and tightly coupling yourself to the internals of the implementation, which in turn forces you to design good distributed APIs.