Yet another “based on my experience” opinion. Based on my experience our service would fail due to performance because we’ll , nodejs is still single thread. Given this we should either duplicate deployment of big service by roles that gives you same level of orchestrating complexity or rewrite in different languages, means hello microservices again :) ps our product was initially written by non tech cofounders that used heroku and microservices from day one. They used a swarm of small services to stay on free tier. So microservices in this use case are cheaper. And yes, it's simpler for non experience developer to get up to speed with your backend if it's a simple service.
Some thoughts on microservices
81–90 of 139 posts
Re: Some thoughts on microservices
#82One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
This doesn't match my experience at all. In particular, in the case where a small team is working on a series of small projects it can make a lot of sense to split up the components so that any one of the small projects can be built with one or two existing generalized components along with some custom machinery and some glue code to bring it all together. That way development of all of the small products can contrib…
The major difference is whether the small projects are independent applications that use some shared libraries (what I think you mean by "existing generalized components") or whether the small projects all talk to each other to create a single large application.
If it's the former then you're just talking about refactoring functionality into a shared library, but at the end of the day you're still just building little monoliths. You don't have to worry about most of the problems that come up with microservices.
Re: Some thoughts on microservices
#83Earlier quoted context omitted.
Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.
So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
I didn’t read any of that. I read it as more tools in the toolbox.
Re: Some thoughts on microservices
#84I was going to say that one nice aspect is that rollbacks are less frequent because the size of each deployment is smaller. But I've worked on million line code bases that still do weekly CICD pretty well, so I don't know if that advantage really holds water.
Re: Some thoughts on microservices
#85Yet another “based on my experience” opinion. Based on my experience our service would fail due to performance because we’ll , nodejs is still single thread. Given this we should either duplicate deployment of big service by roles that gives you same level of orchestrating complexity or rewrite in different languages, means hello microservices again :) ps our product was initially written by non tech cofounders that…
Node can run multi-process with the Cluster module. Node being written as a monolith but running it in 100 instances is also an option. Roles can be implemented in software. There's much less "orchestrating complexity" when you're deploying a single service.
So Node being single-threaded is not itself a reason to use microservices.
I tend toward writing a monolith for the core API of a service, but then break out microservices for tasks that need to scale independently (or that need to run on high-memory/high-performance instances, for example). So I'm not totally against using microservices. But we should choose to use them when they're to our advantage to use them, not just "because they're already written that way."
Re: Some thoughts on microservices
#86One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
It is worth thinking about them before you need them because by the time you gain the skill and infra needed to support them, you’ll have scaled so large that your ability to coordinate and communicate will be overwhelmed.
How many startups out there have run into the problem of "oh no, we got too big too fast"?
Re: Some thoughts on microservices
#87Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment. Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely m…
Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.
I'd be more worried with, "do you just have shared infrastructure for all data?"
Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.
Re: Some thoughts on microservices
#88Earlier quoted context omitted.
So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?
I didn’t read any of that. I read it as more tools in the toolbox.
Without single instance, an in process queue doesn't provide the same kind of functionality that a shared queue does and would probably introduce split brain kind of problems, no?
Re: Some thoughts on microservices
#89I'm looking at micro services for a different reasons: security. I have given up on the idea that our code will ever be completely secure. However micro services means if someone breaks into one service they can't see data belonging to a different service. (that is run each service as a different user, and so OS protections means file commands cannot open such data) This only protects against some threats related to…
I could maybe see that for some specialized case, but for the general case it seems like the more independent, distributed things you're juggling, the more likely you are to end up with security holes in the first place. The time you have to spend on security would have to be spread too broad and thin.
Re: Some thoughts on microservices
#90One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.
This is key. Recently I've become a bit obsessed with naming, and not just because naming needs to be consistent and coherent - how you name something in software dictates how you will think about it, what concepts you will relate to it, etc. The name of one component can affect your entire architecture. I'm not sure how to validate it, but I believe that naming choices are almost as important as application architecture because of their effects on your thought process.