When microservices were new they brought a whole slew of new technologies and architecture patterns with them: SPAs, JWT authentication, micro frameworks, REST/Graphql, containerization. Things that solved problems people were having with the previous monolithic approach, all above the lack of maintainability and composability. So I see the term microservice today not as something that's measured in lines of code, but above all by embracing the new technology landscape that came from it.
Don't start with microservices – monoliths are your friend
61–70 of 468 posts
Re: Don't start with microservices – monoliths are your friend
#62> One or more (relational) databases, depending on whether you’re gonna go with single database per service or not This imho is where serious complications can come in. A single database for all services is a good trade off if you want the nice parts of microservice decoupling but not the headaches of a distributed system. Just perhaps don’t call it “microservices” to avoid having to deal with arguments from purists…
>nice parts of microservice decoupling
If you require microservices to enforce decoupling you're "doing it rong"
Re: Don't start with microservices – monoliths are your friend
#63I am just using services with my medium sized application. They are not "micro", but they separate the domains and different concerns pretty well. I have the deployment setup more or less like a monolith, but still having separation of concerns with my services. And stateless service runners.. Fair enough I have the state in a single (mirrored) database. But this works perfectly fine for the medium sized app. Not sur…
Service oriented architecture then...
Re: Don't start with microservices – monoliths are your friend
#64Just write it in Rails, if you ever reach Rails limits, it means you've made it :-)
Re: Don't start with microservices – monoliths are your friend
#65There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang ht…
> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…
no why?
The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs.
Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhere anyway no?
Deployment: Depending on anything you listed how do i do anything? Of course if have to define it but if you want a fancy example: k8s argocd canary deployments done. I literally set it up once.
security? Really? Please dont get this wrong but this feels to me like whataboutism but well here i go:
i implement security just the same way as i would in the monorepo. The thing/person/entity just has to look into more repositories ;)
It comes down do one sentence i think: State is not shared, state is communicated.
Re: Don't start with microservices – monoliths are your friend
#66Doesn’t this highly depend on your use case?
For example, right now I’m building a system that will take in a URL, crawls the webpage, and does some processing on the data. The whole process takes a good 10 seconds. I designed this as a micro service, simply because I know URLs will need to be queued up. Should this have been done as a monolith? Or am I right that micro services was actually the right approach?
Re: Don't start with microservices – monoliths are your friend
#67The only issue I have with microservices is when you're dealing with atomic things. Like in a monolith you'd probably just stick it all in a database transaction. But I can't find any good reads about how to deal with this in a distributed fashion. There's always caveats and ultimately the advice "just try not to do it" but at some point you will probably have an atomic action and you don't want to break your existing architecture.
Distributed transactions? Two stage commits? Just do it and rely on the fact you have 99.9% uptime and it's _probably_ not going to fail?
Anyone else dealt with this headache?
Re: Don't start with microservices – monoliths are your friend
#68All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no. Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code". Does it sometimes make sense to break some larger services up in smaller ones? Yes. Does it make sense to "factor out" e…
I've seen organizations that have hundreds of developers organized in 5-10 man teams, each managing their microservice. I think it tends to happen when a large organization decides to get down with the kids and start to do microservices.
Conway's law enters into it in a lot of ways. Because of the way the people are organized into tiny isolated teams, the code shares that shape too. There is an event horizon one team/service away, beyond which nobody knows what happens or who wrote the code.
What you get is that the services actually don't do that much, except take a request from one service, translate it to an internal format, perform some trivial operation, then translate it to another external format and pass it on to another service. It's a lot of code, but it's not a lot of logic. Add to that maintaining the test and prod environments as code, and suddenly it looks like this is a lot of work, but you've essentially gotten a hundred people to do work that three people could probably accomplish if it wasn't for this pathological misapplication of an architectural pattern.
Re: Don't start with microservices – monoliths are your friend
#69Earlier quoted context omitted.
> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…
no why? The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs. Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhe…
For monitoring I’d also say the alerting side of things can be done via the older monolith. That is, catch exceptions and log/re-raise them as “PdfServiceException”.
Re: Don't start with microservices – monoliths are your friend
#70Example of decoupling things in goblins framework (nodejs):
one domain give one package/module, domains are now dependencies
actors models can act as services, one actor in a domain is a service with an API communicating with other trought event loops or tcp/ip (microservice?)
we can develop and debug the whole system in a mono-repo <- the monolith is the repository of code.