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

461–470 of 782 posts

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

#461

Post by acjohnson55 »

StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

Only thing is, for any given real world tension between dual paradigms, it's arbitrary which one you label as old or new. At this point, the oscillation has been going on longer than anyone has been in the field.

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

#462

Post by avarun »

khalilravanna wrote: post #448

This might come off as being snide, but I'm genuinely curious: was their solution really just having all the services in one repository? That doesn't seem like a problem with microservices at all but more of a devops problem. To be clear, I'm not arguing for microservices, I'm just trying to understand if this was really a problem with splitting off multiple repos. Maybe I'm just really dense and someone can set me s…

It seems like splitting off small repos for everything is a solution looking for a problem. Some of the most successful software companies out there have monolithic repos, but not monolithic services.

The real solution is microservices in monorepos.

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

#463

Post by ahallock »

I don't think you reverted to a monolith. I think you built a singular service with more cohesion than when it was split into 140 repos. And it sounds like the split wasn't because of the microservices architecture but because you didn't have a good solution for the queue problem.

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

#464

Post by drb91 »

StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

I mean, this is the nature of hype, including scientific paradigms, fast fashion, music tastes. But this narrative obscures underlying causes and basically assumes the underlying cause is human love of hype. However, this isn’t a 2d circle as you imply, but a 3d spiral: you do learn over time. You can see which patterns apply to which problems. There’s a tendancy in these narratives to bemoan the individual that represents culture, but the real pain is that you’re watching people learn things you already learned, and there’s this irrational reaction where you think “i learned this already; so should have they.”

But none of this implies that we are losing knowledge, just that the curve of engineers is fatter at the inexperienced level.

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

#465

Post by acjohnson55 »

craigc wrote: post #244
StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

Yup. Everyone wants to use the latest and greatest, but there is a reason that certain things like SQL have stood the test of time. I think the same could be said of the design world. There was a time not too long ago when designs actually felt polished and had real shapes, shadows, gradients. When you clicked on a button you actually knew you were clicking on a button. Then iOS 7 came along and everything became whi…

You don't really need jQuery anymore, due to the browser APIs being far more mutually compatible and useful than a decade ago. So really it would be more like React vs vanilla JS. There's definitely a place for vanilla, when you just need minor dynamism on an otherwise basic UI.

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

#466

Post by bsder »

thermodynthrway wrote: post #391
chrisco255 wrote: post #283

Earlier quoted context omitted.

There's actually no reason you can't architect microservices like this. You can put RabbitMQ or some AMQP service as a comm layer between services. But then you have to architect your system to be event-driven. It's not a bad approach.

I've worked on a system that used Kafka in-between. It makes consistency issues a ton worse because everything is async. At least with HTTP you can do synchronous calls

Repeat after me: there is no such thing as a synchronous network.

I get where you are coming from. But you will go async sooner or later if you need any reasonable error recovery or reliability.

The only question is how much pain you will suffer before you do so.

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

#467

Post by FuckOffNeemo »

pnloyd wrote: post #458
keithnz wrote: post #336

Earlier quoted context omitted.

sounds like an awesome idea! Anyone who wants to do a startup around this I have an awesome idea about how to implement this using blockchain and a serverless tech stack :D

Serverless is my most hated buzz word, even if I like what it actually means. I mean come on, there are always servers.

An article or maybe comment on HN the other day where serverless is hyperbolic hit the nail on the head.

The OP at the time suggest serverless should instead be re-branded Function as a Service which is a considerable improvement.

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

#468

Post by wsy »

scarface74 wrote: post #434
wsy wrote: post #402

Earlier quoted context omitted.

You will end up with something like OSGi. That can be the right choice, but is also a quite 'heavyweight' architecture. For a certain class of applications and organizational constraints, I also would prefer it. But it requires a much tighter alignment of implementation than microservices (e.g., you can't just release a new version of a component, you always have to release the whole application).

See the below response for more details. But that’s not how modern testing works (neither is my feature flag suggestion). https://www.developerhandbook.com/unit-testing/writing-unit-... It works similarly in almost every language. For a certain class of applications and organizational constraints, I also would prefer it. But it requires a much tighter alignment of implementation than microservices (e.g., you can't ju…

> 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 card transactions need to work 24x7, but generating the monthly account statement for these credit cards is not time-critical. Now suppose one of the changes in a less critical component requires a database migration which will take a minute. 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.

I agree with your remark about refactoring. In addition, when doing a refactoring in a microservice, you always need a migration strategy, because you can't switch all your microservices to the refactored version at once.

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

#469

Post by AdrianB1 »

briandear wrote: post #97
scarface74 wrote: post #80

Earlier quoted context omitted.

The reality is that since the days of the social contract between employer and employee are long gone - i.e. I show a company loyalty and they will keep me at least at market rates and not lay me off to “increase shareholder value. Developers have to use the new and shiny to keep themselves marketable and be ready to jump ship at the first opportunity or out of necessity.

How frequently are developers being laid off? And why should companies just keep people around if they aren’t adding value? The lack of that “social contract” has resulted in much higher wages. Look at developer salaries in Paris compared to New York. Since there is more job security in France, the trade off is that “market rates” are dramatically lower.

There is different social contract there: in Paris the "fraternite, egalite" means you cannot pay developers more than the other people around and high taxes are a second way to ensure this will not happen. This makes Paris a prime choice not to do development and in the end gives dramatically lower "market" rates. Don't forget that "the best of the best" more to places like Silicon Valley where they earn top dollar, the ones that chose to stay in Paris are what is left behind and a few exceptions. At least this is what it looks from an European point of view.

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

#470

Post by acjohnson55 »

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…

> But you probably can't imagine a world without relational databases. I know I can't.

Having worked on a couple projects that used Mongo at the core, I wish I could say the same.

Post reply on HN