
Everything old is new again: Microservices - CrankyBear
https://blogs.dxc.technology/2018/05/08/everything-old-is-new-again-microservices/
======
deanCommie
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).

~~~
mattmanser
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.

~~~
pc86
Even if you're not really big, sometimes it's helpful just to have everything
broken up and not have to go to a 750,000 LOC solution and find the 10-line
file that you need to edit.

I'm on the architecture side so am bearing the brunt of the complexity but the
senior and especially mid level developers who have code open 7.8 hours a day
say the few things we do that have real microservices are the easiest to debug
and work on. The monolithic apps take longer to get less done.

Agreed though that it certainly adds complexity on the admin/arch/ops side.

~~~
jjoonathan
Monolith: a->b

Microservice: a->async->serialization->network->serialization->scheduling->b

A monolith is extremely simple to traverse with a debugger, a microservice is
not. I can make a dozen jumps over/into/out in less time than it would take me
to open Fiddler or man tcpdump.

I have heard that some companies have tooling that makes the microservices
debugging situation tolerable or sometimes even better than monolith (e.g.
writing tests for you by snooping the network layer), but I have yet to play
with any. Do you have recommendations?

~~~
reacharavindh
Very much this.

It may be worthwhile for really complex and "business vice separated" services
to be written as micro services because it gives you clear separation of
concerns. But, in reality, to often you see a single logical service getting
implemented with a lot of (N/W + serialization + management) costs
unnecessarily just because it is cool to say that you did micro services.

My thumb rule is : If you don't foresee different teams of devs working on
these different services, then you're better off leaving it as a monolith and
scaling it as a whole application instead.

~~~
JamesBarney
Yes, I've always seen microservices as an organizational win over any type of
technical win.

Basically having separate teams work on one code base with one deployment
cycle can sometimes be really tough. And sometimes you can get a big win by
splitting up this service so multiple teams can each have their own service to
focus on.

This whole team of one developer supporting 8 microservices seems ludicrious
to me.

~~~
kakwa_
I completely agree with you.

I tend to like the idea of the 2 pizzas rule from Jeff Bezos.

Having a small team (let say under 10 people) manage a service end to end
(from spec to code to production) can be really efficient.

On large code bases/large products, this can help a lot, offsetting the cost
of a more complex architecture.

However in a microservice architecture, the APIs between services is critical.
It's a contract between services, and it should be clearly stated, you cannot
go berserk every other day and change it. You also need to establish clear
rules about versioning, deprecation and end of life of said APIs.

(by the way, it would be nice if we had a standard to negotiate API versions,
for example stating that a rest API must always have a /version which lists
the available versions, if some versions are deprecated and when they will be
EOLed).

------
_bxg1
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.

~~~
hinkley
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.

~~~
_bxg1
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
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
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
Anything that promises to turn building software into "magic intuitive re-
usable Lego blocks" is probably mostly full of [censored].

------
scarface74
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.

~~~
throwaway2016a
SOAP is an absolute nightmare to work with. A WSDL is not even remotely
comparable to Swagger.

For one, Swagger is for humans not machines to consume. At it's core it is a
way to standardize documentation that can be easily displayed to humans. WSDL
is not only used by humans but also by client and server apps.

REST APIs themselves if done right though hypermedia can be self-documenting
and require no download of large spec files to use it.

SOAP also suppers from a number of quirks. One for example, that order often
matters. Yes you can write a WSDL that doesn't require order but nothing is
worse than having a bug because <price> has to appear after <token> but before
<expirationMonth> and any other order throws anon-specific validation error.
Yes, I know there are tools that can help with this but I have never felt
compelled to download a tool for REST. Curl does just fine for me. And to top
it off a lot of the best SOAP tools are Windows only.

What I think you really should be pointing at is RPC (of which SOAP is a
terrible no good implementation of). RPC indeed offers some benefits over REST
and can even be simpler. At the expense of losing the discover and hypermedia
aspects of REST if done right.

