Dare I suggest that it is possible that the nimble startup was moving quickly not necessarily because of tool choice, but because of the small team size and because the appropriate amount of complexity was introduced? And conversely the inflated team was slow exactly because it was inflated and complexity was introduced? This effect happens with or without bringing third-party or in-house tooling/frameworks into the equation, and is well known and well covered since Mythical Man Month.
And no, I don't see the point of rebuilding Kubernetes and Docker in-house and most critics also don't. What I'm saying that teams will be better of if they work towards not needing Docker or Kubernetes (or any NIH replacement) at all. But that requires challenging the assumption that software needs "something" like Docker or Kubernetes.
Sure, if there's a tool for X then by all means use it, but my point is more that not doing anything in-house can often lead to the same issues.
The speed difference boils down to flexibility and tool usage. In the startup, I could swiftly create a new service, harness Kubernetes for deployment, and seamlessly integrate it into the existing architecture. Data computation used tools like Airflow/BigQuery, storing results in production PostgreSQL.
In contrast, with a Golang monolith, service integration often involved complex, time-consuming conversations due to rigid NIH abstractions. And given the tendency of senior engineers to resist changes, progressing became challenging. A developer like me would be caught between resistant seniors and a product team demanding immediate feature release. Additionally, data processing often required extensive custom coding, slowing down operations. And if more than one machine was needed, it would mean a total overhaul and a long wait.
In comparison, a lean startup allowed me to use apt tools (like BigQuery), containerize it with Docker, and then let it be - without involving anyone senior. Moreover, in case of a new feature, we could simply replace the entire component instead of struggling with additions.
The agile startup emphasized less on seeking senior developers' approval for every change. In the monolithic Golang environment, senior devs often fixated on code quality without acknowledging that, in a microservices context, it's frequently more effective, faster, and simpler to reboot and rewrite parts instead of altering the existing solution. Hence, the intense focus on solution maintainability becomes less critical.
I think there's too many red flags there to chalk it up to a single problem: time-consuming conversations, rigid abstractions, resistance to changes, demanding PMs, total overhauls needed, more bureaucracy on change approval, you also complained about fixation on code quality.
Saying that it's all up to the one single difference even though there's so many ancillary issues screams of "I've found a silver bullet syndrome" to me.
And no, I don't see the point of rebuilding Kubernetes and Docker in-house and most critics also don't. What I'm saying that teams will be better of if they work towards not needing Docker or Kubernetes (or any NIH replacement) at all. But that requires challenging the assumption that software needs "something" like Docker or Kubernetes.
Sure, if there's a tool for X then by all means use it, but my point is more that not doing anything in-house can often lead to the same issues.