Some thoughts on microservices
filipnikolovski.com
Some thoughts on microservices
1–10 of 139 posts
Re: Some thoughts on microservices
#2I watch the other day, the Lex Fridman podcast with Kevin Systrom, founder of Instagram.
He talks about the scaling issue; they were using Django at that time and scale up to 50 millions users with a small team of developers.
I do not think a majority of companies have more than 50 millions users and absolutely need to go full microservices.
Re: Some thoughts on microservices
#3One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
Re: Some thoughts on microservices
#4One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
I like them for modularity, message queues and asynchronous events. But you are correct, esp. last one.
Re: Some thoughts on microservices
#5I watch the other day, the Lex Fridman podcast with Kevin Systrom, founder of Instagram. He talks about the scaling issue; they were using Django at that time and scale up to 50 millions users with a small team of developers. I do not think a majority of companies have more than 50 millions users and absolutely need to go full microservices. https://www.youtube.com/watch?v=3pvpNKUPbIY
Micro-services are meant to scale the number of developers not the number of users. As the article points out they are meant to address organizational issues and they do - at a significant technical cost.
Re: Some thoughts on microservices
#6Conways law is not about structuring... it's about domain knowledge.
ie. if you work alone on a problem, you can only solve for the issues you know.
Re: Some thoughts on microservices
#7I watch the other day, the Lex Fridman podcast with Kevin Systrom, founder of Instagram. He talks about the scaling issue; they were using Django at that time and scale up to 50 millions users with a small team of developers. I do not think a majority of companies have more than 50 millions users and absolutely need to go full microservices. https://www.youtube.com/watch?v=3pvpNKUPbIY
Micro-services are meant to scale the number of developers not the number of users. As the article points out they are meant to address organizational issues and they do - at a significant technical cost.
As I point out, they were a small team of developers before being bought by Facebook. And they still scale up to 50 million users.
Re: Some thoughts on microservices
#8I do not agree with many of your points.
I also agree with some of them.
Re: Some thoughts on microservices
#9One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.
To me microservices should not be an architecture.
You can have pieces of functionality in a monolith that make sense to scale independently, and those should not be micro, they should be meaningful pieces of functionality that justify the overhead of spinning them out.
In a way your comment reflects this, a lot of the places that justified microservices were at a scale where their "microservice" was serving more requests than the average company's entire codebase.
It's "big data" with 10 GBs of logs all over again.
Re: Some thoughts on microservices
#10Earlier quoted context omitted.
Micro-services are meant to scale the number of developers not the number of users. As the article points out they are meant to address organizational issues and they do - at a significant technical cost.
As I point out, they were a small team of developers before being bought by Facebook. And they still scale up to 50 million users.
Sorry, I misinterpreted what you originally wrote.