Earlier quoted context omitted.
People look at microservices as a solution to the Big Ball of Mud, and then confuse "a solution" with "the solution". You really do have to modularize. In some languages, you can even use separate compilation units for separate modules to enforce the separation. You can do all of that but get simultaneous deployment, which cuts out whole classes of integration nightmares.
It seems like a Big Ball of mud is much more difficult to deal with than a bunch of small balls of mud just in general?
Goodbye Microservices: From 100s of problem children to 1 superstar
201–210 of 782 posts
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#202Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#203Let 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…
Are stuck using the new tech, because implementing it burned bridges with the old tech.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#204I can't imagine you have applied Conway's law.
I think there's some serious confusion between FaaS and microservice architecture.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#205Earlier quoted context omitted.
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.
JS has improved massively over the last few years, it's very nearly an entirely different language than what it used to be.
There's a reason everyone was desperate to avoid writing JS not all that long ago be it the form of coffeescript, silverlight, flash, or GWT. ES5 JS sucks. Like... a lot.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#206Let 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 ?
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#207Let 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…
Thesis --> Antithesis --> Synthesis
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#208This 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…
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…
A lot of software is used to control or impose someone's will on others organizationally.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#209Earlier 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.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#210Let 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 :)