8 ms·

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolith"), that is composed of many different libraries that have well defined interfaces which can be tested in isolation. In fact, that's how most non-web software is still written and done. The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase and enforce their control via separate repo's, and when speaking runtime, via authentication: Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance of her service that gives a guess at how long the car has to arrive to pick poor end user Bob up. I've seen this same thing play out countless times at large tech companies and startups alike. It has nothing to do with building scalable, or more maintainable, or more cleverly designed applications. If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. Not to mention all the issues and headaches caused by fan out of tons of API requests, complicated caching scenarios, etc. I've seen the horror of microservices architecture where no one person is responsible for the actual app, only their "service". There are a few exceptions where its useful to scale out parts of a distributed application, but in 99% of my experience the services aren't a real distributed system anyway and are vaguely organized by function, developer interest, and yes, control.

solipsism 10y ago
in 99% of my experience the services aren't a real distributed system anyway What is a real distributed system?
- lifeisstillgood 10y ago
  To work that out you need to go back when the Galaxy was young, men were real men, women were real women, and small brown furry distributed systems from Alpha Centauri were real small brown furry distributed systems from Alpha Centauri.... Sorry...
- djspoons 10y ago
  A distributed system is one that can fail in new and novel ways
jordwest 10y ago
Any organization that designs a system ... will inevitably produce a design whose structure is a copy of the organization's communication structure — M. Conway
- PJDK 10y ago
  I've heard this said a few times, but never really felt it rung true to systems I've seen/designed. Anyone have any examples?
  - asdfaoeu 10y ago
    Damn, can I get a job where you work?
  - deleted 10y ago
    [deleted]
