Goodbye Microservices: From 100s of problem children to 1 superstar • Hacker News Board

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

#581

Post by stickfigure » Wed, Jul 11, 2018, 5:01 AM UTC

Floegipoky wrote: post #558

It seems like splitting into separate repos was a rash response to low-value automated tests. If tests don't actually increase confidence in the correctness of the code they're negative value. Maybe they should have deleted or rewritten a bunch of tests instead. Which is what they did in the end anyway. >> A huge point of frustration was that a single broken test caused tests to fail across all destinations. When we…

it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices.

That seems... appropriate?

This is the general problem with the microservices bandwagon: Most of the people touting it have no idea when or why it's appropriate. I once had a newly hired director of engineering, two weeks into a very complicated codebase (which he spent nearly zero time looking at), ask me "Hey there's products here! How about a products microservice?" He was an idiot that didn't last another two months, but not before I (and the rest of the senior eng staff) quit.

I'm fully prepared to upvote more stories with the outline of Microservices were sold as the answer! But they weren't.

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

#582

Post by flukus » Wed, Jul 11, 2018, 5:05 AM UTC

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…

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

I think you'd be surprised/alarmed at how little transactions actually get used in the software world. Not just on small systems where it doesn't matter but I've seen a complete absence of them in big financial ones handling billions of dollars worth transactions (the real world kind) a day. Some senior, highly paid people even defend this practice for performance reasons because they don't realize the performance cost of implicit transactions. And this is just the in process stuff where transactions are totally feasible, it get's even worse when you look at how much is moved around via csv files to FTP and excel sheets attached to emails. I've spent the last 2 weeks being paid to fix data consistency issues that should never have been issues in the first place.

Maybe when we're teaching database theory we shouldn't start at select/join but at begin transaction/commit/rollback?

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

#583

Post by pjmlp » Wed, Jul 11, 2018, 5:21 AM UTC

User23 wrote: post #551

scruffyherder wrote: post #531

Earlier quoted context omitted.

Yes the kids have just rediscovered the move from COM to DCOM. It's so silly that we are wasting so much time rebuilding existing things, poorly.

COM wasn't a picnic to work with back when it was the new thing. The toolchain sucked. I'll never write another line of MIDL in my life.

MDIL has been rejuvenated for C++/WinRT, the new C++17 based projection for UWP.

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

#584

Post by DCoder » Wed, Jul 11, 2018, 5:29 AM UTC

foobarian wrote: post #322

organsnyder wrote: post #221

Earlier quoted context omitted.

I agree, though I'm not so cynical about it. Well-defined API contracts are themselves a communication mechanism. If I provide an API, I am declaring that if you interact with me in a given way, I will behave in a certain way. Given that one of the hardest parts of scaling an organization is the boundaries between individuals and teams, providing a structured mechanism to define system behavior is incredibly valuable…

I hated that in our monolith Java web app, any random team could come along and pepper our team's module with global variable lookups and short term hacks that never get cleaned up. Even though we see the changes often times they are urgent changes needed right now, accompanied with promises to clean up later (which usually doesn't happen). The nice thing about a SOA architecture is that it makes it harder to do this…

Isn't that a technical solution to an organizational problem?

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

#585

Post by munchbunny » Wed, Jul 11, 2018, 5:37 AM UTC

kazen44 wrote: post #324

munchbunny wrote: post #216

Earlier quoted context omitted.

In my experience, there's a lot of cargo culting around microservices. The benefits are conferred by having a strong team that pays attention to architecture and good engineering practices. Regardless of whether you are a monolith or a large zoo of services, it works when the team is rigorous about separation of concerns and carefully testing both the happy path and the failure modes. Where I've seen monoliths fail,…

Also, having a solid architectural guideline that is followed across the company in several places (both in infrastructure and application landscapes) makes up the major bulk of insuring stability and usability. The disadvantage is obviously that creating such's a 'perfect architecture' is hard to do because of different concerns by different parties within the company/organisation.

> The disadvantage is obviously that creating such's a 'perfect architecture' is hard to do because of different concerns by different parties within the company/organisation.

I think you get at two very good points. One is that realistically you will never have enough time to actually get it really right. The other is that once you take real-world tradeoffs into account, you'll have to make compromises that make things messier.

But I'd respond that most organizations I see leave a lot of room for improvement on the table before time/tradeoff limitations really become the limiting factor. I've seen architects unable to resolve arguments, engineers getting distracted by sexy technologies/methodologies (microservices), bad requirements gathering, business team originated feature thrashing, technical decisions with obvious anticipated problems...

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

#586

Post by acroback » Wed, Jul 11, 2018, 5:40 AM UTC

johndubchak wrote: post #537

acroback wrote: post #179

Earlier quoted context omitted.

Totally technical considerations which engineers must present and justify. e.g When we added Go, we had to present what it brings? A good testing framework, light weight(subjective), goroutines(which fit our use case), in built benchmark support, mature support of third party packages etc etc.

