14 ms·

Everything old is new again: Microservices

148 points by CrankyBear 9y ago

_bxg1 9y ago
I've come to terms with the fact that every tech trend is cyclical. Just look at the comeback functional programming is making right now. Or the way we went from thin clients (terminals) to thick clients (PCs) to thin clients (early web pages) to thick clients (progressive web apps). All of this has happened before, and it will all happen again.
- dvfjsdhgfv 9y ago
  What is interesting is that each iteration is slightly different and in the end sometimes contributes to creation of something genuinely new. Although frankly I have to admit when I first heard about the "newest" trend in "static websites" I got a bit flabbergasted.
- hinkley 9y ago
  How do you deal with the people who emphatically insist that this isn’t a cycle, that this is new, and that there are no cautionary tales from the last cycle that they have to contend with? These people make me tired, and it feels like they are everywhere.
  - matwood 9y ago
    I agree with your point, but I often think the attitude you're complaining about occurs on both sides. "That's the same thing that we did X years ago" shows a similar level of ignorance. Most changes over time are evolutionary vs. revolutionary. This often means at an abstract level, new things look very similar to old things because they are. But, there is change (sometimes minor) that makes the new thing new. That minor change can also be the difference between something being used or going away into history.
  - _bxg1 9y ago
    The broad strokes ideals (read: dogmatisms) are cyclical, but technology still progresses. i.e., we shouldn't all ditch Clojure for K just because functional programming has had a heyday before; Clojure is a legitimate evolution of the paradigm. But it's also not unlikely that the present hype will die down in a few years and some new form of OOP will make a resurgence, ad infinitum.
    - tabtab 9y ago
      It's hard to know actual progress from fads until roughly a decade down the road. After being burned, I try to let others be the guinea pig now (unless I'm paid to do R&D). OOP was supposed to be the cat's meow. It turned out fairly good for certain infrastructure utilities/API's, but lousy for domain modeling, but was originally sold on domain modelling. It took people a while to realize this. OOP has use, but not the way the hypesters sold it.
      - _bxg1 9y ago
        I just take everything with a spoonful of salt. I enjoy hype to a certain point; it's fun and exciting, but I no longer buy into any one thing as the end-all, and when the party gets tiring I don't feel bad chilling out about it.
        tabtab 9y ago
        Anything that promises to turn building software into "magic intuitive re-usable Lego blocks" is probably mostly full of [censored].
- _pmf_ 9y ago
  "first as tragedy, then as farce" has never been as true as in the age of node.js hello world "microservices" with 136 MB of low quality dependencies in node_modules (I just checked mine). I can run Java servlets with less dependencies, including the JVM.
- gaius 9y ago
  DXC’s business is highly dependent on tech churn. Of course they are pushing this.
taneq 9y ago
Those who do not study history are doomed to reimplement it. :P
- dvfjsdhgfv 9y ago
  Spencer's Unix quote also fits in there.
  - macintux 9y ago
    Given the extent to which Erlang feels like microservices, I’ll submit Virding’s first rule for consideration. http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-...
    - amirouche 9y ago
      Yeah, but aren't Erlang project a single code base?
      - macintux 9y ago
        You're right, it's definitely not a 1:1 mapping, but there are some interesting similarities.
  - lioeters 9y ago
    "Those who do not understand Unix are condemned to reinvent it, poorly." Henry Spencer
andyhedges 9y ago
SOA never required an ESB, this was simply vendors trying to shoehorn in a saleable unit of software - which they succeeded at better in the 90s. Likewise I've seen people implement microservices with an ESB in the middle. Long an short of it is the ESB is an anti-pattern, always has been and SOA and microservices are the same thing.
- flukus 9y ago
  Without an ESB SOA services and microservices are just remote procedure calls. Unless there is a real need like a client-server architecture then remote procedure calls are just an extremely slow version of normal procedure calls.
  - bionoid 9y ago
    Not trying to be pedantic or anything, but it's also extremely insecure, extremely unreliable and extremely hard to implement correctly when compared to a normal procedure call. It just seemed weird to me to leave that out.
  - andyhedges 9y ago
    SOA is more than just RPC it's about the decomposition of your organisation in to cohesive (from a functional(ity) perspective) units of software, to reduce the need to make the remote calls, but more importantly allow you to organise your engineers into small enough groups of people to be effective (7 give or take one person). ESB simply add more complexity in the middle that needs yet another team to manage.
- tannhaeuser 9y ago
  Let's get the dates straight: Enterprise Service Bus was coined by Progress/Sonic Software for their middleware product around 2002 Service Oriented Architecture as a term to describe an enterprise architecture around web services was only used after SOAP became a thing in 1999
  - andyhedges 9y ago