dasil003 10y ago
If you read my top-level comment you'll see that I agree with you 90%, but careful not to throw the baby out with the bathwater. There are legitimate reasons why having those fiefdoms is beneficial despite the overhead. Especially in a SaaS world where you are not distributing binaries. Being able to use different languages for different purposes, and to deploy them to different hardware can be quite a bit more efficient in terms of hardware costs at scale. Also there is something to be said for "you write it, you run it" as it makes developers more careful and decreases finger-pointing. Again, don't take this as a rebuttal, the overhead is potentially a lot, but if clean interfaces can be determined and makes sense from a high-level business perspective then there can be a net gain.
hibikir 10y ago
You say it as if it's a bad thing... Compared to the alternative, fiefdoms really are a wonderful thing! I once work for a giant fortune 500 corporation. Our department had a good 300 developers, and had been writing code for years. They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, had to be deployed pretty much at the same time, and version upgrades had to go in lockstep. Every so often, database changes were necessary, and the world would grind to a halt for months to make the system still work after the migration: It was awful. On top of this, having everyone using one stack really meant that a council of elders got to make tech decisions, and everyone else just did what they were told. This built a giant hierarchy. People near the top would never leave, because nowhere else would give them that much power. Talented developers would take years to gain influence, so they often just left. What remained was developers with no ambitions other than getting a paycheck... it was horrible. The alternative was to let people maintain their own stacks, as long as they provided interfaces that other people could call. By limiting how much code could talk to a database, you didn't need negotiations to change something: Teams made any change they wanted as long as they remained backwards compatible, and then had to lobby users to upgrade to newest API versions if they wanted to remove the backwards compatibility mess. It was awesome in comparison. A gigantic place won't have those problems, because they can invest money on making whatever tech decisions they made tenable: PHP is slow? Let's build a new runtime and compiler, says Facebook! If you are tiny, you don't need any of this BS, because if your team of 8 engineers can't agree, your company will fail regardless. But when you have 200 engineers, it's giving people more control over a piece of the pie or bleeding talent. The one thing you still need to do is make sure teams have the right size, and people have enough accountability, that the product still works. You also need silly amounts of data marshaling and error checking compared to the monolith. But the terror of a company that can't hire engineers because the only way to have any control over your daily life is to have been there for 5 years is just hard to compare. When people say they don't want to work big corporate gigs, what they really mean is that monoliths become soul sucking. So yes, I give thumbs up to fiefdoms, just like I'd rather have inefficiency in a republic vs a theoretically efficient dictatorship.
- r2dnb 10y ago
parasubvert 10y ago
" in 99% of my experience the services aren't a real distributed system anyway and are vaguely organized by function, developer interest, and yes, control." But, that's kind of the point. They're a networked system of interacting processes, but not a distributed system. A distributed system generally is a tightly coupled and coordinated set of services running on many machines for purposes of resilience or scale-out. Microservices are more for organizational scale-out. A microservices might BE a distributed system, but several interacting microservices probably isn't one (pedantically speaking). Microservices are an evolution of how large-scale integrated systems have played out as a pendulum swing between tightly coupled systems and loosely coupled systems. After the mainframe, into the client-server era, most non-web software in a large organization (eg. most IT back offices dating back to the 90s) were NOT built as a single application, it was built as a set of independent applications that were coordinated by something: a shared database, data extracts, message queues, transaction processors and RPCs. Data extracts were the ultimate in loose coupling. You got an update every night from other databases, and could do whatever you wanted with the data. But of course, this led to data quality problems, when customer records or inventory couldn't reconcile. So we moved to "a service owns its data" type situations, and wrapped them in message queues or RPCs. This is basically how something like SAP works - it's a set of modules with their own schemas that are tightly coupled through a set of RPCs and messages. But this eventually had none of the benefits of networked modularity - everything was so coupled and intertwined, it was a mess to change and upgrade - you had to do the whole thing at once (which is why SAP upgrades are so notorious). What makes microservices different is that we've evolved them to have truly independent interface from implementation by having the implementation lifecycle of a module be tied to the server down to the metal, so it can be completely autonomous from other services. Therefore I can upgrade/replace/scale/move these runtimes whereever I want, whenever I want. I can also place proxy or gateway intermediaries between them more easily. This is "SOA done well", in effect. We've also evolved our practice of service interface design beyond rigid IDLs and WSDLs and schemas into more permissive, extensible, and better documented APIs or Events, along with easier versioning, but the state of the art still has a long way to go there. Not a panacea, but on the flip side, I've rarely seen a maintainable, scalable, and easy to change networked monolith. They do exist, but required the controlling designers to be deeply talented with full control over architecture decisions, and they didn't get into analysis paralysis. But even they eventually couldn't keep up with changes, so they're breaking their monoliths up today, IME.
DanielBMarkham 10y ago
I think you've missed the point in several different ways here. First, there's a difference between "I've seen it done like X" and "When done well, it's done like Y" Too often we play this game where we talk, teach, and apply Y, but then in the real world it gets done like X. Turns out that X sucks a lot, so then we throw away Y. Microservices may be done poorly in most real world applications. In fact it would surprise me if they weren't. This article doesn't help much. Microservices are not just another version of SOA. It doesn't work that way. In SOA, you start with a general category of service, say "logging". You write it simple, yet broad, and it's supposed to handle all folks that need logging. In microservices, you're doing one tiny little thing, like "make a record of the errors of this process available on the web". The vast majority of times, if you define what you're doing narrowly enough? The O/S already does it. Whereas if you start broad? You're writing code. Then you slowly and methodically expand on that mission a little bit at a time, refactoring your microservices as you go. It's both a different way of structuring apps from monolithic days and a different way of looking at constructing and maintaining apps. If you think of it as the same blob of binary bits broken into smaller pieces, you've missed it. Likewise if you think of it in terms of "services". The "micro" is the key word here, not the "services" part. This actually requires a much heavier interaction between developers, not setting up fiefdoms. If done correctly, it pushes larger groups of developers across teams to work more tightly together. If it's doing something else? You're doing it wrong.
- nostrademons 10y ago
  If you're starting "micro", why do you need the "services" part at all? Why not just make it a function call? To use your example, if my task were "make a record of the errors of this process available on the web", my first thought would be to write to stderr, pipe stderr to a file, and then serve that from the webroot of some commodity webserver like Apache, 'python -m SimpleHTTPServer', or even S3. If the format is too hard to read, I'd probably write a quick JS viewer that can collapse stack traces, aggregate similar errors, etc, all done in the web browser. Or use cut/awk/sed to process it before dumping it in the webroot. It's only if the data gets big enough that it starts freezing the browser that I'd reach for ELK or something similar. I don't know anyone who would call this a "service" though; indeed, it seems the polar opposite of what most people talk about when they say "microservices".
