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

501–510 of 782 posts

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

#501

Post by alttab »

stickfigure wrote: post #478
jiveturkey wrote: post #376

Earlier quoted context omitted.

> This means, everytime you touch something under a repo, it affects everyone. This is horrible at scale. > This is a classic case of not understanding micro services and trying to fit a problem around a tool. That much I agree with. TFA even acknowledges that, in the conclusion. Not in so many words, but they basically admit they did it wrong.

>> This means, everytime you touch something under a repo, it affects everyone. >This is horrible at scale. I just want to reiterate this. In the early 2000s I worked in the online platform group at EA. The list of things done poorly there was long, but picture: * 40+ engineers * Monorepo with hundreds of thousands of classes; all code deployed to all servers. * Hundreds of different services running across thousands…

The Java serialization downtime was sad, but I died when you said clear case.

When they rolled out clear case in my team at IBM, I quit a few weeks later.

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

#502

Post by crimsonalucard »

ljw1001 wrote: post #337
crimsonalucard wrote: post #276

Earlier quoted context omitted.

The test of time isn't always a good metric. html, css and javascript is a huge hack, yet it has withstood the test of time. SQL to me is a huge design flaw despite it's ubiquity. On the web bottlenecks happen at IO and algorithmic searches. Databases are essentially the bottlenecks of the web and how do we handle such bottlenecks? SQL; A high level almost functional language that is further away from the metal than…

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 to you would be more clear?

SELECT * FROM TABLE WHERE id = 56

binary_search(column_name=id, value=56, show_all_columns=True)

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

#503

Post by dralley »

gaius wrote: post #354
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…

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. Similarly it’s made with make. If anyone has a project more complex than the Linux kernel or GCC I’ll gladly listen to why they need some exotic build system... never met anyone yet...

Firefox probably qualifies. Split between C/C++/Rust/JavaScript/XUL/Python/god knows what else

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

#505

Post by tylerhou »

JamesBarney wrote: post #498
spraak wrote: post #488

Earlier quoted context omitted.

Such a tired view/joke. Python is just as bad but doesn't receive nearly as much hate

JavaScript is a great language because you can run it on pretty much any machine. Buts it's especially terrible because it was designed by a guy without much language expertise in a handful of weeks.

> Buts it's especially terrible because it was designed by a guy without much language expertise in a handful of weeks.

The core isn't too bad; I'd argue that the main reason why it's hard to work with is because you don't have tight control over your execution environment, mostly since the language wasn't really standardized until pretty late. It also solves a much different problem than most languages since it has to optimize for better UX (not crashing the whole program on exceptions, for example).

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

#506

Post by robotresearcher »

mikekchar wrote: post #486
johndubchak wrote: post #235

Earlier quoted context omitted.

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…

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

> From an architectural perspective, there is absolutely no difference between a micro service and a library.

I’ll stick to linking glibc, friend architect. Performance is also architecture.

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

#507

Post by weberc2 »

mikekchar wrote: post #486
johndubchak wrote: post #235

Earlier quoted context omitted.

I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…

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

Microservices do have various organizational tradeoffs. Individual teams can now own deployment, operation, language, and tooling choices for better or worse. This is probably advantageous for large companies where the number of teams scales beyond what a hierarchical control structure can support. In other words, a single devops team can't make good decisions and prescriptions about languages, tooling, deployment, etc nor effectively react to feedback from the dev teams. Control (power and responsibility) becomes distributed instead of centralized, with all the tradeoffs that entails.

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

#508

Post by otterlicious »

ljw1001 wrote: post #392
acroback wrote: post #329

Earlier quoted context omitted.

This means either your contract agreement between services is not language agonistic or someone did not do their job when Interface schema was changed during reviews. Just like any other software, interfaces live in separate repos e.g protoplasm/ for proto-buf definitions. avrobber/ for avro and so on so forth. So, any change to protoplasm/ triggers automated tests on all other services irrespective of boundaries.

ok. But _much_ easier to have compile time checking between projects in the same language/repo. Not saying this approach is wrong, but it's a little like riding a unicycle when a perfectly good bicycle is sitting right there.

It's much easier to drive a car than an 18 wheel truck too, but the latter have their uses.

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

#509

Post by flukus »

stcredzero wrote: post #208
ljm wrote: post #157

Earlier quoted context omitted.

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams can silo themselves off and avoid communication (e.g. "I can work just on my backend image processing bit without dealing with the React guys now", "now the CTO won't be on my back so much," or whatever). The irony being that anything approaching SOA (or micro…

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech A lot of software is used to control or impose someone's will on others organizationally.

This is why things like ticketing systems and other workflow tools almost universally suck. Manager needs x field to run some report so x field becomes mandatory and the software is a pain to use because know one apart from that one manager knows what the field even means.

Currently our JIRA kanban board is crippled because someone just had to take a simple system and impose a workflow that can't be deviated from.

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

#510

Post by codedokode »

tabtab wrote: post #396
tetha wrote: post #323

Earlier quoted context omitted.

Make fun of PHP as much as I like or liked to. But I have some easily readable, rock-solid, easily operated php applications in my infrastructure.

I believe good architectures/stacks depend far more on the skill of the architects than the languages involved. Domain fit also matters. As far as PHP, it's an ugly language from a language-only perspective, but easy to deploy and has lots of existing web-oriented libraries/functions. Think of PHP has a glue language for its libraries and some front-end JavaScript to improve the UI. Python and server-side JavaScript…

PHP might be not the best designed or nice looking language out there, but you cannot even compare it to JS. It has real classes, doesn't require you to put underscore before private methods and type checking. And it issues a warning if you divide by zero or try to access array index that doesn't exist
Post reply on HN