oreganoz 9y ago
I think abstracting the differences away between the 2 seemingly equal technologies is not a good process for understanding them better. Yes, we seem to go back on ideas but this is because the market is constantly evolving, not because we forgot about the past. SOA was not that big of a hit because the time wasn't right. Just like MySpace before Facebook, the market wasn't ready. And to say they are the same is to ignore the advances each tech made. You could push this argument to the extremes and say "well, Microservices are just Processes on different computers talking through a network IPC and this $unknownProject has done that back when Ethernet first started". Nothing in tech is original and everything is.
- coldtea 9y ago
  >SOA was not that big of a hit because the time wasn't right. Huh? It dominated the 90s, especially in enterprise, in a way that micro-services today don't.
  - oreganoz 9y ago
    You are right, I meant more in terms of software developer popularity, apologies for my bad phrasing. But I do think microservices will become bigger, we'll have to wait and see how k8s pans out.
    - tannhaeuser 9y ago
      Sorry for nitpicking, but I think the central value proposition of microservices/SOA is that you communicate with you backend via well-defined network protocols rather than eg. procedure calls so that the client and server technology stack doesn't matter. Containers have nothing to do with it.
      - oreganoz 9y ago
        I'm just mentioning that containers may make implementing & deploying microservices easier and thus a more popular solution.
      - 9y ago
dyjakan 9y ago
One day I had an epiphany: Microservices (or SOA if you will) are just Unix-mindset applied to web applications. Do one thing and do it well, then use all these stand-alone complexes to get an actual result you want. "Those who don't understand Unix are condemned to reinvent it, poorly." -- Henry Spencer
coldtea 9y ago
>Microservices are also lighter than SOA. While SOA services are deployed to servers and virtual machines (VMs), microservices are deployed in containers. The protocols are also lighter. This makes microservices more flexible than SOA Both of these are wrong. A SOA service of yore would be much lighter (in CPU, if not memory) than a microservice of today. Heck, it had to be -- in the 90s they couldn't afford to run a JS runtime to power their service. It was either C++ or Java. The protocols were also lighter, then, not now. Except if the author means simpler and easier to work with. Else, CORBA or DCOC are lighter than serializing to JSON and back.
- hvidgaard 9y ago
  There is nothing about microservices that dictates the use of JS. Our microservices is written in .Net, and I could write it in C++ if I wanted to.
  - coldtea 9y ago
    Sure. But it's very common.
- GrumpyNl 9y ago
  In the eighties we used turbo pascal, 20 years later we found out we were writing microservices. For us it was needed because you could only write programs under 720Kb, So send a message to another program over a 5Mb network en let that program handle a specific task and port the results back to the main program.
- icebraining 9y ago
  Is a program running in the early versions of the JVM really faster than JS on the current version of V8? Current JS engines are very fast. By the way, Server Side JS was a thing in the 90s, though little used. On the other hand, Perl was quite common on websites, despite being much slower than C/C++.
  - DougWebb 9y ago
    Perl could be nearly as fast as C/C++, depending on what your service does and how you wrote it. The early days of running a cgi script for every request had awful performance, caused by the overhead of loading and compiling the Perl code before executing it. But there were ways to avoid that by pre-loading the code. One way was to use Mod_Perl on Apache, for example. I wrote a number of services that way, and also wrote my own pure-Perl standalone http server that could pre-load an entire web application. The other key factor was to use canonical expressions when writing your Perl code. There was always "more than one way to do it", but there were only a few ways that the compiler would recognize and use optimized functions for. Once you learned to take advantage of that, you could get your code running mostly in hand-written C functions. It wasn't as fast as native C because of the way Perl variables were represented, but it could be pretty close.
deanCommie 9y ago
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 9y 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.
  - 9y ago
BjoernKW 9y ago
> With microservices, though, you can make changes one service at a time. That's the main property that sets microservices apart from mere SOAs: Microservices reduce the risk of change. With properly architected microservices a single deployment is unlikely to impair an application as a whole whereas with traditional monolithic deployments a single change can severely affect the functionality and operations of an application. This is also why you probably don't need microservices if you don't need that kind of fine-grained control and risk mitigation.
- bni 9y ago
  But often you will end up with a critical service, like for example the service responsible for the order database. Breakage in this one will impact the system as a whole.
  - BjoernKW 9y ago
    This in turn might point to the services not being cut alongside the right dimensions, that is they might be cut horizontally rather than vertically. Microservices lend themselves to being used in conjunction with domain-driven design. A single microservice should only deal with one domain. If you have a service that covers cross-cutting concerns such as orders that service is not a microservice. In order to improve the design in your case each microservice could access and manipulate order data according to its scope. That way, if one of the services fails only the small part of the order functionality implemented by that service will fail while the remaining order features will remain intact (to some extent; steps in a linear order process that depend on each other of course will still fail without successful outcomes from previous steps).
