The adoption of Kotlin at Zalando
Recently, we moved Kotlin from TRIAL to ADOPT. With this change we are doubling down on the support of Kotlin as the 3rd JVM language next to Java and Scala. This is the result of increased adoption within the company (100+ new applications were written in Kotlin in a year), positive feedback from engineers starting to use it, as well as creation of guidelines, coding standards, reference projects, and service templates by the Zalando Kotlin Guild.
The experience that our Engineering Community gained over the recent years with Kotlin matches the developer stories of other companies. A nice collection of success stories can be found on the Android blog. Kotlin allows writing more succinct code with fewer pitfalls compared to Java and comes with a lot of useful features and libraries (e.g. data classes, null safety) that Java does not (yet) have as part of its standard library. This is probably also a reason why it is more wanted and less dreaded than Java and Scala in the 2020 Stackoverflow insights. Additionally, type inference, read only collections as well as the rich support for functional programming in the standard libraries were among the things our developers see as benefits compared to Java.
The Kotlin Guild
The Kotlin Guild was founded with around 10 core members who want to help the language grow in Zalando. Moving the language to ADOPT in the latest Tech Radar Update was a central milestone in that effort, as the ADOPT status comes with support from central infrastructure teams and the created documentation as well as templates, which help to promote a standardized tech stack and make bootstrapping new services easier. Due to being driven by our language guild, the whole process was kept transparent and open for contributions from the Engineering Community.
As a preparation for wider adoption of Kotlin, we collected internal good practices as well as the definition of tools and libraries for the development of RESTful backend services and Android apps with Kotlin that are recommended as default choices. For additional input we looked at how frequently things are used within the company, sat together with experts on specific topics, consulted external sources, and asked the whole Engineering Community to review final recommendations via a survey. Overall, we made sure that our recommendations support a positive developer experience and fit the need of most services, which are not directly serving customer traffic.
Looking forward the Kotlin Guild will continue to foster knowledge exchange as well as community building for its 250+ members. We also plan to cover more use cases with our documentation, like pure functional services using Arrow and will make sure we stay up to date with new development in the Kotlin space. Next to that, the members support each other with technical issues and regular talks are hosted.
How we build Backend Services at Zalando
Our internal developer tooling allows to initialize a repository from a template project. Those come with out-of-the box configuration and integrations which teams can then adapt to their needs. As an added benefit, they nudge teams towards higher consistency across different services and departments.
All APIs are defined in the OpenAPI format using Swagger. This allows our API portal to list all available APIs in one place along with their API linting results via Zally. API linting can also be required to pass for MUST validations on every build. Many of our teams follow the API first principle throughout service development.
Given that most services are deployed in Kubernetes, we consider Skipper filters the best way to handle Authentication and Authorization. This can either be achieved in Skipper directly, via Route Groups or Fabric Gateway. Skipper is designed to handle a large number of requests and is less likely to be misconfigured than for example Spring security.
Many JVM based Web services in Zalando are built using Spring Boot and we believe that this is also a good option when using Kotlin. This choice is mainly driven by the large adoption, but also because Spring integrates really well with Kotlin, is compatible with multiple application servers, and supports reactive programming via WebFlux. We do also see growing adoption of Ktor and predict it to gain popularity within Zalando in the future, possibly even in conjunction with GraalVM.
Libraries we use for Backend Services
As build system, we prefer Gradle over Maven because of its great customizability and build performance. Gradle is also used to compile the language itself and is used by many major framework projects like Spring Boot. On top of that, the build configuration scripts can be written in Kotlin.
Linting is a very good practice to keep the style consistent in a codebase and to settle disputes over correct indentation. Ktlint is our tool of choice as it follows the official coding conventions, is easy to run in Gradle, and does not enforce too many rules such that it seamlessly integrates into the software development process.
To access relational databases, we see spring-boot-starter-data-jpa as a solid choice in case you like to use ORM, but advise considering jOOQ in cases where database transactions become more complex. It is also worth mentioning that jOOQ can be used together with other clients, as it can be used on top of JPA. jOOQ also has the added benefit that it supports database specifics like Postgres JSON types.
Zalando is investing into traceability with Open Tracing and we recommend opentracing-toolbox which eases integration of tracers, particularly in Spring Boot projects. Tracing allows linking requests across services and is also great to set up automated alerting.
We hope this gives you some idea why Kotlin is gaining popularity for backend development within Zalando. This is just the beginning of the journey - and you can become part of it!