[oreganoz]

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]

>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]

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]

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]

I'm just mentioning that containers may make implementing & deploying microservices easier and thus a more popular solution.

[amirouche]

How a network protocol is more specified that a procedure call?

[tannhaeuser]

It's not. The benefit is that

- you can keep a service running long after the project that created it has disbanded and/or the runtime and build environment is deprecated on a given O/S

- you don't necessarily need to deep-dive into the business logic of legacy services

- you can replace a service implementation with another one running on another stack without having to adapt service clients

- you can change auth mechanism outside of the service implementations

- you can scale out (CPU-bound) services onto multiple hosts

Mind you, these benefits are not achieved by using microservices/SOA in itself; the contribution of microservices/SOA, however, is that these design goals aren't impossible to achieve because of architected reasons.