scarface74 9y ago
And we went from SOAP to REST because REST with JSON was supposedly simpler. Then they realized that they needed some type of way to validate the JSON so they introduced JSON schema. Then they realized that they needed some method to make a REST Api discoverable so they added the Swagger protocol (OpenAI). Now we are right back to being as complicated as SOAP.
- foolfoolz 9y ago
  this one is my favorite. seeing my coworkers add swagger and get all excited over a description language for their API.... but then act like WSDL is some abomination is really funny WSDL is the ultimate api :) it would make my day to see the wsdl comeback of 2018
  - reificator 9y ago
    One of the service providers we use recently started deprecating their "SOAP" APIs in favor of "REST". Which doesn't bother me because with this provider they're far easier to work with. But since they provided WSDL before, their "REST" APIs now come with WADL files that offer zero value to anyone. Swagger would be a massive step up from that.
- tannhaeuser 9y ago
  The value-add of SOA over "REST" (as in JSON-RPC-over-HTTP) is standardized request/response formats for error messages, distributed transactions, and authentication/authorization, and standardized interface artifacts (WSDL and XSD schemas, policy files).
- scruffyherder 9y ago
  Nothing like wasting a decade to re-invent everything that was there before.
- arethuza 9y ago
  I think that's a bit harsh - I've been through a number of these cycles: ONC RPCs, CORBA, XML/SOAP and now JSON/JSON Schema/REST and I much prefer the latter. At least with current JSON and REST API I stand a good chance of experimenting using just an editor and curl - good luck trying that with SOAP.
electrotype 9y ago
I'm not an expert, but what is the difference between a plain old ESB and what we now call an "API Gateway" or "API Manager" (such as Kong or WSO2) in the world of microservices? I know of some architectures where the API Gateway has a lot of logic put into it... And you have to go through it to reach any of the microservices in the network. Isn't this a single point of failure and similar to an ESB?
- nhumrich 9y ago
  The biggest difference is that services don't use the gateway to talk to each other. And hopefully, the gateway isn't transforming responses. If services do use the gateway to talk to each other, then yes, it's pretty much an esb
Pamar 9y ago
Isn't one of the defining characteristic of Microservices to have a data persistence instance for each service (even at the cost of duplication)? (I am basing myself on just a superficial interest for MS so I might be wrong - here is what I am talking about: http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/ http://blog.christianposta.com/microservices/the-hardest-par...) If this is correct, than no, Microservices are really not "just like SOA". (If I am wrong, please correct me - I am here to learn).
- jmartrican 9y ago
  There is no microservices protocol description or RFC so its hard to say anything definitive, but yes you are right. We typically like to have a DB table (or Mongo collection) owned by 1 microservice. This allows changes to be made to the underlying datastore without affecting multiple applications. The other apps that need data, just get it from the microservice without caring about how the microservice handles it. I am in a team now that is just started using to use microservices. And I am noticing that we are stuck on a lot of DB changes we want to make because there are various applications accessing the same tables. So now we are getting into the habit of constraining back-end data stores (tables and collections) to just one microservice because we feel the pain of not doing that now.
  - heavenlyblue 9y ago
    Microservice is a monolith. So what you're describing is essentially: I've got a few front-end microservices tied to 1 huge microservice I call the database. There's no "data layer" that is managed outside the microservice. It _is_ a microservice. That's one of the reasons Google uses a monorepo: any microservice can easily import a database instance and start using it as part of it's structure.
    - amirouche 9y ago
      What do you mean by 'database instance'? Is the the instance of the 'class' that represents the database and its records or something else?
bkovacev 9y ago
Probably non related but I have a question - how do microservices scale in terms of communication to other microservices or to a monolith? We have broken off two of our monolith’s components into a microservice and for now it’s working great - but there are just some things I don’t think make sense to decouple and isolate. I’m afraid I’d get in an integration hell. Has anyone had such an issue?
- LargeWu 9y ago
  Yes. When that will happen in your case is highly dependent on what you're doing, but it will happen. Eventually you will run into situations where implementing a single small feature requires changes to 3 or more systems, plus deploying all of those systems to all of your environments, code reviews for each service, etc. The overhead explodes as you break more things apart.
