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

Goodbye Microservices: From 100s of problem children to 1 superstar

segment.com

Post reply on HN
Print view View original

671–680 of 782 posts

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#671

Post by davewritescode »

stickfigure wrote: post #576
davewritescode wrote: post #527

Earlier quoted context omitted.

Data consistency is one of those things that sounds like it matters but often doesn't. There's not much in Netflix's platform that screams data consistency is an ultra high priority. Any application that deploys active/active multi-region is by definition going to encounter scenarios where data loss is possible. There's just no way around CAP. I'd venture a guess that most applications have all sorts of race conditio…

A little birdie who worked at Grab once told me that they pretty much don't use transactions anywhere. So... maybe there are problem domains where you can get away without transactions, but I'm quite sure that a marketplace that arranges transportation for fee is not one of them. The next time you're standing in a monsoon waiting for the "coming" car that never comes, remember this post :-) Aside from that, I've foun…

Having spent a good amount of time fixing bugs related to code that fetches data with a consistency level of READ_UNCOMMITTED for "performance" reasons I can appreciate what transactions give you as an application developer.

However, I would argue that transactions are overkill. What's the worst case scenario if I book a ride for Grab and my request gets corrupted? I'm guessing I'll see an error message and I'll have to re-request my ride.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#672

Post by radisb »

davidkellis wrote: post #5
thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

> You push data consistency concerns out of the database and between service boundaries. Sing that from the rooftops. That is exactly my observation as well. All the vanilla "track some resource"-style webapps I've worked on were never designed to cope with a consistency boundary that spans across service boundaries. Turning a monolith into distributed services is hard for that reason - you have to redesign your data…

I remember using BEA Tuxedo 15 years ago and I can't help wondering if theoretically one could do microservices using it or some OLTP to achieve consistency when needed. Has it progressed over the years? Is there any free alternative to it? Or is it dead tech? When I used it it was hard and too much extra work, but it did the job successfully.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#673

Post by ex_amazon_sde »

stickfigure wrote: post #457
madamelic wrote: post #163

Earlier quoted context omitted.

>It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. If two microservices have to share databases, they shouldn't be microservices. One microservice should have write access to one database and preferably, all read requests run through that microservice for exactly the reason yo…

My problem with microservices is the word 'micro'. It should just be services . Problem domains (along with organizational structures) inherently create natural architectural boundaries... certain bits of data, computation, transactional logic, and programming skill just naturally "clump" together. Micro services ignore this natural order. The main driving architectural principle seems to be "I'm having trouble with…

> Problem domains (along with organizational structures) inherently create natural architectural boundaries

The "natural" order is very often bad for reliability, speed and efficiency. It forces the "critical path" of a requests to jump through a number of different services.

In well built SOA you often find that the problem space is segmented by criticality and failure domains, not by logical function.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#674

Post by HeavyStorm »

I am a strong believer that microservices is over hyped. I usually resist when senior management asks for us to use it (that proves the point of hype).

But by reading the first paragraphs of the article you see that the guys from Segment made a series of grave mistakes on their "microservices architecture", the most important one being the use of a shared library on many services. The goal of microservices is to achieve isolation, and sharing components with specific business rules between them not only defeats the purpose, but results in increased headaches.

Without deep knowledge of the solution, it's hard to judge, but it seems this was never the case for microservices. They needed infrastructure isolation when the first delay issues surfaced, but there wasn't anything driving splitting the code up.

Sam Newman discusses on his book how to find the proper seams to split services (DDD aggregates being the most common answer) and it seems to people are making rather arbitrary decisions.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#676

Post by [deleted] »

crimsonalucard wrote: post #500
allwein wrote: post #350

Earlier quoted context omitted.

I strongly disagree with your assessment of SQL. All of the questions that you asked have actual answers, but I read (from what I perceive as your tone) that you think these are all mysteries generated by an unknowable black box. While some of them may be implementation dependent (like "What algorithm does a select search execute?"), others have common and knowable answers. > Why does using select * slow down a query…

Those are rhetorical questions. I ask them because these are questions you need to know in order to work well with SQL. I cannot become a master of SQL by only learning SQL. I have to learn the specific implementations, I have to run EXPLAIN... etc... A good abstraction only requires you to know the abstraction not what lies underneath. What we have with SQL is a leaky abstraction. My argument that a high level leaky…

[deleted]

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#677

Post by wsy »

scarface74 wrote: post #499
wsy wrote: post #468

Earlier quoted context omitted.

> It’s easier to just press a button and have your application go to all of your servers based on a deployment group. It's not so much about the deployment process itself (I agree with you that this can be easily automated), but rather about the deployment granularity. In a large system, your features (provided by either components or by independent microservices) usually have very different SLAs. For example, credit…

With separate microservices and databases, you could just pause that microservice. With one application and one database, all teams need to be aware of the highest SLA requirements when doing their respective deployments, and design for it. It is certainly doable, but requires a higher level of alignment between the development teams. That’s easily accomplished with a Blue-Green deployment. As far as the database, yo…

Could you elaborate a bit more?

If your database is a cluster, then it is still conceptually one database with one schema. You can't migrate one node of your cluster to a new schema version and then move your traffic to it.

If you have real replicas, then still all writes need to go to the same instance (cf. my example of credit card transactions). So I also don't understand how your migration strategy would look like.

blue-green is great for stateless stuff, but I fail to see how to apply it to a datastore.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#678

Post by wsy »

collyw wrote: post #609
wsy wrote: post #419

Earlier quoted context omitted.

Yes, they do fine as examples. I have worked both on decades old booking systems and banking software. Both were dependency hells. Refactoring was impossible. Everybody was super-careful even with tiny changes because the risk to break something was just too high. If it could be avoided, these systems were not touched anymore. Instead, other applications where attached to the front and sides.

Isn't that a feature of old systems in general?

I don't think so. For example, the Linux kernel is old, but still quite well maintainable.

So I would say: it applies to systems where proper modularization was neglected. In the anecdotical cases I referred to, one major element of this deficiency was a complex database, shared across the whole system.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#679

Post by sobani »

akerro wrote: post #650

Microservices are damn hard to implement correctly. Think how much math and algorithms must there be to correctly, test, version your model and API, load balance, gather logs, collect logs, archive logs, grep in logs, setup VMs/Dockers, DNS+DHCP and firewalls, load balance databases (master/slaves?) and your services, horizontal scaling maybe?, manage privileges and access, manage disk space, store and collect user-u…

All of these things you mentioned are either also required for a monolith (like DNS+DHCP) or are required for neither (isolated environments).

Does that mean that because of all the work required to properly set those up for a monolith, we better stay with microservices?

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#680

Post by Hendrikto »

Sounds like a typical case of hype driven development. When faced with a problem they threw buzzwords at it, hoping it would go away.

Had they taken the time to explore the root causes of these problems and how to best approach them, they probably wouldn‘t have taken the microservices approach to begin with.

I see this far too often. Instead of looking for solutions to problems, people look for problems to try the new hot solution they read about. Happened with ML/AI, NoSQL, Microservices, Blockchain, …

Post reply on HN