3 ms·

> I never really understood the hatred that people on HN have for microservices. If you're an early stage company and just trying to ship something with a smal

> I never really understood the hatred that people on HN have for microservices. If you're an early stage company and just trying to ship something with a small team, the overhead of microservices (testing, deployment, monitoring, platform infra such as k8s, etc) can be pretty obnoxious (like an order of magnitude more time than the work to actually deliver business value). And microservices give you enough rope for one overly clever person to hang the whole team, so there are definitely some traumatized developers out there. If you are doing something simple enough, throw it in a single docker container and spend your time focused on building something useful.

photonthug 2y ago
This is all true, but I think tends to cover up root-causes. Over the last 5-10 years, tons of people got jobs on the strength of "k8s experience" which was more like "I was on the software-side of an application development that was deployed with kubernetes once" and then got hired based on that as if they had architecture and infrastructure experience/expertise, when they actually don't have either one. So yeah, when you need 6-8 months of on-the-job training for your "experts" to get some expertise, that will set you back 6-8 months when it comes to productionizing your product (assuming the product itself is already finished!). It's not the sheer amount of work that's involved with microservices vs monoliths. It's the skill set, which is large enough that you can't get it overnight. Even setting aside the wider ecosystem and just counting the number core concepts at play, it's easier to pick up a new programming language than to learn kubernetes architecture/administration/operations. Startups (or a company of any size that simply doesn't have the ability to evaluate candidates) will be better off if they won't saddle themselves with full-time people of questionable qualifications, working instead with some limited-engagement technical consultants and contractors in a tactical way. Contractors like this will have actually solved the problems involved multiple times and will probably have bootstrap-a-whole-org testing/deployment/monitoring code in their back pocket already. To me it seems like all this is the predictable downside of the whole "full stack engineer" thing. A server-side language + html/css/javascript can probably fit into the average human brain, but even there it seems misguided. Once "full stack" is further twisted to mean SWE+Infrastructure+Platform+Cloud+Architecture and then you throw in a little "No-Ops" and "Low Code" optimism, then it's getting unrealistic, but naive management will imagine anyone can do anything and it's all very easy. It is easy, but not anyone can do it. Expertise is required, especially during design/bootstrap phases. As a company you don't have to buy that expertise forever with a FTE, but you also can't just assume you'll multipurpose some existing FTE for this stuff if they have less than adequate experience.
- solidasparagus 2y ago
  So do you believe that microservices are no harder than monoliths for small-scale projects, it's just a matter of expertise?
  - photonthug 2y ago
    Pretty much, yeah. Look at it this way. If microservice madness needs N monitors, well, monolith still needs at least 1 right? With the relevant expertise, making N monitors isn’t harder than making 1. Programmers shouldn’t get scared about generalizing existing instructions and adding a loop, and infracode is just another kind of code or you’re doing it wrong. Rejecting microservices because of this kind of “complexity” is usually just FUD that is screening someone’s preference for not working, learning, or hiring. Which desires are ok I guess, but it’s annoying if it’s presented as a discussion around architecture, best practices, etc.

photonthug 2y ago

This is all true, but I think tends to cover up root-causes. Over the last 5-10 years, tons of people got jobs on the strength of "k8s experience" which was more like "I was on the software-side of an application development that was deployed with kubernetes once" and then got hired based on that as if they had architecture and infrastructure experience/expertise, when they actually don't have either one. So yeah, when you need 6-8 months of on-the-job training for your "experts" to get some expertise, that will set you back 6-8 months when it comes to productionizing your product (assuming the product itself is already finished!). It's not the sheer amount of work that's involved with microservices vs monoliths. It's the skill set, which is large enough that you can't get it overnight. Even setting aside the wider ecosystem and just counting the number core concepts at play, it's easier to pick up a new programming language than to learn kubernetes architecture/administration/operations. Startups (or a company of any size that simply doesn't have the ability to evaluate candidates) will be better off if they won't saddle themselves with full-time people of questionable qualifications, working instead with some limited-engagement technical consultants and contractors in a tactical way. Contractors like this will have actually solved the problems involved multiple times and will probably have bootstrap-a-whole-org testing/deployment/monitoring code in their back pocket already. To me it seems like all this is the predictable downside of the whole "full stack engineer" thing. A server-side language + html/css/javascript can probably fit into the average human brain, but even there it seems misguided. Once "full stack" is further twisted to mean SWE+Infrastructure+Platform+Cloud+Architecture and then you throw in a little "No-Ops" and "Low Code" optimism, then it's getting unrealistic, but naive management will imagine anyone can do anything and it's all very easy. It is easy, but not anyone can do it. Expertise is required, especially during design/bootstrap phases. As a company you don't have to buy that expertise forever with a FTE, but you also can't just assume you'll multipurpose some existing FTE for this stuff if they have less than adequate experience.

solidasparagus 2y ago
So do you believe that microservices are no harder than monoliths for small-scale projects, it's just a matter of expertise?
- photonthug 2y ago
  Pretty much, yeah. Look at it this way. If microservice madness needs N monitors, well, monolith still needs at least 1 right? With the relevant expertise, making N monitors isn’t harder than making 1. Programmers shouldn’t get scared about generalizing existing instructions and adding a loop, and infracode is just another kind of code or you’re doing it wrong. Rejecting microservices because of this kind of “complexity” is usually just FUD that is screening someone’s preference for not working, learning, or hiring. Which desires are ok I guess, but it’s annoying if it’s presented as a discussion around architecture, best practices, etc.