The point about "do one thing" is that it takes a lot of rewrites to work out what one thing to do, and where the boundaries are.
Unix tools have developed in tandem in the unix ecosystem over decades of rewrites. They rubbed the rough edges off of each other.
The major failing of most "systems design", architecture and companies is a reluctance to replace what is there with something better. No one likes a rewrite.
And this affects microservices too. Once a microservice exists it's boundaries are defined. sure you can rewrite it to be more peformant but you cannot chnage its interfaces or it's scope - something is depending on that.
The ability to reform those interfaces is what makes it possible to grind down and find the one thing to do well.
And that takes lucking into the right fundamentals and being willing and able to make large scale changes.
"Move fast and break things" might actually be excellent advice
Unix tools have developed in tandem in the unix ecosystem over decades of rewrites. They rubbed the rough edges off of each other.
The major failing of most "systems design", architecture and companies is a reluctance to replace what is there with something better. No one likes a rewrite.
And this affects microservices too. Once a microservice exists it's boundaries are defined. sure you can rewrite it to be more peformant but you cannot chnage its interfaces or it's scope - something is depending on that.
The ability to reform those interfaces is what makes it possible to grind down and find the one thing to do well.
And that takes lucking into the right fundamentals and being willing and able to make large scale changes.
"Move fast and break things" might actually be excellent advice