~~~
tannhaeuser
I've been developing so-called "REST" services for over ten years (and SOAP
services before that), and _not even once_ were REST principles actually
applied in the projects I worked on. As in, the client/browser discovers from
an URL the interactions with a resource without out-of-band info for minimal
coupling of client and service. I agree though getting SOAP/XML right takes
typically considerably more effort than JSON.

Re: statefulness ("order matters"): there are _intrinsical stateful_ processes
that aren't represented adequately by a REST service. Think of a basic
"Purchase Order" resource representing purchased items on an e-commerce
website. You generally can't add and delete line items freely once you have
placed your order, but you may cancel individual items (unless they're already
physically on your way), you may RMA items, etc. Representing this as a flat
"Purchase Order" resource with GET, POST, DELETE, PUT primitives is useless as
it isn't telling your web shop front-end developers what actions are available
at any one time.

~~~
throwaway2016a
> I've been developing so-called "REST" services for over ten years (and SOAP
> services before that), and not even once were REST principles actually
> applied in the projects I worked on.

As a consultant who has talked at conferences on APIs and is brought in to
explicitly fix these kind of issues I have seen a lot of this too but correct
REST APIs do exist. I know because my team builds them.

You're experience is anecdotal and as is mine. But just because a lot of
people assume REST is something it isn't doesn't mean REST is inferior to
SOAP.

> Re: statefulness ("order matters")

My order matters comment had nothing to do with statefulness. I mean in the
XML. In SOP this might work:

    
    
      <order>
        <token>ABC</token>
        <price>19.95</price>
      </order>
    

But this will fail:

    
    
      <order>
        <price>19.95</price>
        <token>ABC</token>
      </order>
    

Why the heck does the order of keys in my object make the API fail!?

Granted that is not a limitation of SOAP but more XML schemas in general. Json
is more likely to be order of values agnostic.

But to play devil's advocate I can see the argument where if you are using
SOAP to make multiple RPC calls in the same envelope than order is important.

~~~
tannhaeuser
Ah ok. But to assemble XML/SOAP for these kind of payloads you'd typically be
using a lib such as JAXB, Jackson/gson, Spring (for Java at least) or SCA
anyway.

Moreover, you _could_ design your XML Schema such that both variants are
accepted (using XSD "all-groups"), though typically record-like data
structures are indeed described using XSD sequences which would cause the
issue you mentioned. Again I agree XML/XSD isn't a great payload/schema
mechanism for data structures such as maps; after all SGML/XML was invented
for encoding _text_. It's being used because it was the first mechanism on the
scene, and it continues to be used because it's still much more capable and
mature/established in terms of data validation than anything JSON, especially
for protocols used in communication with external partners/banks/authorities.

------
coldtea
> _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.

~~~
icebraining
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
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.

~~~
tannhaeuser
The "trick" is to use HTTP caching (build right into the protocol) so that not
every request needs to trigger full-page rebuilding. If you have eg. mod_cache
(or external reverse caches) enabled, your page composition script could be as
slow as it wants, it doesn't really matter.

~~~
DougWebb
For static or static-ish content, absolutely. But I was talking about (and
writing) web applications and web services, where the responses generally
aren't cachable.

------
pc86
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).

~~~
arcbyte
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
Sorry but trying to boil everything down to "dependency management" shows a
basic lack of understanding of software architecture and is objectively wrong.

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

------
Pamar
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-
par...](http://blog.christianposta.com/microservices/the-hardest-part-about-
microservices-data/))

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
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
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
What do you mean by 'database instance'? Is the the instance of the 'class'
that represents the database and its records or something else?

------
andyhedges
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
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
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.

------
jmartrican
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.

------
amirouche
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.

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

~~~
dvfjsdhgfv
Spencer's Unix quote also fits in there.

~~~
macintux
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-...](http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-
programming.html)

~~~
amirouche
Yeah, but aren't Erlang project a single code base?

~~~
macintux
You're right, it's definitely not a 1:1 mapping, but there are some
interesting similarities.

------
DanielBMarkham
_"...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.

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

~~~
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.

------
BjoernKW
> 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
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
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).

------
beastcoast
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.

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

------
bkovacev
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
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.

------
mindcrime
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.

------
pbreit
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.

------
the_arun
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
> ...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)

