Article is from 2015. Should this be added to the title?
Monolith First (2015)
181–190 of 356 posts
Re: Monolith First (2015)
#182Earlier quoted context omitted.
When the same practices used to sell microservices get applied to modules, packages and libraries, there is no need to put a network in the middle to do the linker's job. But too many are eager to jump into distributed computing without understanding what they are bring into their development workflow and debugging scenarios.
More generous take on the meta: people do understand (some of) the problems involved but are less worried about debugging scenarios than resume padding. The most useful property of microservices is architecturing CVs.
Correct. What's best for the long term health of the business is not taken into consideration. The Board of Directors and the CEO only care about this quarter and this year, why would the foot soldiers take a long view?
As an engineer, the thought process goes: I can use the same old tried and true patterns that will just get the job done. That would be safe and comfortable, but it won't add anything to my skillset/resume.
Or we could try out this sexy new tech that the internet is buzzing about, it will make my job more interesting, and better position me to move onto my next job. Or at least give me more options.
It's essentially the principal-agent problem. And by the way, I don't blame developers for taking this position.
Re: Monolith First (2015)
#183Earlier quoted context omitted.
Does each microservice/module have its own db?
Nope. Everything lives in one big DB, but services are not allowed to touch each others tables directly - communication must be done through service API endpoints.
I have seen micro-service architectures like that. It seems pretty pointless. You should be letting the database do as much of the heavy lifting as you can.
Re: Monolith First (2015)
#184Micro services is a networked/cloud buzzword for The Unix Philosophy. Doing “one job and doing it well” implies, though, that you know what that job is, what the right tool is, and that you know how to do it well.
Another word for “monolith” could easily be “prototype” for the sake of this article.
If only we all had the time and money to do real software engineering, amirite? But, time and time again I’ve been proven out that “the hack becomes the solution” and that we’re not going to go back and “fix” working code.
Re: Monolith First (2015)
#185Earlier quoted context omitted.
That is EXACTLY what I have observed, time and time again. If you have trouble managing ONE application what makes you think you will be better at managing multiple? Also, running distributed system is way more complicated than having all logic in a single application. Ideally you want to delay switching to distributed system until it is inevitable that you are not going to be able to fulfill the demand using monolit…
Monoliths are also distributed systems and will run on multiple hosts, most probably co-ordinating on some sort of state (and that state management will need to take care of concurrency, consistency). Some hosts will go down. Service traffic will increase. I understand your point. You are using distributed in the sense of "how is one big work distributed", you probably also hate overly "Object Oriented code" for simi…
> But distributed systems is a well understood thing in the industry.
Wait, what?
Distributed systems are one of the most active areas on CS currently. That's the opposite of "well understood".
It's true that most systems people create are required to be distributed. But they are coordinated by a single database layer that satisfies approximately all the requirements. What remains is an atomic facade that developers can write as if their clients were the only one. There is a huge difference between that and a microservices architecture.
Re: Monolith First (2015)
#186If we were to ignore the mechanism part of microservices, we could say that qmail and postfix have a microservices architecture. Both of them have fared much better than monilithic Sendmail. And, their track records for resilience and reliability are very encouraging too.
There exist other ways of designing 'microservices' that are not necessarily conventional monoliths!
Re: Monolith First (2015)
#187I like the "peeling off" strategy - starting with the monolith and adding microservices from the edges.
I've been working on something that tries to make starting with a monolith in React/Node.js relatively easy. Still don't have much of the "peeling" support but that is something we're looking to add: https://github.com/wasp-lang/wasp
Re: Monolith First (2015)
#188IMO this is an unnecessary dichotomy that we're currently forced to deal with, because we don't yet have a good solution for programming the "cloud" the same way you program a for a single computer, and that ends up leaking into all the consequent decisions of modularisation, performance, code management, deployment, team organisation, etc.
(My holy grail would be programming for distributed environments as if you had one giant single-thread computer, and function calls could arbitrarily happen over IO or not, then concerns would boil down to code organisation first. I believe Erlang's OTP model or the way some features of Google Cloud Platform are organised gets us closer to this ideal, but we're not quite there yet.)
Re: Monolith First (2015)
#189IMO this is an unnecessary dichotomy that we're currently forced to deal with, because we don't yet have a good solution for programming the "cloud" the same way you program a for a single computer, and that ends up leaking into all the consequent decisions of modularisation, performance, code management, deployment, team organisation, etc. (My holy grail would be programming for distributed environments as if you ha…
This is a great summary of the problem, upvoted.
Re: Monolith First (2015)
#190Earlier quoted context omitted.
If you think of microservices as a modularization tool - a way to put reusable code in one place and call it from other places - then you are missing the point. Microservices don’t help solve DRY code problems. Monoliths aren’t merely monolithic in terms of having a monolithic set of addressable functionality; they are also monolithic in terms of how they access resources, how they take dependencies, how they are bui…
Monoliths don't have to be deployed as single instance. In any case, too many rush for micro-services with the intent reason to use the network as a package boundary. Have you ever tried to debug spaghetti RPC calls across the network? I sadly have.
It is possible that there are architectures other than ‘monolith’ and ‘microservices’. Component architectures are also a thing. If it doesn’t all deploy in one go, I don’t think it’s a monolith.