Clojure in Berlin: Zalando
Using Clojure to power a fashion platform
by Jon Pither
This post is part of our Clojure In series, taking an in depth look at companies that have adopted Clojure from across Europe. In this article we look at Zalando, a company building a fashion platform.
A growing fashion company
Zalando is Europe's leading online platform for fashion. It originated in 2008 as an online shoes retailer and has since expanded into 15 markets across Europe.
They now have over 11,000 employees with 1600 working in tech. The website has over 160 million visits per month (~65% mobile) with 19 million active customers. The company made over 3 billion EUR in net sales in 2015.
Their technology HQ is in Berlin and they have offices in other parts of Germany, Helsinki and Dublin.
I caught up with software engineer Dmitrii Balakhonskii to learn more.
Jon: Could you give me some background on the tech at Zalando?
Dmitrii: In the beginning there was a uniform monolithic technology stack; mostly Java applications running in Tomcat clusters.
There was a strict policy on choosing technologies and so developers were restricted; not able to choose the technologies they'd love to work with. As the tech team grew the delivery speed was slowing down. Also there were not as many candidates applying and a lack of excitement about what we were doing.
Jon: What changed?
Dmitrii: The idea came to use a totally new approach to managing developers: what we call Radical Agility. In March 2015 the teams became autonomous teams and treated as first class citizens. The management team defined what to expect and the team decided on how to deliver. The teams could decide which technologies to use.
The overall tech team became more diverse, using Scala, Clojure, and Go in some teams. This diversity made the jobs of the developers more interesting, fun and inspiring.
Jon: How do you co-ordinate across teams?
Dmitrii: We have common standards; everyone builds Microservices using REST API-first. First a team writes a description of an API then publishes it and aligns with the other teams when they implement.
Jon: What is the mix of technologies?
Dmitrii: There is more Scala used and the majority is still doing Java. We have around 10 teams using Clojure. As a company we are mostly JVM based.
Jon: How did Clojure get started at Zalando?
Dmitrii: At one stage we decided to start using AWS. To provide all teams with a uniform approach a special Platform team was organised.
They built a middleware product; an abstraction layer on top of the cloud written in Clojure called STUPS. Nearly everyone who deploys into the cloud now uses STUPS.
Tobias Sarnowski originally introduced Clojure. People saw products successfully built using Clojure and followed suit, embracing the language.
Jon: What do you yourself work on?
Dmitrii: I'm maintaining Pier One. It's a Docker registry that satisfies our company requirements such as OAuth, S3 backend, and immutable tags. We have about 40k Docker images it manages.
It's written in Clojure and I'm happy with it; the codebase is small and easy to maintain.
Jon: Has Clojure grown outside of the deployment layer?
Dmitrii: Yes, one use case is for internal tools such as proxies, infrastructure tools and CI servers. We have a team that provides continuous integration services to the other teams. We have about 200 CI workers that are powered down at night, but then you can still use them if you want to.
Hunter Kelly presented at last years Clojure/Conj on using Clojure and Spark to 'understand fashion in a more quantitative manner'.
We have written libraries in Clojure to help teams write Microservices. Friboo is an example that offers common components and encourages an API First approach using REST and Swagger.
Jon: Do you think that Clojure has made a difference to IT at Zalando?
Dmitrii: It's not so much the technology that makes a difference, but the people being inspired and motivated when they make a decision. Both Scala and Clojure are successful here for this reason. There is no overall trend - our goal is to be more attractive to developers.
When we hire developers they don't immediately join a specific team. The first month they attend workshops and get to know the company. Then the teams present themselves to the new hires and the new developers get to decide which team to join. This makes teams compete to be attractive.
Jon: How do you go about training and upskilling?
Jon: How have people taken to learning Clojure?
Dmitrii: I had a developer join our team who was new to Clojure. After three months he wrote a proxy server that wrapped a legacy server and was highly performant. Three months was enough for him to deliver production code.
We have seen that people are interested in growing and developing their careers. We also have a management team to take people out of their comfort zone and to challenge them with new ideas.
State of Clojure
Jon: What is the state of Clojure in Berlin?
Dmitrii: Clojure in Berlin is quite active - we have monthly meet ups with about 50 people in attendance. I go from time to time and see new faces there. There are other companies here doing Clojure.
We also have a ClojureBridge event 3 times a year - organised by fellow Clojure enthusiasts. I worked as a coach there.
Jon: Anything that interests you in the development of the Clojure language?
Dmitrii: I'm very exciting about a big new feature; clojure.spec. There is lots to explore here. There is very few alternatives to this in other languages. It's very nicely designed and the way of the future.
Jon: What's so radical about Spec?
Dmitrii: It's an alternative way of ensuring the data has the shape you expect it to have. It's the answer from the dynamic typing world to the compile time checks in static languages, but solved in a nicely dynamic and idiomatic way. The presence of Clojure.spec will make Clojure easier to sell.
Jon Pither: Any technologies you'd like to give a shout out to?
Dmitrii: Stuart Sierra's Component framework which is a big thing. All our services are based on Component. Also Midje, it's really a step up from clojure.test. I like that you can mock and check everything in every possible way; very convenient.
Check out the Zalando tech blog.
Sign up to the JUXT newsletter