4 ms·

Turns out the latest hype is a dud for most companies ^_^ There are good reasons to use microservices, like when you have 100+ engineers working on your planet

Turns out the latest hype is a dud for most companies ^_^ There are good reasons to use microservices, like when you have 100+ engineers working on your planet-scale cloud or social network. At that scale, you need to have internal API documentation to ensure people that never met can still work together productively. But if you are a normal company, you will probably never have enough engineers to make microservices worthwhile in the first place. So just put everything into one big git repo and call it a day. Also, the ability to do rolling restarts and no downtime upgrades by running multiple versions in parallel adds a lot of work and complexity. But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem, so all that zero-downtime-upgrade work is just wasted effort. I mean, even my bank has a fixed offline maintenance window every night from 3:00 to 3:30 am. As does Amazon RDS. So don't solve problems that you don't have :) Most companies do fine without microservices.

kqr 7y ago
> But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem, so all that zero-downtime-upgrade work is just wasted effort. The first half of that is true, but the conclusion overlooks a couple of much bigger issues: 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently. (See the yearly state of devops reports for further research about this.) 2. Not all downtime is planned downtime. Being able to handle a true crash gracefully is very important to achieve reasonable response times in the high nines. I'm not a proponent of service-oriented architectures -- my opinion is that enforcing API boundaries is useful, but can be done at the source level rather than application level. I do however think there is great value to being able to deploy/restart your application with virtually no downtime.
- funcDropShadow 7y ago
  > 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently This is only true under certain assumptions. E.g. if your business is not a public facing website, you often don't have the immediate feedback in case of errors, to make the above observation applicable. I have a customer with an application that gather date for a whole year, and then does alot of stuff with it. Then, there are no short feedback cycles in production, no matter how often a day you deploy. Then, it is important to assure quality before a change reaches production. Otherwise it might replace your data with background noise and you only discover it at the end of the next year. This is a symptom of the general tendency in developer circles to assume that personal findings apply to everyone at every time in every situation. Which is obviously ridicoulous. But somehow completely acceptable if you generalize from something one Google employer has posted about.
  - kqr 7y ago
    There's a point to what you're writing that I hadn't considered, but I'd still hold that building "software used every day, or at least every week" constitutes far more of our collective engineering time than "software used once a year or more rarely." Even if the latter category is more numerous, I think we spend much less time working on it. And software that's used semi-frequently can benefit from a shorter feedback cycle, even if it doesn't have one right now. Sometimes there's an insurmountable technical barrier to that (e.g. code on a solar orbiter) but it's even in those cases worth investigating.
dgoldstein0 7y ago
Agree, it seems silly to bash microservices as if all (new) companies decide to use them. They are a tool for medium and bigger companies to solve the problems those companies have. Fundamentally it's adding some complexity to the overall system by breaking it into components that have smaller scope and are easier for fewer people to wrangle. So one reason services can make sense when the complexity of an initial monolith has grown beyond what the average engineer can be expected to learn in a few months; or if a similar growth trajectory is happening because the engineering team is big enough to write code faster than everyone can keep up with understanding the important changes.
aschatten 7y ago
You can have services, just not micro. Splitting into few services that are obviously conceptually separate is enough. If you are a typical web company, you can have a dedicated service for search, maybe a separate service for internal tools and the main app. Granular enough that teams in charge can be focused on on their area and wide enough to avoid complexity.
- jayd16 7y ago
  Imo, that is identical to "microservices" but you're right that there's no reason to go any more than what you need. I always felt the whole microservice hype/movement was simply about defining multiple services as a useful pattern you'll want to use and how to build infrastructure to make it easy. But I agree wholeheartedly. You don't need 100+ services to get the benefits of converting your tool chain to handle deploying n services even if n=3.
  - aschatten 7y ago
    I think prefix “micro“ confuses me :) Opens up a debate as to how granular you need to go. Another thing that confuses me is whether microservice architecture is conceptually different to SOA. Some say it is, some view it as another iteration of SOA.
  - VBprogrammer 7y ago
    In that case I'd say it's unlikely you are truly embracing microservices in the manner that their evangelists intended (and don't misunderstand me, you are probably right not to). One of the characteristics of microservices is that they are small enough that they can be completely written in a couple of weeks. Like every other fad in technology the nuances and practicalities are lost along the way. Now that we have all started bashing microservices can we all take a minute to reflect on what a steaming pile of shit monoliths can turn into without a huge amount of respect for the artificial boundaries and interfaces that you create.
    - aschatten 7y ago
      Where was it stipulated that a characteristic of a microservice is that it can be completely written in a couple of weeks?
jayd16 7y ago
If you have a mono-repo and a maintenance window you could just make cross service updates in a single commit and do the maintenance deploy of all services too. Microservices alone don't prevent any of that.
kevcampb 7y ago
It's still possible to do live upgrades without microservices
vidarh 7y ago
To be truly useful at smaller scale, most of the services needs to be third party components you just drop in, and we need near zero effort orchestration first so splitting up your services doesn't just shift the burden to devops. Neither is really there, and so I agree with you today, but it could change with the right tooling.
- taleodor 7y ago
  Very good point, thank you. My take is we're actually getting there pretty quickly and 3rd party drop-in components where you can mix and match is indeed the future.
  - funcDropShadow 7y ago
    or the past ;-)
