Earlier quoted context omitted.
Great pun!
Not sure if it's a pun, or the literal etymology of the phrase.
[deleted]
The Death of Microservice Madness in 2018
431–440 of 469 posts
Re: The Death of Microservice Madness in 2018
#432Earlier quoted context omitted.
I think the complexity of solutions has gone up (especially in webdev), it seems to me perhaps complexity has gone up way further than actual requirements or new features would suggest... Which seems to end up meaning productivity has gone down when measured by "things end users of websites can do", even though modern FE devs end up creating much more code and html and css than "the old days". (Admittedly, if you inc…
"even though modern FE devs end up creating much more code and html and css than "the old days"" And yet, most homepages today can't be viewed without javascript. You are correct, for the end user the complexity has absolutely not resulted in better homepages but worse.
On the other hand, I can now easily write web pages that let people query and view the results of large CFD simulations in interactive 3d.
Re: The Death of Microservice Madness in 2018
#433Earlier quoted context omitted.
Premature optimisation... YAGNI is almost always the right approach.
I don't think you should always go with a microservice approach first, but you should always separate different domains/features into well defined modules/projects even within a monolith. There have been plenty of times where I've taken a project out of a monolith and created a separate shippable package to be consumed by another monolith in a separate repo. There were also occasions where I had to rip out a feature…
Completely agree.
I mostly tell my people "We aren't going to do that yet - or possibly ever - but keep in mind that we might have to if we ever win the user growth hockey-stick graph lottery, so when choosing between options of how to architect things, prefer very narrow focus that _could_ be pulled apart into microservices more easily if practical"
I've also been known to stand up duplicated instances on a monolith with path routing on the load balancer as a "pretend microservices" scaling or upgrade trick.
Re: The Death of Microservice Madness in 2018
#434Earlier quoted context omitted.
Microservices as the M in MVC?
Microservices is a back-end service pattern. MVC (Model View Controller) is a front-end pattern to enforce separation between data, UI and interaction logic.
Models (should) abstract any data, providing services, and reside on the back end...
Re: The Death of Microservice Madness in 2018
#435Earlier quoted context omitted.
> Higher levels of abstraction makes it easier to get something up and running fast More layers of indirection in a system and more dependencies on external libraries and tooling does not necessarily get you any abstractions. To take a contemporary example, there is no "abstraction" in being driven to use Docker because your dependencies have gotten unmanageable otherwise.
Docker is an abstraction...
No it's not. OS-level virtualization is the abstraction. Docker is a set of tools to manage Linux containers and virtual filesystems. You can argue that libvirt is an abstraction because it does actually work over several different virtualization technologies.
Re: The Death of Microservice Madness in 2018
#436Earlier quoted context omitted.
I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain.
Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.
Real-world business servers are complicated even when you tease apart the different elements.
Re: The Death of Microservice Madness in 2018
#437Earlier quoted context omitted.
Also, there is a nice place between microservices and a monolith
I'm gonna just be honest here and say that I don't really know the difference between "microservices" and "service-oriented architecture" except for the notion that "microservices" implies breaking up your services before they get too big and hairy, which kind of seems obvious. If some companies go completely nuts and deploy 5 microservices per developer, then yes, that is madness. If all of those microservices are R…
> I'm gonna just be honest here and say that I don't really know the difference between "microservices" and "service-oriented architecture" except for the notion that "microservices" implies breaking up your services before they get too big and hairy, which kind of seems obvious.
The impression I get - and this could be totally wrong - is that the difference is how the services relate to each other.
In this post's example, 5 of the 6 microservices look like something that would be exposed to the user in some way. I would call this a microservice architecture; they're networked together in a way where no one thing orchestrates the others. They likely all touch the same data storage, but the overall structure is mostly flat.
In a service-oriented architecture, there'd be a tree-like or graph-like hierarchy. To an end user, it would look monolithic, but the monolith would, behind the scenes, delegate to the "user-facing" services such as Upload and Download. Upload and Download would then use the Transcode service as appropriate. But the important part is that this would all be one way: Transcode isn't allowed to contact Upload or Download, just return the result to whatever called it.
Re: The Death of Microservice Madness in 2018
#438Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some data and drop it somewhere else e.g. image compression. Now you can use this microservice anywhere and just change a few params in how you call it and you have avatars, thumbnails, etc.
So basically a library? :)
No?
Re: The Death of Microservice Madness in 2018
#439People talk about building monoliths like it’s some simpler alternative. On the JVM it’s not. When I first started with Java one of the coolest things was that I could embed anything. I could embed Elasticsearch in my web service. Wow! Forget services calling each other! I’ll prototype real quick with everything in one JVM! But that proved impossible! :( It turned out that until Java 9, the JVM has a single namespace…
I think the recommendation is Monolith First https://martinfowler.com/bliki/MonolithFirst.html You start with a Monolith and break it out as needed. (i.e. When you find out that is not a good idea to embed Elasticsearch ) You avoid premature boundaries that can become a significant constraint.
My experience in attempting to build a monolith—and, oh I tried—was that it's basically impossible.
Forget embedding Elasticsearch for the purpose of running it inside your monlith; just the transport layer drivers (supposing you're not using drivers that work over HTTP) basically add all of Elasticsearch onto your classpath. Good luck building your monolith after that. And that's true for so many things you'd want to use. If you want to build a monolith you basically can't have any dependencies. Or be very experienced in dependency management.
This is why I have a microservice that fronts all my Elasticsearch queries. Its artifact has the Elasticsearch drivers, all other microservices that need access data from Elasticsearch talk to this service over gRPC. Any time I want to upgrade Elasticsearch or change something about a query, I only need to do it in one spot. It's great.
Re: The Death of Microservice Madness in 2018
#440Earlier quoted context omitted.
I meant it in a similar sense to that in which some hobbies are often irrational if you consider them only for market value. I probably could have chosen a better term. An amateur painter will often spend far more time than any reasonable estimation of the market value of that job would justify. Part of this is lack of efficiency and experience, but another part is doing things with sharply diminishing returns. For e…
> amateurs can easily arrive at a finished job (of painting, in this case) that they would never be able to convince themselves to pay market rate for. If you're looking at it from a economic standpoint, to be considered irrational, the tradeoff between the value of time vs the cost of hiring a professional would have to assume that the value of the time is greater than the value of the professional. I always hear th…
[deleted]