jmartrican 9y ago
I started coding when SOA was in full swing and microservices was just something people were doing before it was called microservices. Basically the SOA contractors (and newly minted certificate holders) were pitching these complicated protocol interactions. There was just way too much overhead. So, many developers that just needed to get stuff working whipped up REST services for the front-end to consume. Ultimately these REST services made their way to production and they worked. And people coded them faster. This seemed to have been going on in multiple places and people were discussing it online and the term microservice was coined somewhere along the way. In the end SOA just had too much overhead, rules, and protocols. I remember seeing what these guys were doing with SOA and I would just ignore it and create REST services with JSON. We were able to get stuff in production. Eventually I found out that what we were doing was part of a movement called microservices and then started following and learning what other folks were doing.
p2t2p 9y ago
I've been working for telecoms for ages and it's been like this since forever. Bunch of independent hardware devices from dozens of vendors + software services from independent vendors and you gotta integrate them into one. HLR knows about your users, billing knows about other part of those users, then you have devices, everything independent and glued together via SOAP. In my previous job company had multiple SMSCs (short message service center) and you had to target the proper one, depending on the geography of the customer and you'd go to proper HLR to find the customer and their geo location (you should read country here, not precise location). And then people running around screaming SOA, MICROSERVICES, JSON and I like "You don't say? o_O?" EDIT: spelling
pc86 9y ago
I hate the graybeard need to say $NEW_THING is actually $OLD_THING but with a silly name because these silly kids don't know anything new, while both glossing over the bleak hellscape of $OLD_THING (WCF service development, anyone?) while grossly misunderstanding $NEW_THING. As other have pointed out he's ignoring key failings of SOA and critical differences between SOA and microservices. Overall I like the article but I think he's misstating a few key things. And maybe a nitpick but: > It lends itself to the Continuous Integration/Continuous Deployment (CI/CD) model of developing large, complex applications. Really? Because I thought CICD was the standard way to deploy any application more complex than a spike or proof of concept (which probably doesn't need to be deployed anyway).
- Clubber 9y ago
  >As other have pointed out he's ignoring key failings of SOA and critical differences between SOA and microservices. Can you describe the fundamental differences?
- arcbyte 9y ago
  The thing you're missing though is that as $NEW_THINGs get more popular and more people try to implement them, they do it badly, spread their bad implementation as gospel, and that actually changes the popular definition into something barely recognizable that becomes $OLD_THING. A few smart non-graybeards eventually play around with $OLD_THING enough that they actually stumble upon the original definition of it, but don't realize that they are really just rediscovering the original definition. So of course they (re)name their discovery as the next $NEW_THING. Then cue the graybeards. SOA is really just object oriented programming. Microservices is really just object oriented programming. Object oriented programming is really just dependency management.
  - pc86 9y ago
    Sorry but trying to boil everything down to "dependency management" shows a basic lack of understanding of software architecture and is objectively wrong.
the_arun 9y ago
SOA & Micro Services are not the same. Services in 90s & 2000 are SOA in a monolith. They were not isolated all the way till databases. Micro Services by definition need to be isolated all the way.
- newscracker 9y ago
  > ...microservices need to be isolated all the way They may be, but don't have to be. Like many other technology terms that go through a hype cycle, microservices also vary in definition by a large measure. This talk from 2014 by Martin Fowler [1] is about the breadth of definitions as well as contrasts with monoliths. [1]: https://www.youtube.com/watch?v=wgdBVIX9ifA https://www.youtube.com/watch?v=wgdBVIX9ifA
- dragonwriter 9y ago
  > SOA & Micro Services are not the same. Microservices by theory are a return to the early theory of SOA, which may frequently have been diverged from in practice, but that probably happens with microservices, too. > Services in 90s & 2000 are SOA in a monolith. The theory of SOA is loose coupling through independent services interacting through a shared communication medium. That may not always have been observed strictly in practice, but that's true of microservices, too.
DanielBMarkham 9y ago
"...So what does this mean? The long and short of it is that microservices are an SOA variation for container and cloud computing..." I do not agree with this at all. I think one of the biggest problems microservices face is the over-application of pre-existing paradigms. The failures I see are big object models, large frameworks, dependency on shared resources, complexity in the service, and so forth -- all signs of 90s and 00s thinking moving over to microservices. I agree that everything old is new again. I'd suggest you need to go back further. Good microservices, in my opinion, are not only loosely coupled, any sort of coupling at all is provided by the OS, nothing else. So you'd need to go back to JCL days to find a good analogy for microservices. Trying to stick these other concepts into the microservices bucket looks like a non-starter to me.
deleted 9y ago
[deleted]
pbreit 9y ago
I would say much of today’s micro services are mainly s function of current front end fashion of fat clients (mobile and SPAs) consuming JSON-formatted data. Less driven by the SOA qualities of a microservices architecture.
mindcrime 9y ago
Almost none of that is strictly true. SOA and "microservices" are so close to being synonyms that we might as well say that they are. At worst, they're different "flavors" of the same thing. Like Vanilla ice cream versus Strawberry ice cream.
amirouche 9y ago
I read the whole topic looking for enlightenment and insights to understand micro-services. I've been only in small companies (less that 10 years old with a dozen of engineers each) and AFAICT services grew organically without much architecture supervision or even if there was architecture supervision, it was a way to escape the technical debt of previous services. Don't even add to that the technical difficulty to manage multiple services in development or production or in between. On all the code bases I saw, I never told myself (micro) services are helpful, I will redo that. And if I had to rewrite any of them, I would use a single 'service' that can do everything. IMHO it's more sane to optimize for the developer instead of whatever micro-services try to optimize.
beastcoast 9y ago
What’s interesting is seeing SOA evolve: first it was service calls everywhere, now it’s increasingly asynchronous publish/subscribe architectures (think AWS SNS and SQS) and service orchestration frameworks (SWF, Step Functions). In my department we realized that 700+ services is untenable and we are now exploring home grown frameworks and SDKs to help manage those levels of complexity.

