5 ms·

Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous

Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom. Don't get me wrong, a service-oriented architecture is the only thing that scales to large companies. Once you get to dozens of engineers and millions of lines of code you will inevitably need to have an SOA because Conway's law. Also, there is a learning curve to building microservices which improved tooling really helps with. However the thing that really grates at me is how these articles say things like: > Services are now an everyday, every-developer way of thinking With nary a mention of the overhead. There is no way around it, distributed systems have an irreducible complexity no matter how good your tooling and boilerplate is. You have to put in extra work to decouple everything and handle failure in a way that actually reap the benefits of the distributed system. And in the end, what these articles always gloss over is the interface between these systems. If you can easily define an interface between systems that stays relatively stable as the service evolves, then congratulations, you have a good candidate for a service with minimal overhead. But for most applications, those interfaces are shifting all the time, and there is no better tooling than multiple logical services running within one binary and build system where integration testing and validation is cheap. This is a real fucking problem people, it's not going to go away because there's a couple billion dollars worth of venture-backed startups ready to blow their cash on you in the vain and most likely misplaced hope that they are actually going to have to scale to dozens of engineers. Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now.

pm90 10y ago
This is a great point. I don't think the hype is due to a fad alone. There are a lot of good reason why microservices are much easier to create and deploy today: containerization and the associated technology around it. This makes microservices a very natural paradigm for app deployment. Of course, its not a holy grail. But we see that kind of thing over and over again. I think its OK; it gets developers genuinely excited to try new technology. Its only when this hype influences dangerous decisions that I'm worried about.
dexwiz 10y ago
It's all a balancing act. The two main contenders are developers and scalability. It makes no sense for a single team to run 2000 microservices that come together into a single app. The amount of overhead for managing so many interfaces is insane. At the same time, it's hard to justify 2000 developers working on a single binary. You end up with entire teams dedicated to managing and deploying. Companies do it (Google), but it's not without costs. If every microservice runs with the same specs (container size/# of containers), then there is nothing gained from scalability. If anything, you're probably wasting a large amount of resources if your containers cannot shrink any more. At the same time, if you are deploying thousands of copies of of a single binary, when most of the resources go to 1% of the code, then you're wasting resources with needless copies. The (micro)services fad is definitely brought on by the recent rise of virtualization. It's probably a bit overboard.
- honkhonkpants 10y ago
  You got the Google part wrong. Google is all in on microservice architecture and has over a decade of experience doing it. There is not some gigantic google.exe program. Perhaps you have heard that Google uses a single source code repo and drew an incorrect conclusion.
spriggan3 10y ago
> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then make it scale" ?
- beagle3 10y ago
  > This. What happened to "make it work then make it scale" ? The fact that it is wrong (or rather, incomplete) It should be "make it work with a clear path to scaling, then make it scale" - that's true with respect to both software engineering and business plans. It's the same with "premature optimization is [the|a root of [all]] evil" - Premature optimization is a waste of time and often paints you into a corner. However, if you don't think about the bottlenecks and how to optimize them in advance, you more often than not find later, when profiling, that there are not enough hotspots, and the performance is "lost" all over the place.
  - lmm 10y ago
    Not my experience at all. Systems that were designed as simply as possible can be unpicked and made scalable - it takes time and effort but it's doable. Systems that were designed to be scalable are much worse, because you have to undo all of that work first before you can start actually making them scalable.
    - beagle3 10y ago
      Simpler systems are easier to scale than more complicated ones, for sure - but things like making sure that your database is easily shardable are often cheap (even free) before you start, and might be extremely expensive later on -- I'm familiar with a project that eventually spent a few hundred thousand dollars on some high performance database (Oracle RAC or something, don't remember exactly), where -- if the database schema was shardable in advance -- they could have been ok with 10-20 cheap machines running MySQL. And I remember an earlier project that had to be completely rewritten in the early '90s because at the time, Oracle couldn't yet scale even throwing money at it (and DB2 reportedly could - but the required Mainframe was not an option). Simple is often best, yes. But not oblivious-to-the-future simple.
sp527 10y ago
Speaking as a young engineer, I can tell you many are already looking past microservices towards things like AWS Lambda, AMQs, and BaaS, which make a great deal more sense. Why? Because it helps reduce dev effort down to purely the logic you'd have to write no matter what, with better guarantees about reliability and scalability, and less maintenance. I hesitate to say 'serverless' because that still feels somewhat out of reach, but that's the direction things are trending towards. I also get the sense that a lot of purists moulded in the ways of yore are alarmed at the waning relevance of their skillset. This to me seems like a bigger problem than the evolution of software paradigms.
- dasil003 10y ago
  Oh yeah, I don't think it's bad research going into this. I mean I've been writing software professionally for almost 20 years now and I am super excited about (for example) containerization and other trendy areas. I think it's great that people are pushing the boundaries of SOAs, and I think microservice is a good term describing how the boundaries are being pushed. We will all benefit from the improved tooling and experience gained. My only complaint is this ostrich mentality of declaring ubiquity and ignoring the downsides and unsuitable cases. I suppose drinking the koolaid might be necessary to really buy in and push the paradigm forward, but sometimes it feels like willful ignorance.
  - sp527 10y ago
    I agree completely. I may simply have had the luxury of so far working in environments wherein software fads aren't hailed as Swiss-Army panaceas. Here's to hoping my track record doesn't ever trend Dilbertesque :)
    - dasil003 10y ago
      Me too. At this point in my career I've worked very closely with more than 100 programmers for long periods of time, and only one of them would I classify as being overly interested in fads. To the contrary, I give a ton of credit to the vast majority of programmers as always being pragmatic about the problem at hand. I think the problem lies more in the PR, advocacy and conference circuits where there's an incentive and agenda to present things as silver bullets. It mirrors a greater problem in public discourse that everything has become so polarized that nuanced debate is drowned out by noisy, confident blowhards.
