20 ms·

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generation had no idea what they were doing and they'll do it way better. They usually nail the first 80%, then hit a new edge case not well handled by their architecture/model (but was by the old system) and/or start adding swathes of new features during the rewrite. In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again.

meddlepal 9y ago
I think it has to do with control. I've written microservices and microservices tooling now for a long time... so long when I started we were just calling it something like (isolated-responsibility) SOA and we didn't have a fancy buzzword. Developers want to own their thing. Microserivces desire springs up because of a lack of communication culture and desire for siloification in a companies organization to keep various interests from bothering the developers. Those almost always point to a failure of management in my mind rather than a technical failure.
- deleted 9y ago
  [deleted]
- tyingq 9y ago
  I wouldn't dismiss the effect of résumé based development either. Even if subconscious, having the latest buzzwords on your CV is a motivator.
  - floogtheunfound 9y ago
    These replies are so salty
  - maxxxxx 9y ago
    For me that'a conscious motivator :-)
- bri3d 9y ago
  Is this truly a management failure? If a few things are true, I could see this as a win: * I can isolate my developers from outside interests using microservices. * My developers are more effective in each dimension (quality, retention/happiness, velocity) because they are isolated from outside interests. * My software is easier to operate and more reliable because it is a microservice. If any of these three things aren't true, then I agree. But I'm not sure that a "communication culture" can scale to a large organization and I'd like to see a truly large company (1000+ developers) successfully doing so. I've seen more success come from separation of concerns and well-deployed microservices seem to be fairly effective to this end.
  - cookiecaper 9y ago
    Microservice architectures [usually] represent a management failure because they usually don't work well in the real world. It's easy to concoct a paper-only, theoretical version of an idealized microservice architecture, since you can gloss over all the real-world details and practicalities. Mapping that theory into the real physical world is a whole different ball game. Conway's Law might as well be renamed "The Law of Microservices". Per Wikipedia [0], it states: > "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." "Microservices" are on a tear because they make a perfect cover for the blatant and bare expression of unbridled Conway's Law. Such unbridled expression is much easier in the course of greenfield development, because it lets the core team of 2-3 people per service go about their development work without consulting anyone external. It lets them throw away any overriding convention or cultural concerns, and it avoids the difficulties of cross-group coordination. But it leads to a completely unmaintainable wreck when things transition into production. This is not to say that no one will have a successful microservice deployment or that it's always a bad choice, but it usually goes way off the rails. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
    - bri3d 9y ago
      This I can entirely agree with - framing my point around Conway's law works well and I think I can reframe my question as "is the expression of Conway's law a management failure, or is it the mis-structuring of the organization causing the expression to be harmful?" The parent post I was replying to seemed to simplify things down to "let your developers communicate and they'll build a more coupled system that works, instead of a morass of microservices that don't." That's another thing that looks good on paper but doesn't scale, at least in my experience.
- somberi 9y ago
  " Microserivces desire springs up because of a lack of communication culture and desire for siloification" - Would have upvoted this more than once if possible.
JamesBarney 9y ago
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.
pricetag 9y ago
The company I work for is currently undergoing an effort to move many of the old PHP apis to Graphql. The repo for the graphql api wrapper was quickly becoming a monolith in itself, so it has since been broken down into separate packages. I do wonder about the sustainability of an architecture like this. This is the largest company I’ve ever worked for, so I’ve never seen how this plays out. Who will manage each package/service as time goes on and they sink into obscurity as the original team transitions out or leaves the company? I totally see some of these becoming the technical debt of the future.
ibejoeb 9y ago
It's not exclusive to inheritance, though. There are lots of times that the original principal decides that he could have done it better and winds up in exactly the same place. It could be progress, too, if it trades on set of failure modes for another that is less severe or less frequent. This is why a team needs access to good architect who's seen the paradigms shift, or even cycle. You're almost never starting from scratch, so you really need someone who's able to incorporate better or more suitable tech without throwing out the baby. If you're microservices-based, that last part is easier, even if it falls into one of the described pitfalls, e.g., system-of-systems.
raspie 9y ago
To put it in an even less flattening way, the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Microservices will not help you if your developers have the same level of skill and foresight as whoever wrote the monolith, which is probably true if those devs were selected by the same hiring process that your company has today, subject to the same organizational effectiveness, etc.
- realityenigma 9y ago
  I think you actually have hit the proverbial nail with the hammer. I've seen firsthand the terrible talent pool, at least here in the south-west US. We've done ourselves a disservice trying to get everyone and their brother to become a programmer because...economy! and more accurately, I want more money.
  - iamdave 9y ago
    They haven't hit the proverbial nail with the hammer, they've hit the railroad spike with a sledge; IMO it's 100% about your environment and the demands and obligations your development team has against it's own obligations to deliver. I'm not going to say microservices are the cornucopia, smoking gun or even smoldering slingshot, but much of the dissent in this thread seems predicated on the idea that they are the end result and not merely an optional path to take for desired outcomes of deliverability.