r2dnb 10y ago
>In fact, that's how most non-web software is still written and done. I can even add that we only do web software, but we do them exactly that way. >If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them". >There are a few exceptions where its useful to scale out parts of a distributed application Yes, and very very very few. As I always say : microservices are not an architecture, they are an optimization.
- StavrosK 10y ago
  > I can even add that we only do web software, but we do them exactly that way. I can even add that not only do we do them exactly that way, but it's many times faster and more reliable than microservices, for reasons I have written about before[1]. The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost. [1]: https://www.stavros.io/posts/microservices-cargo-cult/ https://www.stavros.io/posts/microservices-cargo-cult/
  - vonmoltke 10y ago
    > The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost. If you are writing and deploying standalone applications, I agree. Microservices do have another benefit, though: forcing the application to be modularized. There are better ways to do that, though, like having proper systems engineering lay out the application architecture. If you are writing applications that need to be integrated with third-party applications or need to be configured with different functionality for different customers, microservices can still make sense. This is what has pushed my company in that direction. We currently have a set of monolithic applications with varying but overlapping functionality, and customers who want feature X from application Y and feature W from application Z, plus feature V that we are developing just for them. Our code has become a mess of curricular dependencies and duplicated code in order to meet these desires. The microservice (maybe not micro, but definitely service) architecture we are moving to will allow us to compose applications with reusable building blocks more easily than trying to maintain different git branches and library versions. It also allows us to better manage the non-code resources we need to deploy as we have hundreds of gigs of data resources used by various libraries. Furthermore, we will be able to deploy applications with either our in-house GUI and command line tools, as well as provide the APIs necessary for our customers to integrate our applications into their own third-party frameworks.
partycoder 10y ago
When you have a large service, you can end up with a lot of coupling. Meaning that it is hard to have teams that specialize in specific parts of the application, you need a huge team that knows everything about everything and that doesn't scale as your code and company grows. And you can see the effects of that in reduced productivity and technical debt beyond belief. Even if you hire high-end talent, they will be forced to worship people that have the knowledge about how all the bloated jenga-tower mess works. And that's only the people problem, let's not even discuss how you build, deploy, test things in a reliable way without taking days to produce a working build. That, and the fact that your quality of life will suck, since you won't be in control of such mess. With microservices you have one service that does a limited set of things, that is easy to monitor, maintain, test, deploy and even entirely replace if necessary.
deleted 10y ago
[deleted]
gedrap 10y ago
Services can be used and are used when a developer wants to try something fancy in an otherwise boring, simple tech stack. No one says that, it's usually covered as 'best tool for the job' but oh that can be very dangerous.
CuriouslyC 10y ago
I do agree that people tend to over-complicate their architectures initially, this is premature optimization of another form. That being said: * Microservices don't need to be written in the host language, nor do you need to deal with creating wrappers. Granted interacting with kafka/ampq isn't frictionless. * Microservices can be upgraded or scaled out individually without touching the larger application as a whole. * Microservice calls can be deferred and scheduled easily.
quantumhobbit 10y ago
Microservices are for organizations that can't seem to enforce encapsulation at the object level. Devs not creating good interfaces in OO design? Stick them on a different server, that ought to show them. Of course now your spaghettified object hierarchies are spaghettified api call hierarchies.
dmreedy 10y ago
I agree about fiefdoms, and want to address a particular aspect of that pattern, somewhat complementary to yours, that I've seen at least in the (very large) organization that I'm a member of. Specifically, like a microservice allows encapsulation of functionality, it also allows encapsulation of blame[1]. In a monolith (from whence the org I'm in came), a build failure or test regression could be caused by any number of failures across any number of horizontal bands in the organization. Oh, the build automation crashed because the build team updated to the latest version of Java but the build didn't. Oh, the UI Filters stopped working because the API team changed something without deprecating. It meant that development, in spite of agile efforts, still had a tick-tock cadence, where breaks halted work and tracking down the responsible parties and getting things fixed might take time (a lot of areas with deep specialties required to understand why something might be wrong). This also meant, because of the way the organization was structured and the way the build was structured, that "pressure" was directed along very hierarchical routes. Managers saw bugs from customers and pressured testers and dev-ops people who maintained automation to investigate causes and transfer responsiblity to developers who might be able to actually fix the problems. As we've been decomposing into microservices, and likewise aligning along feature teams the blame gets allocated at API/service interfaces[2] instead of top-down. Since the build, deployment, uptime, and algorithmic functionality of each service is theoretically the domain of a single team, the blame-flow is more distributed and simple. An algorithmic bug, a build bug, and an availability issue are all addressed the same way: report the issue to the team responsible for that service, and let them work it out. I'm not advocating that either way is better. There were nice aspects about a single-location debug tree in the monolith. I've seen teams that have become experts at deflecting blame and thus slow down the entire broader effort. And I know I'm possibly conflating two paradigms inappropriately (Feature Teams and Microservices). Just a notable pattern, to my eyes. --- [1] I don't necessarily mean 'blame' here in a pejorative sense. Perhaps 'responsibility' would be a more neutral term. [2] Steve Yegge describes to this being a top priority during Amazon's service/platform decomposition.
- piotrkubisa 10y ago
  > The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase [...] Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance... > Specifically, like a microservice allows encapsulation of functionality, it also allows encapsulation of blame I think, the example of Joe's and Sally in parent [1] and your comment, makes the point in micro-services. During various Web Services integrations developers not only may blame specific part of system as faulty but also helps follow rule 'do not test your own code'. I remember few situation in pre-microservices era when during developing new API wrapper developers discovered a flaw in the remote web service (e.g. parameter doesn't change state) non-documented error code or raw Java exception as response. In these cases, owners of the API are are usually notified about issue so we may expect that will be fixed. I agree with you that is hard way to advocate either way is better. It is worth noting that creating a micro services leads to problem which may end with _duplicating_ (creating monolithic) code to provide possibility to communicate between the hosts (imagine mesh network). [1]: https://news.ycombinator.com/item?id=12134648 https://news.ycombinator.com/item?id=12134648
