>> The rise of microservices, an approach to development in which you structure your software into smaller individual service-oriented units. Each microservice then runs its own process and they communicate with each other through APIs. This software development approach is known to have four primary benefits: agility, efficiency, resiliency, and revenue
Off-topic, but what?! I understand there is a lot of hype about "microservices" right now but I don't think the upsides of the propagated approach are as clear-cut or uncontroversial as the post makes them out to be.
The article defines "microservices" as the act of splitting up an application into many small, individual programms that talk to each other via RPCs.
How does structuring my code into lots of small programs improve revenue of all things? Or are you talking about the revenue of code repository hosting providers and "microservices" consultants?
Also, this approach surely does not improve resiliency and efficiency per se. It actually does the opposite in my opinion. All the additional RPCs are only adding _more_ points of failure (unreliable IPC) and overhead as compared to straight in-process method calls.
And who's saying that "a microservices architecture" improves a dev teams "agility"? How does one even measure agility? The article is stating this like it's an established fact. In my [anecdotal] experience, spreading an application out over lots of individual repositories and binaries makes it harder to work with, not easier.
>> With such tangible business benefits, it is no wonder why Google, Amazon, and Facebook have been using microservice development practices for over a decade.
The fact is that these are a massive software companies with thousands of engineers. Naturally they run an incredible amount of internal software and services. I think this is often conflated with the idea that splitting up a given application into smaller and smaller parts to produce more individual "services" automatically makes it better somehow.
Don't get me wrong. I'm all for having a clear seperation of concerns and well defined interfaces between individual modules. Doing that has been best practice since I started to code. But the latest "let's split our codebase up into 20 different binaries and repos, because microservices" fad is just bonkers.
It's just a popular reason you might need a lot more repos than you once did. Insert your own reason, be it organizing docs, static sites, more skunk works, etc. I doubt the point of the post was to advocate microservices, so making the discussion here about it is distracting.
What's interesting is that FB and Google both use a single large repository. Not sure about Amazon. In fact, I don't know that I've ever read a detailed article about how Amazon handles things like source control internally.
They weren't really making a claim about programming practices, more trying to pump up the idea that you need a lot of repos.
I don't agree with their stance on microservices, but do find that I need a lot of private repos. In my case I just like to create a bunch of hobby projects.
Off-topic, but what?! I understand there is a lot of hype about "microservices" right now but I don't think the upsides of the propagated approach are as clear-cut or uncontroversial as the post makes them out to be.
The article defines "microservices" as the act of splitting up an application into many small, individual programms that talk to each other via RPCs.
How does structuring my code into lots of small programs improve revenue of all things? Or are you talking about the revenue of code repository hosting providers and "microservices" consultants?
Also, this approach surely does not improve resiliency and efficiency per se. It actually does the opposite in my opinion. All the additional RPCs are only adding _more_ points of failure (unreliable IPC) and overhead as compared to straight in-process method calls.
And who's saying that "a microservices architecture" improves a dev teams "agility"? How does one even measure agility? The article is stating this like it's an established fact. In my [anecdotal] experience, spreading an application out over lots of individual repositories and binaries makes it harder to work with, not easier.
>> With such tangible business benefits, it is no wonder why Google, Amazon, and Facebook have been using microservice development practices for over a decade.
The fact is that these are a massive software companies with thousands of engineers. Naturally they run an incredible amount of internal software and services. I think this is often conflated with the idea that splitting up a given application into smaller and smaller parts to produce more individual "services" automatically makes it better somehow.
Don't get me wrong. I'm all for having a clear seperation of concerns and well defined interfaces between individual modules. Doing that has been best practice since I started to code. But the latest "let's split our codebase up into 20 different binaries and repos, because microservices" fad is just bonkers.