4 ms·

Fallacy #4: Simple for Engineers "leads to ‘not my problem’ syndrome.” I've found the exact opposite happens with microservices. With well-defined interfaces

Fallacy #4: Simple for Engineers "leads to ‘not my problem’ syndrome.” I've found the exact opposite happens with microservices. With well-defined interfaces and APIs, I know exactly where things are breaking and can pinpoint the service and code more quickly.

amelius 10y ago
How is that contradicting what the article says?
sp332 10y ago
Right, but the problem is often pinpointed to someone else's team, and then you have to go communicate with them and convince them to make it a priority.
- coldcode 10y ago
  At my company this is the most crucial problem, people with different VP's priority than your VP's priority causes arguments that never end with anything being fixed. So you have to work around the problem which leads to hack upon hack.
  - dasil003 10y ago
    At this scale though, you need service isolation just to operate with any efficacy. Think how much worse this case would be if those two rank and file developers under distant VP hierarchies were deploying the same codebase to the same production machines. Basically it would be impossible to ship without independent QA and Ops arms with heavy policy on what is required to deploy anything. Now you're moving at about 1% of the speed of a Facebook or Amazon.
- clintonb 10y ago
  Solving the problem depends on the organization. At edX, various teams own certain services; but, everyone is encouraged to contribute where needed. My team owns the ecommerce services. If the teaching-and-learning team wants to make an update, all they need to do is touch base with us in the design phase and request a code review once the work is done.
aurelium 10y ago
+1 this sentiment. I'm currently working in a large monolith-based environment and I've never seen a tragedy of the commons effect degenerate an environment to a larger degree. Poorly considered features and changes, horribly written and slow tests, bad modularity, and a total inconsideration for the long term sustainability of the codebase are all par for the course. Good CI configuration, Linters, and lots of RuboCop rules help a little, but only go so far as they can't pick out code that's "only" subjectively bad. The basic problem is a total lack of any individual responsibility. Just like how you'll have a minimal effect if you only throw one plastic bottle into the ocean, introducing poor code quality code into the large repository isn't really your problem, it's everybody's problem, and nothing you can do will ever move the needle in one direction by very much. Going too far the other way into microservices is probably also bad, but given a choice between a company with a monolith and a company practicing microservices in moderation, I'd go with the latter everytime.

amelius 10y ago

How is that contradicting what the article says?

sp332 10y ago

Right, but the problem is often pinpointed to someone else's team, and then you have to go communicate with them and convince them to make it a priority.

coldcode 10y ago
At my company this is the most crucial problem, people with different VP's priority than your VP's priority causes arguments that never end with anything being fixed. So you have to work around the problem which leads to hack upon hack.
- dasil003 10y ago
  At this scale though, you need service isolation just to operate with any efficacy. Think how much worse this case would be if those two rank and file developers under distant VP hierarchies were deploying the same codebase to the same production machines. Basically it would be impossible to ship without independent QA and Ops arms with heavy policy on what is required to deploy anything. Now you're moving at about 1% of the speed of a Facebook or Amazon.
clintonb 10y ago
Solving the problem depends on the organization. At edX, various teams own certain services; but, everyone is encouraged to contribute where needed. My team owns the ecommerce services. If the teaching-and-learning team wants to make an update, all they need to do is touch base with us in the design phase and request a code review once the work is done.

aurelium 10y ago

+1 this sentiment. I'm currently working in a large monolith-based environment and I've never seen a tragedy of the commons effect degenerate an environment to a larger degree. Poorly considered features and changes, horribly written and slow tests, bad modularity, and a total inconsideration for the long term sustainability of the codebase are all par for the course. Good CI configuration, Linters, and lots of RuboCop rules help a little, but only go so far as they can't pick out code that's "only" subjectively bad. The basic problem is a total lack of any individual responsibility. Just like how you'll have a minimal effect if you only throw one plastic bottle into the ocean, introducing poor code quality code into the large repository isn't really your problem, it's everybody's problem, and nothing you can do will ever move the needle in one direction by very much. Going too far the other way into microservices is probably also bad, but given a choice between a company with a monolith and a company practicing microservices in moderation, I'd go with the latter everytime.