NicoJuicy 7y ago
Important nuance in your comment why microservices are useful: 3:00-3:30 in your timezone ;)
mrighele 7y ago
> Also, the ability to do rolling restarts and no downtime upgrades by running multiple versions in parallel adds a lot of work and complexity. You don't need (micro)services to do upgrades without downtime. You just need a couple of load-balanced servers instead of one, and some planning to be sure that the two versions can coexists for some time. This can be a bit tricky until you get used to it, but depending on the company and the customers it can be even easier than organizing a maintenance window.
fiedzia 7y ago
> There are good reasons to use microservices, like when you have 100+ engineers Its enough to have 2 that work in different domains with different constraints and different tools. Company scale is completely irrelevant here. > But if you are a normal company, you will probably never have enough engineers to make microservices worthwhile in the first place Many "normal" companies use microservices and common reason is that they simply cannot function otherwise. > But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem, The fact that some site doesn't function for 5 minutes may not be a problem, the fact that any change requires many people agreeing on deployment time often is.
- jdc 7y ago
  Its enough to have 2 that work in different domains with different constraints and different tools. Wouldn't that be more or less be just two monoliths?
  - fiedzia 7y ago
    If they both work for the same organization to achieve common goal, communicate through some interface they agree on, having to coordinate occasional changes that affect both codebases, than no. If they are completely isolated, than yes, but its really rare scenario. A common example would be a website that gathers/presents some data from users, and a service that provides analytics of said data. Both domains may require completely different technologies.

kqr 7y ago

> But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem, so all that zero-downtime-upgrade work is just wasted effort. The first half of that is true, but the conclusion overlooks a couple of much bigger issues: 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently. (See the yearly state of devops reports for further research about this.) 2. Not all downtime is planned downtime. Being able to handle a true crash gracefully is very important to achieve reasonable response times in the high nines. I'm not a proponent of service-oriented architectures -- my opinion is that enforcing API boundaries is useful, but can be done at the source level rather than application level. I do however think there is great value to being able to deploy/restart your application with virtually no downtime.

funcDropShadow 7y ago
> 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently This is only true under certain assumptions. E.g. if your business is not a public facing website, you often don't have the immediate feedback in case of errors, to make the above observation applicable. I have a customer with an application that gather date for a whole year, and then does alot of stuff with it. Then, there are no short feedback cycles in production, no matter how often a day you deploy. Then, it is important to assure quality before a change reaches production. Otherwise it might replace your data with background noise and you only discover it at the end of the next year. This is a symptom of the general tendency in developer circles to assume that personal findings apply to everyone at every time in every situation. Which is obviously ridicoulous. But somehow completely acceptable if you generalize from something one Google employer has posted about.
- kqr 7y ago
  There's a point to what you're writing that I hadn't considered, but I'd still hold that building "software used every day, or at least every week" constitutes far more of our collective engineering time than "software used once a year or more rarely." Even if the latter category is more numerous, I think we spend much less time working on it. And software that's used semi-frequently can benefit from a shorter feedback cycle, even if it doesn't have one right now. Sometimes there's an insurmountable technical barrier to that (e.g. code on a solar orbiter) but it's even in those cases worth investigating.

