11 ms·

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.

ohyes 9y ago
Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.
- st3fan 9y ago
  Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.
  - HelloMcFly 9y ago
    I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.
    - foo101 9y ago
      I think the context is pretty clear: microservices. If it takes 10 people to manage one service, it is not a microservice by definition. It is more like a 10x-microservice or a macroservice.
      - JamesBarney 9y ago
        While 10 is more than many recommend it's not that much more than Amazon's rule of < 7.
      - zimpenfish 9y ago
        I suppose it depends if those 10 people are purely developers or include the other teams you'd need - monitoring, devops, etc. For a critical, high-performance microservice, I can easily see it needing the involvement of 2+ devs (at least one senior), product owner, project manager, QA, devops, monitoring, etc.
      - bonesss 9y ago
        It's not the number of people that are micro, it's the scope of the service... So what is the right level of manpower for a scoped service with unspecified operational demands? Unknowable. The definition isn't small teams, per se, it's a small area of responsibility with singular focus. A lego block instead of duplo. That lends itself very well to small teams, but you could reasonably have 100 people working on a service and call it "micro". Reason being: if those 100 people weren't working on their scoped 'microservice' they would be part of a much, much, much larger pool working on the shared 'product', 'platform', or 'service' that contains that exact same functionality, only without the clarity/scalability of application boundaries surrounding the individual service components. That's not to say microservices are ideal, just that the size of "micro" is highly relative to ongoing operations.
    - Clubber 9y ago
      10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?
      - jblow 9y ago
        How micro can it possibly be if it takes 10 people to deal with it? Seriously.
        BatFastard 9y ago
        Cause it's not very micro?
        deleted 9y ago
        [deleted]
        sbov 9y ago
        The scope of a microservice is commonly a bounded context in DDD. So depending upon the problem you might be talking about a lot of code.
        snowwrestler 9y ago
        If "micro" refers to the scope of the service (i.e. very limited feature set), you might still need a team to run it, if the service has to handle a very high volume of transactions or provide very low latency, or both.
        sameline 9y ago
        It’s not unreasonable to imagine that any of the examples provided in the source post could require a team larger than 10 people.
        bonesss 9y ago
        "Micro" in this case relates to the services scope, not its operational footprint. So if Netflix has a "User logon" service, and a "payment processing" service, used across their clients clients you might be looking at a couple of "microservice"s with hundreds of related employees. Imagine services for Googles search autocomplete, ML, or analytics... As the article states the "micro" aspect is mostly in terms of deployment responsibility, freeing those 10-1000 employees from thinking about the totality of Googles/Netflixes' operations before rolling out a patch :)
    - jiggunjer 9y ago
      I think he is literally asking for the other perspective? "I run 8 services myself" can be read as arrogant, OR it can be read as "I do things very differently", which is how I read it initially.
      - ohyes 9y ago
        That’s how I meant it, that the advantage of microservices is bite size pieces of work, so 10 people on the same service sounds like they’d step on each other’s toes. I run a bunch of services but they’re each debugged enough to be fairly low maintenance and small enough that the edges are well defined. It’s 8 or so but it’s possible for me to handle it all. If we add features they’re going to be new services, so adding big features to the services I manage is unlikely. It is more likely that I get a new service on my plate in 6 months time than getting additional members of the engineering team to work on already completed services. I’m obviously not entirely alone... I’ll ask for help if I need it, and I help out with other people’s stuff too, but I am primarily in charge of them and I am responsible for keeping everything working well.
  - adbachman 9y ago
    Because it's not a "valid argument", it's snark. The contempt is unnecessary and uninformed.
    - ohyes 9y ago
      It’s not snark, it’s also not any argument. It’s genuine incredulity. I seriously cannot imagine the situation where 10 people work on the same minimal function piece of code.
