9 ms·

This is highly misleading. What made "Service-orientated-architecture" stand out in the 90's and 2000's was standardized communication protocols. It made integ

This is highly misleading. What made "Service-orientated-architecture" stand out in the 90's and 2000's was standardized communication protocols. It made integrating across teams, and even across companies easier than it's ever been before. But there were no best practices around service architecture. Sure, methods were decoupled by responsibility (maybe). But when companies thought about their "Web Service" strategy that meant putting up ONE service exposed to the world, and moving on. Internally, "SOA" meant 1-5 services for a mid-sized shop. This worked for a while until it didn't. First, the services became monoliths of conflicting responsibilities, then the mobile revolution and big data led to scalability challenges that the era of SOA never had to consider. THAT is what microservices promised to solve. By being brutal with decomposing and decoupling your concerns you could scale each intelligently and independently. Containers are just an implementation detail, and weren't around yet when Microservices first made their impact. Of course, plenty of people don't get this. They think of microservices as just another buzzword. So, it's been ruined like "agile" has, and you hear companies about their "Microservice architecture", when really all they've done is migrated their backend to node.js and moved to the cloud. Shame. It's a good idea a lot of the time (and sometimes it isn't, as with all good ideas).

basejumping 8y ago
You're also making a lot of assumptions. I started working in 2004 and in 2006 I was already doing 'microservices', I was responsible for a few web services (.NET) (with a few endpoints each), other colleagues had others. These web services where part of a bigger system (out of the many that we had). Emphasis here is on few endpoints, the services where split on functionality, some services talked to other services, some directly to the database. One of the reasons for the split was also because we were using Visual Source Safe and multiple people working on the same code was hard. So yes, I think 'Microservices' is a buzzword, it's been driven by the use of containers, deployment automation, and the assumptions that people have done monotliths because they didn't know better is wrong. Every sane engineer who has put too much functionality in a service which at some point caused problems with scaling, agility, etc, would take measures to address it.
- icebraining 8y ago
  Yes, people were doing microservices before the name appeared, but that's true of all design and architectural patterns. A few people/teams implement similar solutions to similar problems, then someone recognizes the similitude and names that general pattern. Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience (assuming they can see through the snake-oil sellers that inevitably pop up).
  - misja111 8y ago
    >> Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience In my experience it's exactly the opposite that has happened. I see microservices being abused all the time, just because someone read a blog and thought they were cool. The same thing happened with SOA by the way.
- mattmanser 8y ago
  It's funny that the main reason you switched was because of the difficulties of VSS. Your tools forced you to make decisions about how you code! We just switched to SVN. The migration was an easy < one day job, a few weeks of pain with some developers grumbling that it was too complex and then everyone was (mostly) happy that we no longer had to hunt down the consultant who had locked a particularly critical file and was now out of the office the rest of the week.
  - dpark 8y ago
    You’ve been on VSS until just recently? That seems insane. Wasn’t the last update to VSS shipped in 2005? Also, why SVN? That seems an antiquated choice at this point.
    - eropple 8y ago
      "Just" being "simply", rather than sticking with VSS.
