Hacker News Reader

Comment by FpUser | Hacker News Reader

I've never bought into this idea of microservices. Always wrote high performance native servers and have yet to encounter the situation when well designed monolith running on multicore monster with gobbles of RAM failed to satisfy client. Granted it will not work for Google but what does the world care. Most of the businesses (read potential clients) will never come anywhere close to those scales.

Long time ago when computers were slow I did design some distributed applications myself - reliable IP multicast server, business process servers, map reduce type solutions like bill generation etc where it did make sense. That was long time ago and now most of those at their old scale could run on a single reasonable priced server.

View on HN

Microservices can be useful in medium/large companies where you have many teams of devs and it becomes cumbersome to have them all work on one monolith. As long as there's good communication and understanding of needs between teams, each team can develop their services how they want, in whatever language/platform, with their own review and QA and deploy processes.

For smaller teams or small projects it isn't really super useful. Also, my personal experience is that when you start making microservices, the monolith doesn't go away. It also isn't so cumbersome if each team is in charge of one or a few services and you only split things if there's a clear benefit.

I'm probably saying things you already know. My point is that I think for multiple cooperating teams, monoliths and microservices are complementary.

I think a lot of this also becomes a question of where you choose accomplish the same root goal: if your team can maintain sound boundaries in either a large codebase or a bunch of microservices, test & tune well, you’re likely to have good results either way. A lot of people tend to see something working or failing and attribute it to the technology rather than the social dynamics behind it.

My current set of experiences say:

Microservices (where it makes sense) + Macrorepos.

Microservices are really handy when you're at scale and/or the problem you're solving works well with the paradigm. I'm thinking back to a gig I had where each of our vendor integration points (sending the same data, just formatted for that vendor) was a good use case even for a smaller company. We used Scheduled tasks to launch the application that did what was basically an ETL.

Oh, that vendor is down? Great, just have the sysadmin stop the thing.

No database muckery required. No need to build a fancy front end. Easy to delegate to/train on helpdesk type folks.

But any microservice is part of a larger ecosystem. It's critical to have a workflow that doesn't make refactoring the domain a huge chore/lift. IOW: Keep the related microservices in a single repo.

Really, unless you've got a use case like the above (processes that need granular control) or HA/Scaling concerns (since in that case you'll be able to better focus on the parts that need to scale), A Monolith or domain based services are the way to try to go.

I myself directed teams of developer up to 35. Do not know beyond that scale. Teams simply worked on modules and main designers made sure they complied to a shared interfaces / state machines in more complex cases. Not a big deal. The law was: I trust developer so here is your module interface and constrains. Now go away and come back with implementation (which would still compile to a single monolith). As I was lucky to work with very good programmers bar couple of bad apples I've never had any real problems with the delivery and its quality

Its clear that you could afford to not use microservices (which is great! You didnt burden yourself with the cool approach since it wasnt necessary). Not everyone has those requirements though and may NEED them

I completely fail to see what is so "cool" about increasing system complexity beyond of what is actually enough for most of the real life cases. To me: reliably working product is what is "cool" and that is what I've always pursued.

You don't need to "buy into" an idea to realize that there are advantages and disadvantages to a given approach.

Take one example: The single server idea is going to suffer outages. You could at the very least have two monoliths either load balanced or in some kind of failover setup.

But, what distributing some of the components into so-called microservices would give you is a graceful failure scenario where even if all the instances of a specific component fail, the rest of the application still works. Maybe only one function stops working temporarily but most work continues on.

This doesn't mean everything must be microservice koolaid all the time all the way, but I'm sure you can conceive of that being an advantage under certain use cases that would be worth other possible trade-offs.

I have done extensive work with monoliths, and extensive work with microservices. I quite literally have never seen microservices be a benefit in the way you are describing, and if anything microservices can make the problem of robustness more difficult, because in many workflows there are one (or many) services that are critical. If they're down, everything is down, and if anything distributing these dependencies across different systems can make it more difficult to determine where the critical points of failure are.

As you point out, there is nothing inherent in a monolith that makes it less robust. I currently am building a monolith that is deployed on auto-scaling servers on a cloud provider, so if one server dies it just spins up other instances.