- always_good 9y ago
  Well, I've also worked for places where I'm on call for some service maintained by one person that's built their little impregnable abstraction castle because nobody else had to work on it so they could just yak-shave and bike-shed with their self. These days I kinda wince at "I run 8 services myself."
  - jblow 9y ago
    Those of us who have been around since the 80s-90s are astonished by the low productivity of today's programmers. If it takes 1 person to run 1 microservice, we are all doomed.
    - spraak 9y ago
      You really think that the productivity of today's programmers is less? What evidence and data do you have for that?
      - eggsqqq 9y ago
        You must be the life of every party.
      - nurettin 9y ago
        Warning: all anecdotes. While I don't think that productivity has decreased, what was notepad, a compiler, some dlls and a debugger before turned into a thousand little packages, several configuration files, a bunch of servers you have to run on your dev. computer, which is also 10x more capable, yet everything feels so sluggish. I also feel that ceteris paribus, the meetings got longer, project management tools now consume a lot of input from programmers, and I need to communicate with a lot more people to get something done.
        mauritzio 9y ago
        Sounds for me like productivity went down...
- anfedorov 9y ago
  That's nothing. I once ran 20 services before breakfast.
  - paulddraper 9y ago
    Well, my pre-breakfast routine consists of seq 21 | while read port; do python2 -m SimpleHTTPServer 80$port & done
    - majewsky 9y ago
      seq 21 | while read port; do python3 -m http.server 80$port & done FTFY
- nstj 9y ago
  Putting the I back in Microservices :)
- NicoJuicy 9y ago
  I have a web app with a "file store" ( eg. simple dropbox over API) that i manage. I haven't touched it in a year and it uploads files, proxies them, resizes, ... And it's just one of many.
- isaacremuant 9y ago
  I get both why people downvoted you and why people defended you. One developer can certainly be responsible for coding many microservices and even maintaining them depending on the scope, number of users, etc. Sometimes people might even rotate with a core architect coordinating how they all interact and if they are consistent with each other. Discussing about microservices can be very confusing if people are thinking about different things and, as always, when there's a good idea implemented in a specific context and people who don't use it get exposed to it as a silver bullet we'll end up with a huge backlash like in this article.
- hajile 9y ago
  Real-world business servers are complicated even when you tease apart the different elements.
zenonu 9y ago
The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lookup, etc. should all be "out-of-the-box" before microservices should ever be considered. Otherwise the O(n) gains you get in modularity turn into O(n) FML.
- charlieflowers 9y ago
  Would love to hear some peoples' thoughts on good contenders in each of these areas. What are some good boxes to get these out of in 2018?
  - antonp 9y ago
    Would like to echo this request. Had to implement a micro-service architecture in python about a year ago and was jealous of my Java colleagues who (so I heard) have great ecosystem for enterprise service discovery, messaging etc.
    - ivan_gammel 9y ago
      Yes, we do. The ecosystem is great and microservice architecture may be manageable even in small teams, but it's always a process that defines the success. From my own experience, the biggest technical problem of microservices in Java can be the performance of the whole system (in a monolith there's much less logging and state management, no network latencies and mismatching parallelism settings). Discovery, auth, messaging, configuration management etc are solved.
  - sametmax 9y ago
    Crossbar.io is currently an interesting approach IMO. It does have a single point of failure that is also a bottleneck (the router) and it's a lot of work to load balance / failover it. But other than that, it provides a fantastic way to make microservices: - anything is a client of the crossbar router. Your server code is a client. The db can be a client. The web page JS code is a client. And they all talk to each others. - A client can expose any function to be called remotely by giving it a name. Another client can call this function by simply providing the name. Clients don't need to know each others. Routed RPC completly decoupled the clients from each others. - A client can subscribe to a topic at any time and be notified when anothe client publishes a message on that topic. Quick, easy and powerful PUB/SUB with wildcard. - A client can be written in JS (node and browser), Python, C#, Java, PHP, etc. Clients from other languages can talk to each others transparently. They all just receive JSON/msgpack/whatever and error are propagated and turn into the native language error handling mechanisme transparently. - The API is pretty simple. If you tried SOAP or CORBA before, this is way, way, way simpler. It feels more like using redis. - It uses websockets, which mean it works anywhere HTTP works. Including a web page or behind a NAT or with TLS. - Everything is async. The router handles 6000 msg / s to 1000 clients on a small Raspberry Pi. - The router can act as a process manager and even a static / wsgi web server. - you can load balance any clients, hot swap them, ban them, get meta event about the whole system, etc. - you can asign clients permissions, authentications, etc. Sessions are attached to each connexion, so clients knows what other clients can do.
