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

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

#211

Post by byebyetech » Tue, Jul 10, 2018, 7:12 PM UTC

resource0x wrote: post #198

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…

> Old technology is deemed by people too troublesome or restrictive. "deemed" is the keyword here. Old tech is "deemed" bad, new one is "deemed" good. Without any numbers attached, just by way of hand-waving and propaganda. And it's all "deemed" Computer Science :)

Bob Martin said in one of his lectures that Software Engineering is the only field where people can't even agree on one thing.

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

#212

Post by man2525 » Tue, Jul 10, 2018, 7:13 PM UTC

I'm thinking it's more of a software business life cycle. Microservices are somewhat easier to deploy, which makes it easy for developers to add capabilities to be used by UX developers. Once the eye candy and rough functionality is in place, the sales team signs up new clients. The company draws down investment in developers and puts more money into infrastructure. The product moves from developer land to system land which is monolithic and can handle heavier loads.

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

#213

Post by Dirlewanger » Tue, Jul 10, 2018, 7:14 PM UTC

copperx wrote: post #187

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.

Rails was never really a major leap forward in anything, more so an evolution with convention-over-configuration and a strong community presence that established best practices early. It also hasn't been "cool" for years, it's an entrenched player that "just works". One could argue with all the Rubyists going to Elixir that's part of the cycle, but for many people that's been a net positive.

And then there's those altogether dropping Elixir for Go...

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

#214

Post by stcredzero » Tue, Jul 10, 2018, 7:14 PM UTC

With every destination living in one service, our developer productivity substantially improved. We no longer had to deploy 140+ services for a change to one of the shared libraries.

I say this as someone who worked in an environment widely castigated for its "monolithic" nature: It sounds like trying to have "modularity" hurt you, because you didn't actually have it in the first place. When you stopped pretending, the pain went away.

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

#215

Post by kyberias » Tue, Jul 10, 2018, 7:15 PM UTC

It's as if these people just take a buzz-word and start applying without ANY consideration about basic stuff about distributed systems. Are there any adults around in these firms or what is going on?

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

#216

Post by munchbunny » Tue, Jul 10, 2018, 7:15 PM UTC

codemac wrote: post #28

dualogy wrote: post #17

Earlier quoted context omitted.

"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…

Is there any evidence of this being true? Do they actually force a discipline? Do people actually find swapping languages easier with RPC/messaging than other ffi tooling? And do they really attract talent?! You make some amazing claims that I have seen no evidence of, and would love to see it.

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, it was developers not being rigorous/conscientious/intentional enough at the module boundaries. With microservices... same thing.

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

#217

Post by joshvm » Tue, Jul 10, 2018, 7:15 PM UTC

NickBusey wrote: post #72

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…

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 they're needed; all nodes can be many-many. Each node is a self-contained application which communicates to a master node via tcp/ip (like most pub/sub systems a master node is requried to tell nodes where to send messages). So you can do cool stuff like have lots of seprate networked computers all talking to each other (fairly) easily.

It works pretty well and once you've got a particular node stable - e.g. the node that acquires images - you don't need to touch it. If you need to refactor or bugfix, you only edit that code. If you need to test new things, you can just drop them into an existing system because there's separation between the code (e.g. you just tell the system what your new node will publish/subscribe and it'll do the rest).

There is definitely a feeling of duct tape and glue, since you're often using nodes made by lots of different people, some of which are maintainted, others aren't, different naming conventions, etc. However, I think that's just because ROS is designed to be as generic as possible, rather than a side effect of it running like a microservice.

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

#218

Post by heme » Tue, Jul 10, 2018, 7:16 PM UTC

... step back and embraced an approach that aligned well with our product requirements and needs of the team.

This ^^^. Everyone has an opinion on the Internet... frontend, backend, no-end. It's probably not going to align perfectly with your needs (are you Google/Facebook?) . There are a lot of tools & specs out there. If your blindly following someone else's opinion without truly understanding your users, product, & team you'll probably accrue debt.

Also, devs often forget the team. If your choice of tech cuts the team's velocity in half then it probably wasn't a good choice... even if it had some other technical benefits.

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

#219

Post by ljw1001 » Tue, Jul 10, 2018, 7:17 PM UTC

acroback wrote: post #123

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

what happens when the java code breaks the c code? Or does everyone roll-their-own everything in each language?

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

#220

Post by jacquesm » Tue, Jul 10, 2018, 7:19 PM UTC

spyspy wrote: post #200

matwood wrote: post #96

Earlier quoted context omitted.

Great point. I like separate services, but would cringe at 100s of services in any system I have seen.

I can't believe this made it out of any planning meetings. Engineer 1: "We'll have one repo per downstream service." Engineer 2: "But we have hundreds of those, so now we have to manage hundreds of github repos???" Anyone sane: "That doesn't sound right, we should rethink this..."

I've seen worse. And I wished that I was kidding.