We started our coding language selection by coming up with requirements for how we wanted our services to look and operate with each other. Given these characteristics, the question for us was not whether we should pursue one language but which language we should pursue. Allows engineers to change teams with minimal friction, which promotes collaboration.Allows us to build common libraries that are tuned to our environments, with defaults chosen to work best at our size and continued growth.Helps focus our teams and promotes sharing development best practices across the whole engineering organization.There are a lot of possibilities for building server software, but for a number of reasons we only wanted to use one language. However, we needed to make some changes to handle its growing pains. After surveying a number of different languages, we chose Kotlin for its rich ecosystem, interoperability with Java, and developer friendliness. Finding a tech stack that would support this effort was the first step in the process. We needed to break parts off of our monolith, allowing our systems to scale better, and decide how we wanted our new services to look and behave. On top of that, our monolith was built on old versions of Python 2 and Django, which were rapidly entering end-of-life for security support. Bisecting bad deploys (finding out which commit or commits were causing issues) got harder and longer due to the number of commits each deploy had. Under our legacy system, the number of nodes that needed to be updated added significant time to releases. This new platform would need to support our future growth and enable our team to build using better patterns going forward. When DoorDash approached the limits of what our Django-based monolithic codebase could support, we needed to design a new stack that would provide a strong foundation for our logistics services.
0 kommentar(er)