148 points by CrankyBear 9y ago

I've come to terms with the fact that every tech trend is cyclical. Just look at the comeback functional programming is making right now. Or the way we went from thin clients (terminals) to thick clients (PCs) to thin clients (early web pages) to thick clients (progressive web apps). All of this has happened before, and it will all happen again.

dvfjsdhgfv 9y ago
What is interesting is that each iteration is slightly different and in the end sometimes contributes to creation of something genuinely new. Although frankly I have to admit when I first heard about the "newest" trend in "static websites" I got a bit flabbergasted.
hinkley 9y ago
How do you deal with the people who emphatically insist that this isn’t a cycle, that this is new, and that there are no cautionary tales from the last cycle that they have to contend with? These people make me tired, and it feels like they are everywhere.
- matwood 9y ago
  I agree with your point, but I often think the attitude you're complaining about occurs on both sides. "That's the same thing that we did X years ago" shows a similar level of ignorance. Most changes over time are evolutionary vs. revolutionary. This often means at an abstract level, new things look very similar to old things because they are. But, there is change (sometimes minor) that makes the new thing new. That minor change can also be the difference between something being used or going away into history.
- _bxg1 9y ago
  The broad strokes ideals (read: dogmatisms) are cyclical, but technology still progresses. i.e., we shouldn't all ditch Clojure for K just because functional programming has had a heyday before; Clojure is a legitimate evolution of the paradigm. But it's also not unlikely that the present hype will die down in a few years and some new form of OOP will make a resurgence, ad infinitum.
  - tabtab 9y ago
    It's hard to know actual progress from fads until roughly a decade down the road. After being burned, I try to let others be the guinea pig now (unless I'm paid to do R&D). OOP was supposed to be the cat's meow. It turned out fairly good for certain infrastructure utilities/API's, but lousy for domain modeling, but was originally sold on domain modelling. It took people a while to realize this. OOP has use, but not the way the hypesters sold it.
    - _bxg1 9y ago
      I just take everything with a spoonful of salt. I enjoy hype to a certain point; it's fun and exciting, but I no longer buy into any one thing as the end-all, and when the party gets tiring I don't feel bad chilling out about it.
      - tabtab 9y ago
        Anything that promises to turn building software into "magic intuitive re-usable Lego blocks" is probably mostly full of [censored].
_pmf_ 9y ago
"first as tragedy, then as farce" has never been as true as in the age of node.js hello world "microservices" with 136 MB of low quality dependencies in node_modules (I just checked mine). I can run Java servlets with less dependencies, including the JVM.
gaius 9y ago
DXC’s business is highly dependent on tech churn. Of course they are pushing this.

taneq 9y ago

Those who do not study history are doomed to reimplement it. :P

dvfjsdhgfv 9y ago
Spencer's Unix quote also fits in there.
- macintux 9y ago
  Given the extent to which Erlang feels like microservices, I’ll submit Virding’s first rule for consideration. http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-...
  - amirouche 9y ago
    Yeah, but aren't Erlang project a single code base?
    - macintux 9y ago
      You're right, it's definitely not a 1:1 mapping, but there are some interesting similarities.
- lioeters 9y ago
  "Those who do not understand Unix are condemned to reinvent it, poorly." Henry Spencer

andyhedges 9y ago

SOA never required an ESB, this was simply vendors trying to shoehorn in a saleable unit of software - which they succeeded at better in the 90s. Likewise I've seen people implement microservices with an ESB in the middle. Long an short of it is the ESB is an anti-pattern, always has been and SOA and microservices are the same thing.

flukus 9y ago
Without an ESB SOA services and microservices are just remote procedure calls. Unless there is a real need like a client-server architecture then remote procedure calls are just an extremely slow version of normal procedure calls.
- bionoid 9y ago
  Not trying to be pedantic or anything, but it's also extremely insecure, extremely unreliable and extremely hard to implement correctly when compared to a normal procedure call. It just seemed weird to me to leave that out.
- andyhedges 9y ago
  SOA is more than just RPC it's about the decomposition of your organisation in to cohesive (from a functional(ity) perspective) units of software, to reduce the need to make the remote calls, but more importantly allow you to organise your engineers into small enough groups of people to be effective (7 give or take one person). ESB simply add more complexity in the middle that needs yet another team to manage.
tannhaeuser 9y ago
Let's get the dates straight: Enterprise Service Bus was coined by Progress/Sonic Software for their middleware product around 2002 Service Oriented Architecture as a term to describe an enterprise architecture around web services was only used after SOAP became a thing in 1999
- andyhedges 9y ago

oreganoz 9y ago

