Write a monolith first, then decompose into microservices.
That's it.
Monoliths Are the Future
501–510 of 567 posts
Re: Monoliths Are the Future
#502FYI this is about monoliths vs. microservices, not microkernels.
Re: Monoliths Are the Future
#503Earlier quoted context omitted.
Programmers are, by and large, quite bad at not breaking encapsulation when they're dealing with a monolith. Not their fault, really, but when management comes to you and says, hey, can't you get it done in just a day, we really need this, and you know you could if you just hacked through that particular isolation barrier just this once , and yeah it will create bad bugs if things change in a particular way in the fu…
> Programmers are, by and large, quite bad at not breaking encapsulation when they're dealing with a monolith. What is there about microservices that makes them better at this? Most of the stuff I have seen has been highly coupled.
Physical isolation. I don't actually like the arguments but I can't quite say it's wrong, because the Java landscape just put a huge amount of effort into modularity and encapsulation because developers kept using reflection to bypass module boundaries. Usually for performance reasons. With a microservices architecture that is impossible anymore because there is physically no way to read across address space boundaries without sending a message and introducing an RPC, which would require the support of the target module.
Now that said, with the new jigsaw module system in the jvm, and the multi-language support that is constantly getting better, a disciplined enough senior management team could enforce module boundaries within the process. It means any change to jvm command line flags would require the approval of the most senior tech lead, because that's how module boundary enforcement can be disabled, but if you have that and it works you would get significant performance and simplicity benefits.
Re: Monoliths Are the Future
#504Earlier quoted context omitted.
> Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. This line of argument fails to take into consideration any of the reasons why in general microservices are the right tool for the right job. Yes, it'…
> Take for example Celery. With Celery all you need to do to implement a queuable background task system that's trivially scalable is to write the background tasks, that's a little bit of a straw man because that's not the "microservice" architecture this post is talking about. I personally wouldn't call that a "microservice" architecture, I'd call it, "a background queue", although strictly speaking it can be descri…
> that's a little bit of a straw man because that's not the "microservice" architecture this post is talking about. I personally wouldn't call that a "microservice" architecture, I'd call it, "a background queue", although strictly speaking it can be described as such.
It is not a strawman; it's a concrete example of the technical, practical, operational, and economical advantages of microservices architecture, more specifically service reuse, specially managed services provided by third parties.
While you're groking how a multihreadig library is expected to be used, I already fired a message broker that distributes tasks across a pool of worker instances. Why? Because I've opted not to go with the monolith and went with the microservices/distributed architecture approach.
Re: Monoliths Are the Future
#505I think most people who flock to Micro Services are looking for a better design / architecture choice for software. The thing that Micro Service can teach you is Single Responsibility Principle and learning to segregate responsibility. You need to define a clear scope of the 'modules' in your system. At the end of the day if you don't architect your system correctly Monolith / Micro Services won't help you. For me an…
I think the monolith vs microservice question is more about organizational needs than anything else. Technically neither is superior, and the debate pales compared to the need to only hire quality developers. Good developers can make either pattern work, and bad developers can break either pattern.
You said it man. I agree with you.
Re: Monoliths Are the Future
#506Each to their own. I've worked with both, success with micro-services is largely a function of the organisation. My current company started transitioning 18 months ago, I wouldn't say it was easy but we are in a far better position now than we were with our monolithic architecture. Our success is largely due to the company understanding that big changes would be necessary - things like org charts, engineering culture, engineer responsibilities and job descriptions (you would be forgiven for thinking we only hire SREs).
Re: Monoliths Are the Future
#507I couldn't agree more with an article. Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. Three signs you have a distributed monolith: 1. You're duplicating the tables (information), without transformin…
> Don't duplicate data without adding value to it. What about running multiple versions of a microservice in parallel -- don't each need their own yet separate databases that attempt to mirror each other as best they can?
No.
Re: Monoliths Are the Future
#508Earlier quoted context omitted.
The author is a Kubernetes expert, so perhaps you are the student and not the master? https://github.com/kelseyhightower/kubernetes-the-hard-way
A person’s perceived status shouldn’t win them an argument.
I didn't declare their argument won, lost or invalid. I did suggest that they consider the bona fides of the person whose opinion they were tossing off as uneducated.
Thanks for the downvote, though.
Re: Monoliths Are the Future
#509Earlier quoted context omitted.
> Take for example Celery. With Celery all you need to do to implement a queuable background task system that's trivially scalable is to write the background tasks, that's a little bit of a straw man because that's not the "microservice" architecture this post is talking about. I personally wouldn't call that a "microservice" architecture, I'd call it, "a background queue", although strictly speaking it can be descri…
> that's a little bit of a straw man because that's not the "microservice" architecture this post is talking about. I personally wouldn't call that a "microservice" architecture, I'd call it, "a background queue", although strictly speaking it can be described as such. It is not a strawman; it's a concrete example of the technical, practical, operational, and economical advantages of microservices architecture, more…
You can have a worker pool with a monolith too. Just run multiple copies of your app.
Re: Monoliths Are the Future
#510Earlier quoted context omitted.
He/She cannot do that, at least at their employer, because people would throw up at the sight of the code and cry until its rewritten. As an example slip some DOM methods into your code and watch people go into convulsions like an angry zombie on cocaine.
There are very real reasons not to use DOM methods assuming you're using a front end framework. Not only is the coding style more imperative than say React, but frontend frameworks have been designed to efficiently update the DOM and have diffing algorithms that can check for necessary state changes. Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020?
Maybe they don't want to force their users to download several MB of framework libraries in order to use their website.
DOM manipulation is perfectly fine for interacting with styled documents, the web's forté. If your website amounts to a set of configuration forms and a blog then you probably don't need React.