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

181–190 of 782 posts

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

#181

Post by stanmancan »

fipple wrote: post #147
iamleppert wrote: post #75

Microservices are an organizational and design choice that is intended to mirror the structure of the teams or engineers, the actual human beings doing this stuff. It seems like Segment didn’t really understand this at all, and instead decided to have seemingly arbitrary and rediculous service boundaries that had no relationship to the real world. See also people who create poor abstractions in their code and other s…

Yes, this awful engineering team built an incredibly successful company/product. I wish I was as awful as them.

Not here to comment on Segments engineering prowness, I have no clue one way or another. However; I think an overwhelming number of engineers and developers are mislead in believing that you have to have the perfectly crafted program/service/app/whatever in order for it to be successful.

It doesn't! Your tech stack has next to no impact on the success of your product.

Making something useful is really all that matters. Is the service running? Great, that's all the end user cares about. The back end could be a bunch of code copy-pasted off old form posts from 1998 and string together with scotch tape as long as it works.

The end user doesn't care about what language you use. They don't care if you use redis, mysql, postgres, or mssql 2000. They don't care if the HTML or CSS is messy. They won't judge you if you don't use SASS or LESS or whatever is popular today.

The most successful side project of mine runs on a $20/m VPS and has been re-written 3 times and the code has been pretty terrible every time because every re-write was done in a new language I learnt over a weekend and never touched again. The first was some horrible PHP, then some less horrible PHP, then GO, and recently someone re-write it (properly) in elixir. The end user doesn't know, the end user doesn't care. The site gets about 250K uniques a month and the API handles about 350 million requests a month. The crappy GO I wrote in a weekend worked just the same for the end user as the fancy elixir.

Anyways, sorry for the rant. I've just seen so much wasted effort go on projects that never launch because people are too concerned about stuff that really doesn't matter in the long run.

If your stuff runs like crap because it found a market fit and you have people signing up and your crappy code can't handle it, then that is a FANTASTIC problem you now get to solve.

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

#182

Post by hobls »

matwood wrote: post #103
hobls wrote: post #73

Earlier quoted context omitted.

Agreed. "Micro" is a terribly defined term, and it sounds like this team went absolutely nuts in one direction. (And then in response to their problems, went as far back as possible to a single monolith.) This suggests a bit of a lack of nuance in their decision making process to me. I'm not interested in figuring out exactly what the right marketing term for it is, but I've had good experiences with teams of 6-10 en…

> If I had three engineers on my team I'd be unlikely to end up with more than a small handful of services. We have a small team and have a handful of services. We also have a fully automated CI/CD pipeline. It's worked really well. I doubt any would be considered 'micro', but instead they are designed around functional areas like authentication or backend processing.

> I doubt any would be considered 'micro', but instead they are designed around functional areas like authentication or backend processing.

Yeah, who knows what micro means, but that's exactly how I like to split up services. If at some point a service gets too large, split it up. Hundreds of services out the gate is a gross premature optimization. (And like most premature optimizations, ends up costing much more time both in development and in maintenance.)

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

#183

Post by johnchristopher »

JustSomeNobody wrote: post #172
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…

Great summary! I wonder if you could fit Resume Driven Design in there somewhere. This should be the top post on articles like this. Just to keep it fresh always in everyone's mind.

It's rear-view mirroring though. Some CS tech from after the 60's proved to be useful.

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

#184

Post by entropie »

johnchristopher wrote: post #178
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…

So, should we stick to PHP for web stuff or is JS here to stay ?

I remember a time where javascript was somehow called "old" and obsolete and pretty anyone hated it.

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

#185

Post by dsnuh »

StavrosK wrote: post #174
JustSomeNobody wrote: post #172

Earlier quoted context omitted.

Great summary! I wonder if you could fit Resume Driven Design in there somewhere. This should be the top post on articles like this. Just to keep it fresh always in everyone's mind.

In my experience, this is driven more about engineers wanting to play with the "new shiny thing" than people wanting to pad their resume, but I'm sure that happens a lot too.

In my experience, it's a bit of both, and they are mutually reinforcing. If you want to always play with shiny new things, you might be more likely to jump around to different places, which a padded resume helps with.

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

#187

Post by copperx »

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 can't find the right place for Ruby on Rails here. It doesn't fit.

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

#188

Post by artpepper2 »

SE4L wrote: post #41

Seems to me the problem is the shared libraries. Yes, without sharing it means you have to repeat a fair amount of code, but in most cases the representation that each service cares about is not necessarily the same, which reduces the value of these shared libraries. It seems that they would have solved a lot of the really critical issues by simply not sharing as much code.

Or use versioning and a package manager. You should be able to introduce vNext and then have each service update at its own pace, with a deprecation strategy so that service owners are responsible to get off the old version by such-and-such time. But as others mentioned, part of the problem seems to be too many services given the size of the team.

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

#189

Post by ng12 »

ergo14 wrote: post #82
pythonaut_16 wrote: post #35

Earlier quoted context omitted.

Sounds like you really don't understand development if you think getting to use React isn't a big deal. React (and others like it, e.g. Vue) really is a huge win and solves a ton of pain points common to front end development. It still has its own pain points, but it's hard to overstate how much of an improvement it is over other older approaches like jQuery.

Yes, because between jQuery and react there was nothing in between, and functional programming or singletons for state were unheard of. /S On other hand you still have things broken in react not to mention few years with uncertain patent situation. https://twitter.com/sveltejs/status/999704064937156611 sums this up pretty well. Programming world is in a constant flux, now you have lit-html that gives you react in 5kb…

> lit-html that gives you react in 5kb without vdom overhead

Uh, lit-html seems like just another templating library. Marginally better than something like Soy. Calling it "React" is pretty reductive.

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

#190

Post by copperx »

_ea1k wrote: post #148
kolpa wrote: post #113

Earlier quoted context omitted.

> Usually microservices have their own databases That's news to me, and seems insane. Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.

To be blunt, its news to a lot of people, but it also isn't wrong. Microservices really shouldn't share a database, and if they do then they aren't "microservices".

What is that called, then? Having small programs, each responding to a different part of the API, all storing data in a single shared DB?
Post reply on HN