brandonbloom 9y ago
I agree that it's _easier_ for teams to have their own little fiefdoms, but not necessarily _better_. Shipping the org-chart is often a symptom of a leadership problem. When natural service boundaries exist, good leadership may choose to ship the org-chart, but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture.
- bmer 9y ago
  > ...but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture. hahaha Do you know if there are some well chronicled cases of this happening? I find it very believable, but you know, would love to read something "actual".
  - quodlibetor 9y ago
    I believe this is a paraphrase of Conway's law. The Wikipedia article lists three studies in favor of it, so there's that. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
  - woolvalley 9y ago
    Just go work somewhere that is big enough for that to happen. Usually large tech cos with the amount of devs larger than dunbars number by about 2x or greater.
  - bonesss 9y ago
    [Disclaimer: I've never worked for MS or Amazon, working solely off of reported info here...] A kinda-random example off the top of my head of "shipping the org chart" would be the historical gaps between Windows, Development, and Office at Microsoft. Ie Office is getting a new ribbon, but no development can't supply those icons or any components because they're an "office thing", or the internal API/VBA battles along the same lines. On the opposite side, as reported in the press, Amazon has used this effect to create manageable teams and build up their own SOA: the two-pizza rule for teams means that teams can only really make targeted self-contained services. In this case Amazon worked backwards and re-structured their teams so that 'shipping their org chart' created the desired architecture.
beamatronic 9y ago
What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.
- bigiain 9y ago
  Premature optimisation... YAGNI is almost always the right approach.
  - scarface74 9y ago
    I don't think you should always go with a microservice approach first, but you should always separate different domains/features into well defined modules/projects even within a monolith. There have been plenty of times where I've taken a project out of a monolith and created a separate shippable package to be consumed by another monolith in a separate repo. There were also occasions where I had to rip out a feature in a monolithic API that either needed to scale independently or be released independently and then just created a facade in the originally API that proxies the "microservice".
    - bigiain 9y ago
      Completely agree. I mostly tell my people "We aren't going to do that yet - or possibly ever - but keep in mind that we might have to if we ever win the user growth hockey-stick graph lottery, so when choosing between options of how to architect things, prefer very narrow focus that _could_ be pulled apart into microservices more easily if practical" I've also been known to stand up duplicated instances on a monolith with path routing on the load balancer as a "pretend microservices" scaling or upgrade trick.
- bonesss 9y ago
  Those growth points, and their associated market knowledge and budgetary constraints, would become perfect transition points into a friendlier architecture for the team... Plan for change, moreso than trying to plan against change. Decomposing and fragmenting an established service into smaller clones of itself should be reasonably straightforward. In most languages with a component story (ie java), library reuse across microservices should make your service architecture orthogonal to your application logic. This kind of approach also eases a lot of pain of cross-service issues.
mgkimsal 9y ago
> When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain. Faced this a couple of years ago, and I was the lone dissenting voice suggesting this was not going to go well. Then I learned that "microservice" in reality just meant everything was going to be one nodejs process running endpoints, with ios and android clients hitting it, which... didn't really fit my understanding of "microservice"; that's just "service".
- asfdsfggtfd 9y ago
  If you are slightly careful and put this service behind a load-balancer/reverse-proxy you can take any given set of end points and turn them into a micro-service when you need to. Sounds perfect for a small team.
  - mgkimsal 9y ago
    you could. in this particular case, if memory serves, we had an existing set of endpoints functioning, but people deemed it in need of rewrite to node, because 'microservice'. Instead of putting the code we had behind proxy then migrating, we had to start over. because 'scale' and 'microservice'. and 'lambda'. Also, the same team spent several hours in meetings deciding whether or not to allow email signup, or facebook signup, or both, or neither, in the mobile app. Then had the same discussions/arguments a few weeks later when a couple new people joined the team. I realize I sound a bit bitter. I got pushback because I'd used the 'microservice api' in a "we don't like that" language. consuming the api (which I'd understood to be part of the reason of having a central API vs just hitting db tables directly) by anything that wasn't also node was outside the groupthink, and caused problems. I left the project. They've got their microservice architecture, but no userbase (yet?) to be concerned about scaling issues. I understand it's reasonable to be concerned about potential scaling problems, the team/project spent far too much time chasing architectural perfection (and really... 'shiny new stuff') vs executing a marketing plan. It's easier for a group that is tech-folk-heavy to focus on that; I get it. But it didn't solve any problems at hand. But when the mythical "2 million users in an hour" problem happens, it'll probably hold up, unless it doesn't.
pjmlp 9y ago
They can manage those teams by writing libraries, no need for microservices.
- ivan_gammel 9y ago
  It's much harder to deploy a library fix to production (producing a new build of integrated app in large team is a big deal), than a microservice.
  - McP 9y ago
    It shouldn't be a big deal. https://en.wikipedia.org/wiki/Continuous_delivery https://en.wikipedia.org/wiki/Continuous_delivery
    - sokoloff 9y ago
      It shouldn't, but in practice sometimes is. It's not the pushing of bits that's hard; it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs. Imagine you have a library that implements the serialization and deserialization of something in your system (or anything else where the library implements two "halves" of some functionality). You might (or might not, depending on the change) need to push out that library to other apps to effect the fix you're working on. That new proposed library change may be in a queue behind another pending change that's in development, etc.
      - marcosdumay 9y ago
        > it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs. And guess what, you have to do the same thing with microservices. You must ensure that all its clients are pointing to the correct version, and you must ensure that the new version didn't add any bugs in the clients. Adaptations for new service versions will also get into the release queue, and can also get blocked by other stuff.
  - 9y ago
scarface74 9y ago
I'm the dev lead for a largish company with a small development shop 4-9 people (contractors come and go). I went for a microservice like hub and spoke model where a bunch of small services integrate with a central Mongo database where all of the CRUD is managed via an API and validation is done via the API. Also cross cutting concerns like configuration (a wrapper around Consul), logging (structured logging via Serilog), and job scheduling (Nomad) is done via a common package. I chose this approach because the developers who were already there were relatively new to C#, and I knew we were going to have to ramp up contractors relatively fast. Our dev ops process revolves around creating build and release processes by simply cloning an existing build and release pipeline in Visual Studio Team Services - the hosted version of Team Foundation Services - and changing a variable. Every service is a separate repo. Each dev is responsible for releasing their own service. The advantages: 1. All green field development for a new dev. They always start with an empty repo when creating a new service. 2. Maintenance is easier. You know going in all you have to do is use a few documented Postman calls to run your program if you need to make changes. Also, it's easy to see what the program does and if you make a mistake, it doesn't affect too many other people if you keep the interface the same. 3. The release process is fast. Once we get the necessary approvals, we can log on to VSTS from anywhere and press a button. 4. Bad code doesn't infest the entire system. The permanent junior employees are getting better by the month and we are all learning what works and doesn't work as we build out the system. Each service is taking our lessons learned into account. We aren't forced to keep living with bad decisions we made earlier and building on top of it. A microservice strategy only works if you have the support system around it. In our case, an easy to use continuous integration, continuous deployment system (VSTS), easy configuration (Consul), service discovery and recovery (Consul with watches), automated unit and integration tests, a method to standardize cross cutting concerns And finally, Hashicorp's Nomad has been a god send for orchestration. Our "services" are really just a bunch of apps. Nomad works with shell scripts, batch files, Docker containers, and raw executables. It was much easier to set up and configure than kubernetes.

ohyes 9y ago

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

st3fan 9y ago
Why was this downvoted? I think this is a valid argument. There are plenty of small teams or individuals who have been managing a bunch of small services. Before this was called microservices.
- HelloMcFly 9y ago
  I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.
  - foo101 9y ago
    I think the context is pretty clear: microservices. If it takes 10 people to manage one service, it is not a microservice by definition. It is more like a 10x-microservice or a macroservice.
    - JamesBarney 9y ago
      While 10 is more than many recommend it's not that much more than Amazon's rule of < 7.
    - zimpenfish 9y ago
      I suppose it depends if those 10 people are purely developers or include the other teams you'd need - monitoring, devops, etc. For a critical, high-performance microservice, I can easily see it needing the involvement of 2+ devs (at least one senior), product owner, project manager, QA, devops, monitoring, etc.
    - bonesss 9y ago
      It's not the number of people that are micro, it's the scope of the service... So what is the right level of manpower for a scoped service with unspecified operational demands? Unknowable. The definition isn't small teams, per se, it's a small area of responsibility with singular focus. A lego block instead of duplo. That lends itself very well to small teams, but you could reasonably have 100 people working on a service and call it "micro". Reason being: if those 100 people weren't working on their scoped 'microservice' they would be part of a much, much, much larger pool working on the shared 'product', 'platform', or 'service' that contains that exact same functionality, only without the clarity/scalability of application boundaries surrounding the individual service components. That's not to say microservices are ideal, just that the size of "micro" is highly relative to ongoing operations.
  - Clubber 9y ago
    10 people managing a single "micro service" does raise a red flag to me as well. It may be normal based on the complexity, but my first thought is, why is the codebase require so many people to maintain and add features to? Are they just adding features like mad, or something squirrelly in there where most modifications take a lot of man hours?
    - jblow 9y ago
      How micro can it possibly be if it takes 10 people to deal with it? Seriously.
      - BatFastard 9y ago
        Cause it's not very micro?
      - deleted 9y ago
        [deleted]
      - sbov 9y ago
        The scope of a microservice is commonly a bounded context in DDD. So depending upon the problem you might be talking about a lot of code.
      - snowwrestler 9y ago
        If "micro" refers to the scope of the service (i.e. very limited feature set), you might still need a team to run it, if the service has to handle a very high volume of transactions or provide very low latency, or both.
      - sameline 9y ago
        It’s not unreasonable to imagine that any of the examples provided in the source post could require a team larger than 10 people.
      - bonesss 9y ago
        "Micro" in this case relates to the services scope, not its operational footprint. So if Netflix has a "User logon" service, and a "payment processing" service, used across their clients clients you might be looking at a couple of "microservice"s with hundreds of related employees. Imagine services for Googles search autocomplete, ML, or analytics... As the article states the "micro" aspect is mostly in terms of deployment responsibility, freeing those 10-1000 employees from thinking about the totality of Googles/Netflixes' operations before rolling out a patch :)
  - jiggunjer 9y ago
    I think he is literally asking for the other perspective? "I run 8 services myself" can be read as arrogant, OR it can be read as "I do things very differently", which is how I read it initially.
    - ohyes 9y ago
      That’s how I meant it, that the advantage of microservices is bite size pieces of work, so 10 people on the same service sounds like they’d step on each other’s toes. I run a bunch of services but they’re each debugged enough to be fairly low maintenance and small enough that the edges are well defined. It’s 8 or so but it’s possible for me to handle it all. If we add features they’re going to be new services, so adding big features to the services I manage is unlikely. It is more likely that I get a new service on my plate in 6 months time than getting additional members of the engineering team to work on already completed services. I’m obviously not entirely alone... I’ll ask for help if I need it, and I help out with other people’s stuff too, but I am primarily in charge of them and I am responsible for keeping everything working well.
- adbachman 9y ago
  Because it's not a "valid argument", it's snark. The contempt is unnecessary and uninformed.
  - ohyes 9y ago
    It’s not snark, it’s also not any argument. It’s genuine incredulity. I seriously cannot imagine the situation where 10 people work on the same minimal function piece of code.
always_good 9y ago
Well, I've also worked for places where I'm on call for some service maintained by one person that's built their little impregnable abstraction castle because nobody else had to work on it so they could just yak-shave and bike-shed with their self. These days I kinda wince at "I run 8 services myself."
- jblow 9y ago
  Those of us who have been around since the 80s-90s are astonished by the low productivity of today's programmers. If it takes 1 person to run 1 microservice, we are all doomed.
  - spraak 9y ago
    You really think that the productivity of today's programmers is less? What evidence and data do you have for that?
    - eggsqqq 9y ago
      You must be the life of every party.
    - nurettin 9y ago
      Warning: all anecdotes. While I don't think that productivity has decreased, what was notepad, a compiler, some dlls and a debugger before turned into a thousand little packages, several configuration files, a bunch of servers you have to run on your dev. computer, which is also 10x more capable, yet everything feels so sluggish. I also feel that ceteris paribus, the meetings got longer, project management tools now consume a lot of input from programmers, and I need to communicate with a lot more people to get something done.
      - mauritzio 9y ago
        Sounds for me like productivity went down...
anfedorov 9y ago
That's nothing. I once ran 20 services before breakfast.
- paulddraper 9y ago
  Well, my pre-breakfast routine consists of seq 21 | while read port; do python2 -m SimpleHTTPServer 80$port & done
  - majewsky 9y ago
    seq 21 | while read port; do python3 -m http.server 80$port & done FTFY
nstj 9y ago
Putting the I back in Microservices :)
NicoJuicy 9y ago
I have a web app with a "file store" ( eg. simple dropbox over API) that i manage. I haven't touched it in a year and it uploads files, proxies them, resizes, ... And it's just one of many.
isaacremuant 9y ago
I get both why people downvoted you and why people defended you. One developer can certainly be responsible for coding many microservices and even maintaining them depending on the scope, number of users, etc. Sometimes people might even rotate with a core architect coordinating how they all interact and if they are consistent with each other. Discussing about microservices can be very confusing if people are thinking about different things and, as always, when there's a good idea implemented in a specific context and people who don't use it get exposed to it as a silver bullet we'll end up with a huge backlash like in this article.
hajile 9y ago
Real-world business servers are complicated even when you tease apart the different elements.

