Ask Slashdot: What Exactly Are 'Microservices'? 288
After debating the term in a recent Slashdot subthread, longtime reader Tablizer wants to pose the question to a larger audience: what exactly are 'microservices'? Over the past few years I've asked many colleagues what "microservices" are, and get a gazillion different answers. "Independent deploy-ability" has been an issue as old as the IBM hills. Don't make anything "too big" nor "too small"; be it functions, files, apps, name-spaces, tables, databases, etc.
Overly large X's didn't need special terms, such as "monofunction". We'd just call it "poorly partitioned/sized/factored". (Picking the right size requires skill and experience, both in technology and the domain.) Dynamic languages are usually "independently deployable" at the file level, so what is a PHP "monolith", for example?
Puzzles like this are abound when trying to use the Socratic method to tease out specific-ness. Socrates would quit and become a goat herder, as such discussions often turn sour and personal. Here's a recent Slashdot subthread debating the term.
Overly large X's didn't need special terms, such as "monofunction". We'd just call it "poorly partitioned/sized/factored". (Picking the right size requires skill and experience, both in technology and the domain.) Dynamic languages are usually "independently deployable" at the file level, so what is a PHP "monolith", for example?
Puzzles like this are abound when trying to use the Socratic method to tease out specific-ness. Socrates would quit and become a goat herder, as such discussions often turn sour and personal. Here's a recent Slashdot subthread debating the term.
A single use, web enabled, api function (Score:5, Funny)
I don't know why we try to complicate things by giving them new names. It's like the time that I was asked in an interview where streams derive from. I said data strings coming over a serial device. Wasn't the answer he was looking for, we both went away angry.
Re:A single use, web enabled, api function (Score:5, Funny)
had one recently for a electronics position in automotive "what happens when you start your car" he was looking for well this module starts monitoring blah blah blah my response was "I usually cry cause I am going to my current job"
Re:A single use, web enabled, api function (Score:5, Insightful)
If someone asks an ambiguous questions AND your answer is perfectly valid BUT wasn't what they were looking for THEN it's their failure.
Ask better questions.
Re: (Score:2, Informative)
Re:A single use, web enabled, api function (Score:5, Insightful)
Re:A single use, web enabled, api function (Score:5, Interesting)
How hard is it for an interviewer to laugh at what is likely a joke then rephrase the question? I wouldn't want to work somewhere where they have no sense of humour.
Not only should this not be hard, but that is something that I actively seek out depending on the seniority level of the candidate.
My personal interview style is conversational. I like to ask lots of open ended questions and then I use the responses as a guide for digging further. Sometimes my questions are intentionally "dumb" just to see how the candidate will handle it. Someone who is full of shit is likely to miss the stupidity of the question and will offer an equally dumb response with high confidence. If it's an unfamiliar topic and they have integrity they will say they don't know or don't understand the question. If they know the area well they will ask for clarification and point out that the question doesn't make sense.
In a senior engineering role, often part of the JD is to communicate complex engineering topics to non-technical stakeholders. So I will role-play a little bit and act dumb to see how they "manage me." Mentoring junior engineers is another part of the JD, so that's another reason I ask "dumb" questions, to see if they can explain it to me like the 5 year-old that I just [intentionally] made myself out to be.
If they call me out on something dumb and ask for clarification, that's a good sign ... not a red flag at all. If they respond somewhat sarcastically or tongue in cheek, without being rude or mean about it, it can be a sign that this will be a fun person to work with (context matters, they know I'm an engineer).
Re: (Score:3)
> I said data strings coming over a serial device. Wasn't the answer he was looking for
That's pretty much what I would have said. What WAS he looking for ?
Re:A single use, web enabled, api function (Score:5, Funny)
> I said data strings coming over a serial device. Wasn't the answer he was looking for
That's pretty much what I would have said. What WAS he looking for ?
Precipitation and gravity.
The OP was interviewing for a geologist position.
Re: (Score:3, Funny)
Re:A single use, web enabled, api function (Score:5, Insightful)
Get the UNIX sysadmin, the Web dev, the firewall engineer, the DBA, the telecom tech, and the mainframe system programmer all in the same room.
Now ask, “What’s a ‘session’?”
Re:A single use, web enabled, api function (Score:5, Funny)
What you just said, but with beer and pizza.
Re: (Score:2)
> Now ask, “What’s a ‘session’?”
When the masseuse jerks you off. Then walk out... because you've just landed that job.
Re:A single use, web enabled, api function (Score:4, Funny)
One of my coworkers who also teaches the Cisco content is known for saying "One of the problems in IT is we have 9 words and we use them for everything"
Re: (Score:2)
Re: (Score:2)
in C++ they were scared to have another keyword, so they used static, as they thaught it roughly is what they need.
In Java and C# etc. "static" makes no sense at all. It is just there because they copied a useless usage of that keyword from another language.
Re: (Score:3)
D seems to be the only language that actively decided not to follow in all of C++'s syntax mistakes, instead of apparently cargo-culting it like the other three.
Re: (Score:2)
One of my coworkers who also teaches the Cisco content is known for saying "One of the problems in IT is we have 9 words and we use them for everything"
Is that why IT managers get so excited by new buzzwords?
Re: (Score:2)
You forgot to bring in the priest.
Re: (Score:3)
I agree. It's needless complexity. The fact that we seem to have so much trouble agreeing on a definition should tell us that we probably didn't need a new term in the first place.
Imagine anything you might want to call a "microservice" and think about what word you would have used to describe such a thing in the past. Does calling that thing a microservice really tell us anything meaningful about the thing that we didn't already know? That seems unlikely to me.
My only guess as to why such a pointless t
Re: (Score:2)
> I've said many times before that a large application, if it's well-designed, should feel like a bunch of much smaller applications.
Feel like to the user or developers? Users don't like arbitrary boundaries; they don't care how dev teams are organized, they just want a good app (or app suite) that feels well integrated when it needs to be.
> It should be stateless
Stateless? Please elaborate?
Re: (Score:2)
Feel like to the user or developers?
To the developers, of course. This isn't a development process thing or a UI thing, this is an architecture thing. Individual modules should be largely independent and shouldn't directly affect, or be affected by, other modules in the general case. (This is much easier to do in practice than it sounds at first.) For the developers, working on such a program is a lot like working on a bunch of much smaller programs as their scope of concern is typically limited to just one module.
The two biggest sources o
Re: (Score:2)
If there were multiple instances of a service, a caller could freely switch between them, even using a different instance for every call, without consequence.
That is what micro services aim for.
This doesn't mean the results should necessarily be cacheable like a pure function. Services ought to do things, after all, and that often means reading from or writing to permanent storage or some other stateful entity. This is technically state, but it is state external to the service and not what I mean by state w
Re: (Score:2)
Was not that clear from your post before.
And now we're back to the original question... No consistency amongst definitions.
Re: (Score:2)
The fact that we seem to have so much trouble agreeing on a definition should tell us that we probably didn't need a new term in the first place.
We need the concept, though. I bet essentially everyone agrees that the alternative to "microservices" is a giant monolithic application having grown into doing all sorts of stuff because the deveopers couldn't be assed to think about a useful design for even as long as that their coffee pot was still steaming in the morning.
And while I don't like "microservice" as a term, I kind of have to concede that it sounds a lot more corporate-y than "get off your ass and learn some decent programming, so your code d
Re: (Score:3, Interesting)
We need the concept, though. I bet essentially everyone agrees that the alternative to "microservices" is a giant monolithic application having grown into doing all sorts of stuff because the deveopers couldn't be assed to think about a useful design for even as long as that their coffee pot was still steaming in the morning.
You can create more chaos with a services-depending-on-services model than you can with a "giant monolithic application" because all the same complexity exists in the microservices model, plus the complexity needed to handle the service connections, plus if the resulting code base winds up maintained by a bunch of different teams who don't know what the other teams are doing and can't see into their black boxes, who knows what kind of dragons might be hiding in there?
Re:A single use, web enabled, api function (Score:5, Interesting)
This sounds like the traditional view of Unix utilites. ls, sed, cat, more, less, etc. You know, everything that systemd forgot.
"Do one thing and do it well". So, the cloud is just catching up to 30 years of good computing practice.
Re: (Score:2)
Re: (Score:2)
The problem with stateless is: 99% of everything you do on a computer - and that includes an internet session: requires state.
So the tricky question is: where to save/handle/store that state.
The micro service itself could be stateless, the "application" it is part of: seriously can't.
Re: (Score:2)
Hehe, I just wrote, a few weeks ago, a microservice for managing and maintaining state.
Muahaha!
Re: A single use, web enabled, api function (Score:2)
I think (oh boy, here we go...) what makes an API call a microservice is not what it is (an API call), but perhaps that you're making it available more broadly than we used to; f.e. to Internet-connected stuff.
Floopinator and flobulattor (Score:3)
I make up words too. And I hire or reject based on the applicant's knowledge of those words.
Oddly I am having difficulty expanding my startup to more than 1 employee (myself).
Re: (Score:2)
Either you knew what he was asking about: then why not give the answer?
Or you did not know, so why being angry?
If we are talking about software, then streams obviously have nothing at all to do with a serial device.
But you knew that, right?
Re: A single use, web enabled, api function (Score:2)
Cloud:Someone else's server::Microinstances:Someone else's docker
From the reading.. (Score:2)
I would have to say microservices are just some cute way of changing terminology to be more buzzwordy. A basic example could be writing three tiny programs that could work together instead of just writing one program that had the three little ones compiled it.
For example, a microservice could be something as simple as writing a function that handles a deck of cards. This microserve could then be reused in various card games and one wouldn't have to rewrite the deck of cards.
So yeah, really just sounds like
Re: (Score:3)
Yeah, but then the confusion begins. Would your "Deck of cards" service have endpoints for "deal a card", "shuffle deck", "Check for Blackjack", etc? Or would those be broken down into further microservices? Would a blackjack service itself be one microservice, or is that too high-level? Maybe each aspect of Blackjack should be its own service.
I think this is where the confusion around terminology comes in. To me, it's half of an architecture idea, half buzzword nonsense.
Re: (Score:2)
Re: (Score:2)
Yeah, but then the confusion begins. Would your "Deck of cards" service have endpoints for "deal a card", "shuffle deck", "Check for Blackjack", etc?
Where I work, a deck of cards is a series of short test procedures executed during flight testing of a large unmanned aircraft under development.
Surprise -- the meaning of common terms can be context sensitive.
Re: (Score:2)
I'm not quite sure what your expectation is. Do you think you should be able to know every design decision made by an architect just by knowing the names of a few architectural patterns they used?
If someone tells you they have any application (microservice or not) which manages a deck of cards, you are going to have follow up questions about its design. The value is knowing an application used microservices to manage the deck of cards used by the application is you can assume that functionality is not tight
Re:From the reading.. (Score:5, Funny)
So yeah, really just sounds like a "zoomer" programmer married a "zoomer" marketing major and away they go.
It's funny you should say that.
A microservices architecture enables an Agile SecDevOps team to shift left with its security compliance and best practices while leveraging CI/CD infrastructure-as-a-service for maximum synergies with real-time insights into dynamic demand scaling, surfacing a delightful user experience. Writing a single monolithic app to play a card game simply does not facilitate deep insights into a convergent application stack combining data lake capabilities with fully empowered agents under an AI/ML paradigm.
I mean, simplifying things just a bit, that's really what microservices are.
Re: (Score:3)
A microservices architecture enables an Agile SecDevOps team to shift left with its security compliance and best practices while leveraging CI/CD infrastructure-as-a-service for maximum synergies with real-time insights into dynamic demand scaling, surfacing a delightful user experience. Writing a single monolithic app to play a card game simply does not facilitate deep insights into a convergent application stack combining data lake capabilities with fully empowered agents under an AI/ML paradigm.
My brain... it hurts, it hurts, too much buzzwording...
(p.s. don't say "whoosh")
Re: (Score:2)
Re: (Score:2)
Heh, I hope your comment accidentally makes it into the next ChatGPT training set.
Re: (Score:2)
God dammit I'm and AR and cyrpto short of filling out my bingo card. Not a row mind you. THE ENTIRE CARD.
Re: (Score:2)
I have to confess I accidentally re-used "insight into'. In respect, the second use should have been "optimization of" instead.
Now that that's off my chest, it's back to another day in the salt mine of waterfall-style systems development.
Re: (Score:2)
... and, fully compliant with Muphry's Law, I did not check that comment closely enough: "respect" should have been "retrospect". My phone's keyboard treats me like some kind of unlettered savage!
Re: (Score:2)
And one small nudge from a three-year-old and the whole house falls down.
Stupidness.
Microservices have their place, but some places go all silly with them.
Main part of an app should be sort of monolithic, with microservices broken away from it where it makes sense.
A massive nebulous constellation of nothing but microservices is a recipe for disaster. A big distributed ball of mud. It does nothing but architectural masturbation.
Re: (Score:2)
Re: From the reading.. (Score:2)
"I would have to say microservices are just some cute way of changing terminology to be more buzzwordy"
Now if they could just use that same energy to create a truly satisfying customer experience, and the resulting good reputation and word of mouth can serve as it's own advertising.
Re: (Score:2)
Earliest microservice (Score:2)
1990 NeXTstep, neh BSD unix variant, SteveJobs outfit embedded a crash recovery loop that did a cold-reboot on the OS and reset files without losing data. Very “just works” hands-off.
At the time it felt like AI but was coded automation
Feeling Philosophical, anyone..? (Score:2)
What does it really matter? Microservices aren't much more than an incremental method of monetization.
If I was born in 1950, I'd say they are just a way for them man to nickle and dime you to death.
Stick it to the man and make web servives polymorphic again!
Re: (Score:2)
If I was born in 1950, I'd say they are just a way for them man to nickle and dime you to death.
Since you said "I'd say they are just a way for them to nickle and dime you to death", I suspect you were born in 1950.
Like selling a single cigarette (Score:2)
Re: (Score:2)
Cloud providers (CP) do seem to want to get people to break apps into smaller web-based services so that the CP's can get you addicted to a library of services so they can nickle and dime you for every usage.
Let's say you need a better date-picker for your web app, so you rent one from Amazon and they charge you say a tenth of cent for each user usage. After you hook up dozens of such gizmos, they rake in the fees.
Thus it isn't necessarily better for your apps from your biz's perspective, it's just a way f
ChatGPT Answer (Score:5, Insightful)
ChatGPT is particularly good for common definitions since it gives the average answer over the corpus of texts it is trained on-
A microservice is a software development architecture that structures an application as a collection of small, independent, loosely coupled services. Each service in a microservice architecture performs a single, well-defined task and communicates with other services through well-defined interfaces, typically using lightweight communication mechanisms such as RESTful APIs.
But maybe it is best to think of this is as an ideal that intended microservices are templated against rather than a hard cutoff on what can be considered a microservice.
Re: (Score:2)
Re: (Score:2)
Simple answer: yes.
More complex answer: yes, indeed.
OK, Boomer! (Score:2)
This must be Slashdot, because you're not-really-asking-Slashdot instead of bothering to read an answer anywhere on the Internerd for yourself.
It's about trying to apply UNIX principles to networked architectures. And of course it's stupidly named and over-hyped - it's tech! No doubt you entered tech on one of those waves of over-promise and smoke and mirrors back before that beard filled in and turned gray.
Now get off our lawn so we can do some actual work instead of spending all of our time trying to soot
Re: (Score:2)
I don't see anything in your answer that indicates that you actually know what a microservice is. It has nothing to do with UNIX principles, whatever those are.
Since you castigated the questioner for not looking anywhere on the internet, while at the same time not posting any actual links in your answer, I'll do so. Amazon AWS offers a very good article here: https://aws.amazon.com/microse... [amazon.com]
The wikipedia article which you referenced without credit is poorly written and opinionated. There is a lot of misund
Re: (Score:2)
I don't see anything in your answer that indicates that you actually know what a microservice is
The consensus building here seems to be that no one does. That is, it's a very poorly defined term.
Your AWS link is just one opinion on what a microservice should be. I don't like it personally as the approach described encourages a high degree of coupling between services, which seems to miss the point entirely.
Re: (Score:2)
You are correct, there are different interpretations and nuances and approaches, I'm glad you didn't just make derogatory comments, but engaged in the discussion.
From the AWS article:
With monolithic architectures, all processes are tightly coupled and run as a single service.
Monolithic architectures add risk for application availability because many dependent and tightly coupled processes increase the impact of a single process failure.
With a microservices architecture, an application is built as independent components that run each application process as a service.
I read this to indicate that tight coupling is specifically what we avoid when building software as microservices.
Re: (Score:2)
One other thing about the AWS source. Amazon literally designed their hosting architecture to make microservices possible, so their documentation is worth considering as an authoritative source.
Another authoritative link article, from the Azure point of view, is here: https://learn.microsoft.com/en... [microsoft.com]
Re: (Score:2)
Do some actual work? Fuck, you can't even troll well. Just lame.
Re: OK, Boomer! (Score:2)
I was going to say: SOA + UNIX philosophy
That's essentially my understanding as well. Build one service that does just one thing well, then wire a bunch of them together to do complex things.
Re: (Score:2)
"It's about trying to apply UNIX principles to networked architectures. "
I get what you mean. Nice analogy. It is pretty remarkable how far one can get with a customizable vocabulary of executable functions that communicate inputs, outputs, and state through the a common interface.
Your Mom (Score:5, Funny)
Your Mom is a monolith, she sucks, she fucks, she jerks you off. Your Mom handles one customer at a time, from a queue.
Another alternative is to hire your Grandma, your Aunt, and your Sister. You see, your Grandma only does hand jobs, your Aunt only does blow jobs, and your Sister only fucks, and each has a separate queue. Like good pimp you distribute customers out to each as appropriate, once is a while you get a customer that wants the works and needs to go through each one-at-a-time. Your Grandma, your Aunt, and your Sister provide microservices.
What are microservices? (Score:5, Informative)
Opinion (Score:5, Insightful)
Think about all the times you've had to make a drop-down list for States, Provinces, or Countries. Imagine replacing that fast local code with a slow round-trip call across the network because you're too lazy to be bothered to update your app when goatpooistan becomes the people's free republic of poopistan.
That's what microservices are, tiny little webservices that shit back data, usually in JSON format, because people forget that networks are not instant and data service is not free.
Re: (Score:3)
Oh man, in my nearly 30 years of working as a coder I've never seen ANY idea (and trust me, I've seen JS) destroy productivity and responsiveness more than trying to transition to microservices.
Suddenly your not maintaining one code base but 20 and all them have to talk to each other. and each time they do, they are waiting and waiting, and suddenly youve got timeouts because these things have warmup times, and suddenly your reconsolidating things back because theres no feasible way to dislodge dependencies
Re:Opinion (Score:5, Insightful)
Multiple people, multiple organizations failing, and being told "that's because you're not doing it our correct way", is a cargo cult.
It's exactly how real cults work too. The guru isn't wrong. It must be something you're doing wrong.
Re: (Score:2)
Could be both, the "Guru" and his followers.
One thing is certain: if it is not working someone (or all are?) is doing it wrong.
Re:Opinion (Score:5, Funny)
make a drop-down list for States, Provinces, or Countries. Imagine replacing that fast local code with a slow round-trip call across the network
Don't forget to populate that list asynchronously so that when I see Mexico then right as I hover my finger or mouse over the name, it changes to Nepal at the click event.
Re: (Score:2)
Come on now, the internet timing gods like trolling as much as anyone, we have to give them something to work with.
"Web Service" (Score:2)
Web services were a big buzzword of the early 2000's. I remember we joked then that one web-service hypster printed his resume as XML.
Web services have uses but didn't revolutionize anything, as older network protocols had already been doing similar for decades. Now most use JSON instead of XML, but the pro's and con's of web services haven't changed much.
Do note that what works well for really big orgs or apps often doesn't for smaller ones. People seem to over-copy tooling of big dogs like Netflix or Amaz
Re: (Score:2)
+5 Insightfull for typing utter nonsense - /. or just typical internet?
Re: (Score:3)
Yeah! We moved from the overhead of XML to JSON. That's progress! That progress does not negate the overhead of dns, tcp, and https connections or the frailty of certificate renewals, OCSP, and server spool-up times. Hiding all that behind a reverse proxy to make an API gateway doesn't reduce the complexity _at all_.
I am in no way advocating for a return to linear non-oop programming. Encapsulation and abstraction are VERY GOOD things. That said, I've sat on both sides of the developer/administrator l
Seriously? (Score:3)
Seriously, people. Some things are not that mysterious.
A microservice is an application with an API and a database that only that service can access. It is run by the team that writes it. It is used by other teams or applications to provide the functionality for a larger application or service. It's an implementation of SOA.
Start with Martin Fowler: https://www.martinfowler.com/m... [martinfowler.com]
Round out the history from Wikipedia: https://en.wikipedia.org/wiki/... [wikipedia.org]
Read a friggin' book:
- Building Microservices: Designing Fine-grained Systems (https://www.amazon.com/Building-Microservices-Designing-Fine-Grained-Systems/dp/1491950358)
- Building Event-Driven Microservices: Leveraging Organizational Data at Scale (https://www.amazon.com/gp/product/1492057894/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1492057894&linkCode=as2&tag=booksoncode-20&linkId=c808f09c52b77dbda92bb35973e3dc51)
- Microservices Patterns: With examples in Java (https://www.amazon.com/gp/product/1617294543/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617294543&linkCode=as2&tag=booksoncode-20&linkId=19ffe59e7e17f62a43f52acf39687707)
Re: (Score:2)
Marty is a bit opinionated. So am I, but I try to at least say things that make sense. That's never been a real concern for him. He's in the business of making up completely arbitrary definitions for things, after all. Still, this is odd even for him. What possibly reasoning could there be for his requirement that microservices be "independently deployable by fully automated deployment machinery." I get 'independently deployable', but what possible difference could it make if deployment is or can be a
Re: (Score:2)
but what possible difference could it make if deployment is or can be automated or not?
I would hazard a guess that the difference is that automation is the litmus test of whether something is a actually microservice or not.
Something isn't fit for being a microservice if it isn't cleanly partitioned enough if some bits still require manual deployment. Or maybe it leaves out too much that it must be manually coordinated with the deployment of other parts.
Avoid too many languages & DB's (Score:2)
> Start with Martin Fowler:
There seems fuzzy and buzzy words there also:
> developing a single application as a suite of small services
How is "services" defined? Is a function call a service? If not, why not? Stored procedure?
> each running in its own process
How is process defined? Per core? Per chip? Per EXE? PHP doesn't compile to EXE's, so is it in out?
Developers shouldn't have to care much about how the interpreter/compiler/load-balancer uses chips. Most of that should be automatic based on usag
Re: (Score:2)
There is nothing to ask what a process is:
$ ps
Does it list here? It is a process. If it does not, it might be a thread in a process.
There is no "definition" of what a "micro service is". Make your own and get over it.
Re: (Score:2)
> A microservice is an application with an API and a database that only that service can access.
Of course, soon you'll find that you need to "join" the data from different services, and you'll start suffering and asking what is the microservice-orthodox way of dealing with that.
At that point you'll learn that that dogma (a database for each microservice) is actually not writen in stone
https://softwareengineering.st... [stackexchange.com]
(and at that point you'll start losing your faith and questioning what is all this about
Re: (Score:2)
Martin Fowler is a hack who is years out of date. No wonder you're confused.
Saw a good definition ... (Score:2)
... on YouTube (no joke) by some senior engineer taking about advanced dev topics. Basically anything "you can implement in a few days up to a week on your own, exposed via API".
He's not wrong you know.
A monolith (either PHP or any other technology) is an application running on a single host that has all it's functionality tightly bound and coupled at the application layer and is meant to be used and utilized that way.
AWS article (Score:3)
AWS enables microservice architecture, so their thoughts on the subject are probably worth noting.
https://aws.amazon.com/microse... [amazon.com]
Cutting to the chase (Score:2)
Remember a few years back when a whole bunch of stuff failed because of a "library" that was just a few lines of JavaScript? Presumably it was an expediency or a hack, or perhaps even a larger library that got paired down to a remnant as some project evolved.
Based on reading the other comments, I'd say microservices are a cut-to-the-chase, where you bake in the ability to fail hard on something trivial right from the get-go. It's a great leap forward in fragility. Well done, community.
Not to be confuse
Re: (Score:2)
Re: (Score:2)
well that is kinda where the idea started.
Rather than have big monolith that gets taken down because someone updates an XML file with a list of zip codes in it improperly and lets it get pushed to prod, you have a little look up service. Nominally the web form does nice things for the user they enter their zip and some javascript runs in the background and populates the city and state for them -or- the service does not respond the front end javascript throws a bunch of scary errors in the javascript consol
bullshit (Score:3)
the theoretical idea of microservices is that they're functional, specific, stateless units that allow you to build complex massively scalable systems.
the theory makes sense, it's a neat idea and ceos and ctos love it, and can even be a sensible design principle if applied sensibly.
but of course that's usually not the case, because you actually have to get a working system form all those pieces and companies tend to pay bullshitters far more than the people who actually gets things to work. it turns out buzzwords don't produce magically working systems. doers do. so in practice it tends to be a nightmare to develop culminating in a dysfunctional clusterfuck that in the end only barely becomes a working system at the cost of, god forgive us, wedging in some late "old school monolithic" server component to actually get the tricky shit of business nobody thought of sorted, at which point the whole "microservice architecture" becomes just a very expensive flowering legacy of hardly maintainable code because at the end of all the bullshit chain nobody actually knows what the whole zoo of services is supposed to exist for.
Re: (Score:2)
besides ... it's 2023. microservices? really? is that fad still going?
got "gazillion different answers" and came /.? (Score:2)
Nothing has changed, only vocabulary. (Score:2)
The principles are the same as always: aim for low coupling, high cohesion. Reduce coupling across the system where possible, in an ongoing process.
Now does it matter whether it gets called a "microservice" or not? Does it matter if you get to advertize as a "microservice" or not?
News for Nerds? (Score:2)
The whole Wikipedia article on micro services is not good enough for you? https://en.m.wikipedia.org/wiki/Microservices
In one case I know... (Score:2)
... it was an entire Spring Boot stack running in a container that served exactly one endpoint that built a database string. Talk about sheer overkill. My example service was up there in the cloud eating up CPU and memory and generating heat. Whenever anyone called it (which was a lot), it was adding a small delay to all those processes too because they're spinning around an extra 50ms or whatever waiting for their response. Doesn't sound like much but what gets me is the sheer fact that someone wrote a mic
Re: (Score:2)
There is most certainly nothing bloated about Spring Boot.
The simplest Micro Service is perhaps roughly 10 lines of code.
A term that has lost meaning... (Score:2)
It became a buzzword and so now everyone claims to do it no matter what they actually do. I no longer even bother to consider microservices to mean anything.
Most recently, a team was bragging on how they converted their backend to a microservices architecture. What this concretely meant to them is that they took their unmodified backend code and started running it in a container instead of directly in the os.
Instead of banking on a shorthand word that is corrupted from being overvalued, have to just descri
It's easy to define. (Score:2)
Can be an effective pattern or a huge anti-pattern (Score:2)
First the negative. If you divide up your services poorly, or define what is a service poorly you will absolutely have a negative experience. Also if you fail to take into account caching you'll have a negative experience. My first venture into micro service land was horrible. An architect decided to try an
It's DLL-hell at the service level (Score:2)
It has been heavily abused as a hammer, it doesn't work well for all applications.
Re: (Score:3)
If I have to read your wall of text to understand Agile, I think I'm better off not understanding.