- qaq 9y ago
  "Your company's code will be as good as your developers" as good as your companies nn% of worst developers
- tabtab 9y ago
  Re: ...the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Indeed! Good developers/architects spot repetition or weaknesses in current techniques and can often devise solutions that can be added to the stack or shop practices with minimal impact. You don't necessarily need paradigm or language overhauls to improve problem-areas spotted. Poor developers/architects will screw up the latest and greatest also.
humanrebar 9y ago
> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again. I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already. The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithic service and microservice people are trying to do exactly that. It's just what sort of scale they're thinking about and what part of the software development lifecycle they think will be especially difficult going forward.
- elgenie 9y ago
  The critical distinction between "it's all crap, so just ship whatever already" and what the grandparent wrote is that "technical debt" doesn't reside in easily disposable code/components, but rather as may-need-to-be-rectified-but-maybe-not-right-now downsides in what is enormously useful and producing value. Good developers create code that's prepared for the possibility of being modified repeatedly and becoming foundational; on the other hand, preparing for code/components to be thrown away is a no-op.
  - humanrebar 9y ago
    > ...preparing for code/components to be thrown away is a no-op. You might be agreeing, but I find that the bad code that sticks around is bad code that is hard to get rid of. So in that sense, code that is removable isn't a no-op. It takes some effort, for instance, to keep a clear dividing line between two components so that either may be replaced someday.
- foo101 9y ago
  > The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. Management does not understand code, but they understand working long hours. If I ignore this and still care enough to write good quality code, in nearly all projects, I am not going to be the only one to work on the code. There is going to be a time, when someone else has to work on the code (because responsibilities change, or because I am busy with some other project). As per my anecdata, the number of people who do not care about code quality far exceeds those who do. So this new person would most likely start developing his features on the existing clean code in a chaotic manner without sufficient thought or design. So any carefully written code also tends to become ugly in the long term. In many cases, you know that you yourself would move out the project/organization to another project/organization in a year or so, and the code would become ugly in the long term no matter what you do, so why bother writing good code in the first place! It is very disappointing to me that the field of programming and software development that I once used to love so much out of passion has turned out to be such a commercial, artless, and dispassionate field. How do you retain your motivation to be a good developer in such a situation?
pweissbrod 9y ago
The monolith first approach has always served me well. Nascent projects benefit from portability because they need higher amounts of flux. As they mature let's assume they grow in scale and integrations and somewhere along the line it becomes sensible to break off pieces into services. To me the big benefit of microservices is scaling out components into flexible independent release cadences but the trouble comes with employing them too early. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html
tehlike 9y ago
If something isn't broken, do not fix. I think part of it is that large companies can keep engineers happy by giving them rewrites. Otherwise, not enough projects to keep everyone entertained.
- deepsun 9y ago
  Well, the best architectured project I've ever worked on in Google was actually rewritten 4 times from scratch. I believe rewriting is always good for the project. Not always for business, though. Fortunately, Google had resources to allow rewrites to happen. Rewrites also serve as thorough code review and security audit.
  - tehlike 9y ago
    Were the previous ones not getting the job done? 4 rewrites over what time period? I am more in the camp of "let's do something useful" than "let's rewrite this because previous guy didn't do it good, or it no longer meets our demands". Because whatever you do it will get rewritten again, and it's imho useful to resist the urge. Ps: also a googler.
rtpg 9y ago
Do you legit think that people are all just doing this as a fad? There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course. The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And its not even not doing it right, but simply that scales change. Or patterns change. And in new companies, it _could_ be that people don't get it. "Microservices as mass delusion" discounts a lot of people who are really thinking hard about how to handle the pros and the cons of things.
- nucleardog 9y ago
  > Do you legit think that people are all just doing this as a fad? As you say there are a lot of pros and cons to any architecture or paradigm, which is why we're still talking about it and saying things like "right tool for the job" and not just using the One True Method(TM). I legit think that a lot of people using the new hotness as a form of cargo cult programming with no understanding of the methods they're considering or how they apply to the problems they're trying to solve. It's not just microservices that are improperly applied. I've been in the industry long enough to see dozens of languages, technologies, paradigms, processes, and everything else hailed as the second coming of christ and applied inappropriately all over the place until the shinyness wore off. And I mean... When we start talking about developing for Amazon scale, we're already talking about situations that don't apply to 99% of developers. Not a great argument that their cases aren't inappropriate applications of the pattern.
- philwelch 9y ago
  The ops cost of not using microservices is a lot higher than you'd think, too. At some point, when you have hundreds of engineers and your monolith is compiled together from libraries written by a dozen different teams and you have to try and make one heroic release per week, except half the time it fails and you have to go back and fix it, and absolutely no one in the company can ship a new feature because you're blocked.
  - 9y ago
