Jimmy to Microservices – The Journey One Year Later

by Dan Persa - 5 Oct 2016

We started our migration from “Jimmy”, our monolithic shop application, to microservices more than a year ago. We had lots of fun with this project from the beginning of it, with us, Team Spearheads, discussing potential ideas about what to do and how to do it, and then quickly “cowboy coding” some prototypes.

Now that the project has become more mature, our challenges have changed from prototyping to optimizing for performance; from “cowboy coding” to providing stable components for other teams at Zalando to rely on.

To show our progress, I’ll be using this opportunity to explore the current status of the project.

Evolution and progression

Since we started, our project has been given a brand new name, Project Mosaic, and I’m proud to say that it’s been a successful venture. We’ve added more components to the project as well, such as Shaker, Quilt, and Instaskip.

Our team has also evolved, from Spearheads — a task force whose job was to come up with the new architecture — to Pathfinder, a team with a clear purpose: Team Pathfinder enables team autonomy by providing a platform to deliver web content.

Our team trains other Zalando development teams to create their new fragments, and teaches them how to create routes and templates in the new Mosaic architecture. We are currently supporting these teams in their efforts to migrate parts of Jimmy to Mosaic Fragments.

We’re also putting more and more languages into production: We recently added Clojure to our stack, with Instaskip. We started to build a new UI for Mosaic and this web app has no customer impact, so it seemed natural for us to try Elixir together with Elm.

Migration updates

One of the goals of the project is to migrate from the shop monolith to microservices, to get rid of Jimmy. Here is the progress:

The new Wish List and PDP fragments are going live as we speak. The Header and Footer fragments are also live. Other feature teams in the Fashion Store are on their way to putting their fragments live in the next quarter.

Project updates

Each of the projects under the Mosaic umbrella have evolved nicely:

Skipper has even more filters, like http compression, and predicates like the cookie, query, source ip, and time range. There’s also better documentation. We have support for debugging endpoints and experimental SPDY and WebSocket upgrades. We’ve improved the static file server filter and TLS Configuration handling. For eskip we have pretty printing and route patching.

Tailor now supports base templates. Seeing how multiple templates are sharing quite a few commonalities, the need to be able to define a base template arose. The implemented solution introduces the concept of slots that you define within these templates. Derived templates will use slots as placeholders for their elements.

Shaker is a library and living showcase for UI components. It is used inside Zalando to provide a consistent user experience while developing Fragments in distributed and autonomous teams. During the last few months we’ve added more components to the library.

New features in Innkeeper include better path management, wildcard routes, more granular authorization, and tighter integration with Skipper by using the eskip format.

Instaskip is a new project, a command line tool for Innkeeper. The goal behind developing it is to give teams a tool to easily migrate their routes to Innkeeper, while using the familiar eskip format Skipper provides.

Next challenges

We’ve started to develop the UI for Mosaic, to make sure Zalando teams are able to manage their routes and templates on their own.

We also plan to evolve Innkeeper’s API to accommodate more use cases, like REGEX routes.
During the next quarter we’ll start expanding our Mosaic architecture to other departments as well. We’ll keep you updated on the progress!

Conclusion

In the end I’d like to say thanks to everybody who contributed to make Mosaic a success. My team, the Pathfinders, who worked hard and put lots of passion into making Mosaic a reality.

We’d also like to extend this thank you to our managers who came up with Radical Agility, and gave us the autonomy to innovate. And a shout-out to the other teams in the Fashion Store who trusted us and invested their efforts into creating their own fragments, who gave us valuable feedback and dealt with our bugs.

To find out more about how Radical Agility helped us realize our project goal, visit RadicalAgility.org.

To see more on Mosaic, check out our presentation of the project below.

Similar blog posts