pjlegato 10y ago
It happens for another reason too: everyone likes to flatter themselves that they're top-tier big shots, that they're "web scale," that they have the same scaling problems and uptime problems that Google and Facebook have, and thus they think they need to adopt the same architecture patterns that Google and Facebook use. Someone builds a monolith, it gets some traction, and suddenly the server bill gets into five, six figures a month. Management have never been management before, and have never paid anything more than a few hundred dollars a month for servers, so their new cloud bill is mind blowing to them. They're spending as much money as a house costs every month on renting servers. They imagine they're hemmoraging cash right and left, they freak out and order engineering to rearchitect everything around a Service Oriented Architecture, because clearly it's time for the big boy toys. Google does it that way, so clearly that's what one does when one is at scale, when one is successful and has lots of paying customers, right? 99.9% would be better off financially and technically just rewriting a V2 of the monolith using lessons learned from V1, but that's perceived as outmoded, old-world thinking, because it's not what Google does.
- elgoog1212 10y ago
  This comment is made all the more humorous by the fact that Google doesn't actually do "microservices" internally. They have no qualms about building giant, monolithic binaries for things, and split things out based on the need, not some blind architectural fetish. The reason being, they don't like to be woken up by their pagers.

solipsism 10y ago

in 99% of my experience the services aren't a real distributed system anyway What is a real distributed system?

lifeisstillgood 10y ago
To work that out you need to go back when the Galaxy was young, men were real men, women were real women, and small brown furry distributed systems from Alpha Centauri were real small brown furry distributed systems from Alpha Centauri.... Sorry...
djspoons 10y ago
A distributed system is one that can fail in new and novel ways

jordwest 10y ago

Any organization that designs a system ... will inevitably produce a design whose structure is a copy of the organization's communication structure — M. Conway

PJDK 10y ago
I've heard this said a few times, but never really felt it rung true to systems I've seen/designed. Anyone have any examples?
- asdfaoeu 10y ago
  Damn, can I get a job where you work?
- deleted 10y ago
  [deleted]

dasil003 10y ago

If you read my top-level comment you'll see that I agree with you 90%, but careful not to throw the baby out with the bathwater. There are legitimate reasons why having those fiefdoms is beneficial despite the overhead. Especially in a SaaS world where you are not distributing binaries. Being able to use different languages for different purposes, and to deploy them to different hardware can be quite a bit more efficient in terms of hardware costs at scale. Also there is something to be said for "you write it, you run it" as it makes developers more careful and decreases finger-pointing. Again, don't take this as a rebuttal, the overhead is potentially a lot, but if clean interfaces can be determined and makes sense from a high-level business perspective then there can be a net gain.

hibikir 10y ago

