Microservices Are Something You Grow Into, Not Begin With
nickjanetakis.com
Microservices Are Something You Grow Into, Not Begin With
1–10 of 159 posts
Re: Microservices Are Something You Grow Into, Not Begin With
#2Why not? I mean we don't use micro-services for what it is supposed to do. The application would perfectly be a monolith. We do it, just because it lets us experiment newer technologies in not-so-important services in a smaller scale without undergoing major re-work since when the change is big, everyone in management layer understandably becomes conservative.
Re: Microservices Are Something You Grow Into, Not Begin With
#3What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
Re: Microservices Are Something You Grow Into, Not Begin With
#4What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.
Re: Microservices Are Something You Grow Into, Not Begin With
#5I grew out of microservices because it felt like I was doing the same boilerplate REST service over and over.
So I made a modular REST API service that could load plugins. The plugins can contain anything from simple endpoints to database schemas with sqlalchemy. All this is loaded into the main app at runtime.
So the main app can handle authentication against LDAP for example while all the various deployed microservices can have their own roles.
Re: Microservices Are Something You Grow Into, Not Begin With
#6What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
Though keep in mind that in microservice world suddenly you have dozen of problems you would never face in monolith world. You are forced to implement a good orchestration, deployment, segregate data between services and other stuff. It's all fun, but takes time to dive into that and build the right process. For sure it is nice and sound once it's built, but you might simply lose track of your primary product if you're solo project dev :)
Re: Microservices Are Something You Grow Into, Not Begin With
#7What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
What I love about monolith is coherence and forcing you to do things well from the beginning. Microservice mesh tend to become horrible to maintain after a few years when no one really measure which components will be impacted by a single change. On the opposite, change one small 50 line function and your IDE will happily show you all the calls to that specific function.
So the consensus is to do things well from the start. IMHO both have their merits but strongly depend on the usecase. There is no one size fits all. A lot of thought has to go into both options to make them really effective. Otherwise it's just garbage in garbage out.
Re: Microservices Are Something You Grow Into, Not Begin With
#8Why not? I mean we don't use micro-services for what it is supposed to do. The application would perfectly be a monolith. We do it, just because it lets us experiment newer technologies in not-so-important services in a smaller scale without undergoing major re-work since when the change is big, everyone in management layer understandably becomes conservative.
Sounds like resume-driven-development.
I worked at a company with this disease before. The system was an abomination of vastly different technologies over the years stitched together loosely.
Development was slowed substantially by having such a mess and the company couldn't move fast enough to compete so the startup died. Usually tech isn't the reason for a startup's death. In this case, it was.
Re: Microservices Are Something You Grow Into, Not Begin With
#9What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!
And then another downstream microservice fails when you deploy your change into a running environment, because you lack the integration testing capabilities of a monolith.
It's true you achieve higher isolation with microservices, but you also lose points in other areas. And you can get lost in your haystack of microservices just as easily as in your typical monolith ;)
Re: Microservices Are Something You Grow Into, Not Begin With
#10The argument here is that microservices are another level of code reuse, with their own encapsulation.
But microservices are also about coupling: just have a self-contained service that does one thing.