kbuchanan 9y ago
A little over two years ago my little team of three (gasp!) succumbed to the allure of microservices. After six months of writing custom solutions for problems I'd created, I bagged it. The _one_ upside of our microservice architecture was how simple it was to consolidate back into a single app. Only took a couple months. I believe the theoretical benefits of microservices, namely, hard domain boundaries, remain compelling, but geez, I also learned its benefits are extremely circumstantial.
- cookiecaper 9y ago
  Props to you for realizing you were going down a bad path and cutting your losses. Many people are unwilling to honestly evaluate their projects until they've been in the rear view mirror for a long time. A great deal of software is driven by ego and fads, and it's great to see someone make a decision to change pace based on practicalities.
deleted 9y ago
[deleted]
dreamcompiler 9y ago
I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.
- markatkinson 9y ago
  Great analogy. I tried to paint my own flat. Was a disaster.
  - WalterBright 9y ago
    I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.
    - moreless 9y ago
      For us non-english speakers - "sheetrock" == drywall. I find I can do most such works better than (average) professionals, but it takes a lot of time to learn, prepare, execute (+ sometimes re-execute) and clean. It all depends on when you are satisfied with the result.
      - Jaruzel 9y ago
        I recently came across 'sheetrock' as a term and had to google it... For UK natives it's actually three steps: "sheetrock" == drywall == Plasterboard
        logfromblammo 9y ago
        I have also heard it as "gypsum wallboard", which is certainly most descriptive. I'm not certain whether the water-resistant, mold-resistant variety typically hung behind tiles in bathrooms is ever referred to as "wetwall" or if they still call it "drywall". Nor am I aware of whether anyone calls the foil-backed, glass-reinforced, fire-resistant variety "firewall" instead of "drywall". I wouldn't be surprised if obsolete and inapplicable names still attach to items with the same function. If we ever move to polyethylene film panels sandwiched with phase-change material for our walls, it might still be called "plasterboard" somewhere.
maga_2020 9y ago
I think these are appealing for 2 reasons: 1. There is a believe, that component isolation (taken to extreme by microservices) enables better productivity of the development department. That is more features, more prototypes, more people can be moved in and out a given role. So that those 5 crusty programmers are not a bottleneck for the 'next great idea' that a Product manager or CIO reads up on. 2. There is a constant battle for the crown of "I am modern" (eg data science, micro services, big data ) That is going on in every development or technology organization. Where the closer you are in your 'vision' to google or Netflix, the more 'modern' you are. The rest of the folks is 'legacy'. So you get budgets, you get to hire, you get to 'lead'. Micro-services is the enabler to help to win this battle (although, probably, for a short term). --- I personally, do not believe that microservices bring anything new compared to previously used methods of run-time modularization : Plugins Web services RPC N-tier architectures I do not think they replace the standards like CORBA, although I think they will end up eventually replicating it, with better thought out standards and tools.
rb808 9y ago
> the pattern I've seen time and time again is Developers thinking the previous generation had no idea what they were doing and they'll do it way better. They usually nail the first 80%, then hit a new edge case not well handled by their architecture/model Perfect, I've seen this happen many times as well. I think you're generous on the 80% part. Usually they nail the first 50%, but they time they get to 80% its getting just as messy and some of the developers are planning another rewrite again.
amrx101 9y ago
Damn, you described my manager.
fulafel 9y ago
The reinvention and re-discovery of the problems can be very good for the new developers who are taking over a slice of the monolith's functionality. And it an happen rapidly, on the new developers' own terms. Depends on the case.
simias 9y ago
The #1 thing they should teach in any engineering school (or maybe any school period) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".
- ZeroGravitas 9y ago
  Would those graduates be rewarded or penalised for their professionalism? I would guess penalised in a depressing number of situations.
- dancek 9y ago
  This principle is commonly known as Chesterton's fence. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
- stult 9y ago
  >"you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". That only works until you encounter something for which there was no rational reason in the first place.
  - artimaeis 9y ago
    I've yet to encounter anything erected for no reason at all. But there are plenty of projects where rationality didn't have much a role in their choice of creation. Examples like that can usually be tied to a previous dev/engineer wanting to pad their resume with a new project, maybe with a new framework. Or a manager who wanted their team to have more completed work to look better on some miscalculated performance metric. Failing those options - it could be a bored employee who just wanted to make _something_. That is to say - most people are acting rationally, but their context to an outsider may not appear rational. Maybe there's something to be said for a general relativity of rationality?