I think abstracting the differences away between the 2 seemingly equal technologies is not a good process for understanding them better. Yes, we seem to go back on ideas but this is because the market is constantly evolving, not because we forgot about the past. SOA was not that big of a hit because the time wasn't right. Just like MySpace before Facebook, the market wasn't ready. And to say they are the same is to ignore the advances each tech made. You could push this argument to the extremes and say "well, Microservices are just Processes on different computers talking through a network IPC and this $unknownProject has done that back when Ethernet first started". Nothing in tech is original and everything is.

coldtea 9y ago
>SOA was not that big of a hit because the time wasn't right. Huh? It dominated the 90s, especially in enterprise, in a way that micro-services today don't.
- oreganoz 9y ago
  You are right, I meant more in terms of software developer popularity, apologies for my bad phrasing. But I do think microservices will become bigger, we'll have to wait and see how k8s pans out.
  - tannhaeuser 9y ago
    Sorry for nitpicking, but I think the central value proposition of microservices/SOA is that you communicate with you backend via well-defined network protocols rather than eg. procedure calls so that the client and server technology stack doesn't matter. Containers have nothing to do with it.
    - oreganoz 9y ago
      I'm just mentioning that containers may make implementing & deploying microservices easier and thus a more popular solution.
    - 9y ago

dyjakan 9y ago

One day I had an epiphany: Microservices (or SOA if you will) are just Unix-mindset applied to web applications. Do one thing and do it well, then use all these stand-alone complexes to get an actual result you want. "Those who don't understand Unix are condemned to reinvent it, poorly." -- Henry Spencer

coldtea 9y ago

>Microservices are also lighter than SOA. While SOA services are deployed to servers and virtual machines (VMs), microservices are deployed in containers. The protocols are also lighter. This makes microservices more flexible than SOA Both of these are wrong. A SOA service of yore would be much lighter (in CPU, if not memory) than a microservice of today. Heck, it had to be -- in the 90s they couldn't afford to run a JS runtime to power their service. It was either C++ or Java. The protocols were also lighter, then, not now. Except if the author means simpler and easier to work with. Else, CORBA or DCOC are lighter than serializing to JSON and back.

hvidgaard 9y ago
There is nothing about microservices that dictates the use of JS. Our microservices is written in .Net, and I could write it in C++ if I wanted to.
- coldtea 9y ago
  Sure. But it's very common.
GrumpyNl 9y ago
In the eighties we used turbo pascal, 20 years later we found out we were writing microservices. For us it was needed because you could only write programs under 720Kb, So send a message to another program over a 5Mb network en let that program handle a specific task and port the results back to the main program.
icebraining 9y ago
Is a program running in the early versions of the JVM really faster than JS on the current version of V8? Current JS engines are very fast. By the way, Server Side JS was a thing in the 90s, though little used. On the other hand, Perl was quite common on websites, despite being much slower than C/C++.
- DougWebb 9y ago
  Perl could be nearly as fast as C/C++, depending on what your service does and how you wrote it. The early days of running a cgi script for every request had awful performance, caused by the overhead of loading and compiling the Perl code before executing it. But there were ways to avoid that by pre-loading the code. One way was to use Mod_Perl on Apache, for example. I wrote a number of services that way, and also wrote my own pure-Perl standalone http server that could pre-load an entire web application. The other key factor was to use canonical expressions when writing your Perl code. There was always "more than one way to do it", but there were only a few ways that the compiler would recognize and use optimized functions for. Once you learned to take advantage of that, you could get your code running mostly in hand-written C functions. It wasn't as fast as native C because of the way Perl variables were represented, but it could be pretty close.

deanCommie 9y ago

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 9y 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.
- 9y ago

BjoernKW 9y ago

> With microservices, though, you can make changes one service at a time. That's the main property that sets microservices apart from mere SOAs: Microservices reduce the risk of change. With properly architected microservices a single deployment is unlikely to impair an application as a whole whereas with traditional monolithic deployments a single change can severely affect the functionality and operations of an application. This is also why you probably don't need microservices if you don't need that kind of fine-grained control and risk mitigation.

bni 9y ago
But often you will end up with a critical service, like for example the service responsible for the order database. Breakage in this one will impact the system as a whole.
- BjoernKW 9y ago
  This in turn might point to the services not being cut alongside the right dimensions, that is they might be cut horizontally rather than vertically. Microservices lend themselves to being used in conjunction with domain-driven design. A single microservice should only deal with one domain. If you have a service that covers cross-cutting concerns such as orders that service is not a microservice. In order to improve the design in your case each microservice could access and manipulate order data according to its scope. That way, if one of the services fails only the small part of the order functionality implemented by that service will fail while the remaining order features will remain intact (to some extent; steps in a linear order process that depend on each other of course will still fail without successful outcomes from previous steps).

scarface74 9y ago

And we went from SOAP to REST because REST with JSON was supposedly simpler. Then they realized that they needed some type of way to validate the JSON so they introduced JSON schema. Then they realized that they needed some method to make a REST Api discoverable so they added the Swagger protocol (OpenAI). Now we are right back to being as complicated as SOAP.

