5 ms·

Understatement of the month. Last I heard, the HN consensus was that it's better to delay microservices (personally I'd say wait until profitable or >100 engine

Understatement of the month. Last I heard, the HN consensus was that it's better to delay microservices (personally I'd say wait until profitable or >100 engineers). Even Twitter, probably the most successful performant microservice-at-scale company advocates waiting as long as absolutely possible to make microservices. They said "It fixes one problem, and makes every other piece of application development significantly harder."

keithnz 8y ago
I generally agree, but I'd make a bit of a distinction that doesn't mean making a pure monolith, you can still spinoff dedicated services where it makes sense without adopting a a full "microservices architecture".
- Waterluvian 8y ago
  I found this to be true with auth. Big monolith but I split off auth, which made using a single user authority much easier for all kinds of stuff that wanted nothing to do with the rest of the monolith.
  - paulie_a 8y ago
    There are definitely some services that can be self contained and if it is a legacy codebase, modernized in an isolated way.
    - beaker52 8y ago
      And Domain Driven Design can help you understand which parts are the best candidates
- karmakaze 8y ago
  I specifically agree. The 'where it makes sense' has to be based on something practical, not theoretical nor in-the-not-immediate-future. Currently in one of our products we have 4 back-end services: webapp, api, relay, and broadcast. The scaling requirements and lifetimes of the relay and broadcast instances differ. The relay also has audio requirements. It all depends on your environment and the teams ability to deal with what's required.
- edvinbesic 8y ago
  Thinking about micro-services as a scaling solution is only ever looked at from the orchestration perspective for some reason. Most of the lessons there can be applied to scale your code as well so that you can spin parts of it off with ease. This also has the benefit of giving you a cleaner & more maintainable code-base so there is still a gain even if you never spin anything off, which could be argued was the problem in the first place. This is perhaps the best bang for your buck until you actually know what the bottlenecks are as it otherwise becomes a brute-force approach to "scale everything individually". Unfortunately "our code is ready to scale" doesn't quite sound as cool as "we run a thousand micro-services".
User23 8y ago
You're absolutely right. Amazon was already a huge successful company when they began their microservices journey. Mr. Bezos is the only chief executive I know of who has knowingly applied Conway's Law[1] to corporate governance. Amazon's conversion to services is best understood as an hybrid managerial/engineering decision. This means that the microservices approach only makes sense as part of a larger organizational strategy. A small organization is almost always better off building a monolith, because while it's less efficient at scale, if the organization is successful enough for that to be a problem, it's also successful enough to be able to afford the rearchitecting, assuming competent leadership. [1]https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- justicezyx 8y ago
  Amazon is using SOA, not micro-service as it was understood today.
to_bpr 8y ago
>personally I'd say wait until profitable or >100 engineers Personally I'd say delay until you can find an area causing such a performance or scalability issue that it justifies its own repo(s), build pipelines / devops / ops, deployable artifacts, and team to hold the context on it. Without that, your profitability or engineering team is best invested into extending your offering to better service your customers.
oppositelock 8y ago
The need for microservices has little to do with company size, they have to be the right tool for the job. People mistakenly use them for scalability, or to partition work between teams. I'm in a small engineering org, and I split out a bunch of security critical code from an unsecure monolith and moved that into a microservice, running in a very tightly controlled and audited environment. A tiny part of my runtime needed different security from the rest of it, and a microservice was the easiest way to accomplish it. Now, I've traded a security problem for a latency problem, as everything that used to be handled internally is now an RPC - though this is an easy problem to solve.
- bayonetz 8y ago
  Ha! A close cousin to what I call "Resume Driven Development". Most engineers don't want to add to or maintain something someone else built prior. Since most people are working on and inheriting monoliths at small to midsize companies, the "micro services are what successes like Google do" era has been a real boon to RDD because you've got this great ready made justification for a rebuild. It would be a much harder sell to rebuild a better 2.0 of your monolith. In most cases, you don't need to do either for business value. But we pretend it is needed so that we can get a chance to do something blue sky for a change. I'm pretty conscious of when I'm RDDing but I've seen a lot of folks really delude themselves into thinking there is an urgent need to rebuild. It's very amusing watching RDD theater play out.
- alrs 8y ago
  Scalability is what microservices give you, at the expense of nearly everything else.
  - edejong 8y ago
    Independant deployment Multiple languages A/B testing at deployment fir small services Less dependency to software specific stack Security compartmentalizations Strict programming by interface Failure isolation
    - 8y ago