zenonu 9y ago

The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lookup, etc. should all be "out-of-the-box" before microservices should ever be considered. Otherwise the O(n) gains you get in modularity turn into O(n) FML.

charlieflowers 9y ago
Would love to hear some peoples' thoughts on good contenders in each of these areas. What are some good boxes to get these out of in 2018?
- antonp 9y ago
  Would like to echo this request. Had to implement a micro-service architecture in python about a year ago and was jealous of my Java colleagues who (so I heard) have great ecosystem for enterprise service discovery, messaging etc.
  - ivan_gammel 9y ago
    Yes, we do. The ecosystem is great and microservice architecture may be manageable even in small teams, but it's always a process that defines the success. From my own experience, the biggest technical problem of microservices in Java can be the performance of the whole system (in a monolith there's much less logging and state management, no network latencies and mismatching parallelism settings). Discovery, auth, messaging, configuration management etc are solved.
- sametmax 9y ago
  Crossbar.io is currently an interesting approach IMO. It does have a single point of failure that is also a bottleneck (the router) and it's a lot of work to load balance / failover it. But other than that, it provides a fantastic way to make microservices: - anything is a client of the crossbar router. Your server code is a client. The db can be a client. The web page JS code is a client. And they all talk to each others. - A client can expose any function to be called remotely by giving it a name. Another client can call this function by simply providing the name. Clients don't need to know each others. Routed RPC completly decoupled the clients from each others. - A client can subscribe to a topic at any time and be notified when anothe client publishes a message on that topic. Quick, easy and powerful PUB/SUB with wildcard. - A client can be written in JS (node and browser), Python, C#, Java, PHP, etc. Clients from other languages can talk to each others transparently. They all just receive JSON/msgpack/whatever and error are propagated and turn into the native language error handling mechanisme transparently. - The API is pretty simple. If you tried SOAP or CORBA before, this is way, way, way simpler. It feels more like using redis. - It uses websockets, which mean it works anywhere HTTP works. Including a web page or behind a NAT or with TLS. - Everything is async. The router handles 6000 msg / s to 1000 clients on a small Raspberry Pi. - The router can act as a process manager and even a static / wsgi web server. - you can load balance any clients, hot swap them, ban them, get meta event about the whole system, etc. - you can asign clients permissions, authentications, etc. Sessions are attached to each connexion, so clients knows what other clients can do.

