
The Great Microservices vs. Monolithic Apps Twitter Melee - Garbage
http://highscalability.com/blog/2014/7/28/the-great-microservices-vs-monolithic-apps-twitter-melee.html
======
coldcode
Anyone else tired of people arguing complex concepts in tweets? So hard to
read. People don't usually talk in single sentences.

~~~
FooBarWidget
Yes, extremely. I receive questions from time to time for which the answer is
complicated (and if I simplify the answer, the important nuance will be lost).
I usually write my response in a gist and tweet a link to it.

But the thing is: Twitter is extremely easy to use and the barrier to tweeting
is extremely low, more so than email. People are more inclined to tweet than
to send an email, even for complex subjects. As much as I dislike it, this is
how things are, so better accept it and use it to your advantage than trying
to fight it or complain about it.

~~~
johnchristopher
But why hasn't a twitter clone/alternative that would allow more than 140
characters taken off yet then ?

~~~
bunderbunder
There's an interesting startup that I think does that. It's called Facebook.

~~~
aikah
Then why are people using Twitter then ? You cant say Facebook is like Twitter
with more characters in the messages,it simply doesnt work.

~~~
FooBarWidget
Because Twitter has a lower barrier to entry. Yes the 140 character limit
sucks. But because of the character limit, people are more inclined to open
Twitter in the first place. The psychological advantage of that outweights the
disadvantage of hitting the 140 character limit later, at least for users.

------
FooBarWidget
Why is it "microservices" vs "monolithic"? It's not black and white, it's a
continuum. Why would 300 microservices make more sense than, say, 6 medium-
sized SOA apps?

According to the article, the point of microservices is scaling development,
not scaling as in req/sec. But development scaling can already be done without
microservices. You can already split source code in multiple files. You can
already refactor classes into multiple smaller classes. So then why are
microservices "awesome"? Why does it make more sense to have 300
microservices, each 500 lines, compared to 6 medium-size SOA apps, each
consisting of 25.000 lines spread over 50 files/classes?

Now, if you have 200 developers then I understand why splitting your app into
50+ independent microservices makes sense. But I get the feeling that lots of
developers, even those in 3-man teams, are jumping on the several-hundred-
microservices bandwagon.

~~~
lkrubner
We had this debate at my company. You might want to read this:

[http://www.smashcompany.com/technology/an-architecture-of-
sm...](http://www.smashcompany.com/technology/an-architecture-of-small-apps)

It's important to realize that you are wrong when you use the word
"continuum". In a true continuum you can move in both directions with equal
ease, whereas there is an important asymmetry in the tension between micro-
services and monolithic apps. Read this part:

"There is an important asymmetry between an architecture of small apps and an
architecture of The Monolithic CMS. If you have small apps, and decide you
want to move to a monolithic CMS, then you must do The Big Rewrite: the
exhausting effort of reproducing all of your funtionality so that it is
handled by your one, all-consuming CMS. But when you move from the monolithic
CMS to an architecture of small apps, there is no need for The Big Rewrite.
Instead you take some small part of your CMS, rewrite it as an independent
app, set the app on its own port, use your webserver to proxy the app-on-a-
port to whatever URL the CMS was previously using for that functionality, and
thus you’ve taken a step towards a new architecture without having to rewrite
anything but the functionality covered by your new, small app."

I did not hear the phrase "micro-services" until Martin Fowler wrote his essay
in March 2014, but clearly, what I talked about in that essay, 14 months ago,
is what we would now call micro-services.

~~~
krschultz
That's the first time I've ever read it was hard to move from a collection of
small services to a monolith, and easy to move from a monolith to small
services.

~~~
SerpentJoe
Agreed, that seems totally backward from my experience. I notice no
justification is given either, apart from describing both refactors
(small->large and large->small).

------
mbseid
I also think a lot has to do with language and deployment. Etsy uses PHP for
their entire codebase. PHP can be easily hot swapped without any overhead.
It's all scaffolded and thrown out every pageview. This provides a much
simpler deploy process and has much less impact.

Java on the other hand takes time to warm up. It just isn't practical to
redeploy the whole app when you are just updated one aspect.

------
emo_tards_on_hn
But, I have more services! But, each of my fewer services do more!

And this folks, is why IT is still a joke in most quarters.