scruffyherder 8y ago
We did this before with COM/CORBA, and then 'scaled to size' with DCOM and CORBA. And yeah that went awesome. So many machines with the potential of having the wrong versions, or expecting certain results to not get them was catastrophic. Not to mention so many teams would re-work their components and all hell would break loose in seemingly unrelated parts of the app. The more things change, the more they stay the same.

keithnz 8y ago

I generally agree, but I'd make a bit of a distinction that doesn't mean making a pure monolith, you can still spinoff dedicated services where it makes sense without adopting a a full "microservices architecture".

Waterluvian 8y ago
I found this to be true with auth. Big monolith but I split off auth, which made using a single user authority much easier for all kinds of stuff that wanted nothing to do with the rest of the monolith.
- paulie_a 8y ago
  There are definitely some services that can be self contained and if it is a legacy codebase, modernized in an isolated way.
  - beaker52 8y ago
    And Domain Driven Design can help you understand which parts are the best candidates
karmakaze 8y ago
I specifically agree. The 'where it makes sense' has to be based on something practical, not theoretical nor in-the-not-immediate-future. Currently in one of our products we have 4 back-end services: webapp, api, relay, and broadcast. The scaling requirements and lifetimes of the relay and broadcast instances differ. The relay also has audio requirements. It all depends on your environment and the teams ability to deal with what's required.
edvinbesic 8y ago
Thinking about micro-services as a scaling solution is only ever looked at from the orchestration perspective for some reason. Most of the lessons there can be applied to scale your code as well so that you can spin parts of it off with ease. This also has the benefit of giving you a cleaner & more maintainable code-base so there is still a gain even if you never spin anything off, which could be argued was the problem in the first place. This is perhaps the best bang for your buck until you actually know what the bottlenecks are as it otherwise becomes a brute-force approach to "scale everything individually". Unfortunately "our code is ready to scale" doesn't quite sound as cool as "we run a thousand micro-services".

User23 8y ago

You're absolutely right. Amazon was already a huge successful company when they began their microservices journey. Mr. Bezos is the only chief executive I know of who has knowingly applied Conway's Law[1] to corporate governance. Amazon's conversion to services is best understood as an hybrid managerial/engineering decision. This means that the microservices approach only makes sense as part of a larger organizational strategy. A small organization is almost always better off building a monolith, because while it's less efficient at scale, if the organization is successful enough for that to be a problem, it's also successful enough to be able to afford the rearchitecting, assuming competent leadership. [1]https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

justicezyx 8y ago
Amazon is using SOA, not micro-service as it was understood today.

to_bpr 8y ago

>personally I'd say wait until profitable or >100 engineers Personally I'd say delay until you can find an area causing such a performance or scalability issue that it justifies its own repo(s), build pipelines / devops / ops, deployable artifacts, and team to hold the context on it. Without that, your profitability or engineering team is best invested into extending your offering to better service your customers.

oppositelock 8y ago

The need for microservices has little to do with company size, they have to be the right tool for the job. People mistakenly use them for scalability, or to partition work between teams. I'm in a small engineering org, and I split out a bunch of security critical code from an unsecure monolith and moved that into a microservice, running in a very tightly controlled and audited environment. A tiny part of my runtime needed different security from the rest of it, and a microservice was the easiest way to accomplish it. Now, I've traded a security problem for a latency problem, as everything that used to be handled internally is now an RPC - though this is an easy problem to solve.

bayonetz 8y ago
Ha! A close cousin to what I call "Resume Driven Development". Most engineers don't want to add to or maintain something someone else built prior. Since most people are working on and inheriting monoliths at small to midsize companies, the "micro services are what successes like Google do" era has been a real boon to RDD because you've got this great ready made justification for a rebuild. It would be a much harder sell to rebuild a better 2.0 of your monolith. In most cases, you don't need to do either for business value. But we pretend it is needed so that we can get a chance to do something blue sky for a change. I'm pretty conscious of when I'm RDDing but I've seen a lot of folks really delude themselves into thinking there is an urgent need to rebuild. It's very amusing watching RDD theater play out.
alrs 8y ago
Scalability is what microservices give you, at the expense of nearly everything else.
- edejong 8y ago
  Independant deployment Multiple languages A/B testing at deployment fir small services Less dependency to software specific stack Security compartmentalizations Strict programming by interface Failure isolation
  - 8y ago

scruffyherder 8y ago

We did this before with COM/CORBA, and then 'scaled to size' with DCOM and CORBA. And yeah that went awesome. So many machines with the potential of having the wrong versions, or expecting certain results to not get them was catastrophic. Not to mention so many teams would re-work their components and all hell would break loose in seemingly unrelated parts of the app. The more things change, the more they stay the same.