Out of curiosity, was it replacing an existing language or developing new functionality?

New functionality, breaking existing perfectly fine and working functionality is a big no.

One of our core services is written in C, it never crashes, it sustains QPS no other service can in the entire ecosystem, why change it to something new unless there is a solid reasoning to it?

I kid you not, one of the companies we integrated with gave us 2 64 Core VMs in their private cloud to run our service. We run 3 instances of our process on each VM along with Redis taking about 60GB of memory in total, with 59.996 MB of memory taken by Redis. And it was written in Go. Apparently, we miscommunicated that we will be using a GC language for this service. They assumed Java and based on their experience allocated 2 64 core VMs with 256GB memory each :D.

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

#587

Post by shub » Wed, Jul 11, 2018, 5:51 AM UTC

stefano wrote: post #192

hosh wrote: post #153

Earlier quoted context omitted.

Sometimes, I've seen a lack of regard for data consistency within a monolith. That is not completely on the developer, either. Pre 4.0 Mongodb, for example, does not do transactions. On the other hand, I've seen some pretty flagrant disregard for it just because there are not atomicity guarantees. Microservices makes reasoning on that harder.

> That is not completely on the developer, either. Pre 4.0 Mongodb, for example, does not do transactions I'd argue that's on the developer, if he was the one to choose a database that doesn't support transactions, and then didn't implement application-level transactions (which is very hard to do correctly).

Txns are just hard in general but mature RDBMS have spent a huge number of man-years on getting it right. After the time I've spent on Couchbase, Mongo, Elasticsearch, I doubt I'll ever use something non-transactional for anything OLTP or OLTP-adjacent. If Postgres or MySQL can't scale up to handle it, make them...or get a new job. Scale is a PITA.

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

#588

Post by User23 » Wed, Jul 11, 2018, 5:51 AM UTC

crimsonalucard wrote: post #568

User23 wrote: post #554

Earlier quoted context omitted.

Actually computing science is the most well understood science. Physicists can only give results with a few millionths* of accuracy, a computing scientist can prove a theorem about his subject matter with perfect accuracy. Everyone else, including doctors, who call themselves scientists are just trying to float on the cachet physicists earned with their astonishingly good predictions. Properly speaking, they are phen…

You are diving to deep and talking about the difference between formal logic and empirical sciences. I am not talking about that. Things like algorithmic complexity are well understood and formalized but design patterns are not a science nor has the concepts ever been formalized.. There is no theory or formalized system that says monolithic is better than micro or vice versa, it's all opinion. That's why its' called…

Formal logic is a tool used by computing scientists and that they made almost incredible contributions to. It’s a tool that’s available to other scientists too, and the more rigorously minded ones use it.

For your latter point, it’s a matter of elegance, which is a pretty way of saying cognitively manageable. Think of epicycles vs Newtonian mechanics as an analogy. With enough epicycles you can compute the same result, but Newton’s approach is still a clear scientific advance.

Your point about design is well taken. Any given design is analogous to a theory. So we should aim for the simplest and most cognitively manageable design that satisfies our needs. That’s not literally formalized, but it’s a well established principle with an excellent record.

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

#589

Post by blub » Wed, Jul 11, 2018, 5:55 AM UTC

parasubvert wrote: post #556

mikekchar wrote: post #486

Earlier quoted context omitted.

> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…

You’re oversimplifying. Architecturally speaking, there are some similarities between micro services and libraries because they’re both forms of modularization and usually have an API, but there are some stark differences beyond the “dispatch mechanism”. The main difference is that a service’s deployment lifecycle is completely up to the service admin. Microservices are like websites - they can continuously evolve (w…

You are assuming that microservices must be deployed on the internet, however they can be deployed on another type of network or on a single OS installation, which would prevent them from being completely transparently updated.

Shared libraries can be an implementation of micro services. On a platform (e.g. Android) it can be that a shared library is updated and then all consumers are forced to update.

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

#590

Post by shub » Wed, Jul 11, 2018, 5:59 AM UTC

crimsonalucard wrote: post #502

ljw1001 wrote: post #337

Earlier quoted context omitted.

You've demonstrated above that using RDBMS and SQL involves making tradeoffs, like everything else. But you probably can't imagine a world without relational databases. I know I can't. Many of the problems you mention above occur because the database handles stuff for programmers. Sure. you could create a custom solution around your biggest bottlenecks, but do you want to create a custom solution for every query, or…

I'm saying there could be another high level language that took the place of SQL. An imperative language with explicit algorithmic declarations. I'm not talking about custom solutions, I'm talking about how the web has evolved away from ideas that could have been better, because SQL to me is clearly not what I imagine to be the best we could possibly do for database queries. Same story with javascript and CSS. which…

If deciding join order and what indexes to use sounds like your idea of a good time. It certainly isn't mine.