WalterBright 9y ago
I've been writing code since the 70's. The further back in time one looks, the worse my code is. The good news, I suppose, is that one is never finished learning how to write code better. Until they plant me, that is.
Cthulhu_ 9y ago
This is not wrong; this is I think also the reason behind the "framework of the month" craze in JS that seemed to be a thing last year / year before. Implementing business value is boring; working with new technology is cool and fun. I'm not impervious to that either. I mean I'm writing a HN comment while I should be building a feature :p
deepGem 9y ago
I wonder why. Isn't it so unproductive to keep tearing down stuff and rebuilding them with the next shiniest tool ? I mean, you are making very little progress on product features.
chillidoor 9y ago
While I'm not arguing with you, I have had a different experience working with developers and microservices, perhaps because the teams have been more seasoned/experienced and there is more of a collaborative environment. I found that a lot of the time developers start moving towards microservices when they find that a monolithic app becomes too difficult to work on. For example, multiple teams working on the same codebase will often have accidental code conflicts. Plus, scaling a monolithic app because one part of it is under load isn't always cost effective or logical. So, teams will start to break off components into microservices to make development easier and less painful. Naturally this has to be weighed up as microservices bring a different set of challenges, 'gotchas', etc, etc but in my experience the teams have done a proper job discussing the pros and cons.
- bonesss 9y ago
  I think that kind of process, slow decomposition based on performance and requirements, is the only sane approach. It's also reflected in how we manage code at the micro-level: collecting related logic into a module until it becomes unwieldy and then separating out independent sub-functionality into their own modules and dependencies as they grow... There is no right size for a class. Smaller is better, but the ideal is "right sizing". What's right? Well, that's tricky, but whatever doesn't hurt is pretty ok. There's no right size for a service. Smaller is better, but...
  - chillidoor 9y ago
    Yep, there is no real "one size fits all" to microservices
sply 9y ago
But in fact, K8s provides more robustness than old good kinda monolith Pacemaker
jrs95 9y ago
This is usually true but I’ve recently been introduced to a legacy codebase which is so bad it can hardly be modified. Mixed tabs and spaces, sometimes one space indentation or no indentation at all, 1000+ line Java methods, meaningless variable names, no comments or documentation. SQL transactions aren’t used, the database is just put into a bad state and hopefully the user finishes what they’re doing so it doesn’t stay that way. That’s just the server. The UI is just as bad and based on Flash (but compiled to HTML5 now)
tboyd47 9y ago
That's absolutely true, but it's not specific to microservices. The pendulum could very well swing back the other way I've come to view microservices in the context of Conway's Law. If you have a team of developers working on a project who don't like to communicate or work with each other, do not understand version control, and all have different programming styles and technology choices, the only feasible architecture is one service per person. I have no trouble believing that this is what's really behind Netflix's adoption of microservices. From what I've heard it's a sociopathogenic work culture, and if I worked there I would probably want to just disappear from everybody too.
- corpMaverick 9y ago
  You do have to use Conway's Law to your advantage. At least be very aware of its effects.
jlg23 9y ago
I don't think microservices are loved by developers so much because they are technically superior but because they allow for quicker/safer decision-making on management level - just like "agile development" imho only helps trainee-devs but shines in providing clear communication strategies between management and developers (read: keeps mgmt off dev's back for at leat 6h a day). Abstractly spoken, I don't care whether you call f(x) directly, via IPC, RPC or as a microservice. In my preferred programming languages there is not much of a difference anyway.
tvanantwerp 9y ago
An important piece of advice I was given when embarking on my technical career: > You don't solve problems. You take the problems you have, and exchange them for a different set of problems. If you're doing your job, the new problems won't be as bad as the old problems. That's all you can really do.
deleted 9y ago
[deleted]
efa 9y ago
I 100% agree. I even catch myself thinking I didn't know what I was doing when looking at code I wrote years before. I'll jump into rewriting it and discover it was written that way for a reason. I've learned to trust my former self wasn't an idiot.
gadders 9y ago
Things you should never do, Part 1: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
warrenm 9y ago
You need to be keeping a ledger on technical debt, the same way any and all other "debt" is tracked - http://www.hydrick.net/?p=2394 http://www.hydrick.net/?p=2394 "Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative."
- mstade 9y ago
  I was wondering how such a ledger might work, given that it should be about as difficult to quantify this kind of debt as it may be to estimate the time and effort required to implement certain changes in general. Later on in the post, there's this nugget of gold: So how would this ledger work? Well, for starters it has to track what we can’t do because of current technical debt. It should also be updatable to note any complications to subsequent work or things you can’t do yet because for old design decisions. At this point, you’re tracking the “principle” (the original design decision causing technical debt) and interest (the future work that was impacted by the debt). That's it, isn't it? You need to define the principle and the interest, and these two are actual tangible things in the form of specific decisions (principle) and things that are now adversely affected by them (interest.) If these are linkable, then it should become trivial to compute a number to this debt, whether it is simply just the number of things adversely affected or some other kind of aggregate like the combined estimated effort of those adversely affected things. This debt could probably be calculated in many different ways, but the fact that you can properly quantify it should make decisions on whether to tackle or ignore the debt much more informed. This was an eye opener for me – thanks for sharing!
  - warrenm 9y ago
    Figuring how to link the “principal” and “interest” is definitely the lynchpin ... but if you’re not even noting there is principal and interest, you’ll never be able to recover

meddlepal 9y ago