You say it as if it's a bad thing... Compared to the alternative, fiefdoms really are a wonderful thing! I once work for a giant fortune 500 corporation. Our department had a good 300 developers, and had been writing code for years. They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, had to be deployed pretty much at the same time, and version upgrades had to go in lockstep. Every so often, database changes were necessary, and the world would grind to a halt for months to make the system still work after the migration: It was awful. On top of this, having everyone using one stack really meant that a council of elders got to make tech decisions, and everyone else just did what they were told. This built a giant hierarchy. People near the top would never leave, because nowhere else would give them that much power. Talented developers would take years to gain influence, so they often just left. What remained was developers with no ambitions other than getting a paycheck... it was horrible. The alternative was to let people maintain their own stacks, as long as they provided interfaces that other people could call. By limiting how much code could talk to a database, you didn't need negotiations to change something: Teams made any change they wanted as long as they remained backwards compatible, and then had to lobby users to upgrade to newest API versions if they wanted to remove the backwards compatibility mess. It was awesome in comparison. A gigantic place won't have those problems, because they can invest money on making whatever tech decisions they made tenable: PHP is slow? Let's build a new runtime and compiler, says Facebook! If you are tiny, you don't need any of this BS, because if your team of 8 engineers can't agree, your company will fail regardless. But when you have 200 engineers, it's giving people more control over a piece of the pie or bleeding talent. The one thing you still need to do is make sure teams have the right size, and people have enough accountability, that the product still works. You also need silly amounts of data marshaling and error checking compared to the monolith. But the terror of a company that can't hire engineers because the only way to have any control over your daily life is to have been there for 5 years is just hard to compare. When people say they don't want to work big corporate gigs, what they really mean is that monoliths become soul sucking. So yes, I give thumbs up to fiefdoms, just like I'd rather have inefficiency in a republic vs a theoretically efficient dictatorship.

r2dnb 10y ago

parasubvert 10y ago

" in 99% of my experience the services aren't a real distributed system anyway and are vaguely organized by function, developer interest, and yes, control." But, that's kind of the point. They're a networked system of interacting processes, but not a distributed system. A distributed system generally is a tightly coupled and coordinated set of services running on many machines for purposes of resilience or scale-out. Microservices are more for organizational scale-out. A microservices might BE a distributed system, but several interacting microservices probably isn't one (pedantically speaking). Microservices are an evolution of how large-scale integrated systems have played out as a pendulum swing between tightly coupled systems and loosely coupled systems. After the mainframe, into the client-server era, most non-web software in a large organization (eg. most IT back offices dating back to the 90s) were NOT built as a single application, it was built as a set of independent applications that were coordinated by something: a shared database, data extracts, message queues, transaction processors and RPCs. Data extracts were the ultimate in loose coupling. You got an update every night from other databases, and could do whatever you wanted with the data. But of course, this led to data quality problems, when customer records or inventory couldn't reconcile. So we moved to "a service owns its data" type situations, and wrapped them in message queues or RPCs. This is basically how something like SAP works - it's a set of modules with their own schemas that are tightly coupled through a set of RPCs and messages. But this eventually had none of the benefits of networked modularity - everything was so coupled and intertwined, it was a mess to change and upgrade - you had to do the whole thing at once (which is why SAP upgrades are so notorious). What makes microservices different is that we've evolved them to have truly independent interface from implementation by having the implementation lifecycle of a module be tied to the server down to the metal, so it can be completely autonomous from other services. Therefore I can upgrade/replace/scale/move these runtimes whereever I want, whenever I want. I can also place proxy or gateway intermediaries between them more easily. This is "SOA done well", in effect. We've also evolved our practice of service interface design beyond rigid IDLs and WSDLs and schemas into more permissive, extensible, and better documented APIs or Events, along with easier versioning, but the state of the art still has a long way to go there. Not a panacea, but on the flip side, I've rarely seen a maintainable, scalable, and easy to change networked monolith. They do exist, but required the controlling designers to be deeply talented with full control over architecture decisions, and they didn't get into analysis paralysis. But even they eventually couldn't keep up with changes, so they're breaking their monoliths up today, IME.

DanielBMarkham 10y ago

