One of the largest clusters of engineering teams driving Zalando is our Fashion Store department, which develops and maintains our 15 country-specific, customer-facing websites. The Fashion Store focuses on creating great online experiences for Zalando’s +16 million active customers — developing great features like the catalog and the product detail page.

Our Fashion Store engineers are organized into small, independent, autonomous teams that own their code. These teams take responsibility for the whole application development cycle: programming, assuring quality, deploying and operating their applications. My team, the Spearheads, formed in May 2015 to completely rebuild the Fashion Store. In this post — the first in a series — I’ll discuss the Spearheads’ motivation and goals, following up in future installments with more detailed insights into our architectural decisions.

Spearheading Change

The key goal of Team Spearheads is to create a new, state-of-the-art architecture that enables engineers to work autonomously and fosters innovation. Our team — seven engineers and a UX/UI designer — decided to replace “Jimmy”, our monolithic shop application, with microservices built by multiple autonomous teams. Under Jimmy, all of the Shop teams shared the same code base, lacked true ownership or the freedom to make decisions, and couldn’t move quickly because of Jimmy’s slow startup time and our overly complicated deployment processes.

Spearhead Key Principles

Enable Team Autonomy

Autonomy allows every team, including those belonging to the Fashion Store to execute a full product cycle on currently active features without being dependent on any other teams. We can also introduce new features autonomously. If dependencies are unavoidable, we try to limit them as much as possible.

Rapid Feature Development

Microservices allow teams to independently develop new features and put them into production. Being able to quickly bring new features live will motivate our product team to come up with innovative ideas, experiment, and “play” with adding and removing features — producing wins for our growing customer base.

Create a Consistent User Experience

We need to balance our drive for team autonomy and experimentation with the need to provide a consistent user experience. Although different teams will develop and deploy each page of our new Fashion Store, the end result should appear as if a single person designed them. This requires the same visual style for each part of the website, as well as coherent handling of user input, animation timings, wording, and even performance of each individual page.

High Perceived Performance

By targeting perceived performance instead of absolute numbers, our team can focus more effort on customer experience rather than raw system numbers. With our new architecture, we can immediately stream markup from different microservices to the browser and arrange it on the client side (see Facebook’s Big Pipe). For some of our pages this might not be enough, as we need the content to be ordered on the server side. For this particular use case, we’ve developed a new approach called Smart Pipe (we’ll get into more detail about it in a future blog post).

Cutting-Edge Technologies

In choosing which technologies to use, the Spearheads want to keep current Fashion Store team members happy and engaged while also attracting new talent. As an example, we’ve decided not to support non-JavaScript browsers — eliminating lots of overhead that would have made our architecture slower and harder to implement. We enjoy writing software in many languages; being polyglot is both fun and challenging. We started writing our prototypes in Scala, Go, JavaScript (Node.js). Open sourcing the code we write is a priority for us. That’s how nice projects like Skipper, Innkeeper and Beard were born.

Simplicity

"The effort required to design something is inversely proportional to the simplicity of the result." — Roy Fielding

Simple is beautiful! Spearheads strive to eliminate any unnecessary complexity from the new architecture. In many of our earliest brainstorming sessions, we tried to find the right balance between enabling team autonomy and creating a consistent user experience. We took into account many of the possible solutions for each of the problems we were facing and, by discussing each one, eliminated the weakest ideas. We developed prototypes for the viable solutions and chose the ones which best fit our use cases. As we needed to create a router for the Fashion Store, we developed two prototypes, one written in Scala and Skipper, written in Go. In the end we chose to continue with the Go solution and open sourced it.

Communication

Internal communication and feedback are very important to us. Having a new architecture is pointless if the other Fashion Store teams don’t find it helpful. We regularly present on our progress with the whole tech team. We consider other teams’ feedback and document all of our decisions on the internal tech wiki.

That’s it for today! In my next blog post, I’ll disclose more details about my team and on the new Fashion Store architecture.