I think it has to do with control. I've written microservices and microservices tooling now for a long time... so long when I started we were just calling it something like (isolated-responsibility) SOA and we didn't have a fancy buzzword. Developers want to own their thing. Microserivces desire springs up because of a lack of communication culture and desire for siloification in a companies organization to keep various interests from bothering the developers. Those almost always point to a failure of management in my mind rather than a technical failure.

deleted 9y ago
[deleted]
tyingq 9y ago
I wouldn't dismiss the effect of résumé based development either. Even if subconscious, having the latest buzzwords on your CV is a motivator.
- floogtheunfound 9y ago
  These replies are so salty
- maxxxxx 9y ago
  For me that'a conscious motivator :-)
bri3d 9y ago
Is this truly a management failure? If a few things are true, I could see this as a win: * I can isolate my developers from outside interests using microservices. * My developers are more effective in each dimension (quality, retention/happiness, velocity) because they are isolated from outside interests. * My software is easier to operate and more reliable because it is a microservice. If any of these three things aren't true, then I agree. But I'm not sure that a "communication culture" can scale to a large organization and I'd like to see a truly large company (1000+ developers) successfully doing so. I've seen more success come from separation of concerns and well-deployed microservices seem to be fairly effective to this end.
- cookiecaper 9y ago
  Microservice architectures [usually] represent a management failure because they usually don't work well in the real world. It's easy to concoct a paper-only, theoretical version of an idealized microservice architecture, since you can gloss over all the real-world details and practicalities. Mapping that theory into the real physical world is a whole different ball game. Conway's Law might as well be renamed "The Law of Microservices". Per Wikipedia [0], it states: > "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." "Microservices" are on a tear because they make a perfect cover for the blatant and bare expression of unbridled Conway's Law. Such unbridled expression is much easier in the course of greenfield development, because it lets the core team of 2-3 people per service go about their development work without consulting anyone external. It lets them throw away any overriding convention or cultural concerns, and it avoids the difficulties of cross-group coordination. But it leads to a completely unmaintainable wreck when things transition into production. This is not to say that no one will have a successful microservice deployment or that it's always a bad choice, but it usually goes way off the rails. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
  - bri3d 9y ago
    This I can entirely agree with - framing my point around Conway's law works well and I think I can reframe my question as "is the expression of Conway's law a management failure, or is it the mis-structuring of the organization causing the expression to be harmful?" The parent post I was replying to seemed to simplify things down to "let your developers communicate and they'll build a more coupled system that works, instead of a morass of microservices that don't." That's another thing that looks good on paper but doesn't scale, at least in my experience.
somberi 9y ago
" Microserivces desire springs up because of a lack of communication culture and desire for siloification" - Would have upvoted this more than once if possible.

JamesBarney 9y ago

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.

pricetag 9y ago

The company I work for is currently undergoing an effort to move many of the old PHP apis to Graphql. The repo for the graphql api wrapper was quickly becoming a monolith in itself, so it has since been broken down into separate packages. I do wonder about the sustainability of an architecture like this. This is the largest company I’ve ever worked for, so I’ve never seen how this plays out. Who will manage each package/service as time goes on and they sink into obscurity as the original team transitions out or leaves the company? I totally see some of these becoming the technical debt of the future.

ibejoeb 9y ago

It's not exclusive to inheritance, though. There are lots of times that the original principal decides that he could have done it better and winds up in exactly the same place. It could be progress, too, if it trades on set of failure modes for another that is less severe or less frequent. This is why a team needs access to good architect who's seen the paradigms shift, or even cycle. You're almost never starting from scratch, so you really need someone who's able to incorporate better or more suitable tech without throwing out the baby. If you're microservices-based, that last part is easier, even if it falls into one of the described pitfalls, e.g., system-of-systems.

raspie 9y ago

To put it in an even less flattening way, the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Microservices will not help you if your developers have the same level of skill and foresight as whoever wrote the monolith, which is probably true if those devs were selected by the same hiring process that your company has today, subject to the same organizational effectiveness, etc.

realityenigma 9y ago
I think you actually have hit the proverbial nail with the hammer. I've seen firsthand the terrible talent pool, at least here in the south-west US. We've done ourselves a disservice trying to get everyone and their brother to become a programmer because...economy! and more accurately, I want more money.
- iamdave 9y ago
  They haven't hit the proverbial nail with the hammer, they've hit the railroad spike with a sledge; IMO it's 100% about your environment and the demands and obligations your development team has against it's own obligations to deliver. I'm not going to say microservices are the cornucopia, smoking gun or even smoldering slingshot, but much of the dissent in this thread seems predicated on the idea that they are the end result and not merely an optional path to take for desired outcomes of deliverability.
qaq 9y ago
"Your company's code will be as good as your developers" as good as your companies nn% of worst developers
tabtab 9y ago
Re: ...the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Indeed! Good developers/architects spot repetition or weaknesses in current techniques and can often devise solutions that can be added to the stack or shop practices with minimal impact. You don't necessarily need paradigm or language overhauls to improve problem-areas spotted. Poor developers/architects will screw up the latest and greatest also.