I think you've missed the point in several different ways here. First, there's a difference between "I've seen it done like X" and "When done well, it's done like Y" Too often we play this game where we talk, teach, and apply Y, but then in the real world it gets done like X. Turns out that X sucks a lot, so then we throw away Y. Microservices may be done poorly in most real world applications. In fact it would surprise me if they weren't. This article doesn't help much. Microservices are not just another version of SOA. It doesn't work that way. In SOA, you start with a general category of service, say "logging". You write it simple, yet broad, and it's supposed to handle all folks that need logging. In microservices, you're doing one tiny little thing, like "make a record of the errors of this process available on the web". The vast majority of times, if you define what you're doing narrowly enough? The O/S already does it. Whereas if you start broad? You're writing code. Then you slowly and methodically expand on that mission a little bit at a time, refactoring your microservices as you go. It's both a different way of structuring apps from monolithic days and a different way of looking at constructing and maintaining apps. If you think of it as the same blob of binary bits broken into smaller pieces, you've missed it. Likewise if you think of it in terms of "services". The "micro" is the key word here, not the "services" part. This actually requires a much heavier interaction between developers, not setting up fiefdoms. If done correctly, it pushes larger groups of developers across teams to work more tightly together. If it's doing something else? You're doing it wrong.

nostrademons 10y ago
If you're starting "micro", why do you need the "services" part at all? Why not just make it a function call? To use your example, if my task were "make a record of the errors of this process available on the web", my first thought would be to write to stderr, pipe stderr to a file, and then serve that from the webroot of some commodity webserver like Apache, 'python -m SimpleHTTPServer', or even S3. If the format is too hard to read, I'd probably write a quick JS viewer that can collapse stack traces, aggregate similar errors, etc, all done in the web browser. Or use cut/awk/sed to process it before dumping it in the webroot. It's only if the data gets big enough that it starts freezing the browser that I'd reach for ELK or something similar. I don't know anyone who would call this a "service" though; indeed, it seems the polar opposite of what most people talk about when they say "microservices".

r2dnb 10y ago

>In fact, that's how most non-web software is still written and done. I can even add that we only do web software, but we do them exactly that way. >If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them". >There are a few exceptions where its useful to scale out parts of a distributed application Yes, and very very very few. As I always say : microservices are not an architecture, they are an optimization.

StavrosK 10y ago
> I can even add that we only do web software, but we do them exactly that way. I can even add that not only do we do them exactly that way, but it's many times faster and more reliable than microservices, for reasons I have written about before[1]. The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost. [1]: https://www.stavros.io/posts/microservices-cargo-cult/ https://www.stavros.io/posts/microservices-cargo-cult/
- vonmoltke 10y ago
  > The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost. If you are writing and deploying standalone applications, I agree. Microservices do have another benefit, though: forcing the application to be modularized. There are better ways to do that, though, like having proper systems engineering lay out the application architecture. If you are writing applications that need to be integrated with third-party applications or need to be configured with different functionality for different customers, microservices can still make sense. This is what has pushed my company in that direction. We currently have a set of monolithic applications with varying but overlapping functionality, and customers who want feature X from application Y and feature W from application Z, plus feature V that we are developing just for them. Our code has become a mess of curricular dependencies and duplicated code in order to meet these desires. The microservice (maybe not micro, but definitely service) architecture we are moving to will allow us to compose applications with reusable building blocks more easily than trying to maintain different git branches and library versions. It also allows us to better manage the non-code resources we need to deploy as we have hundreds of gigs of data resources used by various libraries. Furthermore, we will be able to deploy applications with either our in-house GUI and command line tools, as well as provide the APIs necessary for our customers to integrate our applications into their own third-party frameworks.

partycoder 10y ago

When you have a large service, you can end up with a lot of coupling. Meaning that it is hard to have teams that specialize in specific parts of the application, you need a huge team that knows everything about everything and that doesn't scale as your code and company grows. And you can see the effects of that in reduced productivity and technical debt beyond belief. Even if you hire high-end talent, they will be forced to worship people that have the knowledge about how all the bloated jenga-tower mess works. And that's only the people problem, let's not even discuss how you build, deploy, test things in a reliable way without taking days to produce a working build. That, and the fact that your quality of life will suck, since you won't be in control of such mess. With microservices you have one service that does a limited set of things, that is easy to monitor, maintain, test, deploy and even entirely replace if necessary.

deleted 10y ago

[deleted]

gedrap 10y ago

Services can be used and are used when a developer wants to try something fancy in an otherwise boring, simple tech stack. No one says that, it's usually covered as 'best tool for the job' but oh that can be very dangerous.

CuriouslyC 10y ago

I do agree that people tend to over-complicate their architectures initially, this is premature optimization of another form. That being said: * Microservices don't need to be written in the host language, nor do you need to deal with creating wrappers. Granted interacting with kafka/ampq isn't frictionless. * Microservices can be upgraded or scaled out individually without touching the larger application as a whole. * Microservice calls can be deferred and scheduled easily.

