Marketing brief
Manage your servers with Git.
We let developers manage their servers using simple tools they are familiar with: Git and YAML.
Add a simple YAML description of your server, git commit, git push and voila. Need to automate things up: adding database backups, continuous deployment, autoscaling or testing is just as easy.
We want to be to DevOps what GitHub is to the development community.
2 crowds, 2 points of view, 2 polarized solutions:
| Name | Examples | Description | Advantage | Issues |
|---|---|---|---|---|
| NoOps | PaaS (Heroku, dotCloud, AppFog), CI & CD (CircleCI, TravisCI, Wercker) | Developers' answers; abstract away all infrastructure concerns. | Low barriers of entries, user-friendly | Fragmented, rigid/limited, expensive, black-box/not reusable/shareable. |
| Tools | Configuration management (Chef, Puppet, Ansible), CI & CD (Capistrano, Fabric, Jenkins) | Ops' answer: build better tools to help professionals scale themselves. | Powerful/flexible, strong OSS, transparent | High barriers of entries, not portable, silo-ed/fragmented, not user-friendly |
These two polarized views are still leaving a huge, unaddressed segment of the market/needs in the middle, focusing on the fringes (large community of developers with small $$$/complexity OR few enterprise clients with lots of $$$/complexity).
Our end goal is aligned with the DevOps movement, we intend to bridge that gap. The first step towards this is lowering the barriers of entries to Ops.
- Low barriers of entries (low hanging fruits): developers can use what they already know; YAML + Git and you're done.
- Collaboration (long term goal): among professionals within an organization (ops & devs) but also across teams and organizations (OSS infrastructure).
We will win for several reasons:
- Flexibility and costs; we are providing the right balance of customization/power and cost effectiveness.
- Satisfying to both camps; we're letting developers build and manage infrastructure, while following the best practices and transparency that ops need.
- Build on collaboration/social; the ability to easily share with your team members, but also the rest of the dev/ops community your infrastructure blueprint (CI, CD, backup and revert strategies, autoscaling) will fuel itself.
Massive.
There is still no clear winner in this space; it is clearly, still as of today, a greatly underserved market. If you get started with development, there is a plethora of very good options (GitHub, Bitbucket...). Not if you're going for managing servers.
There is humongous amount of people with lots of problems and nowhere to throw their money at.
- Primary: DevOps, Cloud, Infrastructure, Servers, Automation, Deployment, Configuration Management, Orchestration
- Secondary: PaaS, IaaS, System administration, Performance & Scalability
The bottom line:
- The larger portion of the market are companies who don't have (yet) a large and/or dedicated DevOps team but are passed the scale for Heroku.
- Companies need a better platform they can invest in freely: no lock-in, no limitation on technology, access to their infrastructure, use of common standards.
- Dev and Ops teams need a tool they can collectively build upon their infrastructure strategy, something reachable, visible and portable.
We make this bridge possible at a fraction of the cost of implementing it on your own, mostly by forcing our description of the elements of this strategy as compact and portable JSON files.
We are serving first small to medium sized technical teams, in or out of large organizations. For example:
- Startups: teams that move fast and have high level of expertise in development, but lack the resources (staff and/or time) to invest in ops. More often than not, somebody on the team is defaulted to ops and pick up the slack. It leads to wasted bandwidth on product development and mistakes on the ops side (lack of expertise/best practices).
- Dev shops: teams which may have an ops guy/team but often struggling with the repetitive boilerplate work. Good ops who can multitask/automate are a rare breed and they often struggle to reach the point where they can share automation with the rest of the team (bottleneck of incoming requests from the larger part of the team who are developers).
- Technical teams within larger companies (candidates for Enterprise): same as regular teams but they usually struggle with independent/centralized ops teams. This means poor communication channels, low reactivity, drastic "across the board" technological choices...
Our potential customers are simply frustrated about the very hurdles the DevOps movement is trying to address. They also intersect heavily with Github's, which explains why we've taken a of inspiration from their licensing and pricing model.
Our audience at large is technical, and can be found on communities like Hacker News, Reddit (/r/sysadmin, /r/devops). For more details with regards to the types of people we are targeting, refer to the Personas page.
- Vincent Viallet - Infrastructure: having worked with startups and Fortune 500, Vincent designs infrastructures that scale to millions of users. He leads all discussions related to ops, automation and security.
- Makara Wang - Development: Makara has been working on small to complex software architectures for the largest organizations in the world: CNN, the UN, the World Bank, governments... He leads the development team.
- Ronan Berder - Product and Business: founder of a software consultancy focusing on the the humanitarian world, Ronan leverages his background in development, design, management and marketing to lead the business development, product management and marketing initiatives at devo.ps