humanrebar 9y ago

> In my opinion, only the extremely good developers seem to comprehend that they are almost always writing what will be considered the "technical debt" of 5 years from now when paradigms shift again. I've also seen really bad developers with that attitude: it's all crap, so just ship whatever already. The good developers write code that can be replaced, rewritten, or rescaled later. Though, charitably, both monolithic service and microservice people are trying to do exactly that. It's just what sort of scale they're thinking about and what part of the software development lifecycle they think will be especially difficult going forward.

elgenie 9y ago
The critical distinction between "it's all crap, so just ship whatever already" and what the grandparent wrote is that "technical debt" doesn't reside in easily disposable code/components, but rather as may-need-to-be-rectified-but-maybe-not-right-now downsides in what is enormously useful and producing value. Good developers create code that's prepared for the possibility of being modified repeatedly and becoming foundational; on the other hand, preparing for code/components to be thrown away is a no-op.
- humanrebar 9y ago
  > ...preparing for code/components to be thrown away is a no-op. You might be agreeing, but I find that the bad code that sticks around is bad code that is hard to get rid of. So in that sense, code that is removable isn't a no-op. It takes some effort, for instance, to keep a clear dividing line between two components so that either may be replaced someday.
foo101 9y ago
> The good developers write code that can be replaced, rewritten, or rescaled later. You make a very good point. Over the years, I learnt that almost nobody except the developer and maybe one or two peer-developers cares about good quality code. The management just wants to ship services/products. They don't care how good the code is. All they care is that they can meet their deadlines. Of course, good quality code can increase the chance of meeting deadlines, but working long hours can also increase the chance of meeting deadlines. Management does not understand code, but they understand working long hours. If I ignore this and still care enough to write good quality code, in nearly all projects, I am not going to be the only one to work on the code. There is going to be a time, when someone else has to work on the code (because responsibilities change, or because I am busy with some other project). As per my anecdata, the number of people who do not care about code quality far exceeds those who do. So this new person would most likely start developing his features on the existing clean code in a chaotic manner without sufficient thought or design. So any carefully written code also tends to become ugly in the long term. In many cases, you know that you yourself would move out the project/organization to another project/organization in a year or so, and the code would become ugly in the long term no matter what you do, so why bother writing good code in the first place! It is very disappointing to me that the field of programming and software development that I once used to love so much out of passion has turned out to be such a commercial, artless, and dispassionate field. How do you retain your motivation to be a good developer in such a situation?

pweissbrod 9y ago

The monolith first approach has always served me well. Nascent projects benefit from portability because they need higher amounts of flux. As they mature let's assume they grow in scale and integrations and somewhere along the line it becomes sensible to break off pieces into services. To me the big benefit of microservices is scaling out components into flexible independent release cadences but the trouble comes with employing them too early. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html

tehlike 9y ago

If something isn't broken, do not fix. I think part of it is that large companies can keep engineers happy by giving them rewrites. Otherwise, not enough projects to keep everyone entertained.

deepsun 9y ago
Well, the best architectured project I've ever worked on in Google was actually rewritten 4 times from scratch. I believe rewriting is always good for the project. Not always for business, though. Fortunately, Google had resources to allow rewrites to happen. Rewrites also serve as thorough code review and security audit.
- tehlike 9y ago
  Were the previous ones not getting the job done? 4 rewrites over what time period? I am more in the camp of "let's do something useful" than "let's rewrite this because previous guy didn't do it good, or it no longer meets our demands". Because whatever you do it will get rewritten again, and it's imho useful to resist the urge. Ps: also a googler.

rtpg 9y ago

Do you legit think that people are all just doing this as a fad? There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course. The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And its not even not doing it right, but simply that scales change. Or patterns change. And in new companies, it _could_ be that people don't get it. "Microservices as mass delusion" discounts a lot of people who are really thinking hard about how to handle the pros and the cons of things.

nucleardog 9y ago
> Do you legit think that people are all just doing this as a fad? As you say there are a lot of pros and cons to any architecture or paradigm, which is why we're still talking about it and saying things like "right tool for the job" and not just using the One True Method(TM). I legit think that a lot of people using the new hotness as a form of cargo cult programming with no understanding of the methods they're considering or how they apply to the problems they're trying to solve. It's not just microservices that are improperly applied. I've been in the industry long enough to see dozens of languages, technologies, paradigms, processes, and everything else hailed as the second coming of christ and applied inappropriately all over the place until the shinyness wore off. And I mean... When we start talking about developing for Amazon scale, we're already talking about situations that don't apply to 99% of developers. Not a great argument that their cases aren't inappropriate applications of the pattern.
philwelch 9y ago
The ops cost of not using microservices is a lot higher than you'd think, too. At some point, when you have hundreds of engineers and your monolith is compiled together from libraries written by a dozen different teams and you have to try and make one heroic release per week, except half the time it fails and you have to go back and fix it, and absolutely no one in the company can ship a new feature because you're blocked.
- 9y ago

