4 ms·

It might depend a bit on how you scope it, too. I once worked at a company where a team of 3 produced way more than 25 microservices. But the trick was, they w

It might depend a bit on how you scope it, too. I once worked at a company where a team of 3 produced way more than 25 microservices. But the trick was, they were all running off the same binary, just with slightly different configurations. Doing it that way gave the ops team the ability to isolate different business processes that relied on that functionality, in order to limit the scale of outages. Canary releases, too. It's 3 developers in charge of 25 different services all talking to each other over REST that sounds awful to me. What's that even getting you? Maybe if you're the kind of person who thinks that double-checking HTTP status codes and validating JSON is actually fun...

twic 8y ago
I've done that a couple of times. It's a good pattern! I worked on an e-commerce site a decade ago where the process types were: 1. Customer-facing web app 2. CMS for merchandising staff 3. Scheduled jobs worker 4. Feed handler for inventory updates 5. Distributed lock manager 6. Distributed cache manager We had two binary artifacts - one for the CMS, one for everything else - and they were all built from a single codebase. The CMS was different because we compiled in masses of third-party framework code for the CMS. Each process type ran with different config which enabled and configured the relevant subsystems on as needed. I'm not sure to what extent we even really needed to do that: the scheduled jobs and inventory feed workers could safely have run the customer app as well, as long as the front-end proxies never routed traffic to them.
- NicoJuicy 8y ago
  Looks like a service oriented architecture to me
dtech 8y ago
I work on an application like that. Not 3:25 but not that far off either. I'm quite content with the situation. The apps all handle a bespoke data connection, converting it into a standard model which they submit to our message broker. From then on our services are much larger and smaller in number. It's very write-once-run-forever, some of these have not been touched since their inception years ago, resulting in a decreased complexity and maintenance cost. The trick is not having REST calls all over yours services. You're just building a distributed monolith at that point.
xirdstl 8y ago
Why does it happen? Consultants, buzzwords, $$
sbov 8y ago
It really depends upon what those 25 different services are. If they are trivial to separate sure. Like an image resizing microservice, an email sending microservice, and so on. I mean go wild, these are trivial. Coincidentally, when people like to talk about how easy microservices are, they love to talk about these trivial examples. What isn't trivial is when someone decides to make an Order microservice and an Account microservice when there's a business rule where both accounts and orders can only co-exist. Good fucking luck with 3 developers, I'm pretty sure with a team of 3 in charge of 23 other microservices you aren't exhaustively testing inter-microservice race conditions.
- jacquesm 8y ago
  Or better yet: a massive front end SPA talking to an array of stupid microservices that are not much more than tables with web accessible endpoints for CRUD and probably an authentication service thrown in for good measure. All of the business logic on the JS side of things. The worst of both worlds, now you have a monolith and a microservices based architecture with the advantages of neither.
tabs_masterrace 8y ago
Last startup I've been part of, we've been having a bit of fun building our server architecture in Swift and so far the One-Binary-Many-Services model has been working out pretty well. You can run it all on single machine, you can have debug hooks, that make it seem like a Monolith, or scale it out if need be. When it comes down to it the Authentication Service really doesn't need to know about the Image Upload Service, and splitting it is all about defining good interfaces. Just need to put some effort in to keep your development environment sane.
kaidax 8y ago
We recently gave a name to that One-Binary-Many-Services approach - Roles. https://github.com/7mind/slides/raw/master/02-roles/target/roles.pdf https://github.com/7mind/slides/raw/master/02-roles/target/r...
- bunderbunder 8y ago
  This wasn't actually that. All of them did the same job, just that one did it for widgets for the widget-handling team, and another did it for whatsits for the whatsit-handling team, and another did it for both widgets and whatsits for the reporting system, etc. etc.
