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

481–490 of 567 posts

Re: Monoliths Are the Future

#481

Post by laichzeit0 »

Polylactic_acid wrote: post #334
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-…

>It is also true that analysts should not be given access to service databases, because the schema and semantics are likely to change out from under them. Its not perfect but what we do is create a bunch of table views that represent each of the core data types in the system. We can then do all of the complex joins to collect the data analysts want in to an easy to query table as well as trying to keep the views cons…

So you have a single database for all your microservices?

Re: Monoliths Are the Future

#482

Post by idiocratic »

Aperocky wrote: post #480
idiocratic wrote: post #479

Earlier quoted context omitted.

Unique storage for multiple services sounds like a recipe for disaster. The purpose of splitting services, at least one of, is to decouple parts of the code at a fundamental level, including storage and overall ownership thereof. You're probably better served with a modular monolith if you really can't break storage up.

No, only one service is reading/writing, everything else just call that. Still, things get quite lost when it involves talking to multiple other teams and needing to keep everything in sync.

Ok, but then what's the point of splitting it in the first place? The way I see it is to split your domain so that a team owns not only the code, but also the model, the data, the interface and the future vision of a small enough area. If a service owns all the data, then someone who needs to make any change is bottlenecked by it and they would need knowledge beyond their domain. So the key is defining the right domains (or domain boundaries). Unfortunately most people just split before thinking about the details of this process, so the split will sooner or later hit a wall of dependencies.

Re: Monoliths Are the Future

#483

Post by IggleSniggle »

galaxyLogic wrote: post #443
huherto wrote: post #407

Earlier quoted context omitted.

I totally agree. Mostly we are doing microservices the wrong way. We are not drawing the boundaries correctly, they are too small, they have too many interdependencies, they don't really encapsulate the data, and you end up with many interdependencies. There is not enough guidance about sizing them. We are just building distributed monoliths. Which is great for cloud companies because they get to sell many boxes.

Micro-services are just connected things which work together to accomplish something. But where are those connections described? In some tables somewhere. Maybe. Whereas if you write a single monolithic program its connections are described in code, preferably type-checked by a compiler. I think that gives you at least theoretically a better chance of understanding what are the things that connect, and how they conne…

There is such a language, and it is Erlang.

Re: Monoliths Are the Future

#484

Post by pjmlp »

Thaxll wrote: post #330
pjmlp wrote: post #95

Earlier quoted context omitted.

The bad reputation that enterprise Java gets, comes from enterprise C and C++ codebases. https://en.wikipedia.org/wiki/Structured_systems_analysis_an... https://en.wikipedia.org/wiki/Booch_method Any language that gets into enterprise architect hands, with projects spread around multiple development sites with several consulting agencies, gets their FactoryFactories and such.

Spring, Hibernate and other "enterprise" monsters came from Java alone. FactoryFactory123.

Have you ever used CORBA and DCOM factories?

Enterprise ORMs were created in Smalltalk, C++ and Objective-C, years before Java was created.

Poet and Enterprise Object Framework were two well known ones.

In fact J2EE was born of the ashes of a failed Objective-C project at Sun, Neo, after its collaboration with NeXT on OpenSTEP failed apart.

https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...

Things are not created in vacuum, it helps to actually know computing history.

Re: Monoliths Are the Future

#485

Post by takeda »

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…

> I think one reason to avoid this approach is because SQL and other DB languages are pretty terrible (compared to popular languages like C#, Python, etc...) But why has no one written a great DB language yet?

SQL is actually hard to compare to programming languages, because in SQL you say what you want, while in iterative language you say how. I only know one language that was competing with SQL (and lost) it is QUEL (originally it was used by Ingress and Postgres).

BTW for triggers and stored procedures you actually can use traditional language, I know that PostgreSQL supports Python, you just need to load a proper extension to enable it.

Re: Monoliths Are the Future

#486

Post by beardedman »

I wish we could appreciate the middle ground more & stop evangelising extremes. Our work is complex & deserves considered approaches that don't always fall within the current zeitgeist of our industry.

Re: Monoliths Are the Future

#487

Post by patrec »

abraxas wrote: post #435
yes_man wrote: post #374

Earlier quoted context omitted.

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

> 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.

In my experience it's not hard to implement, but of course it depends on the problem domain (and probably also on not splitting things up willy-nilly because of the microservices fad). I think the key to event sourcing and immutability in general is to not overdo it. For example you will likely need to redact certain data (e.g. for legal compliance), so zero information loss is out. Systems like Kafka are a poor choice for long term data storage, the default retention is 1 week for a reason.

But the things that are wonderful about event sourcing (the ability to inspect, replay and fix because you haven't lost information) mostly materialize over a 1 week timeframe.

If you need to recover a lot of state from the event log you will need store aggregated event data at regular intervals to play back from to have acceptable performance. But in practice, in many cases the data granularity you need goes down as the data ages anyway, and you do some lossy aggregation as a natural part of your business process (as opposed to to deal with even sourcing performance problems). I.e. for the short timeframe kafka is the source of truth, but for the stuff you care long term it's some database, and this happens kinda naturally. So often you don't need to implement checkpointing.

Re: Monoliths Are the Future

#488

Post by Legogris »

I feel a lot of the excitement for microservices came from fatigue and frustration with overly complex monoliths. Turns out that the complexity was just brought out of microservices, one abstraction layer up into the architecture.

I think a lot of the principles in classic OOP design (SOLID) can be applied to microservice systems: Classes/Objects Services.

Re: Monoliths Are the Future

#489

Post by tarsinge »

smoyer wrote: post #406
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…

We've moved a lot of services into Kubernetes and broken things up into smaller and smaller micro-services. It definitely eliminates a lot of the complexity for developers ... but you trade it for operational complexity (e.g. routing, security, mis-matched client/server versions, resiliency when dependency isn't responding). I still believe that overall software quality is higher with micro-services (our Swagger docu…

The big trade off is the ability to rewrite a large part of the system if a business pivot is needed. That was the bane of the previous company I worked in, engineering and operations was top notch unfortunately it was done too soon and it killed the company because it could not adjust to a moving market (ie customer and sales feedback was ignored because a lot of new features would require an architecture change that was daunting). It was very optimized for use cases that were becoming irrelevant. In my small startup where product market fit is still moving I always thank myself that everything is under engineered in a monolith when signing a big client that ask for adjustments.

Re: Monoliths Are the Future

#490

Post by i_dursun »

closeparen wrote: post #459
therealdrag0 wrote: post #234

Earlier quoted context omitted.

My favorite project to work on was a modular monolith. It was a single deployable but each component (vertical) had its own maven-module.

How does that solve the deployment-rollback problem?

You can still deploy a new version of the monolith with a downgraded module.
Post reply on HN