Starting with microservices
arnoldgalovics.com
Starting with microservices
1–10 of 139 posts
Re: Starting with microservices
#2I don't understand why people treat microservices or monoliths as either or. If I find my various projects using the same functionality over and over, then I'll split that off as a microservice to serve my monolith projects of various sizes.
It's like functions: don't turn code into a function until you need it in three different places.
Re: Starting with microservices
#3I don't understand why people treat microservices or monoliths as either or. If I find my various projects using the same functionality over and over, then I'll split that off as a microservice to serve my monolith projects of various sizes. It's like functions: don't turn code into a function until you need it in three different places.
I agree but the trend still seems to prefer one or the other and that's why it's so important to talk about the potential downsides instead of closing our eyes and saying everything is gonna be better if we do microservices.
Re: Starting with microservices
#4I don't understand why people treat microservices or monoliths as either or. If I find my various projects using the same functionality over and over, then I'll split that off as a microservice to serve my monolith projects of various sizes. It's like functions: don't turn code into a function until you need it in three different places.
Maybe it's just the activation energy. Until you have the setup for making a microservice, you're kinda limited to a monolith. Once you pay the setup cost though, making incrementally more services is trivial so you end up on the other end of the spectrum.
Re: Starting with microservices
#5In 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.
Re: Starting with microservices
#6In 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.
> In my opinion implementing strong interfaces and good modularization is something, that we should talk about more, than doing Microservices.
This is my position as well. Strong interfaces, good logical separation of function under the covers, etc. should allow splitting off things at whatever level of micro you prefer.
Re: Starting with microservices
#7Do 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 ergonomics change, not one of capability.
Re: Starting with microservices
#8In 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.
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 forced to do it for a while to learn how, so you can more comfortably adapt the paradigm elsewhere. My Go code is not 100% split into actors everywhere, but it definitely has actors embedded into it where useful, and even on my small team I can cite multiple cases where "actors" got pulled out into microservices. It wasn't "trivial", but it was relatively easy.
Re: Starting with microservices
#9Do 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 guess the idea is to split the workload into parts so if one part of the workload is proving to use more resources, it can then get a larger dedicated pool of resources.
Plus being able to choose different tech for different types of work, and also being able to split between teams when your org gets more vast.
Though I guess this is more about using services than micro services, per-say.
Re: Starting with microservices
#10I have a theory that auto-wired Dependency Injection in a single DI container is partly to blame for monolith spaghetti. Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult.
I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments, orders, shipping, customers etc) before needing to break it into distributed micro-services.
Note: I quite like Dependency Injection, I just think the 1 giant bag of dependencies can lead to complexity at scale.