I have also done extensive work on both (I'm much older than the word microservices) and have found advantages to both approaches depending on requirements.

I've also found that most so-called monoliths still often end up breaking apart components anyway. I've only seen true monoliths as described above in the mom and pop type IT shops where there's only a couple support staff and they don't have the resources or experience to properly break things out into separate resilient components. And yes supportability is definitely a valid part of that design call.

Again that was just one example of a potential advantage to it while admitting there are trade offs. Others here have given better examples such as at larger orgs where multiple independent teams get involved with a single app.

This is what I do, I just develop monolithic stateless API's in Docker containers and run them as serverless Cloud Run apps or as Kubernetes pods, if one of them fails it's no big deal.

For particular usecases that fall out of the wheelhouse of my preferred language, I'll typically use single OpenFaaS functions + endpoints for these things (think doing ML with Python, or really heavy computation with Go/Rust).

This combination of containerized Mostly-Monolith with single-purpose endpoints for particular usecases works really well and is very productive. If something is much easier in another language (due to tooling/ecosystem) for example, then I can just build that method or sub-system out in whatever language it's fastest in with this architecture.

> But, what distributing some of the components into so-called microservices would give you is a graceful failure scenario where even if all the instances of a specific component fail, the rest of the application still works. Maybe only one function stops working temporarily but most work continues on.

The important thing to note here is that microservices give you one way to build a graceful failure scenario. You don't get it for free. Often that 500 will propagate all the way back! So you have all the same failure modes + network failure modes!

You could also build a monolith that could handle component level failures, for that matter. Tooling doesn't seem to be as common, though.

I don't disagree with you at all. There are certainly different ways of thoughtfully building things.

The point being you don't need to be a paying subscriber to microservices(tm) to recognize there can be positives to the approach, which you describe in your last paragraph

A monolith that can handle component level failures is very close to the same idea infrastructure-wise minus a lot of baggage implied by the buzzword microservices.

"A monolith that can handle component level failures" - being able to handle component level failures I think is more related to business logic design rather than being a monolith/microservice implementation. If your business process depends on some login microservice and that one is down it does not matter that the other parts are functional.

So just to play to your hypothetical. If there were two login methods, and they were separate microservices, if only one failed and the other remained up, that would be the graceful failure scenario.

I'm not telling you that you must to do this. Others may have requirements that go beyond yours.

"running on multicore monster"

Just curious, but how do you take advantage of the multiple cores? Are you using a language that handles concurrency directly, with something like threads? If you use a language that has historically been single threaded (Ruby, PHP, partially Python) do you use multiple processes? If you use multiple processes, what manages the processes? What can spin up additional processes? And when you talk about a "multicore monster" what are you actually running there, the application or the web server or both? If the web server runs elsewhere, how does it connect to the app? Do you have something else to load balance the web server itself?

I write multi-threaded servers in languages like C++/C/FreePascal/Java. As how to properly write multi threaded applications that take advantage of multiple cores? Well I think it is beyond the scope of this discussion. I have no desire to write lengthy articles. It takes experience anyways and ff you do not already know how to do it putting few words in newsgroup is not going to help.

You can have a monolith distributed across many machines, all your microservices running on the same machine, cluster per microservice, all your microservices running in a shared cluster, etc. Those axes are only tangentially related.

Do your clients not have availability needs? Even if one machine can handle the traffic levels, what if there are hardware failures? How do you do patching?

I've always had failover functionality built in. As for patching - it very much depends on the nature of the patch, type of application and business constraints. Too much to write here. For the most part it never caused me any particular grief. The most generic case for server type is: all new requests are denied with appropriate error code, all requests in process are either gracefully completed or aborted if business logic allows for that. Meanwhile the background process is migrating/upgrading in place data model if there are any changes. Upon finishing the upgrade the new server takes over.

I do not thing upgrading microservices is any simpler. It could actually be way way worse.

Nothing stops you from running multiple instances of a monolith on different servers.

Right, but the person I was commenting was not really talking about microservice vs monolith as much as "I only need one server"

If you dont have a team large enough or a business big enough to need multiple individual services than you aren't the target market. Unless you care about high availability (which small services can help you achieve) then a single server is fine.

Everyone wants to believe they are the target market. That’s the problem.

What you should be doing is telling people what they need to hear and let the biggest layers figure out for themselves that they don’t work that way.

But we want to know what the big people are doing as if that will let us become big too.

But the bulk of what we do is reacting to situations, not creating them.

May I ask what high availability has to do with the microservices? Since many of my servers were designed for relatively large companies (like TELCO) high availability/reliability requirements were always there. Running 2 or more monoliths in parallel with the appropriate logic built in does not make them into micro services

if they are large enough and have components that need to scale independently than a bottleneck in one of those components may affect availability of the service.

Or may not. I design and create products that serve particular problem for customers while satisfying reasonable constraints. If it comes to a situation you've described than it will be spun into a separate component. I already told that I did and know how to do distributed applications. The keywords here are "WHEN NEEDED". And on modern hardware it is not in my cases.

also running two very large pieces of complex software in parallel is not always easy without breaking out the things that cant always be run in parallel :)

Whatever problems you MIGHT have with the monolith - the same problems will hunt you in your microservice implementation. You'll just have a lot more microservice related problems as an extra toppings. Also it sounds like you're bringing straw arguments without having practical experience

Reply on news.ycombinator.com