foolfoolz 9y ago
this one is my favorite. seeing my coworkers add swagger and get all excited over a description language for their API.... but then act like WSDL is some abomination is really funny WSDL is the ultimate api :) it would make my day to see the wsdl comeback of 2018
- reificator 9y ago
  One of the service providers we use recently started deprecating their "SOAP" APIs in favor of "REST". Which doesn't bother me because with this provider they're far easier to work with. But since they provided WSDL before, their "REST" APIs now come with WADL files that offer zero value to anyone. Swagger would be a massive step up from that.
tannhaeuser 9y ago
The value-add of SOA over "REST" (as in JSON-RPC-over-HTTP) is standardized request/response formats for error messages, distributed transactions, and authentication/authorization, and standardized interface artifacts (WSDL and XSD schemas, policy files).
scruffyherder 9y ago
Nothing like wasting a decade to re-invent everything that was there before.
arethuza 9y ago
I think that's a bit harsh - I've been through a number of these cycles: ONC RPCs, CORBA, XML/SOAP and now JSON/JSON Schema/REST and I much prefer the latter. At least with current JSON and REST API I stand a good chance of experimenting using just an editor and curl - good luck trying that with SOAP.

electrotype 9y ago

I'm not an expert, but what is the difference between a plain old ESB and what we now call an "API Gateway" or "API Manager" (such as Kong or WSO2) in the world of microservices? I know of some architectures where the API Gateway has a lot of logic put into it... And you have to go through it to reach any of the microservices in the network. Isn't this a single point of failure and similar to an ESB?

nhumrich 9y ago
The biggest difference is that services don't use the gateway to talk to each other. And hopefully, the gateway isn't transforming responses. If services do use the gateway to talk to each other, then yes, it's pretty much an esb

Pamar 9y ago

Isn't one of the defining characteristic of Microservices to have a data persistence instance for each service (even at the cost of duplication)? (I am basing myself on just a superficial interest for MS so I might be wrong - here is what I am talking about: http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/ http://blog.christianposta.com/microservices/the-hardest-par...) If this is correct, than no, Microservices are really not "just like SOA". (If I am wrong, please correct me - I am here to learn).

jmartrican 9y ago
There is no microservices protocol description or RFC so its hard to say anything definitive, but yes you are right. We typically like to have a DB table (or Mongo collection) owned by 1 microservice. This allows changes to be made to the underlying datastore without affecting multiple applications. The other apps that need data, just get it from the microservice without caring about how the microservice handles it. I am in a team now that is just started using to use microservices. And I am noticing that we are stuck on a lot of DB changes we want to make because there are various applications accessing the same tables. So now we are getting into the habit of constraining back-end data stores (tables and collections) to just one microservice because we feel the pain of not doing that now.
- heavenlyblue 9y ago
  Microservice is a monolith. So what you're describing is essentially: I've got a few front-end microservices tied to 1 huge microservice I call the database. There's no "data layer" that is managed outside the microservice. It _is_ a microservice. That's one of the reasons Google uses a monorepo: any microservice can easily import a database instance and start using it as part of it's structure.
  - amirouche 9y ago
    What do you mean by 'database instance'? Is the the instance of the 'class' that represents the database and its records or something else?

bkovacev 9y ago

Probably non related but I have a question - how do microservices scale in terms of communication to other microservices or to a monolith? We have broken off two of our monolith’s components into a microservice and for now it’s working great - but there are just some things I don’t think make sense to decouple and isolate. I’m afraid I’d get in an integration hell. Has anyone had such an issue?

LargeWu 9y ago
Yes. When that will happen in your case is highly dependent on what you're doing, but it will happen. Eventually you will run into situations where implementing a single small feature requires changes to 3 or more systems, plus deploying all of those systems to all of your environments, code reviews for each service, etc. The overhead explodes as you break more things apart.

jmartrican 9y ago

I started coding when SOA was in full swing and microservices was just something people were doing before it was called microservices. Basically the SOA contractors (and newly minted certificate holders) were pitching these complicated protocol interactions. There was just way too much overhead. So, many developers that just needed to get stuff working whipped up REST services for the front-end to consume. Ultimately these REST services made their way to production and they worked. And people coded them faster. This seemed to have been going on in multiple places and people were discussing it online and the term microservice was coined somewhere along the way. In the end SOA just had too much overhead, rules, and protocols. I remember seeing what these guys were doing with SOA and I would just ignore it and create REST services with JSON. We were able to get stuff in production. Eventually I found out that what we were doing was part of a movement called microservices and then started following and learning what other folks were doing.

p2t2p 9y ago

I've been working for telecoms for ages and it's been like this since forever. Bunch of independent hardware devices from dozens of vendors + software services from independent vendors and you gotta integrate them into one. HLR knows about your users, billing knows about other part of those users, then you have devices, everything independent and glued together via SOAP. In my previous job company had multiple SMSCs (short message service center) and you had to target the proper one, depending on the geography of the customer and you'd go to proper HLR to find the customer and their geo location (you should read country here, not precise location). And then people running around screaming SOA, MICROSERVICES, JSON and I like "You don't say? o_O?" EDIT: spelling

