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

651–660 of 782 posts

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

#651

Post by rcxdude »

joshvm wrote: post #217
NickBusey wrote: post #72

Earlier quoted context omitted.

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

One example I'm familiar with that sounds like microservices is the Robot Operating System (ROS). At its heart it's just a framework for pub/sub over IP, it just happens to be targeted towards robotics. A ROS system comprises of 'nodes' for each logical operation e.g. image acquisition -> camera calibration -> analysis -> output. The system is defined by a graph of these nodes, since you can pipe messages wherever th…

ROS is not a particularly good implementation of this concept though. And it tends to encourage extremely fine splitting of jobs, which basically just turns your robotics problem into a distributed robotics problem, making it much harder in the process (as well as less efficient).

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

#652

Post by je42 »

lolive wrote: post #614
ChicagoDave wrote: post #605

I’ve been tracking the comments and my sense is that almost no one here believes the business domain drives the technical solution. Microservices, when constructed from a well-designed model, provides a level of agility I’ve never seen in 33 years of software development. It also walls off change control between domains. My take from the Segment article is that they never modeled their business and just put services…

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

you avoid them. you design your system (a set of microservices) in such a way that you don't need a transaction across service boundaries ( or rather database boundaries )

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

#653

Post by lmm »

paxys wrote: post #155
blablabla123 wrote: post #106

Earlier quoted context omitted.

But there is a big difference. These small targeted programs are invoked in user land, usually by the user. Microservices get invoked directly by the user when debugging is going on. Otherwise they are expected to automagically talk to each other and depending on the abstraction even discovery each other automatically. Also I can pipe these tools together from the same terminal session, like tail -f foo | grep someth…

Look at the package dependency tree of an average linux program. They are absolutely examples of "microservices" talking to each other.

The big problems with microservices come from distributed transactions being difficult and clocks getting out of sync. Multiple services on a single machine don't have that problem.

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

#654

Post by lmm »

fastball wrote: post #128
apeace wrote: post #107

Earlier quoted context omitted.

My understanding is that OpenBSD is constructed this way, and I have also heard that their code is well-organized and easy to follow. There is the "base" system which is the OS itself and common packages (all the ones you mentioned), then there is the "ports" repo which contains many open-source applications with patches to make them work with OpenBSD. Here is a Github mirror of their repos: https://github.com/openbs…

"packages" and "ports" are both collections of "microservices" in your analogy, so you can't really assert the whole thing is a monolith.

The whole thing is released and deployed together, which is the usual distinction between microservices and not. I don't think anyone's advocating not using modules and folders to structure your code in your repository (certainly I hope not), but a single deployment artifact makes life a lot easier.

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

#655

Post by lmm »

bewo001 wrote: post #641
neuromantik8086 wrote: post #545

Earlier quoted context omitted.

It took me longer than it probably should have to realize that the term microservices was made by analogy to the term microkernel . I think that part of my main issue with the "microservices" is that it conflates highly technical semantics with word forms that are a bit more wishy washy in meaning (i.e., a service is something formed more of human perception, not rooted directly in operating system abstractions).

I wonder if microservices will have a similar evolution as microkernels. While some microkernels almost closed the performance gap to monolith kernels, the communication overhead killed them. It turned out that the kernel's complexity could be reduced by moving some functions to the applications ("library OS"). Linux kernel drivers are only accepted when the functionality can't be done in user space. The extreme vers…

> The extreme version is running single purpose, highly specialized unikernels on a hypervisor.

Which, strangely enough, ends up looking almost the same thing as running services on a microkernel.

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

#657

Post by notyourday »

stickfigure wrote: post #581
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 on…

The problem is not micro services. The problem is that company's engineering leadership could not lead their way out of a paper bag.

Micro services is an extremely powerful pattern which solves a bazillion critical issues most important ones being:

* separation of concerns

* ability of different teams maintain, develop and reiterate on different subsystems independently from each other

* loose coupling of the subsystems

Do you have auth server that your API accesses using auth.your.internal.name which does not share its code base with the API? You have a micro service.

Do you have a profile service that is responsible for the extra goodies on a profile of a user that the rest of the API business logic does not care about?

You have a micro service. Do you spin up some messaging layer in a cloud that knows a few things about the API but really is only concerned with passing messages around? You have a micro service.

The alternative is that you have a single code base and a single app that starts with ENV_RUNMODE=messaging or ENV_RUNMODE=API or ENV_RUNMODE=website and ENV_RUNMODE=auth ( except in the case of auth it only implements creation/changes of the new entries and a change of passwords but not validation as the validation is done by the code in any ENV_RUNMODE by accessing the auth database directly with read-write privilege and no one ever implemented deletion of the entries from the authentication database. Actually, even that would be an good step - there's no auth database because that would require knowing the mode we are running in and managing multiple sets of credentials so instead it is simply another table in a single database that stores everything )

That is the alternative to micro services. So I would argue that unless Segment has that kind of architecture it does not have a monolith. It implements a sane micro services pattern.

Should the engineering be lead by a blind squirrel that once managed to find a nut, in a winter, three years ago, the sane micro services pattern would be micro serviced even more -- I call it nanoservice pattern aka LeftPad as a service. We aren't seeing it much yet but as Go becomes bigger and bigger player in shops without excellent engineering leadership I expect to see it more and more due to Go giving developers tools to gRPC between processes.

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

#658

Post by erfgh »

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

Because make is built with the assumption that you can launch a process (cc) with minimal startup overhead. That doesn't work for javac for example.

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

#659

Post by erfgh »

9935c101ab17a66 wrote: post #529
barkingcat wrote: post #364

Earlier quoted context omitted.

FTP workflows are so extremely widely used in today's world that it's inconceivable you think it's behind us.

Maybe in frontenddev/small companies/small largely static websites FTP pervades, but I'd argue that most developers that deal with any real complexity probably use some kind of source control system to 'share' files rather than some kind of FTP program. And I'd be very surprised if relative FTP usage hadn't decreased significantly over the last 3-4 years (But this is all quite anecdotal, and I could be wrong). Someth…

FTP is still extremely widespread in the form of SFTP.

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

#660

Post by mpweiher »

sieabahlpark wrote: post #635
mpweiher wrote: post #628

Earlier quoted context omitted.

> never worked on a single service whose tests ran that fast I'd say you've never had good tests. I have a test-suite for a bunch of my frameworks that dates to the mid 90s, with tests added regularly with new functionality. It currently takes 4 seconds total for 6 separate frameworks and 1000 individual tests. Which is actually a bit slower than it should be, it used to take around 1-2 seconds, so might have to dig…

Not all domains have libraries which can run tests that fast?

Sure. I'd suggest that the domains that limit testing speed are exceedingly rare. Much, much, much more common are technical issues.

Either way, the idea of considering slow tests a feature was novel to me.

Post reply on HN