Update:Archive/1.0/Overall Plan

Update: Home Page » Overall Plan

Introduction

The following page will give an overview of what the overall plans are for development and deployment of the UMO service.

Getting our Bearings

We have an application that we do not know what it does fully. In addition, we do not have a clear idea of key policy issues as well as any documentation on the overall architecture of the UMO service. The first two weeks will be spent assessing the situation so that we know what we have and what it does.

Development

There are two main components to development at this time; getting v1.0 stablized and to a point where we feel comfortable with public consumption and then the re-engineering of the UMO service with v2.0.

Getting to version 2.0

In our discussions on #umo we have talked about a few things in regards to v2.0. The overall opinion is that we should rewrite completely from scratch so as to take advantage of frameworks/tools to scale the application and grow it over time better. The following is a summary:

What language should we use?

Sticking with PHP seems to make the most sense at this time. We have that skill set (both on the development and systems side) and the alternatives are not particularly attractive. We considered both Perl and Java but decided against both at this time. The existing UMO service is currently scaling quite well with over 3 million unique clients a day across 3 servers.

What tools/frameworks should we use?

This is an [[Update:Bestongoing discussion that will hopefully yield the "best tools for the job".

Infrastructure/Deployment

In looking at the future, we need to identify what it's going to take to handle the UMO service during peak loads. The community will not judge us on how sexy UMO is or the tools built around it. We believe the community and pundits will be most critical of UMO if it fails to perform during peak usage. If a new security update is released and UMO melts down, that will reflect poorly on the use of Firefox but also the Mozilla Foundation as a whole.

The existing infrastructure will not scale to handle peak loads at this time. Peak loads will occur when new and popular extensions come out and most notably when security updates are released. We need to build a scalable, reliable and secure infrastructure to handle the delivery of the UMO service to end users.

Corey Shields will be tasked with coming up with a plan for this and presenting it to the Mozilla Foundation system administrators. The [[1]] would be willing to completely manage this service up to the application layer (including upgrades, etc) for the MoFo.