Monoliths Are the Future • Hacker News Board

Re: Monoliths Are the Future

#421

Post by yahyaheee » Fri, Jan 31, 2020, 1:17 AM UTC

BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

This is a problem but I’m not sure having everything in a single data store is a great idea either. Generally you want your analytics separate from your operations anyway. We do this by having a central ES instance which just informs on the data it needs, which had worked perfectly fine for our needs

Re: Monoliths Are the Future

#422

Post by nathankunicki » Fri, Jan 31, 2020, 1:17 AM UTC

jsjohnst wrote: post #132

nathankunicki wrote: post #116

Earlier quoted context omitted.

With less flexibility, and more round trips.

> With less flexibility, and more round trips That all depends on the API.

Sure - but if you ever want it to be as flexible as GQL, you need to implement...a query language?

Re: Monoliths Are the Future

#423

Post by yahyaheee » Fri, Jan 31, 2020, 1:19 AM UTC

Eh I think 5 years from now you’ll be able to deploy and manage a distributed architecture like a monolith. There is so much energy in this space and the problems are being solved we’re just not there yet.

Re: Monoliths Are the Future

#424

Post by huherto » Fri, Jan 31, 2020, 1:22 AM UTC

closeparen wrote: post #57

My employer adopted microservices for a very specific reason: it became nearly impossible to deploy the monolith. With hundreds of commits trying to go out every day, probability that at least one would break something approached 1. Then everything had to be rolled back. Getting unrelated concerns into separate deployable artifacts rescued our velocity. It came with many of its own challenges, too! A great deal of in…

But how big are your microservices ? How many did you build ? A monolith that has hundreds of commits is very worth separating it. But do you break it on 10, 100, 1000 microservices ? We have a case where we have 20 people managing 40 microservices. Way too granular. In the general literature there is not good consensus finding boundaries and rightsizing. Many authors just duck the question.

Re: Monoliths Are the Future

#425

Post by mfDjB » Fri, Jan 31, 2020, 1:26 AM UTC

franciscop wrote: post #420

mfDjB wrote: post #414

Perhaps there is a problem where people are splitting a perfectly good monolith into microservices, but I do wonder how do you deal with large scale machine learning without microservices? I am a rather small operation and I still have models taking several gigabytes worth of memory and ANN indexes of about the same size, which clearly couldn't operate in a monolith unless it was a massive machine, and even if it cou…

Is there any problem with separating the ML into a different service/machine, and everything else together? Then you can treat the ML in the same way you treat an external service, or your DB or Redis (if external). While no longer a pure monolith that certainly doesn't qualify as a microservices architecture. Note: no idea what I'm talking about, I'm genuinely curious if that's a valid solution.

You could do that, but then I wonder if that isn't going down the road of microservices? The ANN services for example would need to interface to the database if you want some kind of real time ANN service.

Re: Monoliths Are the Future

#426

Post by [deleted] » Fri, Jan 31, 2020, 1:28 AM UTC

yes_man wrote: post #374

rubyn00bie wrote: post #347

I 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…

I don't want advocate one way or another (micro vs. monoliths) because tomato tomato. However here are a few arguments in defense of microservices regarding these three signs you commented: 1. Microservices do not have some inherent property of having to duplicate data. You can have data in single source and deliver that data to anyone who needs it through an API. There are infinitely many caching solutions if you ar…

[deleted]

Re: Monoliths Are the Future

#427

Post by franzwong » Fri, Jan 31, 2020, 1:32 AM UTC

I am just thinking if I use different kinds of SaaS, is that also treated as microservice?

Re: Monoliths Are the Future

#428

Post by davnicwil » Fri, Jan 31, 2020, 1:37 AM UTC

0x445442 wrote: post #379

davnicwil wrote: post #199

Earlier quoted context omitted.

> people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript. Do you have a concrete example to illustate this, and what issues it causes? On the surface I'm not sure I agree, if what you're saying is people wanting a certain feature should switch languages…

What new problem was Nodejs trying to solve and why does it exist?

Well, indeed, Node is a good example of the point I'm making - it provided a full environment for writing programs in JS outside the browser.

There were a plethora of other languages/runtimes available for writing such programs, but Node made this available to people who already knew & liked using JS without having to switch to and/or learn a new language.

Re: Monoliths Are the Future

#429

Post by tynpeddler » Fri, Jan 31, 2020, 1:40 AM UTC

notJim wrote: post #217

tynpeddler wrote: post #181

There are two big reasons to go to microservices (note that the exact definition of microservice can vary a lot). 1. Organizational streamlining. If the team working on the monolith becomes to large, then coordinating and pushing out changes quickly can become incredibly difficult. One rule of thumb I've heard is the two pizzas rule. If two pizzas can't feed the team working on a system, it's time to break up the sys…

Regarding point 1, why is coordination required? I think that continuous deployment, where you're integrating dozens of times per day solves this problem much better.

In large, distributed teams working on very large monoliths, it's pretty easy to end up with conflicting changes. In such monoliths, the testing process also tends to be long. So you run your tests, get a pass, but someone else merges in before you and there's a conflict. You resolve the conflict quickly (if you're lucky. Some conflicts are not easy to resolve), you rerun your test suite, only to find out that someone else has merged ahead of you again and you have to go through the loop one more time. And all of this assumes that no one breaks the pipeline.

At this point, many teams institute a merge queue. Which works only until more devs are added to the teams, which makes the merge queue very long and it can take several days in the ideal case to get things merged.

Re: Monoliths Are the Future

#430

Post by andrewrothman » Fri, Jan 31, 2020, 1:46 AM UTC

My approach to this is pretty simple. For existing systems, don't refactor from one to the other unnecessarily. If you do decide to refractor, do it in small steps, one piece at a time.

There are huge advantages to both patterns. For newer systems, if there's a clear enough split such as "backend" and "frontend" (where frontend is a statically-hosted SPA) then it could be advantageous to keep the codebases and deployments separate.

If data is shared between services, then keeping the code to interact with the data all in one service is likely most useful.

I like to use a few services, with one often ending up being the large "monolith" potentially with a few supporting microservices on the side as it makes sense. "As it makes sense" means that the service has a specific individual encapsulated concern. Billing could be a good example, depending on how it integrates with the rest of the system.

I find microservices very useful to encapsulate independent concerns and for experimentation (don't want to rewrite the whole app using some new tech, but the billing service is small enough to give it a shot). The main problem points are the glue that holds it all together, duplicating code shared between services, and changing apis / data schema.

Ultimately, it's best to know what you and your team is/will be most comfortable with managing based on everyone's skillsets and the product at hand. If you spend time to understand the differences between the patterns in practice, and remain realistic about the advantages and disadvantages of both, you can arrive at an informed decision that works well for your team.

And lastly, make sure you pick something and then build your product. These details don't mean anything to your customers. If you made the wrong choice, you'll know when it's the right time to switch.