51–60 of 139 posts
That's an overstatement if I've ever heard one. Staring a greenfield project with microservices is a nightmare. In a greenfield monolith you can code and deploy your dependencies together. In greenfield microservices? Oh, right. Set them all up for deployment, figure out netwroking and access between them, any change requires the fix-test-deploy dance etc.
Earlier quoted context omitted.
I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re already doing so by running multiple workers/threads in your application server. Spreading that to other machines is trivial. The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database,…
Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion. And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!). If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic. And since it's likely a nonlinear problem i…
For deploying they are nothing but a very large hindrance.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
Earlier quoted context omitted.
I wouldn't blame (badly implemented) DI for all the problems of monoliths. I think the real main issue is lack of discipline when dividing the application into modules. Spaghetti is basically defined as an application where real modularisation does not exist and everything talks to everything. It is much easier to work with an application when you can abstract parts of it when you are solving your problem. You effect…
Ravioli == you have so many small distinct things on that are hard to stick together, which makes it hard to build a larger structure out of them.
Sure, if you were ready to make an entire separate application for it it will not be worse when you turn it into one package of a monolith?
Also you can build nested structures with modules (like a larger module consisting of smaller submodules).
Divide and conquer. This is how abstraction works in a nutshell. You start with a large problem, divide it into smaller parts (modules), each part you treat as a separate problem dividing it into smaller modules, and so on.
There exists no need to have a flat application consisting of hundreds of sibling modules.
An application might consist of larger modules, then some of those might have smaller submodules (packages), then those might have even smaller ones (classes), then you have methods, then you have statements, then you have function calls, etc.
A large monolith does not have to succumb to spaghetti or ravioli-type structuring. A good developer should know how to structure an application of any size.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
Do you know what kind of software has an absurd level of horizontal scalability by default? Web servers. The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this. There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an…
> but it's an ergonomics change, not one of capability. Isn't that a bit of an empty argument. Literally anything Turing complete is an ergonomics change when compared to anything else Turing complete. We are writing for the same computer. There's nothing different (fundamentally) about the kernel and my program.
What you have on your desk isn't equivalent to a Turing machine.
Architecture astronauts love microservices. I'm watching a government customer take simple, cohesive systems developed by a small team (4-5 people) and split it up into tiny little pieces scattered across different hosting platforms and even clouds. Why? Because it's "fun" for the architects and pads out their resume. Just now, I'm watching a "digital interactions" project that will have dozens of components across t…
Fingers crossed he doesn't discover k8s...
Earlier quoted context omitted.
Farming out libraries or subprojects to separate teams is an ok way to go as long as you don't mind a single language/build system. Its not as flexible but you maybe get some perf out of it. You don't get the convenience of a single datastore with simple transactions but it sounds like you prefer the flexibility of services owning their own data. As it turns out there's no silver bullet. Do what works for you.
>> single language/build system Imagine designing your entire architecture around your build system.
On the opposite extreme you're talking multiple PRs, languages, test suites and deploys for every new feature. I've watched startups do this and die before finding something people want to buy.