dgoldstein0 7y ago

Agree, it seems silly to bash microservices as if all (new) companies decide to use them. They are a tool for medium and bigger companies to solve the problems those companies have. Fundamentally it's adding some complexity to the overall system by breaking it into components that have smaller scope and are easier for fewer people to wrangle. So one reason services can make sense when the complexity of an initial monolith has grown beyond what the average engineer can be expected to learn in a few months; or if a similar growth trajectory is happening because the engineering team is big enough to write code faster than everyone can keep up with understanding the important changes.

aschatten 7y ago

You can have services, just not micro. Splitting into few services that are obviously conceptually separate is enough. If you are a typical web company, you can have a dedicated service for search, maybe a separate service for internal tools and the main app. Granular enough that teams in charge can be focused on on their area and wide enough to avoid complexity.

jayd16 7y ago
Imo, that is identical to "microservices" but you're right that there's no reason to go any more than what you need. I always felt the whole microservice hype/movement was simply about defining multiple services as a useful pattern you'll want to use and how to build infrastructure to make it easy. But I agree wholeheartedly. You don't need 100+ services to get the benefits of converting your tool chain to handle deploying n services even if n=3.
- aschatten 7y ago
  I think prefix “micro“ confuses me :) Opens up a debate as to how granular you need to go. Another thing that confuses me is whether microservice architecture is conceptually different to SOA. Some say it is, some view it as another iteration of SOA.
- VBprogrammer 7y ago
  In that case I'd say it's unlikely you are truly embracing microservices in the manner that their evangelists intended (and don't misunderstand me, you are probably right not to). One of the characteristics of microservices is that they are small enough that they can be completely written in a couple of weeks. Like every other fad in technology the nuances and practicalities are lost along the way. Now that we have all started bashing microservices can we all take a minute to reflect on what a steaming pile of shit monoliths can turn into without a huge amount of respect for the artificial boundaries and interfaces that you create.
  - aschatten 7y ago
    Where was it stipulated that a characteristic of a microservice is that it can be completely written in a couple of weeks?

jayd16 7y ago

If you have a mono-repo and a maintenance window you could just make cross service updates in a single commit and do the maintenance deploy of all services too. Microservices alone don't prevent any of that.

kevcampb 7y ago

It's still possible to do live upgrades without microservices

vidarh 7y ago

To be truly useful at smaller scale, most of the services needs to be third party components you just drop in, and we need near zero effort orchestration first so splitting up your services doesn't just shift the burden to devops. Neither is really there, and so I agree with you today, but it could change with the right tooling.

taleodor 7y ago
Very good point, thank you. My take is we're actually getting there pretty quickly and 3rd party drop-in components where you can mix and match is indeed the future.
- funcDropShadow 7y ago
  or the past ;-)

NicoJuicy 7y ago

Important nuance in your comment why microservices are useful: 3:00-3:30 in your timezone ;)

mrighele 7y ago

> Also, the ability to do rolling restarts and no downtime upgrades by running multiple versions in parallel adds a lot of work and complexity. You don't need (micro)services to do upgrades without downtime. You just need a couple of load-balanced servers instead of one, and some planning to be sure that the two versions can coexists for some time. This can be a bit tricky until you get used to it, but depending on the company and the customers it can be even easier than organizing a maintenance window.

fiedzia 7y ago

> There are good reasons to use microservices, like when you have 100+ engineers Its enough to have 2 that work in different domains with different constraints and different tools. Company scale is completely irrelevant here. > But if you are a normal company, you will probably never have enough engineers to make microservices worthwhile in the first place Many "normal" companies use microservices and common reason is that they simply cannot function otherwise. > But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem, The fact that some site doesn't function for 5 minutes may not be a problem, the fact that any change requires many people agreeing on deployment time often is.

jdc 7y ago
Its enough to have 2 that work in different domains with different constraints and different tools. Wouldn't that be more or less be just two monoliths?
- fiedzia 7y ago
  If they both work for the same organization to achieve common goal, communicate through some interface they agree on, having to coordinate occasional changes that affect both codebases, than no. If they are completely isolated, than yes, but its really rare scenario. A common example would be a website that gathers/presents some data from users, and a service that provides analytics of said data. Both domains may require completely different technologies.