kbuchanan 9y ago

A little over two years ago my little team of three (gasp!) succumbed to the allure of microservices. After six months of writing custom solutions for problems I'd created, I bagged it. The _one_ upside of our microservice architecture was how simple it was to consolidate back into a single app. Only took a couple months. I believe the theoretical benefits of microservices, namely, hard domain boundaries, remain compelling, but geez, I also learned its benefits are extremely circumstantial.

cookiecaper 9y ago
Props to you for realizing you were going down a bad path and cutting your losses. Many people are unwilling to honestly evaluate their projects until they've been in the rear view mirror for a long time. A great deal of software is driven by ego and fads, and it's great to see someone make a decision to change pace based on practicalities.

deleted 9y ago

[deleted]

dreamcompiler 9y ago

I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.

markatkinson 9y ago
Great analogy. I tried to paint my own flat. Was a disaster.
- WalterBright 9y ago
  I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.
  - moreless 9y ago
    For us non-english speakers - "sheetrock" == drywall. I find I can do most such works better than (average) professionals, but it takes a lot of time to learn, prepare, execute (+ sometimes re-execute) and clean. It all depends on when you are satisfied with the result.
    - Jaruzel 9y ago
      I recently came across 'sheetrock' as a term and had to google it... For UK natives it's actually three steps: "sheetrock" == drywall == Plasterboard
      - logfromblammo 9y ago
        I have also heard it as "gypsum wallboard", which is certainly most descriptive. I'm not certain whether the water-resistant, mold-resistant variety typically hung behind tiles in bathrooms is ever referred to as "wetwall" or if they still call it "drywall". Nor am I aware of whether anyone calls the foil-backed, glass-reinforced, fire-resistant variety "firewall" instead of "drywall". I wouldn't be surprised if obsolete and inapplicable names still attach to items with the same function. If we ever move to polyethylene film panels sandwiched with phase-change material for our walls, it might still be called "plasterboard" somewhere.

maga_2020 9y ago

I think these are appealing for 2 reasons: 1. There is a believe, that component isolation (taken to extreme by microservices) enables better productivity of the development department. That is more features, more prototypes, more people can be moved in and out a given role. So that those 5 crusty programmers are not a bottleneck for the 'next great idea' that a Product manager or CIO reads up on. 2. There is a constant battle for the crown of "I am modern" (eg data science, micro services, big data ) That is going on in every development or technology organization. Where the closer you are in your 'vision' to google or Netflix, the more 'modern' you are. The rest of the folks is 'legacy'. So you get budgets, you get to hire, you get to 'lead'. Micro-services is the enabler to help to win this battle (although, probably, for a short term). --- I personally, do not believe that microservices bring anything new compared to previously used methods of run-time modularization : Plugins Web services RPC N-tier architectures I do not think they replace the standards like CORBA, although I think they will end up eventually replicating it, with better thought out standards and tools.

rb808 9y ago

> the pattern I've seen time and time again is Developers thinking the previous generation had no idea what they were doing and they'll do it way better. They usually nail the first 80%, then hit a new edge case not well handled by their architecture/model Perfect, I've seen this happen many times as well. I think you're generous on the 80% part. Usually they nail the first 50%, but they time they get to 80% its getting just as messy and some of the developers are planning another rewrite again.

amrx101 9y ago

Damn, you described my manager.

fulafel 9y ago

The reinvention and re-discovery of the problems can be very good for the new developers who are taking over a slice of the monolith's functionality. And it an happen rapidly, on the new developers' own terms. Depends on the case.

simias 9y ago

The #1 thing they should teach in any engineering school (or maybe any school period) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".

ZeroGravitas 9y ago
Would those graduates be rewarded or penalised for their professionalism? I would guess penalised in a depressing number of situations.
dancek 9y ago
This principle is commonly known as Chesterton's fence. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
stult 9y ago
>"you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". That only works until you encounter something for which there was no rational reason in the first place.
- artimaeis 9y ago
  I've yet to encounter anything erected for no reason at all. But there are plenty of projects where rationality didn't have much a role in their choice of creation. Examples like that can usually be tied to a previous dev/engineer wanting to pad their resume with a new project, maybe with a new framework. Or a manager who wanted their team to have more completed work to look better on some miscalculated performance metric. Failing those options - it could be a bored employee who just wanted to make _something_. That is to say - most people are acting rationally, but their context to an outsider may not appear rational. Maybe there's something to be said for a general relativity of rationality?

WalterBright 9y ago

I've been writing code since the 70's. The further back in time one looks, the worse my code is. The good news, I suppose, is that one is never finished learning how to write code better. Until they plant me, that is.

Cthulhu_ 9y ago

This is not wrong; this is I think also the reason behind the "framework of the month" craze in JS that seemed to be a thing last year / year before. Implementing business value is boring; working with new technology is cool and fun. I'm not impervious to that either. I mean I'm writing a HN comment while I should be building a feature :p

