i think everything is already covered with this video https://www.youtube.com/watch?v=y8OnoxKotPQ
Starting with microservices
21–30 of 139 posts
Re: Starting with microservices
#22noob
Re: Starting with microservices
#23I have done the full theme park ride on monolith->microservices->monolith. Both have ups and downs. The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol? We now have a "monolith" (proces…
Farming out libraries or subprojects to separate teams is an ok way to go as long as you don't mind a single language/build system. Its not as flexible but you maybe get some perf out of it.
You don't get the convenience of a single datastore with simple transactions but it sounds like you prefer the flexibility of services owning their own data.
As it turns out there's no silver bullet. Do what works for you.
Re: Starting with microservices
#24Do you know what kind of software has an absurd level of horizontal scalability by default? Web servers. The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this. There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an…
I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re already doing so by running multiple workers/threads in your application server. Spreading that to other machines is trivial. The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database,…
Totally.. and adding read replicas in the mix too.
Even rails allows you to stipulate the DB each model lives in, in a rather trivial manner.
Re: Starting with microservices
#25Do you know what kind of software has an absurd level of horizontal scalability by default? Web servers. The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this. There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an…
It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalable'. In other words, you could scale parts independently and shape your infrastructure more effectively for your workload. e.g. If your bottleneck is logins, you scale the LoginService and don't need extra copies of the AppointmentService running to keep up.
Re: Starting with microservices
#26TL;DR - don't. (which I agree with)
Re: Starting with microservices
#27Do you know what kind of software has an absurd level of horizontal scalability by default? Web servers. The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this. There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an…
I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re already doing so by running multiple workers/threads in your application server. Spreading that to other machines is trivial. The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database,…
Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion.
And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!).
If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic.
And since it's likely a nonlinear problem it's hard to map the problem-solution space, hard to get a good mental model for it, so we use the next best thing: stories. We have success stories and parables on what not to do. (And whole conferences dedicated to telling them :))
Re: Starting with microservices
#28Earlier quoted context omitted.
I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re already doing so by running multiple workers/threads in your application server. Spreading that to other machines is trivial. The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database,…
Totally.. and adding read replicas in the mix too. Even rails allows you to stipulate the DB each model lives in, in a rather trivial manner.
And there are DB proxies that can hide this complexity from the application (to a degree).
Re: Starting with microservices
#29Earlier quoted context omitted.
This is what I do in practice. I've seen it called a "distributed monolith". One of the good reasons to spend time with Erlang or Elixir is it'll force you to learn how to write your programs with a variety of actors. Actors are generally easy cut points for turning into microservices if necessary. As with many programming languages I appreciate not being forced to use that paradigm everywhere, but it's great to be f…
That's where a lot of the fun of Elixir comes from I think. It's viscerally satisfying to split off functionality into what almost feels like an independent machine that happens to be in the same codebase. It clicked in a way normal object oriented programming never did for me, I guess since it's not feasible to mint 10,000 genservers to use as more complicated structs.
Yeah.. rails hits this same nail with jobs.. I use jobs in a synch manner, and it's great. It's a rather functional way of working within an OO world.
Re: Starting with microservices
#30In my opinion implementing strong interfaces and good modularization is something, that we should talk about more, than doing Microservices. In the end it might be easy to rip of a Microservice, when needed, if the code is well structured.
Indeed, the principal seems to often be forgotten. The why of monolith vs citadel vs microservices is ignored by some people. This results in K8s-driven-development instead of microservices.
I love that sentence.