Assume for a moment that you’re starting a new application. You start thinking about the user experience you want to build, or API you want to serve. But quickly you’ll get to a familiar set of questions:
What’s the right strategy to set up performant builds?
Which cloud provider should I use, and what are the latest best practices to deploy services to production?
I want to test out a complex interaction, how do I write an end-to-end test?
And these are just some of them.
For any non-trivial application or team, figuring out how to combine many of the individual tools and infrastructure into a coherent development lifecycle is something that you need to do from scratch. Whether deliberately or not, you design and maintain your development platform.
And you are not alone. Teams in companies of all sizes struggle with the same challenges.
We believe you shouldn’t have to spend energy figuring this out yourself.
We’re introducing Namespace, a composable and extensible development platform, which automates your development, testing, and production workflows. (Skip to Getting started).
We’d like to help you focus on your application, rather than building your own development platform.
Grows with you
You may also realize that your set of needs doesn’t remain static. Teams and applications evolve, as well as their requirements. Which adds a burden for you to keep adding new workflows to your developer platform, or updating existing ones so that they keep working with existing or new providers.
Namespace grows with you.
Composable and Extensible
OK, but PaaS works best for simpler applications; we always hit a feature cliff.
We agree. Unlike traditional PaaS, which have a fixed set of functionality, we understand that the realities of different applications come with different needs. And that we alone can’t support all of these needs. So we’ve built the Namespace platform to be extensible at its core.
Apart from a common semantic layer of concepts you already use, like Applications, Servers, or Services, most of Namespace is extensible with new components that you are also able to write.
Our goal is to simplify common patterns while allowing complex workflows and integrations.
We introduce a composition model that combines build, test, and production from an extensible set of reusable workflows.
Servers and services are bundled together, whether they are your own or they are third-party services you depend on. Adding supporting infrastructure to your application – databases, object stores, message queues, etc. – is as simple as a code-level dependency that you commit into your repository to instantiate that resource.
Check out our examples to explore this further.
Development and DevOps
Although DevOps surfaced to break silos between development and operations, we still experience those silos through different tooling, ladders, staffing, budgets, etc. Some of these make sense: specialization benefits teams and separation of concerns is often essential to helping development organizations scale.
But scale should lean on speaking a common language and building on a set of standard primitives.
We believe that codebases should not be opaque to Release and Production oriented folks – whether it’s the architecture of those codebases, what service-level dependencies exist, the implied security perimeters, is a service stateless or stateful, etc.
By representing these needs into reusable components and properties: Components that “make sense” to developers (databases, object stores, etc.) and whose intent is isolated from their implementation, we’ll enable all engineers to use a standard architecture and infrastructure language.
We’ve seen this before
The team at Namespace Labs helped build some of Google’s core platforms – with a stand out: Boq, Google’s internal development platform. Before having a managed development lifecycle that you could rely on, many Google teams – from single-digit to large-size teams – struggled with many of the same questions that teams of all sizes today also face.
We build on that experience and how we saw it helping teams focus on their strengths and build their applications.
We’re just getting started
Today we mark the beginning of a journey. This year we’ve been iterating on our core, learning with a small set of users in a private preview. And in the last few months, we’ve focused on something we believe is a meaningful startup point.
Although it is still early, we’d love for you to try it out and let us know your thoughts.
Head over to Getting Started for instructions on how to try Namespace.
And from here, you can read our Documentation, and join our community on Discord. Follow us on Twitter and Github for updates.