deepGem 9y ago

I wonder why. Isn't it so unproductive to keep tearing down stuff and rebuilding them with the next shiniest tool ? I mean, you are making very little progress on product features.

chillidoor 9y ago

While I'm not arguing with you, I have had a different experience working with developers and microservices, perhaps because the teams have been more seasoned/experienced and there is more of a collaborative environment. I found that a lot of the time developers start moving towards microservices when they find that a monolithic app becomes too difficult to work on. For example, multiple teams working on the same codebase will often have accidental code conflicts. Plus, scaling a monolithic app because one part of it is under load isn't always cost effective or logical. So, teams will start to break off components into microservices to make development easier and less painful. Naturally this has to be weighed up as microservices bring a different set of challenges, 'gotchas', etc, etc but in my experience the teams have done a proper job discussing the pros and cons.

bonesss 9y ago
I think that kind of process, slow decomposition based on performance and requirements, is the only sane approach. It's also reflected in how we manage code at the micro-level: collecting related logic into a module until it becomes unwieldy and then separating out independent sub-functionality into their own modules and dependencies as they grow... There is no right size for a class. Smaller is better, but the ideal is "right sizing". What's right? Well, that's tricky, but whatever doesn't hurt is pretty ok. There's no right size for a service. Smaller is better, but...
- chillidoor 9y ago
  Yep, there is no real "one size fits all" to microservices

sply 9y ago

But in fact, K8s provides more robustness than old good kinda monolith Pacemaker

jrs95 9y ago

This is usually true but I’ve recently been introduced to a legacy codebase which is so bad it can hardly be modified. Mixed tabs and spaces, sometimes one space indentation or no indentation at all, 1000+ line Java methods, meaningless variable names, no comments or documentation. SQL transactions aren’t used, the database is just put into a bad state and hopefully the user finishes what they’re doing so it doesn’t stay that way. That’s just the server. The UI is just as bad and based on Flash (but compiled to HTML5 now)

tboyd47 9y ago

That's absolutely true, but it's not specific to microservices. The pendulum could very well swing back the other way I've come to view microservices in the context of Conway's Law. If you have a team of developers working on a project who don't like to communicate or work with each other, do not understand version control, and all have different programming styles and technology choices, the only feasible architecture is one service per person. I have no trouble believing that this is what's really behind Netflix's adoption of microservices. From what I've heard it's a sociopathogenic work culture, and if I worked there I would probably want to just disappear from everybody too.

corpMaverick 9y ago
You do have to use Conway's Law to your advantage. At least be very aware of its effects.

jlg23 9y ago

I don't think microservices are loved by developers so much because they are technically superior but because they allow for quicker/safer decision-making on management level - just like "agile development" imho only helps trainee-devs but shines in providing clear communication strategies between management and developers (read: keeps mgmt off dev's back for at leat 6h a day). Abstractly spoken, I don't care whether you call f(x) directly, via IPC, RPC or as a microservice. In my preferred programming languages there is not much of a difference anyway.

tvanantwerp 9y ago

An important piece of advice I was given when embarking on my technical career: > You don't solve problems. You take the problems you have, and exchange them for a different set of problems. If you're doing your job, the new problems won't be as bad as the old problems. That's all you can really do.

deleted 9y ago

[deleted]

efa 9y ago

I 100% agree. I even catch myself thinking I didn't know what I was doing when looking at code I wrote years before. I'll jump into rewriting it and discover it was written that way for a reason. I've learned to trust my former self wasn't an idiot.

gadders 9y ago

Things you should never do, Part 1: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

warrenm 9y ago

You need to be keeping a ledger on technical debt, the same way any and all other "debt" is tracked - http://www.hydrick.net/?p=2394 http://www.hydrick.net/?p=2394 "Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative."

mstade 9y ago
I was wondering how such a ledger might work, given that it should be about as difficult to quantify this kind of debt as it may be to estimate the time and effort required to implement certain changes in general. Later on in the post, there's this nugget of gold: So how would this ledger work? Well, for starters it has to track what we can’t do because of current technical debt. It should also be updatable to note any complications to subsequent work or things you can’t do yet because for old design decisions. At this point, you’re tracking the “principle” (the original design decision causing technical debt) and interest (the future work that was impacted by the debt). That's it, isn't it? You need to define the principle and the interest, and these two are actual tangible things in the form of specific decisions (principle) and things that are now adversely affected by them (interest.) If these are linkable, then it should become trivial to compute a number to this debt, whether it is simply just the number of things adversely affected or some other kind of aggregate like the combined estimated effort of those adversely affected things. This debt could probably be calculated in many different ways, but the fact that you can properly quantify it should make decisions on whether to tackle or ignore the debt much more informed. This was an eye opener for me – thanks for sharing!
- warrenm 9y ago
  Figuring how to link the “principal” and “interest” is definitely the lynchpin ... but if you’re not even noting there is principal and interest, you’ll never be able to recover