Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoliths Are the Future

changelog.com

Post reply on HN
Print view View original

381–390 of 567 posts

Re: Monoliths Are the Future

#381

Post by stock_toaster »

andrewprock wrote: post #360
stock_toaster wrote: post #224

Earlier quoted context omitted.

> 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. Software tends to reflect the structure of the organization that creates it, so this makes sense to me. If you have multiple teams contributing to a stack, eventually it is eas…

I think you are missing the intermediate step of libraries. 1. monolith 2. libraries 3. services If you skip step 2, there is a high probability that the services you end up with are going to be just as disorganized as the monolith which is causing grief.

yup, agreed. I generally would consider your step2 as part of the lifecycle of a well architected monolith, but calling it out as a separate step is certainly clearer, and does reflect more of what I have seen "work well" in the real world too.

Re: Monoliths Are the Future

#382

Post by no_wizard »

echelon wrote: post #140
MadWombat wrote: post #131

Earlier quoted context omitted.

> Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting? One of the key concepts in microservice architecture is data sovereignity. It doesn't matter how/where the data is stored. The only thing that cares about the details of the data storage is the service itself. If you need some data the service operates on for reporting purposes, make an API that gets you this data and…

> But you do not simply go and poke your reporting fingers into individual service databases. This is why I distrust all of the monolith folks. Yes, it's easier to get your data, but in the long run you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. Monoliths are undisciplined and encourage unhealthy and unsustainable engineering. Microservices enforce separat…

In practice, splitting your code into consumable libraries/modules works equally as well.

Then your monolith is just all the modules glued together.

Re: Monoliths Are the Future

#383

Post by 0x445442 »

endorphone wrote: post #235
eternalny1 wrote: post #35

What is old is new again. I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess. Sometimes, if it's not broke, don't try to "fix" it. I can say th…

"What is old is new again." It isn't really, though. This is Some Guy's Opinion™. There are many Some Guy's, and there are countless anti-monolith articles being penned at this moment (probably). People have different experiences with different groups and different tech stacks and different needs. Results may vary. Just to give my own Some Guy opinion, people fail with so-called microservices when it's not really mic…

Your next to last sentence is spot on but it requires well defined interfaces and engineering which is orthogonal to middle management’s desire to commodities development.

Re: Monoliths Are the Future

#384

Post by pbiggar »

We have a similar thesis in Dark. People do microservices because they have to (well, some people have to, some people do them cause they're shiny). But in terms of actually understanding your application, microservices really don't help. And they bring so much complexity with them.

Our concept is to allow the decoupling of microservices, with the tooling of a monolith. Kinda hard to describe and we haven't done it yet, but basically give you the ability to write it as a monolith, but also have the separate scalability/deployment of a microservice.

Re: Monoliths Are the Future

#385

Post by nkozyra »

edw wrote: post #339
lostmsu wrote: post #295

Earlier quoted context omitted.

What does Google Analytics have to do with datalakes? Are you talking about some specific scenario?

Google Analytics is associated with gleaning useful, actionable insights from your users' behavior on your web sites and in your apps, which was what the guy who sold you on the concept of a data lake was promising.

While this is absolutely true in my experience and Google Analytics has handled most of my needs in contrast with a homegrown data lake or ETL, there's always the spectre of Google pulling the rug out from under you with service shutdown or massive price increase.

Use off the shelf stuff but be prepared to have to move in a (relative) hurry.

Re: Monoliths Are the Future

#386

Post by mc3 »

satyrnein wrote: post #275
jlmorton wrote: post #255

Earlier quoted context omitted.

> Spend 12 months building ETLs Okay, sounds reasonable enough for a complex enterprise. > to feed a torrent of raw data to your lake Well, there's the problem. Why is it taking a year to export data in its raw, natural state? The entire point of a data lake is that there is no transformation of the data. There's no need to verify the data is accurate. There's no need to make sure it's performant. It's just data expo…

If you are "export[ing] data in its raw, natural state" then haven't you lost the isolation benefits of microservices? Now you have external systems dependent on your implementation details, and changing your schema will break them.

Yeah I think you'd want the microservice to expose an bulk export API point, to an API specification. It might need to transform data most likely and possibly ignore some data. And then you grab data from those and piss them into the lake. The lake now conforms to your published APIs.

To me this sounds great. And honestly you should do the same thing with a monolith. Nothing worse than "oh you can't make that schema change because a customer with a read-only view will have broken reports".

Re: Monoliths Are the Future

#387

Post by flukus »

no_wizard wrote: post #382
echelon wrote: post #140

Earlier quoted context omitted.

> But you do not simply go and poke your reporting fingers into individual service databases. This is why I distrust all of the monolith folks. Yes, it's easier to get your data, but in the long run you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. Monoliths are undisciplined and encourage unhealthy and unsustainable engineering. Microservices enforce separat…

In practice, splitting your code into consumable libraries/modules works equally as well. Then your monolith is just all the modules glued together.

Splitting code into libraries works better, it's simpler and faster. The only thing micro services bring to the table is being to deploy updates independently (although this is also possible with libraries). If you don't need to deploy independently then micro services are useless complexity, if you can't deploy independently then you've got a distributed monolith.

Re: Monoliths Are the Future

#389

Post by lolc »

te_chris wrote: post #332
jlmorton wrote: post #301

Earlier quoted context omitted.

That's a problem for the future data engineers to deal with. The data lake is an insurance policy so you only need to think about these problems if you later want the data. If you already know you want to analyze the data, then a data lake is not a good choice. Yes, it makes life harder for the data engineers in the future, but it might turn out that analysts only ever need 5% of the data in the lake, and dealing wit…

The data lake is also a real, live GDPR PII time bomb if you worked out how to get the data in but not take it out

But if I haven't spent the effort to extract it, do I really own it? Let me argue that I don't have it because all my implemented queries turn up none of your data. You wouldn't tax me on gold that hasn't yet been extracted, would you? (End of joke.)

Re: Monoliths Are the Future

#390

Post by 0x445442 »

markbnj wrote: post #338

I often agree with Kelsey Hightower, but there are so many things he doesn't mention here. For example, being able to independently deploy components frees up certain kinds of development worklows. Distributed components also scale and fail independently, and you can use nifty things like message queues between them to provide resilience and soak up load spikes. I'm sure the pattern has often been applied in the wron…

Being able to independently deploy components is only useful if you can test the deployed components in isolation. This requires extremely well thought out interfaces and is really what makes the components independent.

It seems in many cases teams have decided to port their highly coupled monoliths over to highly coupled distributed monoliths and now they have the worst of both worlds.

Post reply on HN