dubbel 8y ago
Aren't you comparing the historical reality of SOA with the ideal/theoretical implementation of microservices? (I wasn't around in the SOA era)
crdoconnor 8y ago
SOA was just as notable as microservices is for people arguing over its "true meaning" which is how so many arguments got started. In reality the definition of both was always fairly fuzzy.
mattmanser 8y ago
I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. Mainly if you're really big. There are a lot of advantages to having a monolith, especially in statically typed languages. Every extra service you add is costly, it involves setup, build steps that can break, extra things to monitor, more complex development environment, less flexibility, harder to redesign, harder to fix flaws in the original architecture, etc.
- joshdick 8y ago
  You need a certain level of maturity in devops practices before microservices are worth it. Deploying an extra service to a kubernetes cluster, for example, is neither costly nor prone to breaking nor harder to monitor, etc. I think the best practice nowadays is for a small startup to first write a monolith and then later split it out into microservices when they're ready.
  - mattmanser 8y ago
    To me it seems guaranteed that it is more expensive, regardless of if you use [insert trendy tool here]. There's always something that can break. More parts, more breakdowns. The services have to communicate, those communication channels are extra points of failure. What happens when one service inadvertently passes along something another one can't decode properly? Ooops, wasn't expecting unicode! Ooops, wasn't expecting a long int! Oops, the JSON encoder we used in this service spits out stuff the JSON decoder in this one hates! Ooops, we upgraded a package in this service, but not that one! And on, and on. And when something does inevitably break in the chain, there's the extra cost in debugging of figuring out which bit actually broke.
    - eropple 8y ago
      Agreed on all counts. The only time I recommend multiple services, rather than just load-balancing across monolithic applications, is when part of it's written on a different stack. As an example: I'm writing a gizmo with a Ruby core and a NodeJS ingest endpoint, and yeah, I'll probably run them on separate machines. But here's the dirty secret: if you have a load balancer in front of your application, you already have a way to send requests for feature X to a separate pool of machines if that feature is a hot spot for you currently--and unless your application hits some really degenerate cases your base RAM load Simply Should Not be that high for your application in the first place, making the marginal cost and machine sizing floor less of an issue. There are benefits to microservices in some environments, chiefly to reflect your org chart when your human protocols are breaking down. They tend to be marginal, and whether they outstrip the increased overhead of dealing with more moving parts (whether in your code or not; I quite like k8s but I still wouldn't want somebody less comfortable with it than I am running it in production, and plenty of those folks do!) is in many ways up in the air.
Clubber 8y ago
>First, the services became monoliths of conflicting responsibilities, Really depends on how they were written and how they were maintained. >then the mobile revolution and big data led to scalability challenges that the era of SOA never had to consider. Can you describe this in more detail?
DanielBMarkham 8y ago
"By being brutal with decomposing and decoupling your concerns you could scale each intelligently and independently." Yep. This is the first concept he misses. "They think of microservices as just another buzzword. " And this is the second one. What he's describing as SOA doesn't match what I've seen. Even your 1-5 services example is rare. It was mostly taking a buzzword, loading up on some tooling, and cranking WSDLs. You could end up with dozens of those little rascals right out of the starting gate. (It should have been 1-5, agreed. I just never saw it work like that in shops of any significant size)
cirgue 8y ago
One common theme of the tech industry is that excellent ideas get picked up by bullshit artists with time to waste and ink to spill and are then turned into something completely anathema to their original intent. Anecdotally, this seems to happen with more speed and vigor than in other domains.
- pjmlp 8y ago
  Yeah pop culture driven programming.
lkrubner 8y ago
It's worth remembering how painful SOAP was, and what a disaster the early implementations were, and how little agreement there was on anything, for many years. Pete Lacey has written a hilarious satire of the whole thing: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. I agree the term "microservices" has been ruined by those who came in with a very specific agenda. When I was at Timeout.com, in 2013, I used the phrase "an architecture of small apps": http://www.smashcompany.com/technology/an-architecture-of-small-apps http://www.smashcompany.com/technology/an-architecture-of-sm... It was a few months later, when Martin Fowler wrote his essay about it, that I first heard the term "microservices". When I read his essay, I assumed he was talking about the same thing that I was talking about. But I later found that the people promoting microservices defined it entirely in terms of HTTP, so I've gone back to talking about "an architecture of small apps" when I am talking about small apps that talk to each other with something other than HTTP, such as this kind of architecture: http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-in-Clojure-4/ http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-... In that example, Mattias Nehlsen builds a system where the communication is via Redis.
- bitwize 8y ago
  > Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. Well, SOAP and Wiz-Dull. Many of the robotics platforms in common use (e.g., ROS) consist of independent, single-responsibility services that communicate over a shared message bus using a protocol that's not HTTP. But for enterprise apps, it's 2018. Other protocols? What other protocols? You should be using HTTP/2. It can MUX multiple streams over the same connection. FINALLY! At long last! We're no longer limited to a single concurrent stream!
- nailer 8y ago
  Sure, but you could point a generic client at a SOAP endpoint, and have a client for it, since the endpoint told the client what methods were available and what their signatures were. REST lost that. I think GraphQL has it back again. Any GraphQL people want to comment?
tabtab 8y ago
Our shop tried microservices, and so far it's a BIG FLOP and time-drain. Conway's Law overpowered it: if the org structure (both dev's and domain org) don't match the microservices partitioning, bleep happens. You cannot force sharing/reuse where the parties don't want it (both dev and domain). If you share something, you create a dependency; and that dependency needs to be managed both technically and domain-wise. Group X now has to depend on Group Y's decisions if they both use/share service Z. If X and Y don't buy off on a common dependency on Z, they get frustrated and blame devs and the other service users. Stored procedures and SQL allow data/service sharing with less code anyhow.
- deleted 8y ago
  [deleted]

basejumping 8y ago

You're also making a lot of assumptions. I started working in 2004 and in 2006 I was already doing 'microservices', I was responsible for a few web services (.NET) (with a few endpoints each), other colleagues had others. These web services where part of a bigger system (out of the many that we had). Emphasis here is on few endpoints, the services where split on functionality, some services talked to other services, some directly to the database. One of the reasons for the split was also because we were using Visual Source Safe and multiple people working on the same code was hard. So yes, I think 'Microservices' is a buzzword, it's been driven by the use of containers, deployment automation, and the assumptions that people have done monotliths because they didn't know better is wrong. Every sane engineer who has put too much functionality in a service which at some point caused problems with scaling, agility, etc, would take measures to address it.

icebraining 8y ago
Yes, people were doing microservices before the name appeared, but that's true of all design and architectural patterns. A few people/teams implement similar solutions to similar problems, then someone recognizes the similitude and names that general pattern. Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience (assuming they can see through the snake-oil sellers that inevitably pop up).
- misja111 8y ago
  >> Then it becomes easier to know in which conditions it might be useful to apply it, especially for people with less experience In my experience it's exactly the opposite that has happened. I see microservices being abused all the time, just because someone read a blog and thought they were cool. The same thing happened with SOA by the way.
mattmanser 8y ago
It's funny that the main reason you switched was because of the difficulties of VSS. Your tools forced you to make decisions about how you code! We just switched to SVN. The migration was an easy < one day job, a few weeks of pain with some developers grumbling that it was too complex and then everyone was (mostly) happy that we no longer had to hunt down the consultant who had locked a particularly critical file and was now out of the office the rest of the week.
- dpark 8y ago
  You’ve been on VSS until just recently? That seems insane. Wasn’t the last update to VSS shipped in 2005? Also, why SVN? That seems an antiquated choice at this point.
  - eropple 8y ago
    "Just" being "simply", rather than sticking with VSS.

dubbel 8y ago

Aren't you comparing the historical reality of SOA with the ideal/theoretical implementation of microservices? (I wasn't around in the SOA era)

crdoconnor 8y ago

SOA was just as notable as microservices is for people arguing over its "true meaning" which is how so many arguments got started. In reality the definition of both was always fairly fuzzy.

mattmanser 8y ago

I've always got the impression that micro-services are a bad idea most of the time, apart from sometimes where they're not. Mainly if you're really big. There are a lot of advantages to having a monolith, especially in statically typed languages. Every extra service you add is costly, it involves setup, build steps that can break, extra things to monitor, more complex development environment, less flexibility, harder to redesign, harder to fix flaws in the original architecture, etc.

joshdick 8y ago
You need a certain level of maturity in devops practices before microservices are worth it. Deploying an extra service to a kubernetes cluster, for example, is neither costly nor prone to breaking nor harder to monitor, etc. I think the best practice nowadays is for a small startup to first write a monolith and then later split it out into microservices when they're ready.
- mattmanser 8y ago
  To me it seems guaranteed that it is more expensive, regardless of if you use [insert trendy tool here]. There's always something that can break. More parts, more breakdowns. The services have to communicate, those communication channels are extra points of failure. What happens when one service inadvertently passes along something another one can't decode properly? Ooops, wasn't expecting unicode! Ooops, wasn't expecting a long int! Oops, the JSON encoder we used in this service spits out stuff the JSON decoder in this one hates! Ooops, we upgraded a package in this service, but not that one! And on, and on. And when something does inevitably break in the chain, there's the extra cost in debugging of figuring out which bit actually broke.
  - eropple 8y ago
    Agreed on all counts. The only time I recommend multiple services, rather than just load-balancing across monolithic applications, is when part of it's written on a different stack. As an example: I'm writing a gizmo with a Ruby core and a NodeJS ingest endpoint, and yeah, I'll probably run them on separate machines. But here's the dirty secret: if you have a load balancer in front of your application, you already have a way to send requests for feature X to a separate pool of machines if that feature is a hot spot for you currently--and unless your application hits some really degenerate cases your base RAM load Simply Should Not be that high for your application in the first place, making the marginal cost and machine sizing floor less of an issue. There are benefits to microservices in some environments, chiefly to reflect your org chart when your human protocols are breaking down. They tend to be marginal, and whether they outstrip the increased overhead of dealing with more moving parts (whether in your code or not; I quite like k8s but I still wouldn't want somebody less comfortable with it than I am running it in production, and plenty of those folks do!) is in many ways up in the air.

Clubber 8y ago

>First, the services became monoliths of conflicting responsibilities, Really depends on how they were written and how they were maintained. >then the mobile revolution and big data led to scalability challenges that the era of SOA never had to consider. Can you describe this in more detail?

DanielBMarkham 8y ago

"By being brutal with decomposing and decoupling your concerns you could scale each intelligently and independently." Yep. This is the first concept he misses. "They think of microservices as just another buzzword. " And this is the second one. What he's describing as SOA doesn't match what I've seen. Even your 1-5 services example is rare. It was mostly taking a buzzword, loading up on some tooling, and cranking WSDLs. You could end up with dozens of those little rascals right out of the starting gate. (It should have been 1-5, agreed. I just never saw it work like that in shops of any significant size)

cirgue 8y ago

One common theme of the tech industry is that excellent ideas get picked up by bullshit artists with time to waste and ink to spill and are then turned into something completely anathema to their original intent. Anecdotally, this seems to happen with more speed and vigor than in other domains.

pjmlp 8y ago
Yeah pop culture driven programming.

lkrubner 8y ago

It's worth remembering how painful SOAP was, and what a disaster the early implementations were, and how little agreement there was on anything, for many years. Pete Lacey has written a hilarious satire of the whole thing: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. I agree the term "microservices" has been ruined by those who came in with a very specific agenda. When I was at Timeout.com, in 2013, I used the phrase "an architecture of small apps": http://www.smashcompany.com/technology/an-architecture-of-small-apps http://www.smashcompany.com/technology/an-architecture-of-sm... It was a few months later, when Martin Fowler wrote his essay about it, that I first heard the term "microservices". When I read his essay, I assumed he was talking about the same thing that I was talking about. But I later found that the people promoting microservices defined it entirely in terms of HTTP, so I've gone back to talking about "an architecture of small apps" when I am talking about small apps that talk to each other with something other than HTTP, such as this kind of architecture: http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-in-Clojure-4/ http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-... In that example, Mattias Nehlsen builds a system where the communication is via Redis.

bitwize 8y ago
> Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. Well, SOAP and Wiz-Dull. Many of the robotics platforms in common use (e.g., ROS) consist of independent, single-responsibility services that communicate over a shared message bus using a protocol that's not HTTP. But for enterprise apps, it's 2018. Other protocols? What other protocols? You should be using HTTP/2. It can MUX multiple streams over the same connection. FINALLY! At long last! We're no longer limited to a single concurrent stream!
nailer 8y ago
Sure, but you could point a generic client at a SOAP endpoint, and have a client for it, since the endpoint told the client what methods were available and what their signatures were. REST lost that. I think GraphQL has it back again. Any GraphQL people want to comment?

tabtab 8y ago

Our shop tried microservices, and so far it's a BIG FLOP and time-drain. Conway's Law overpowered it: if the org structure (both dev's and domain org) don't match the microservices partitioning, bleep happens. You cannot force sharing/reuse where the parties don't want it (both dev and domain). If you share something, you create a dependency; and that dependency needs to be managed both technically and domain-wise. Group X now has to depend on Group Y's decisions if they both use/share service Z. If X and Y don't buy off on a common dependency on Z, they get frustrated and blame devs and the other service users. Stored procedures and SQL allow data/service sharing with less code anyhow.

deleted 8y ago
[deleted]