Reading this makes me feel a little like I woke up in 1990.
>> Distributed systems are harder to program, since remote calls are slow and are always at risk of failure.
This is a true statement, but it's hardly the point on which current architecture choices turn. Distributed systems are the norm now. Almost everyone is working on one, even if they don't think of it that way (and I bet they don't). There are still simple, single-process programs that are relevant to users and the people working on them, but those aren't the domains in which this microservices debate is supposed to be taking place.
Is it relevant to evaluate "microservices" vs. a "monolithic architecture" based on the costs of traversing the network stack? Back when we were thinking about breaking up our C and C++ programs into processes using RPC as glue this was something we worried a lot about, but that is because in many cases having everything in a single process was still a credible alternative. Few people are wrestling with this choice today.
The last site I worked on consisted of nginx, elasticsearch, logstash, kibana, postgresql, celery, redis, and a bunch of custom python, java, and javascript code. It could run on one server or (as it did in production) twelve. Almost all of those pieces ran in separate processes, communicated over the network using mostly standard protocols, and did one specific thing. Were these microservices?
I feel like microservices as a thing is one of the least meaningful tech fads I have seen. Minimality and cohesiveness aren't surprising new challenges. They were desirable concepts of C++ class libraries two decades ago. An implementation of a service should always be both minimal and cohesive, and it should be complete. It should be as small as possible. Whether that is "micro" or not is entirely too subjective for me.
The other trade-offs mentioned, consistency and complexity, are not much more relevant to the big question the author is trying to convince us to ask. Consistency is a property of a view of state, but the article is about distributing code (otherwise why care about module boundaries and deployment?), not distributing state. Complexity is always a a key trade-off, but the complexity of distributed code is table stakes in the world we actually work in.
Things that don't need any synchronization or interesting state can of course easily go into microservices. This does not mean that application state should be stored in a concurrent model unless you have to.
My point was that most people don't consider the fact that calling MySQL or the same is a remote call and is just as likely to fail. Of course there are ways to avoid that, but most people don't think in those terms.
>> Distributed systems are harder to program, since remote calls are slow and are always at risk of failure.
This is a true statement, but it's hardly the point on which current architecture choices turn. Distributed systems are the norm now. Almost everyone is working on one, even if they don't think of it that way (and I bet they don't). There are still simple, single-process programs that are relevant to users and the people working on them, but those aren't the domains in which this microservices debate is supposed to be taking place.
Is it relevant to evaluate "microservices" vs. a "monolithic architecture" based on the costs of traversing the network stack? Back when we were thinking about breaking up our C and C++ programs into processes using RPC as glue this was something we worried a lot about, but that is because in many cases having everything in a single process was still a credible alternative. Few people are wrestling with this choice today.
The last site I worked on consisted of nginx, elasticsearch, logstash, kibana, postgresql, celery, redis, and a bunch of custom python, java, and javascript code. It could run on one server or (as it did in production) twelve. Almost all of those pieces ran in separate processes, communicated over the network using mostly standard protocols, and did one specific thing. Were these microservices?
I feel like microservices as a thing is one of the least meaningful tech fads I have seen. Minimality and cohesiveness aren't surprising new challenges. They were desirable concepts of C++ class libraries two decades ago. An implementation of a service should always be both minimal and cohesive, and it should be complete. It should be as small as possible. Whether that is "micro" or not is entirely too subjective for me.
The other trade-offs mentioned, consistency and complexity, are not much more relevant to the big question the author is trying to convince us to ask. Consistency is a property of a view of state, but the article is about distributing code (otherwise why care about module boundaries and deployment?), not distributing state. Complexity is always a a key trade-off, but the complexity of distributed code is table stakes in the world we actually work in.