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

431–440 of 567 posts

Re: Monoliths Are the Future

#431

Post by tootie »

timwaagh wrote: post #333
tootie wrote: post #241

Earlier quoted context omitted.

When developers complain about being verbose and not a great language for coders, I counter that it doesn't exist to solve programming problems, but rather organizational problems. The killer feature that launched Java wasn't crap like checked exceptions, it was javadoc. Strict, self-documenting APIs are 10X more valuable than any intrinsic language feature.

i dont care about it not being great. its good enough as a language. but maven... but websphere... java is a hellish platform that ordinarily would not win from interpreted languages or those which focus on fast compilation. But it runs literally everywhere, including your toaster, but more importantly on mainframes which also run the real mvp aka Cobol. run once, run anywhere remains a killer feature no other platfo…

Maven is great. Better than any competitor I've seen. WebSphere is long dead and was crappy even when it was new.

Re: Monoliths Are the Future

#432

Post by zip1234 »

default-kramer wrote: post #372
projektfu wrote: post #130

Earlier quoted context omitted.

It's a little sad because originally, people thought there would be a shared data base (now one word) for the whole organization. Data administrators would write rules for the data as a whole and keep applications in line so that they operated on that data base appropriately. A lot of DBMS features are meant to support this concept of shared use by diverse applications. What ended up happening is each application use…

Do you know why the shared database vision didn't work out? Because I still think it would be the best approach for many companies. Most companies are small enough that they could spend less than $10k/month for an extremely powerful cloud DB. Then you could replace most microservices with views or stored procs. What could be simpler? I think one reason to avoid this approach is because SQL and other DB languages are…

SQL is actually amazing at some things that are very difficult, verbose, or slow to do in C# or Python.

Re: Monoliths Are the Future

#433

Post by tomc1985 »

mewpmewp2 wrote: post #184
echelon wrote: post #165

Earlier quoted context omitted.

Humans are the most expensive part of the system. You have to make it easy for humans to understand and change the system, and at the end of the day that's the number one thing to optimize for. This is why microservices are compelling. But to speak directly to your concern, you have to think about service boundaries and granularity correctly. Nobody is saying make a microservice out of every conceivable table. Think…

In my experience it is a lot more difficult to navigate around all the different microservices to understand what needs to be done compared to being in a monolith where you can jump from file to file. Also then what also happens is microservices are created using different languages which in turn adds so much complexity to understand what is going on on the whole big picture level. And code gets repeated a lot more.…

I work on a monolith with a team experimenting in microservices and good lord do I hate it. The microservice represents a required step in our user flow, and due to the way we're set up I have to spin up my own private copy. Very often there have been configuration or API changes that were not communicated to me and so for the past few months that service have been broken and I've managed to avoid it for the most part. When I can't, I find it is faster to simply re-assign existing database records or simply bullshit them in a database editor rather than deal with the "why isn't the XXXXXXXXXXXX service working for me again?" flavor of the day

And holy fuck is debugging that stuff difficult. HUUUUUGE waste of time, but management looooooooooves their blasted microservices...

Re: Monoliths Are the Future

#435

Post by abraxas »

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…

The trouble is that this process of streaming events over Kafka or Kinesis means that subscribed microservices will be duplicating the bus data in their own way in their local databases. If one of them falls out of the loop for whatever reason you are in trouble.

Now, there is a pattern called Event Sourcing (ES) which proposes that the source of truth should be the event bus itself and microservice databases are mere projections of this data. This is all good and well except it's very hard to implement in practice. If a microservice needs to replay all business events from months or years in the past it may take hours or days to do this. What about the business in the meantime? If it's a service that significantly reduces the usability of you application you effectively have a long downtime anyway.

Transactional activity becomes incredibly hard in the microservices world with either 2 phased commit (only good for very infrequent transactions due to performance) or with so called Sagas (which are very complex to get right and maintain).

Any company that isn't delivering its service to billions of users daily will likely suffer far more from microservices than they will benefit.

Re: Monoliths Are the Future

#436

Post by Shicholas »

Microservices can work, and fwiw, here are 3 things I've learned to the hard way:

1. Use a package manager, and export interfaces to a given service in each of the consumers. It's great that GitHub now offers it for node. 2. Create a DAL library for I/O to a given database (e.g. PostgreSQL, or Mongo) that be consumed by other services. 3. Enforce styling company-wide with one source of truth. We use GitHub Actions, so we can enforce styling with a shared GitHub Action.

Re: Monoliths Are the Future

#437

Post by abraxas »

simonh wrote: post #322
abhishekjha wrote: post #304

Earlier quoted context omitted.

>It goes into GC hell Can you exapand on this a little? Or a paper that I can read?

The service will need to read all its data and put it into objects, then extract the data from the objects to report it, then garbage collect all of that. For every single record in its entire data set. You could say but oh, why not just return the underlying data without making objects? Well now you are exposing the underlying data format, which is what we’re trying to avoid by giving this job to the service.

And thus such patterns lead to the absurdity where 90% of enterprise apps do little actual computations beside serializing and deserializing JSON (or XML if a "legacy" app).

Re: Monoliths Are the Future

#439

Post by asimpletune »

no_wizard wrote: post #378
jonahbenton wrote: post #271

Earlier quoted context omitted.

Sorry, but "making an API that gets you this data" is the wrong answer. Most APIs are glorified wrappers around individual record-level operations like- get me this user- or constrained searches that return a portion of the data, maybe paginated. Reporting needs to see all the data. This is a completely different query and service delivery pattern. What happens to your API service written in a memory managed/garbage-…

Real question: Why pull it into memory like that? Why not just pump it through a stream?

A stream would be the correct way to handle that problem, so backpressure can be used to prevent too much memory churn.
Post reply on HN