Update:Archive/1.0/Overall Plan: Difference between revisions
No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
This is an [[Update:Bestongoing discussion that will hopefully yield the "best tools for the job". | 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 [[Update:Infrastructure|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 [[http://osuosl.org|OSL]] would be willing to completely manage this service up to the application layer (including upgrades, etc) for the MoFo. | |||
Revision as of 22:51, 23 January 2005
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
Getting to version 1.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.