djspoons 10y ago
I wrote the post with pretty rose-colored glasses on. :) I totally agree that microservices can be a form of premature optimization, in particular because of the cost with today's tooling. But I think there's hope that lot of those costs will go down (both in terms of dev time and infrastructure) with things like AWS Lambda, etc. Anyway, if devs think a little more about the interfaces, I think that will be a good thing.

pm90 10y ago

This is a great point. I don't think the hype is due to a fad alone. There are a lot of good reason why microservices are much easier to create and deploy today: containerization and the associated technology around it. This makes microservices a very natural paradigm for app deployment. Of course, its not a holy grail. But we see that kind of thing over and over again. I think its OK; it gets developers genuinely excited to try new technology. Its only when this hype influences dangerous decisions that I'm worried about.

dexwiz 10y ago

It's all a balancing act. The two main contenders are developers and scalability. It makes no sense for a single team to run 2000 microservices that come together into a single app. The amount of overhead for managing so many interfaces is insane. At the same time, it's hard to justify 2000 developers working on a single binary. You end up with entire teams dedicated to managing and deploying. Companies do it (Google), but it's not without costs. If every microservice runs with the same specs (container size/# of containers), then there is nothing gained from scalability. If anything, you're probably wasting a large amount of resources if your containers cannot shrink any more. At the same time, if you are deploying thousands of copies of of a single binary, when most of the resources go to 1% of the code, then you're wasting resources with needless copies. The (micro)services fad is definitely brought on by the recent rise of virtualization. It's probably a bit overboard.

honkhonkpants 10y ago
You got the Google part wrong. Google is all in on microservice architecture and has over a decade of experience doing it. There is not some gigantic google.exe program. Perhaps you have heard that Google uses a single source code repo and drew an incorrect conclusion.

spriggan3 10y ago

> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then make it scale" ?

beagle3 10y ago
> This. What happened to "make it work then make it scale" ? The fact that it is wrong (or rather, incomplete) It should be "make it work with a clear path to scaling, then make it scale" - that's true with respect to both software engineering and business plans. It's the same with "premature optimization is [the|a root of [all]] evil" - Premature optimization is a waste of time and often paints you into a corner. However, if you don't think about the bottlenecks and how to optimize them in advance, you more often than not find later, when profiling, that there are not enough hotspots, and the performance is "lost" all over the place.
- lmm 10y ago
  Not my experience at all. Systems that were designed as simply as possible can be unpicked and made scalable - it takes time and effort but it's doable. Systems that were designed to be scalable are much worse, because you have to undo all of that work first before you can start actually making them scalable.
  - beagle3 10y ago
    Simpler systems are easier to scale than more complicated ones, for sure - but things like making sure that your database is easily shardable are often cheap (even free) before you start, and might be extremely expensive later on -- I'm familiar with a project that eventually spent a few hundred thousand dollars on some high performance database (Oracle RAC or something, don't remember exactly), where -- if the database schema was shardable in advance -- they could have been ok with 10-20 cheap machines running MySQL. And I remember an earlier project that had to be completely rewritten in the early '90s because at the time, Oracle couldn't yet scale even throwing money at it (and DB2 reportedly could - but the required Mainframe was not an option). Simple is often best, yes. But not oblivious-to-the-future simple.

sp527 10y ago

Speaking as a young engineer, I can tell you many are already looking past microservices towards things like AWS Lambda, AMQs, and BaaS, which make a great deal more sense. Why? Because it helps reduce dev effort down to purely the logic you'd have to write no matter what, with better guarantees about reliability and scalability, and less maintenance. I hesitate to say 'serverless' because that still feels somewhat out of reach, but that's the direction things are trending towards. I also get the sense that a lot of purists moulded in the ways of yore are alarmed at the waning relevance of their skillset. This to me seems like a bigger problem than the evolution of software paradigms.

dasil003 10y ago
Oh yeah, I don't think it's bad research going into this. I mean I've been writing software professionally for almost 20 years now and I am super excited about (for example) containerization and other trendy areas. I think it's great that people are pushing the boundaries of SOAs, and I think microservice is a good term describing how the boundaries are being pushed. We will all benefit from the improved tooling and experience gained. My only complaint is this ostrich mentality of declaring ubiquity and ignoring the downsides and unsuitable cases. I suppose drinking the koolaid might be necessary to really buy in and push the paradigm forward, but sometimes it feels like willful ignorance.
- sp527 10y ago
  I agree completely. I may simply have had the luxury of so far working in environments wherein software fads aren't hailed as Swiss-Army panaceas. Here's to hoping my track record doesn't ever trend Dilbertesque :)
  - dasil003 10y ago
    Me too. At this point in my career I've worked very closely with more than 100 programmers for long periods of time, and only one of them would I classify as being overly interested in fads. To the contrary, I give a ton of credit to the vast majority of programmers as always being pragmatic about the problem at hand. I think the problem lies more in the PR, advocacy and conference circuits where there's an incentive and agenda to present things as silver bullets. It mirrors a greater problem in public discourse that everything has become so polarized that nuanced debate is drowned out by noisy, confident blowhards.

djspoons 10y ago

I wrote the post with pretty rose-colored glasses on. :) I totally agree that microservices can be a form of premature optimization, in particular because of the cost with today's tooling. But I think there's hope that lot of those costs will go down (both in terms of dev time and infrastructure) with things like AWS Lambda, etc. Anyway, if devs think a little more about the interfaces, I think that will be a good thing.