ArchitectureGuide/Services

Not logged in - Log In / Register

Revision 3 as of 2011-05-22 23:20:27

Clear message

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?

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