Our journey from a Python monolith to a managed platform
So what&#x27;s the end game here, is Dropbox going to keep building out an internal Kubernetes-like platform with Atlas, or do they plan to eventually just move to k8s?  I noticed this line in particular:<p>&quot;We evaluated using off-the-shelf solutions to run the platform. But in order to de-risk our migration and ensure low engineering costs, it made sense for us to continue hosting services on the same deployment orchestration platform used by the rest of Dropbox.&quot;<p>It sounds like they acknowledge they&#x27;re reinventing a lot of stuff but for now are sticking to their internal platform.  Perhaps Atlas is a half-step then to get teams used to owning and running their code as isolated services. But everything I read that they built in Atlas--isolated orchestrated services, gRPC load balancing, canary deployments, horizontal scaling, etc.--are bog standard features of Kubernetes today.  I&#x27;d be very leery of maintaining a bespoke Kubernetes-like platform in 2021 and beyond--in some ways it seems like it&#x27;s just shifting the monolith technical debt into an internal Atlas platform team&#x27;s technical debt.  What&#x27;s the plan to get rid of that debt for good I wonder?<p>This hurdle shows there&#x27;s already some cracks in the idea of long-term Atlas too:<p>&quot;While splitting up Metaserver had wins in production, it was infeasible to spin up 200+ Python processes in our integration testing framework. We decided to merge the processes back into a monolith for local development and testing purposes. We also built heavy integration with our Bazel rules, so that the merging happens behind the scene and developers can reference Atlasservlets as regular services.&quot;<p>If I read that right does it really mean the first time a developer&#x27;s code is run like it will run in production is when it goes out to canary deployment?  I.e. integration tests are done in a local monolith instead of setting up a mini-prod cluster.  That seems a bit nerve-racking as a dev to have no way to really test the service until bits are hitting user requests.  In the k8s world a ton of work has been put into tooling and processes to make setting up local clusters easily.  It&#x27;s a shame to not have something similar for Atlas.