The goal

Launchpad implemented as a collection of heterogeneous fast, reliable and flexible focused services. This goal has widespread support throughout the Launchpad team and management.

Why change?

As a monolithic source tree and nearly-monolithic service Launchpad has a very high friction around change, which makes change hard. It also drives test suite duration, makes NIH easier (and reuse harder). There are good reasons to believe that refactoring Launchpad to use a services model internally will make a lot of things easier, including further performance improvements and code reduction (through reusable subsystems like messaging). There is a detailed analysis of why we should move to a services based design.

What needs to change?

• We need to start thinking services rather than database tables.

• We need to accept some discomfort while we transition: we have a lot of accomodations to our current constraints, which will take some untangling - and until untangled things may be confusing. We should try to minimise this period.

• We will want some basic infrastructure around notification of object changes between services: many services will be caching or deriving data from another service. Not all services need this (for instance a service to do what IGPGHandler does would not need this). Other services will be incredibly dependent on it (for instance bugsummary as a service).

• We probably need to document how much potential skew we will accept on data in the collection of services. That is, for each service - where does it fit on the ACID/BASE spectrum.

• Having a way to get a microservice up and running production-ready easily would be win. E.g. a lazr project which sets up logging, default thread pool size (1) etc with a couple of lines of code.
• And we need to actually split out a raft of services into smaller dedicated trees.
• There will be a tonne of little areas like feature flags that we need to expose as a service early on, because so many things will want to use them.

How do we go about doing this?

One step at a time! Its a target rich environment and that makes it hard to choose what to do first. Someone wanting to work on it could sensibly scratch their personal itch (e.g. splitting codehosting out) or build up some of the common bits like a microservice template. At the project level, so that we can resource splitting up as a direct project, we need a bit of a roadmap to feed into the team work queue.

When will we do this?

We can as a team start doing bits and pieces whenever they make sense. That said, the technical architect, product strategist and Launchpad team lead are all agreed that some resourcing is needed - this is a vital change to make to the design of Launchpad and its worth putting significant resources into it to help make the change come sooner rather than later. No date is set yet, but the hope is to start a squad rotation onto this during the 2011 calendar year.

References

• Roadmap.

• Analysis of the case for/against services.

• Requirements for microservices.