6 ms·

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 monol

by FpUser 7y ago

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.

jzoch 7y ago
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.
- FpUser 7y ago
  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
  - jzoch 7y ago
    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.
    - FpUser 7y ago
      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.
    - deleted 7y ago
      [deleted]
  - jzoch 7y ago
    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 :)
    - FpUser 7y ago
      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
- hinkley 7y ago
  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.
brodie 7y ago
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.
- FpUser 7y ago
  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
  - jzoch 7y ago
    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
    - FpUser 7y ago
      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.
- to11mtm 7y ago
snupples 7y ago
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.
- gavinray 7y ago
  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.
- hn_throwaway_99 7y ago
  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.
closeparen 7y ago
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.
cortesoft 7y ago
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?
- FpUser 7y ago
  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.
- jeremyjh 7y ago
  Nothing stops you from running multiple instances of a monolith on different servers.
  - cortesoft 7y ago
    Right, but the person I was commenting was not really talking about microservice vs monolith as much as "I only need one server"
lkrubner 7y ago
"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?
- deleted 7y ago
  [deleted]
- FpUser 7y ago
  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.

by FpUser 7y ago

jzoch 7y ago

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.

FpUser 7y ago
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
- jzoch 7y ago
  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.
  - FpUser 7y ago
    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.
  - deleted 7y ago
    [deleted]
- jzoch 7y ago
  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 :)
  - FpUser 7y ago
    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
hinkley 7y ago
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.

brodie 7y ago

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.

FpUser 7y ago
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
- jzoch 7y ago
  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
  - FpUser 7y ago
    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.
to11mtm 7y ago

snupples 7y ago

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.

gavinray 7y ago
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.
hn_throwaway_99 7y ago
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.

closeparen 7y ago

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.

cortesoft 7y ago

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?

FpUser 7y ago
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.
jeremyjh 7y ago
Nothing stops you from running multiple instances of a monolith on different servers.
- cortesoft 7y ago
  Right, but the person I was commenting was not really talking about microservice vs monolith as much as "I only need one server"

lkrubner 7y ago

"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?

deleted 7y ago
[deleted]
FpUser 7y ago
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.