I once scoffed at microservices.
Then I was tasked with building a scalable platform around a message broker system.
Then the switch clicked. I get it now.
Goodbye Microservices: From 100s of problem children to 1 superstar
381–390 of 782 posts
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#382Earlier quoted context omitted.
I agree, though I'm not so cynical about it. Well-defined API contracts are themselves a communication mechanism. If I provide an API, I am declaring that if you interact with me in a given way, I will behave in a certain way. Given that one of the hardest parts of scaling an organization is the boundaries between individuals and teams, providing a structured mechanism to define system behavior is incredibly valuable…
I hated that in our monolith Java web app, any random team could come along and pepper our team's module with global variable lookups and short term hacks that never get cleaned up. Even though we see the changes often times they are urgent changes needed right now, accompanied with promises to clean up later (which usually doesn't happen). The nice thing about a SOA architecture is that it makes it harder to do this…
I had enough of this stuff in my case so I locked repo down so only members of a team can merge PRs and no one can merge anything without a PR.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#383> Recall that the original motivation for separating each destination codebase into its own repo was to isolate test failures.
This seems like a weird reason to adopt microservices. Can't you isolate tests within the same repo using folders?
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#384Earlier quoted context omitted.
Computer Science... Now there's an oxymoron. At most institutions the subject matter is not really about computers nor is it science, at least not in the physics or chemistry sense.
That sounds like a rather narrow definition of science that will become even more obsolete in the years to come. With how far mankind has come, it's a little silly to think that "natural" systems will remain the only things that science is concerned with.
I think that their point is that "Computer Science" does not seem very very interested in the provability of their science (the "Science" part) nor the applicability for general purpose computing (the "Computer" part).
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#385Earlier quoted context omitted.
Do you realize that this is actually an anti-pattern, that adds unnecessary complexity and potential security problems to your app? Test code must be separated from production code - something, that should know every developer.
It’s basically a feature flag. I don’t like feature flags but it is a thing. But if you are testing an artifact, why isn’t the artifact testing part of your CI process? What you want to do is no more or less an anti pattern than swapping out mock services to test a microservice. I’m assuming the use of a service discovery tool to determine what gets run. Either way, you could screw it up by it being misconfigured.
First of all it is the test code, no matter whether it's implemented as a feature flag or in any other way. Test code and test data shall not be mixed with the production one for many well-documented and well-known reasons: security, additional points of failure, additional memory requirements, impact on architecture etc.
>But if you are testing an artifact, why isn’t the artifact testing part of your CI process?
It is and it shall be part of the CI process. Commit gets assigned build number in tag, artifact gets the version and build number in it's name and metadata, deployment to CI environment is performed, tests are executed against specific artifact, so every time you deploy to production you have a proof, that the exact binary that is being deployed has been verified in its production configuration.
>I’m assuming the use of a service discovery tool to determine what gets run.
Service discovery is irrelevant to this problem. Substitution of mock can be done with or without it.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#386Earlier quoted context omitted.
I remember a time where javascript was somehow called "old" and obsolete and pretty anyone hated it.
JavaScript prior to ES6 was "old" and obsolete and hated. Building JS objects pre-classes is pretty terrible (to say nothing of the .bind(this) that is spammed everywhere without the => operator) 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…
Interesting. I haven't touched, or even read, any JavaScript since well before ES6 arrived. I suppose I don't really know the language if it's changed so much (I've never even heard of JavaScript classes). I jumped on the JavaScript hater train and left the station.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#387sounds like a lack of Devops
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#388Let 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…
You missed a crucial detail: > * Everyone slowly goes back to the old technology, forgetting the new technology. This step is just as misguided as cult-y as "Everyone adopts this new technology and raves about how great it is now that they have just adopted it." In some cases the technology WAS the right idea, just implemented incorrectly or not sufficiently broadly, and the baby ends up getting thrown out with the b…
I agree completely.
I think that regardless of whether microservices works for anyone or not, they came about to address a real issue that we still have, but that I’m not sure anyone has fully solved.
I think that microservices are an expression of us trying to get to a solution that enables loose coupling, hard isolation of compute based on categorical functions. We wanted a way to keep Bob from the other team from messing with our components.
I think most organizations really need a mixture of monolithic and microservices. If anyone jumps off the cliff with the attitude that one methodology is right or wrong, they deserve the outcome that they get. A lot of the blogs at the time espoused the benefits without bothering to explain that Microservices were perhaps a crescent wrench and really most of the time we needed a pair of pliers.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#389Let 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…
Prediction: SPAs and GraphQL are quickly heading towards the last few bullet points.
As someone maintaining a SPA that uses GraphQL, they're not really comparable. Everyone and their dog has a SPA, while GraphQL has been somewhat restricted by the small number of React users who dared to install the first version of Relay.
GraphQL could wither like Backbone and Angular and nobody would really notice or care. An industry-wide shift away from SPAs would be something else entirely.
Re: Goodbye Microservices: From 100s of problem children to 1 superstar
#390Earlier quoted context omitted.
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.
Storytime?