3 ms·

Ask HN: I can use your advice on Microservices VS Monolith

1 points by swtf 9y ago

Our current architecture at work is: |frontend angular| -> |Node.js MW Layer| -> |1 large microservice + 3 smaller ones all in Node.js| 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. He's argument is that monolithic apps can still scale well. Furthermore, it'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. I'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'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. Lastly a very smart person told me once to shard early. It's hard enough to shard early he said, so why do it when you're running out of time. That engineers argument is to just keep scaling up the DB. While I agree that's a temporary solution, in a world that produces and collects more data each day, sharding in my opinion is inevitable.

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

1 points by swtf 9y ago

dylanhassinger 9y ago

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

stephenr 9y ago

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