
Ask HN: I can use your advice on Microservices VS Monolith - swtf
Our current architecture at work is:
|frontend angular| -&gt; |Node.js MW Layer| -&gt; |1 large microservice + 3 smaller ones all in Node.js|<p>A new engineer on the team suggests that we merge all the applications together. We render the frontend using express, and combine the microservices together.<p>He&#x27;s argument is that monolithic apps can still scale well. Furthermore, it&#x27;ll be easier for engineer to roll out features since the entire code is in one project, and a feature can be developed all the way from the back to the frontend.<p>I&#x27;m finding his argument hard to believe. An app of that size can end up very coupled. It will be a single point of failure. If one child process crashes so much damage can be done. DB ORM will run slower because of how DB intensive the app will be.  Obviously many of these issues can be solved with sufficient scaling. Which would also cost more since we&#x27;re not scaling whats in demand, but instead the entire app. -- Even if we decide to split the app down the road that only means a way larger effort.<p>Lastly a very smart person told me once to shard early. It&#x27;s hard enough to shard early he said, so why do it when you&#x27;re running out of time.<p>That engineers argument is to just keep scaling up the DB. While I agree that&#x27;s a temporary solution, in a world that produces and collects more data each day, sharding in my opinion is inevitable.
======
stephenr
Unless your app is going to hit massive scales (hint: it won't. the chances
that you are one of the few that do is so minuscule, it's not worth assuming
it will happen), optimise for simplicity, not scale.

Micro services are the exact opposite of simplicity. What used to be a method
call, is now a network request.

With a monolithic application, you have to worry about the application process
(which may be Node directly, or may be an application server like Phusion
Passenger), and the associated services it depends on: database, caching,
possibly http/tls front-end.

With a micro services architecture you have to worry about all those processes
for each and every micro service. Sure, they may be sharing a database, but
they also may not. They may be sharing a caching layer, but they may not. They
may not even use the same caching/database software.

Unless your app _already_ works when one of the four micro services is down,
any argument about "single point of failure" is moot, because you currently
have 4 single points of failure.

~~~
swtf
I don't think I'm convinced. But maybe I'm missing something ?

You can't go on assuming user base won't grow. Also massive is not a
quantifiable amount. There are certain thresholds that require the application
to scale, and those depend on the functionality expected. If I hash passwords,
but I can only hash 100 at once. If I offer integration API's that get hit
more often than my actual site. Will I need to scale my monolith app for those
specific cases?

To say that a large application let's you focus on just dev work is a bald
statement in my opinion. A large application is harder to test, harder to
deploy, changes have a higher risk, risk of data leaking by mistake, very
coupled, and not simple -> harder to design for -> harder to move stack. Just
on boarding an engineer into a monolith app from my experience is hard..

I'm not sure how with micro services you're worried about the processes? I
lost you there..

I have a quick script that spits out a microservice with basic health
endpoint. I made a communication module that uses sockets and parent as a bus
to communicate through.

A bank offers some sort of signin application, statement generating (sent to
email), some api's for payroll, and maybe an integration with a credit card
where it notifies customers about any purchases made. When sign in is down, it
doesn't mean you shouldn't get alerts about CC purchases, or that reports
shouldn't be generated. Even when you're signed it's possible certain feature
might not be active. With a mono if a bug took down the application every
service you offer is down. --- This scenario is very much around the kind of
service we want to provide.

~~~
stephenr
> You can't go on assuming user base won't grow.

The number of developers today who assume their user base _will_ grow, and
optimise for that, when it's not required, _far_ exceeds the number who assume
their user base _won 't_ grow, and have growing pains because of it.

> If I hash passwords, but I can only hash 100 at once

What do you mean _if_? Why would you ever _not_ hash passwords?

Also, this is exactly what horizontal scaling is for, which you need to deal
with regardless of whether you're using micro services or not.

> A bank offers some

first off - you're still comparing yourself to a massively different field. If
you _are_ working for a bank, you shouldn't be asking for this type of advice,
unless you've lied to them about your skills.

secondly - those things you described are all different applications within a
bank. There may be _some_ integration but more likely the common point for
them all is a massive mainframe system that they all interact with. That is
not micro services.

~~~
swtf
> The number of developers today who assume their user base will grow, and
> optimise for that, when it's not required, far exceeds the number who assume
> their user base won't grow, and have growing pains because of it. I think
> discussing this point is useless. For the same of the argument assume we
> are.

> Also, this is exactly what horizontal scaling is for, which you need to deal
> with regardless of whether you're using micro services or not. I give you
> that. You can. I don't think it's a correct approach, but you can def just
> scale once you hit your smallest bottlenecks and you'll be fine (I think).

>first off - you're still comparing yourself to a massively different field.
If you are working for a bank, you shouldn't be asking for this type of
advice, unless you've lied to them about your skills. >secondly - those things
you described are all different applications within a bank. There may be some
integration but more likely the common point for them all is a massive
mainframe system that they all interact with. That is not micro services.

I'm confused. How do you know which field I'm working in? I am comparing us to
a bank because like I said, the services we offer are very similar. I
shouldn't be asking for advice? That's plain ignorant. I am asking for the
advice because I am a strong believer in micro services but I figured I'd
rather ask people for their opinion to see what I get without the title giving
away my thoughts. I doubt you would have clicked this thread if what you read
was an opinionated title saying "Micro services are the only way" at least I
wouldn't. I'd assume that persons mind won't change. Instead I wanted to get
as much feedback as possible (including yours :) ).

While the banking world moves slow, and tends to make up new terms for
anything they do to make them sound cooler. The newer core banking systems
(check out cloud banking, micro service banking) are usually composed of
smaller services that communicate through some buss and managed through one
uniform API. I'm pretty sure that's along the lines of micro services or at
the very least more micro than mono! -- When I say new I mean within the last
10-15 years. I worked at Citigroup and they had that structure implemented on
so many of their products.

~~~
stephenr
You're asking for technical advice for a financial platform, on HN, watering
hole for flavour of the week, cargo culting, me-too cool kids who change
software stacks, libraries and development methodologies more often than they
change their underwear.

 _That_ is why I said you shouldn't be asking for advice here, if you're
working on a banking like platform.

It's like a brain surgeon going to ~~~webmd.com~~~ reddit.

As for the bit about horizontal scaling: if you have a limit like # of hashes
per second you can generate, microservices isn't going to solve that -
whatever is running your password checking code has that bottleneck, and the
answer is either (to a point) faster cpu's, or more frequently and eventually
inevitable at scale, distributing the workload. That means multiple servers
running the same code to handle more clients - aka horizontal scaling. That's
unrelated to whether it's monolithic or microservices based.

Edit: more appropriate analogy

~~~
swtf
You just sound angry..

------
dylanhassinger
its an art not a science. use your best judgement

in my opinion, a small collection of core services is better than a monolith
or a large collection of tiny services

Somtimes it makes sense to have multiple services live in a single "monorepo"
for shared tooling and other resources. 1 repo, deployed to multiple places
for different purposes.

~~~
swtf
Oh how I would love to hug you right now.

My initial response to the team when I heard the proposal was that programming
is an art form. There is a beauty how software is organized and orchestrated.

Given that the microservices do very different things, combining them together
will do nothing but clutter a the code base. JS gives an excellent module
system which allows for maximum code reuse. That should be emphasized. But
combining 6 code bases together into a project that is planning to expand
extensively over the next year makes little to no sense at least to me.

