Earlier quoted context omitted.
You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?
You are if you care about whether you're deploying things that aren't necessary. With microservices you can take a single specific service that two projects share and reuse it. With a monolith you can't unless you deploy everything else as well. That can easily fail a requirements check (say, hardware requirements are too costly) and force you to redevelop the service for the second project.
The End of Microservices
61–70 of 154 posts
Re: The End of Microservices
#62I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it. A core principle which a lot of people and articles ignore, though, is reusability . I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it. Essentially, you build out the backend to act as a library for your front end. So we have log…
Re: The End of Microservices
#63Earlier quoted context omitted.
You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?
I think it's the old loose coupling vs. late binding discussion. Some people confuse the former with the latter. You can very mechanically achieve late binding with microservices, but it takes extra effort to actually achieve loose coupling; and guess what, the effort might or might not be less than doing loose coupling within the components of a monolith.
This is where I got the BFF pattern from:
Re: The End of Microservices
#64I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…
I think you've missed the point in several different ways here. First, there's a difference between "I've seen it done like X" and "When done well, it's done like Y" Too often we play this game where we talk, teach, and apply Y, but then in the real world it gets done like X. Turns out that X sucks a lot, so then we throw away Y. Microservices may be done poorly in most real world applications. In fact it would surpr…
To use your example, if my task were "make a record of the errors of this process available on the web", my first thought would be to write to stderr, pipe stderr to a file, and then serve that from the webroot of some commodity webserver like Apache, 'python -m SimpleHTTPServer', or even S3. If the format is too hard to read, I'd probably write a quick JS viewer that can collapse stack traces, aggregate similar errors, etc, all done in the web browser. Or use cut/awk/sed to process it before dumping it in the webroot. It's only if the data gets big enough that it starts freezing the browser that I'd reach for ELK or something similar. I don't know anyone who would call this a "service" though; indeed, it seems the polar opposite of what most people talk about when they say "microservices".
Re: The End of Microservices
#65I'm sorry -- I think the author completely misses the point about why microservices were controversial at all? Distributed systems are not the same as centralized ones, and you cannot paper over the differences between the two. It is wrong to think that distributed microservices will completely replace centralized services in some future paradise. The difference is not a tech fad; it's more like a law of nature. Dist…
Re: The End of Microservices
#66Earlier quoted context omitted.
I think this is a smaller evolution than microservices / non microservices.... as others have pointed out, the real discussion is autonomy versus centralised control.
If that's the case, I'd argue we're conflating software development management with software engineering execution. It's illogical to assert that utilizing microservices implies entirely forgoing centralization.
Re: The End of Microservices
#67Re: The End of Microservices
#68Earlier quoted context omitted.
You are if you care about whether you're deploying things that aren't necessary. With microservices you can take a single specific service that two projects share and reuse it. With a monolith you can't unless you deploy everything else as well. That can easily fail a requirements check (say, hardware requirements are too costly) and force you to redevelop the service for the second project.
I'm not trying to be facetious, but isn't that just called a library?
Re: The End of Microservices
#69Earlier quoted context omitted.
I think you've missed the point in several different ways here. First, there's a difference between "I've seen it done like X" and "When done well, it's done like Y" Too often we play this game where we talk, teach, and apply Y, but then in the real world it gets done like X. Turns out that X sucks a lot, so then we throw away Y. Microservices may be done poorly in most real world applications. In fact it would surpr…
If you're starting "micro", why do you need the "services" part at all? Why not just make it a function call? To use your example, if my task were "make a record of the errors of this process available on the web", my first thought would be to write to stderr, pipe stderr to a file, and then serve that from the webroot of some commodity webserver like Apache, 'python -m SimpleHTTPServer', or even S3. If the format is…
I agree with your characterization. All except maybe the "I'd probably write a quick JS viewer that can collapse stack traces" part.
Here's the thing: I'm so minimalist that I'm only going to add frameworks and libraries as a last result, if you stuck a gun to my head. I'm going to resist as much as I possibly can.
I love writing code. And every line of code I write has to be compiled, deployed, is prone to bugs, has version dependencies, and so on. Many times it adds unnecessary complexity to the solution. I love using cool frameworks and libraries. Same goes for them.
The magic here is that the vast majority of whatever you're doing? It's already been done. Use O/S code that's ran successfully for ten, twenty years. Write your own code only as a last result. Micrososervices shouldn't have more than 100 lines of code.
Yes, it's a function. Maybe 3 or 4 closely-related functions. If it gets past that level of complexity, refactor.
(The only thing I'd add here is that you'll end up factoring out common code as you go along. That code needs to be put into a shared corporate library, which also should be small, along with shared types)
When done well, you end up with the realization that you've been doing it wrong all along. When done poorly, you just make an even bigger mess than you did doing it the old way.
Here's one small example. I was writing a production project for some folks a few years ago. We needed some way of showing system status.
The old way could have used all sorts of things: logging systems, server metric systems, and so on. I would have probably done some research, downloaded a library or framework, set it up along the happy path, and made some really awesome html dashboards.
Then the library would change, or the metrics would be different, or the configuration would need tweaking, etc.
I figured out what we really needed to see was time/date stamps on certain files. So I pipe ls to a web file and chron it. Five minutes later it's working. It'll be working ten years from now. If we need something more complicated? We'll add it. One tiny little bit at a time.
I'm okay with calling that a microservice, since it's infrastructure code that needs to be deployed and maintained as part of the app. But it's really only a line of BASH.
Some people would say that what I did was completely trivial. These are people who do not understand what the hell is going on. That was a win. If I could have 5 or 10 microservices like that which provide business value? I'm freaking way ahead of the value curve as opposed to a similar team who's still slogging through 7,000 lines of mostly boilerplate code that does basically the same thing.
Re: The End of Microservices
#70It is weird to read people write about microservices (or some other tech fad) as if it is this otherworldly thing that requires instruction and training. So many words dedicated to describing the supposedly bad old days! All this stuff is just another aspect in the life of a practitioner of computing. A proper expert should see these things not as a fad, but as a collection of techniques that can be added or subtract…