Project Sagrada is a Services project to build a solid and stable platform to develop new and highly scalable services and applications to support Mozilla’s mission. The initial goal is to make it easy for internal developers to build reliable and high performance backend services, easily deploy them to test or production, and have their deployed services be robust and easy to manage. Based on the current product direction for the known services, this set of capabilities are both the hardest to get right at scale and the most important shared aspects between all of the services.
The first phase of the project will focus on adding capabilities (abuse detection, metrics, crypto, and more) and tooling (testing support, build automation, and packaging/dependency tracking) to the current python services-core framework. Later phases will provide better support for building and deploying web-based applications, increasing amounts of “self-serve” capabilities around deployment and provisioning, and options for isolating experimental/external apps.
Creating a core set of stable and reusable code libraries and, where appropriate, web APIs alongside the programmatic ones, technology choices (i.e. which key-value store, which auth technology, which abuse detection system, etc) are abstracted away and allow the user to focus on the core of code that is unique to their app. We believe this is the best and fastest path to a solid, scalable and highly capable base platform that can be used as a framework and as individual components.
How We Get There
Our efforts to date have focused on building out and refining capabilities as they arisen on a project by project basis. While still maintaining a focus on products we support and products we are working towards launching, our priorities in Q4 and beyond will shift towards building generic support for applications that teams across Mozilla will develop.
We recognize that this is a highly ambitious project, and can be effectively described as completely open-ended. While true, there is much to be said for where we can get in finite time along that path.
The structure of a service generally follows the same pattern: a set of API entrypoints, some authentication, controller logic, storage, and a response. Then there’s the additional questions of deployment, monitoring and maintenance. All of these things combine to make writing an app from scratch a challenge, especially if you want to build it to scale out of the box.
What if we could make that 20% easier? That would seem to be a big win, both internally and externally. We probably have that today – use our base application and generating your entrypoints is pretty simple. Sure, you still have to write all your controller logic, and figure out your storage story, etc, but hey, 20% is a pretty good start.
What if we could make it 40% easier? Simple key-value storage APIs and a strong metrics component might do that. And so on and so on.
Why not use one of the many available frameworks out there? We could probably pick up a quick win building on one of them, and we haven’t ruled out the possibility. However, most frameworks are built to support HTML generation, and while they’re capable of creating the appropriate responses, they pull in a lot of additional functionality that we do not need or use, and if it gets in the way of our ability to scale, it’s a nonstarter. Making it easy for us to get to 30% is a great idea, as long as it doesn’t make it much harder to get to 50%.
The ultimate goal is 100%. This goal is impossible, as any computer programmer can tell you, and trying to achieve that produces the infinite horizon that makes this work seem so vast. But setting that as the goal misses the point – getting a user 75% of the way to having a stable, scalable backend application that does what they need would be an enormous game-changer in the application creation space.
The Roadmap
We’re still in the bootstrapping phase of the project, so we’re building some of the obvious pieces, and gathering feedback on the rest. Please see the wiki for the current set of features we’re looking to add to the platform.
— mconnor & telliott, on behalf of the Services team
We launched Weave as an add-on, rebranded it as Firefox Sync, moved Firefox to Rapid Release and eventually integrated Firefox Sync into the browser. Our goal has always been to offer the best service so you can seamlessly share your Firefox experience across devices
