-
Notifications
You must be signed in to change notification settings - Fork 1
Marketing brief
devo.ps makes it easy to build and manage your cloud infrastructure. Our SaaS makes creating, managing and automating your servers (and what runs on them) not suck.
We want to be the Github of DevOps.
We allow you to:
- Create, manage and delete servers on any cloud: AWS, Rackspace, Linode, Digital Ocean...
- Manage services and their related configurations on these servers (think NGINX, Varnishd or Ruby).
- Easily build automation for anything managed through devo.ps: backup or deployment strategies, throttling, scaling, notifications, code builds...
- And soon manage your applications.
Our core idea is organized around representing all of the components of your infrastructure as simple JSON files (not unlike packages.json), making it a compact, portable, visible and transparent blueprint of your strategy.
- Primary: DevOps, Cloud, Infrastructure, Servers, Automation, Deployment, Configuration Management, Orchestration
- Secondary: PaaS, IaaS, System administration, Performance & Scalability
The following describes the existing competition and provides pointers at its perceived shortcomings. For a more exhaustive list, refer to the Space & Competitors page.
There are currently two options to solve your DevOps/infrastructure issues:
- PaaS aka The expensive black box: Heroku, DotCloud, AppFog and the likes. You settle for somebody else's strategy and decide to forget about the problem.
- The DIY approach: using various tools (Chef/Puppet, Capistrano, Jenkins...) you invest heavily into implementing parts of the DevOps tool chain (automation, orchestration, deployment...).
These do not answer the fundamental challenges:
- The Heroku-likes are mainly solving the deployment and (horizontal) scaling issues, while obfuscating the infrastructure layer, effectively keeping you out of the servers. It gets expensive quickly and effectively lock you in (migrating is non-trivial).
- Building things on your own is expensive, time consuming and risky. DevOps profiles are a rare breed and hard to evaluate. Moreover, this approach lacks portability and visibility; what you build is spread across many technologies and tools.
Development and Operations are two different beasts. The Heroku stand is an attempt at obfuscating Operations from developers. Chef, Puppet, Rightscale and the likes are just better tooling for Ops.
We've witnessed teams moving away from Heroku (or at least trying) passed a certain scale. More tooling (Chef, Puppet, etc) doesn't mean a better collaboration between the teams (high barriers of entry and poor visibility, leaving development teams in the dark).
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