quantumhobbit 10y ago

Microservices are for organizations that can't seem to enforce encapsulation at the object level. Devs not creating good interfaces in OO design? Stick them on a different server, that ought to show them. Of course now your spaghettified object hierarchies are spaghettified api call hierarchies.

dmreedy 10y ago

I agree about fiefdoms, and want to address a particular aspect of that pattern, somewhat complementary to yours, that I've seen at least in the (very large) organization that I'm a member of. Specifically, like a microservice allows encapsulation of functionality, it also allows encapsulation of blame[1]. In a monolith (from whence the org I'm in came), a build failure or test regression could be caused by any number of failures across any number of horizontal bands in the organization. Oh, the build automation crashed because the build team updated to the latest version of Java but the build didn't. Oh, the UI Filters stopped working because the API team changed something without deprecating. It meant that development, in spite of agile efforts, still had a tick-tock cadence, where breaks halted work and tracking down the responsible parties and getting things fixed might take time (a lot of areas with deep specialties required to understand why something might be wrong). This also meant, because of the way the organization was structured and the way the build was structured, that "pressure" was directed along very hierarchical routes. Managers saw bugs from customers and pressured testers and dev-ops people who maintained automation to investigate causes and transfer responsiblity to developers who might be able to actually fix the problems. As we've been decomposing into microservices, and likewise aligning along feature teams the blame gets allocated at API/service interfaces[2] instead of top-down. Since the build, deployment, uptime, and algorithmic functionality of each service is theoretically the domain of a single team, the blame-flow is more distributed and simple. An algorithmic bug, a build bug, and an availability issue are all addressed the same way: report the issue to the team responsible for that service, and let them work it out. I'm not advocating that either way is better. There were nice aspects about a single-location debug tree in the monolith. I've seen teams that have become experts at deflecting blame and thus slow down the entire broader effort. And I know I'm possibly conflating two paradigms inappropriately (Feature Teams and Microservices). Just a notable pattern, to my eyes. --- [1] I don't necessarily mean 'blame' here in a pejorative sense. Perhaps 'responsibility' would be a more neutral term. [2] Steve Yegge describes to this being a top priority during Amazon's service/platform decomposition.

piotrkubisa 10y ago
> The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase [...] Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance... > Specifically, like a microservice allows encapsulation of functionality, it also allows encapsulation of blame I think, the example of Joe's and Sally in parent [1] and your comment, makes the point in micro-services. During various Web Services integrations developers not only may blame specific part of system as faulty but also helps follow rule 'do not test your own code'. I remember few situation in pre-microservices era when during developing new API wrapper developers discovered a flaw in the remote web service (e.g. parameter doesn't change state) non-documented error code or raw Java exception as response. In these cases, owners of the API are are usually notified about issue so we may expect that will be fixed. I agree with you that is hard way to advocate either way is better. It is worth noting that creating a micro services leads to problem which may end with _duplicating_ (creating monolithic) code to provide possibility to communicate between the hosts (imagine mesh network). [1]: https://news.ycombinator.com/item?id=12134648 https://news.ycombinator.com/item?id=12134648

pjlegato 10y ago

It happens for another reason too: everyone likes to flatter themselves that they're top-tier big shots, that they're "web scale," that they have the same scaling problems and uptime problems that Google and Facebook have, and thus they think they need to adopt the same architecture patterns that Google and Facebook use. Someone builds a monolith, it gets some traction, and suddenly the server bill gets into five, six figures a month. Management have never been management before, and have never paid anything more than a few hundred dollars a month for servers, so their new cloud bill is mind blowing to them. They're spending as much money as a house costs every month on renting servers. They imagine they're hemmoraging cash right and left, they freak out and order engineering to rearchitect everything around a Service Oriented Architecture, because clearly it's time for the big boy toys. Google does it that way, so clearly that's what one does when one is at scale, when one is successful and has lots of paying customers, right? 99.9% would be better off financially and technically just rewriting a V2 of the monolith using lessons learned from V1, but that's perceived as outmoded, old-world thinking, because it's not what Google does.

elgoog1212 10y ago
This comment is made all the more humorous by the fact that Google doesn't actually do "microservices" internally. They have no qualms about building giant, monolithic binaries for things, and split things out based on the need, not some blind architectural fetish. The reason being, they don't like to be woken up by their pagers.