brandonbloom 9y ago

I agree that it's _easier_ for teams to have their own little fiefdoms, but not necessarily _better_. Shipping the org-chart is often a symptom of a leadership problem. When natural service boundaries exist, good leadership may choose to ship the org-chart, but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture.

bmer 9y ago
> ...but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture. hahaha Do you know if there are some well chronicled cases of this happening? I find it very believable, but you know, would love to read something "actual".
- quodlibetor 9y ago
  I believe this is a paraphrase of Conway's law. The Wikipedia article lists three studies in favor of it, so there's that. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- woolvalley 9y ago
  Just go work somewhere that is big enough for that to happen. Usually large tech cos with the amount of devs larger than dunbars number by about 2x or greater.
- bonesss 9y ago
  [Disclaimer: I've never worked for MS or Amazon, working solely off of reported info here...] A kinda-random example off the top of my head of "shipping the org chart" would be the historical gaps between Windows, Development, and Office at Microsoft. Ie Office is getting a new ribbon, but no development can't supply those icons or any components because they're an "office thing", or the internal API/VBA battles along the same lines. On the opposite side, as reported in the press, Amazon has used this effect to create manageable teams and build up their own SOA: the two-pizza rule for teams means that teams can only really make targeted self-contained services. In this case Amazon worked backwards and re-structured their teams so that 'shipping their org chart' created the desired architecture.

beamatronic 9y ago

What if you expect the team of 7 to grow to 20 or more.. In a larger context almost any company would hire more developers if they could find them and hire them.

bigiain 9y ago
Premature optimisation... YAGNI is almost always the right approach.
- scarface74 9y ago
  I don't think you should always go with a microservice approach first, but you should always separate different domains/features into well defined modules/projects even within a monolith. There have been plenty of times where I've taken a project out of a monolith and created a separate shippable package to be consumed by another monolith in a separate repo. There were also occasions where I had to rip out a feature in a monolithic API that either needed to scale independently or be released independently and then just created a facade in the originally API that proxies the "microservice".
  - bigiain 9y ago
    Completely agree. I mostly tell my people "We aren't going to do that yet - or possibly ever - but keep in mind that we might have to if we ever win the user growth hockey-stick graph lottery, so when choosing between options of how to architect things, prefer very narrow focus that _could_ be pulled apart into microservices more easily if practical" I've also been known to stand up duplicated instances on a monolith with path routing on the load balancer as a "pretend microservices" scaling or upgrade trick.
bonesss 9y ago
Those growth points, and their associated market knowledge and budgetary constraints, would become perfect transition points into a friendlier architecture for the team... Plan for change, moreso than trying to plan against change. Decomposing and fragmenting an established service into smaller clones of itself should be reasonably straightforward. In most languages with a component story (ie java), library reuse across microservices should make your service architecture orthogonal to your application logic. This kind of approach also eases a lot of pain of cross-service issues.

mgkimsal 9y ago

> When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain. Faced this a couple of years ago, and I was the lone dissenting voice suggesting this was not going to go well. Then I learned that "microservice" in reality just meant everything was going to be one nodejs process running endpoints, with ios and android clients hitting it, which... didn't really fit my understanding of "microservice"; that's just "service".

asfdsfggtfd 9y ago
If you are slightly careful and put this service behind a load-balancer/reverse-proxy you can take any given set of end points and turn them into a micro-service when you need to. Sounds perfect for a small team.
- mgkimsal 9y ago
  you could. in this particular case, if memory serves, we had an existing set of endpoints functioning, but people deemed it in need of rewrite to node, because 'microservice'. Instead of putting the code we had behind proxy then migrating, we had to start over. because 'scale' and 'microservice'. and 'lambda'. Also, the same team spent several hours in meetings deciding whether or not to allow email signup, or facebook signup, or both, or neither, in the mobile app. Then had the same discussions/arguments a few weeks later when a couple new people joined the team. I realize I sound a bit bitter. I got pushback because I'd used the 'microservice api' in a "we don't like that" language. consuming the api (which I'd understood to be part of the reason of having a central API vs just hitting db tables directly) by anything that wasn't also node was outside the groupthink, and caused problems. I left the project. They've got their microservice architecture, but no userbase (yet?) to be concerned about scaling issues. I understand it's reasonable to be concerned about potential scaling problems, the team/project spent far too much time chasing architectural perfection (and really... 'shiny new stuff') vs executing a marketing plan. It's easier for a group that is tech-folk-heavy to focus on that; I get it. But it didn't solve any problems at hand. But when the mythical "2 million users in an hour" problem happens, it'll probably hold up, unless it doesn't.

pjmlp 9y ago

They can manage those teams by writing libraries, no need for microservices.

ivan_gammel 9y ago
It's much harder to deploy a library fix to production (producing a new build of integrated app in large team is a big deal), than a microservice.
- McP 9y ago
  It shouldn't be a big deal. https://en.wikipedia.org/wiki/Continuous_delivery https://en.wikipedia.org/wiki/Continuous_delivery
  - sokoloff 9y ago
    It shouldn't, but in practice sometimes is. It's not the pushing of bits that's hard; it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs. Imagine you have a library that implements the serialization and deserialization of something in your system (or anything else where the library implements two "halves" of some functionality). You might (or might not, depending on the change) need to push out that library to other apps to effect the fix you're working on. That new proposed library change may be in a queue behind another pending change that's in development, etc.
    - marcosdumay 9y ago
      > it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs. And guess what, you have to do the same thing with microservices. You must ensure that all its clients are pointing to the correct version, and you must ensure that the new version didn't add any bugs in the clients. Adaptations for new service versions will also get into the release queue, and can also get blocked by other stuff.
- 9y ago

scarface74 9y ago

I'm the dev lead for a largish company with a small development shop 4-9 people (contractors come and go). I went for a microservice like hub and spoke model where a bunch of small services integrate with a central Mongo database where all of the CRUD is managed via an API and validation is done via the API. Also cross cutting concerns like configuration (a wrapper around Consul), logging (structured logging via Serilog), and job scheduling (Nomad) is done via a common package. I chose this approach because the developers who were already there were relatively new to C#, and I knew we were going to have to ramp up contractors relatively fast. Our dev ops process revolves around creating build and release processes by simply cloning an existing build and release pipeline in Visual Studio Team Services - the hosted version of Team Foundation Services - and changing a variable. Every service is a separate repo. Each dev is responsible for releasing their own service. The advantages: 1. All green field development for a new dev. They always start with an empty repo when creating a new service. 2. Maintenance is easier. You know going in all you have to do is use a few documented Postman calls to run your program if you need to make changes. Also, it's easy to see what the program does and if you make a mistake, it doesn't affect too many other people if you keep the interface the same. 3. The release process is fast. Once we get the necessary approvals, we can log on to VSTS from anywhere and press a button. 4. Bad code doesn't infest the entire system. The permanent junior employees are getting better by the month and we are all learning what works and doesn't work as we build out the system. Each service is taking our lessons learned into account. We aren't forced to keep living with bad decisions we made earlier and building on top of it. A microservice strategy only works if you have the support system around it. In our case, an easy to use continuous integration, continuous deployment system (VSTS), easy configuration (Consul), service discovery and recovery (Consul with watches), automated unit and integration tests, a method to standardize cross cutting concerns And finally, Hashicorp's Nomad has been a god send for orchestration. Our "services" are really just a bunch of apps. Nomad works with shell scripts, batch files, Docker containers, and raw executables. It was much easier to set up and configure than kubernetes.