3 ms·

Counter considerations would be: What is the delta between out of box solutions and current solutions? What is the cost of the migration? For what period will t

Counter considerations would be: What is the delta between out of box solutions and current solutions? What is the cost of the migration? For what period will two services be supported simultaneously? Will development effort continue on the previous service while the new one is created? Will the new service successfully solve problems the old one didn't? What happens when Kubernetes is insufficient for a task or has a critical bug that only appears at scale? How will people be onboarded into the new system? Will the team handling how services run perform the migration or will the teams who own services perform the migration? How much time should be spent experimenting with new things compared to fixing bugs/adding requested features? > in some ways it seems like it's just shifting the monolith technical debt into an internal Atlas platform team's technical debt. This is a key insight into the monolith problem. How does a monolith become poor and unmaintainable? A monolith becomes poor quality and unmaintainable when there is no entity enforcing architectural simplicity. It becomes unmaintainable when there is no team focusing solely on how the monolith functions. It becomes unmaintainable if there is no entity capable of saying "no" to a product engineer. A monolith in a company with weak leadership is a tragedy of the commons where everyone takes from the commons by adding complexity and there is no governing entity to ensure that the commons remains viable. The exact statement you made is the key strength of this approach. Where there was a vacuum of responsibility before (monolith technical debt), a team has been created with direct responsibility and authority creating a governing force over that technical debt/overall complexity and therefore an entity directly responsible for improving it. This is a key first step. Atlas appears to be a compromise solution rather than an ideal end state.

spondyl 6y ago
> A monolith becomes poor quality and unmaintainable when there is no entity enforcing architectural simplicity. Having worked in a company where no single team "owned" the monolith, the term "communally owned" tended to come up. It was generally understood within the platform teams that if everyone owns it then in reality, no one owns it :)
- peterhunt 6y ago
  yes, this is why you need a dedicated team who owns the quality and scalability of the monolith once you reach a certain size. many companies call this team "product infrastructure".
- hayst4ck 6y ago
  Exactly. The greater problem is that the ways to fail monolith specific work vastly outnumbers the way to succeed. Furthermore, the primary work involved is months to years worth of horrible unattractive refactoring. Then this is compounded by it being very hard to measure success. So you run into a situation that makes principal engineers run or look for the door. Rather than working on an actually hard problem, they would rather pad their resumes with increasingly complex novel work, further detracting from the commons. So not only is it an un-owned common, but senior engineer alignment is directly against work involving the root problem because no one in their right mind would be responsible or accountable for something with so few avenues to success. Not only is senior engineering alignment individually against being directly responsible for the monolith, but managerial leadership is as well. You have infrastructure with infrastructure concerns, and product worried about shipping product, and then you have to ask where this monolith responsible team is. Pushing code, monitoring, capacity management, oncall, etc. are all traditionally under the infra umbrella. Business logic is traditionally under the product umbrella. So who takes responsibility for the monolith, the chief repository of business logic? A monolith is a marriage between the two entities. Each individual product team doesn't want to do monolith work, because it makes it harder to ship the features they promised. Infra doesn't want to do monolith work because it is business logic code that needs to be refactored. So no infra team and no product team will directly feel responsible. Senior managerial leadership is at the mercy of senior engineering leadership, and therefore also cannot claim responsibility for the monolith. If you travel up the management hierarchy, that leaves roughly 4 people capable of doing anything about this most critical problem. The CEO, who has ultimate responsibility for all problems, the VP of infra, who could choose to claim responsibility for this area, the VP of product, who could choose to claim responsibility for this area, or the CTO who is the most directly responsible person for solving this problem as the de facto mediator of product and infra concerns and responsibilities. The answer is probably inventing a 3rd VP responsible for the area between product and infra and giving them proper authority.

spondyl 6y ago

> A monolith becomes poor quality and unmaintainable when there is no entity enforcing architectural simplicity. Having worked in a company where no single team "owned" the monolith, the term "communally owned" tended to come up. It was generally understood within the platform teams that if everyone owns it then in reality, no one owns it :)

peterhunt 6y ago
yes, this is why you need a dedicated team who owns the quality and scalability of the monolith once you reach a certain size. many companies call this team "product infrastructure".
hayst4ck 6y ago
Exactly. The greater problem is that the ways to fail monolith specific work vastly outnumbers the way to succeed. Furthermore, the primary work involved is months to years worth of horrible unattractive refactoring. Then this is compounded by it being very hard to measure success. So you run into a situation that makes principal engineers run or look for the door. Rather than working on an actually hard problem, they would rather pad their resumes with increasingly complex novel work, further detracting from the commons. So not only is it an un-owned common, but senior engineer alignment is directly against work involving the root problem because no one in their right mind would be responsible or accountable for something with so few avenues to success. Not only is senior engineering alignment individually against being directly responsible for the monolith, but managerial leadership is as well. You have infrastructure with infrastructure concerns, and product worried about shipping product, and then you have to ask where this monolith responsible team is. Pushing code, monitoring, capacity management, oncall, etc. are all traditionally under the infra umbrella. Business logic is traditionally under the product umbrella. So who takes responsibility for the monolith, the chief repository of business logic? A monolith is a marriage between the two entities. Each individual product team doesn't want to do monolith work, because it makes it harder to ship the features they promised. Infra doesn't want to do monolith work because it is business logic code that needs to be refactored. So no infra team and no product team will directly feel responsible. Senior managerial leadership is at the mercy of senior engineering leadership, and therefore also cannot claim responsibility for the monolith. If you travel up the management hierarchy, that leaves roughly 4 people capable of doing anything about this most critical problem. The CEO, who has ultimate responsibility for all problems, the VP of infra, who could choose to claim responsibility for this area, the VP of product, who could choose to claim responsibility for this area, or the CTO who is the most directly responsible person for solving this problem as the de facto mediator of product and infra concerns and responsibilities. The answer is probably inventing a 3rd VP responsible for the area between product and infra and giving them proper authority.