cableshaft 8y ago
I'm kind of dealing with your awful scenario right now. It is pretty bad. What happened was the department used to be a lot, lot larger, and people tended to only have to deal with 7 or 8 of them at a time (it was still excessive, I often had difficulty debugging and keeping things straight for tasks) but after two years layoffs, other employees quitting, and executives pulling our employees into other departments, we're a tiny shell of what we used to be, and we still have to manage all of those microservices, and it's so difficult. I've been daydreaming about monoliths and will be asking at interviews for my next job hoping to find more simplified systems. I came from the game industry originally, where you only have one project for the game and one more for the webservice if it had one, and maybe a few others for tools that help support the game.

twic 8y ago

I've done that a couple of times. It's a good pattern! I worked on an e-commerce site a decade ago where the process types were: 1. Customer-facing web app 2. CMS for merchandising staff 3. Scheduled jobs worker 4. Feed handler for inventory updates 5. Distributed lock manager 6. Distributed cache manager We had two binary artifacts - one for the CMS, one for everything else - and they were all built from a single codebase. The CMS was different because we compiled in masses of third-party framework code for the CMS. Each process type ran with different config which enabled and configured the relevant subsystems on as needed. I'm not sure to what extent we even really needed to do that: the scheduled jobs and inventory feed workers could safely have run the customer app as well, as long as the front-end proxies never routed traffic to them.

NicoJuicy 8y ago
Looks like a service oriented architecture to me

dtech 8y ago

I work on an application like that. Not 3:25 but not that far off either. I'm quite content with the situation. The apps all handle a bespoke data connection, converting it into a standard model which they submit to our message broker. From then on our services are much larger and smaller in number. It's very write-once-run-forever, some of these have not been touched since their inception years ago, resulting in a decreased complexity and maintenance cost. The trick is not having REST calls all over yours services. You're just building a distributed monolith at that point.

xirdstl 8y ago

Why does it happen? Consultants, buzzwords, $$

sbov 8y ago

It really depends upon what those 25 different services are. If they are trivial to separate sure. Like an image resizing microservice, an email sending microservice, and so on. I mean go wild, these are trivial. Coincidentally, when people like to talk about how easy microservices are, they love to talk about these trivial examples. What isn't trivial is when someone decides to make an Order microservice and an Account microservice when there's a business rule where both accounts and orders can only co-exist. Good fucking luck with 3 developers, I'm pretty sure with a team of 3 in charge of 23 other microservices you aren't exhaustively testing inter-microservice race conditions.

jacquesm 8y ago
Or better yet: a massive front end SPA talking to an array of stupid microservices that are not much more than tables with web accessible endpoints for CRUD and probably an authentication service thrown in for good measure. All of the business logic on the JS side of things. The worst of both worlds, now you have a monolith and a microservices based architecture with the advantages of neither.

tabs_masterrace 8y ago

Last startup I've been part of, we've been having a bit of fun building our server architecture in Swift and so far the One-Binary-Many-Services model has been working out pretty well. You can run it all on single machine, you can have debug hooks, that make it seem like a Monolith, or scale it out if need be. When it comes down to it the Authentication Service really doesn't need to know about the Image Upload Service, and splitting it is all about defining good interfaces. Just need to put some effort in to keep your development environment sane.

kaidax 8y ago

We recently gave a name to that One-Binary-Many-Services approach - Roles. https://github.com/7mind/slides/raw/master/02-roles/target/roles.pdf https://github.com/7mind/slides/raw/master/02-roles/target/r...

bunderbunder 8y ago
This wasn't actually that. All of them did the same job, just that one did it for widgets for the widget-handling team, and another did it for whatsits for the whatsit-handling team, and another did it for both widgets and whatsits for the reporting system, etc. etc.

cableshaft 8y ago

I'm kind of dealing with your awful scenario right now. It is pretty bad. What happened was the department used to be a lot, lot larger, and people tended to only have to deal with 7 or 8 of them at a time (it was still excessive, I often had difficulty debugging and keeping things straight for tasks) but after two years layoffs, other employees quitting, and executives pulling our employees into other departments, we're a tiny shell of what we used to be, and we still have to manage all of those microservices, and it's so difficult. I've been daydreaming about monoliths and will be asking at interviews for my next job hoping to find more simplified systems. I came from the game industry originally, where you only have one project for the game and one more for the webservice if it had one, and maybe a few others for tools that help support the game.