I wonder what the rationale behind AGPL is? Prevents it from being used for commercial SaaS
That is usually the rationale behind such licenses, yes.
Make microservices look like monoliths
81–90 of 106 posts
Re: Make microservices look like monoliths
#82My goto for this kind of task is moleculer: https://moleculer.services/
Fast, battle tested, vue2-like approach, great documentation, good community. The automatic indipendent-scalability as an option is usually the main selling point of these solutions, but honestly I think the real pro is the "composition" approach, which is essential if you want to keep a clean and well-organized codebase. On this regard, I found moleculer pretty great even for large teams.
Re: Make microservices look like monoliths
#83So you are trying to build Erlang without Erlang and OTP. Nice try :) You are maybe 5% there. How about the rest? Error handling, handling network issues, latency, partitions, deployments, scaling etc... I would also argue that because of the async calls (NodeJS is single-threaded, right?) you can easily run into weird and unexpected issues where two sequential service calls return out of order (which is impossible i…
That was my thought too, this has been done many times before; I'd like projects like this to show their homework and prove they've tried e.g. erlang, scala, etc for the same thing, the pros and cons, the dealbreakers (and there won't be many dealbreakers), and why building a new tool is worth the effort.
Re: Make microservices look like monoliths
#84Earlier quoted context omitted.
Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.
Most (successful) paths lead to balkanization. Just one acquisition can do it, much less 2 or N more. And the pace of these changes can outpace your ability to respond to it, which makes fighting it a losing battle.
That's a "nice to have" problem down the line. What I've seen is the insanity of microservices being adopted by one-pizza-team startups.
Re: Make microservices look like monoliths
#85Earlier quoted context omitted.
Microservices don't solve the tight coupling problem. Rather, they make dealing with it even more painful because rather than updating assumptions across modules, you update them across different units of deployment. This leads to ossification because it is even more difficult to fix bad architecture.
I never claimed they did, I said if your code is SOLID then it doesn’t really matter if it’s a microservice or not, it will likely be useful up to the point where scaling/organizational/too many cooks/long deploy/spof problems start to crop up.
Not sure this holds water. Which SOLID principle, or combination, solves the problem of building a system where a request traverses a boundary that is not problematic when executed locally, but introduces too much latency when you put a new network call behind an interface?
From what I can see, SOLID lets you split the monolith, as long as you happen to have interface segregation on the right seams. It says nothing about the operational properties of the service once split, which is by far the bigger problem, and depends on the non-functional properties of the code using the interfaces. Unless you already know you are headed for a microservice split, you're unlikely to have designed with that in mind.
Re: Make microservices look like monoliths
#86It makes no sense. Why not just create modular monolith?
This is a way to modularise a monolith. It just happens to also be a way to allow it to build out to a distributed deployment.
I hesitate to say "microservices" because I strongly suspect that the 95th-percentile use case will see all the parts strongly coupled and deployed as a single commonly-versioned blob. Not saying that's a bad thing necessarily, but if one of the benefits of microservices is loose coupling, it's not going to encourage a good microservice architecture.
Re: Make microservices look like monoliths
#87Why on earth would you use javascript for that? There are way better alternatives out there like Go, Erlang, Kotlin, or any other of the typical backend languages. Is it too much to ask for frontend devs to learn a new language?
Re: Make microservices look like monoliths
#88Why on earth would you use javascript for that? There are way better alternatives out there like Go, Erlang, Kotlin, or any other of the typical backend languages. Is it too much to ask for frontend devs to learn a new language?
Works great for applications where you spend most of the time waiting for a database.
The dynamic type system makes it easier to write testable code with less abstraction overhead.
Faster to train up junior devs.
That said, you * must * set up the codebase with appropriate guard rails or bad things can happen.
Re: Make microservices look like monoliths
#89Earlier quoted context omitted.
I haven't heard of any, the classic 'allowed languages' pages of tech companies come to mind. "You build it you run it", until the OCaml guy quits and now you need to support OCaml.
I do recall speaking to people at a betting company many moons ago who tried to recruit me with the claim they were so open with microservices that they had a key system written in Erlang that only one engineer in the company understood. I politely explained my position on why that seemed suboptimal.
That's good, when I had to consume their API it was closer to zero engineers who understood it.
Re: Make microservices look like monoliths
#90Earlier quoted context omitted.
Because all these idiots who pitched microservices super hard need to undo the mess they've created while self promoting themselves into new thought leadership roles.
Yeah, I was just talking to the CEO of a startup that I built the tech for, and still have a small equity stake in. They formed a partnership with some dev shop that's going to rebuild everything that I made (that's working great and scales well). I asked her why, and she said "because they say that doing microsevices on Azure is better architecture". There goes that bit of equity, I guess. /shrug
That's terrible, so sorry