pc86 9y ago

I hate the graybeard need to say $NEW_THING is actually $OLD_THING but with a silly name because these silly kids don't know anything new, while both glossing over the bleak hellscape of $OLD_THING (WCF service development, anyone?) while grossly misunderstanding $NEW_THING. As other have pointed out he's ignoring key failings of SOA and critical differences between SOA and microservices. Overall I like the article but I think he's misstating a few key things. And maybe a nitpick but: > It lends itself to the Continuous Integration/Continuous Deployment (CI/CD) model of developing large, complex applications. Really? Because I thought CICD was the standard way to deploy any application more complex than a spike or proof of concept (which probably doesn't need to be deployed anyway).

Clubber 9y ago
>As other have pointed out he's ignoring key failings of SOA and critical differences between SOA and microservices. Can you describe the fundamental differences?
arcbyte 9y ago
The thing you're missing though is that as $NEW_THINGs get more popular and more people try to implement them, they do it badly, spread their bad implementation as gospel, and that actually changes the popular definition into something barely recognizable that becomes $OLD_THING. A few smart non-graybeards eventually play around with $OLD_THING enough that they actually stumble upon the original definition of it, but don't realize that they are really just rediscovering the original definition. So of course they (re)name their discovery as the next $NEW_THING. Then cue the graybeards. SOA is really just object oriented programming. Microservices is really just object oriented programming. Object oriented programming is really just dependency management.
- pc86 9y ago
  Sorry but trying to boil everything down to "dependency management" shows a basic lack of understanding of software architecture and is objectively wrong.

the_arun 9y ago

SOA & Micro Services are not the same. Services in 90s & 2000 are SOA in a monolith. They were not isolated all the way till databases. Micro Services by definition need to be isolated all the way.

newscracker 9y ago
> ...microservices need to be isolated all the way They may be, but don't have to be. Like many other technology terms that go through a hype cycle, microservices also vary in definition by a large measure. This talk from 2014 by Martin Fowler [1] is about the breadth of definitions as well as contrasts with monoliths. [1]: https://www.youtube.com/watch?v=wgdBVIX9ifA https://www.youtube.com/watch?v=wgdBVIX9ifA
dragonwriter 9y ago
> SOA & Micro Services are not the same. Microservices by theory are a return to the early theory of SOA, which may frequently have been diverged from in practice, but that probably happens with microservices, too. > Services in 90s & 2000 are SOA in a monolith. The theory of SOA is loose coupling through independent services interacting through a shared communication medium. That may not always have been observed strictly in practice, but that's true of microservices, too.

DanielBMarkham 9y ago

"...So what does this mean? The long and short of it is that microservices are an SOA variation for container and cloud computing..." I do not agree with this at all. I think one of the biggest problems microservices face is the over-application of pre-existing paradigms. The failures I see are big object models, large frameworks, dependency on shared resources, complexity in the service, and so forth -- all signs of 90s and 00s thinking moving over to microservices. I agree that everything old is new again. I'd suggest you need to go back further. Good microservices, in my opinion, are not only loosely coupled, any sort of coupling at all is provided by the OS, nothing else. So you'd need to go back to JCL days to find a good analogy for microservices. Trying to stick these other concepts into the microservices bucket looks like a non-starter to me.

deleted 9y ago

[deleted]

pbreit 9y ago

I would say much of today’s micro services are mainly s function of current front end fashion of fat clients (mobile and SPAs) consuming JSON-formatted data. Less driven by the SOA qualities of a microservices architecture.

mindcrime 9y ago

Almost none of that is strictly true. SOA and "microservices" are so close to being synonyms that we might as well say that they are. At worst, they're different "flavors" of the same thing. Like Vanilla ice cream versus Strawberry ice cream.

amirouche 9y ago

I read the whole topic looking for enlightenment and insights to understand micro-services. I've been only in small companies (less that 10 years old with a dozen of engineers each) and AFAICT services grew organically without much architecture supervision or even if there was architecture supervision, it was a way to escape the technical debt of previous services. Don't even add to that the technical difficulty to manage multiple services in development or production or in between. On all the code bases I saw, I never told myself (micro) services are helpful, I will redo that. And if I had to rewrite any of them, I would use a single 'service' that can do everything. IMHO it's more sane to optimize for the developer instead of whatever micro-services try to optimize.

beastcoast 9y ago

What’s interesting is seeing SOA evolve: first it was service calls everywhere, now it’s increasingly asynchronous publish/subscribe architectures (think AWS SNS and SQS) and service orchestration frameworks (SWF, Step Functions). In my department we realized that 700+ services is untenable and we are now exploring home grown frameworks and SDKs to help manage those levels of complexity.