What We Do
At Octopus, we create happy deployments, and by extension, happy software teams.
Deployment time is, for the majority of software teams, a scary time. The process is untested, unreliable, and manual. Mistakes happen, which leads to downtime, finger-pointing, and lack of confidence and trust. Because of this, teams put it off. They deploy to production once a month, or once a quarter, or once a year. The longer the time between deployments, the more likely something will go wrong. It's a downward cycle that's hard to stop.
Our vision is for all software teams to look forward to deployment time; to be excited about seeing their changes deployed and used by their customers. We want them to deploy more and more frequently, and to feel 100% confidence it will just work.
We're going to accomplish this by building the best in class solution that focuses on the three hardest parts of continuous delivery:
Deploy: we automate deployments - getting the software onto the production systems - in a way that's consistent between environments, and thus reliable. That encourages teams to deploy more frequently.
Release: we help teams to coordinate and add safeguards around their deployments. Not just anyone can deploy to production, and what's being promoted to production needs to be what was tested.
Operate: we don't just automate deployments anymore; we also help teams to automate all the things they need to do outside of the deployment window.
We think that by doing this - by focussing on building the best tool, providing the best service, and being the best company for the job - we'll enable our customers not just to do daily builds or unit testing, but to continuously deliver working software to production, and to look forward to deployment time.
We don't think that DevOps or Continuous Delivery should be confined to the Fortune 500 or the FAANGs of the world.
Software is eating the world, and as a result, there are software teams in just about every company in the world.
Companies like Shopify or Spotify or Netflix popularised many of these practices, but historically they have required a huge investment in tooling and internal engineering teams to support. The reality in most smaller teams - companies with 5,000 employees or less, in which less than 300 work in software teams - most deployments are manual or cobbled together with custom scripts, and there's no consistency between teams and no visibility outside of the few people involved in the deployment.
Every software team is inspired by the practices that the tech giants follow, but few can get close.
Octopus enables world-class continuous delivery and DevOps practices for teams of all sizes.
We had great timing with Octopus, and we've ridden three major trends:
The trend towards agile software development means that teams are expected to iterate more quickly, and thus to deploy more frequently.
The trend towards virtualization and the cloud means that there are many more servers required to run the software, which demands automation.
The trend towards microservices and the growth and complexity of software systems means that there are many more moving parts to coordinate.
In short: software teams are building more complex software, and they are expected to deploy it more frequently, to more systems. It's no surprise they need tooling to help with this.
To get a sense of how big the market for Octopus is, consider Jira. Atlassian is a billion-dollar company today, off the back of essentially one product: a bug tracker. In 2005, a bunch of companies made bug trackers; Atlassian was tiny, IBM dominated the top end of the market, Bugzilla was the popular open-source alternative, and Microsoft had just released Team Foundation Server with their own attempt at bug tracking. But it turned out that there are 50,000 companies with software teams around the world that needed a bug tracker to track all the bugs that (let's be honest) they're never going to fix.
Every team that needs a bug tracker must also produce software, and therefore, needs a way to deploy that software. And deploying software is arguably a more valuable problem to solve. Somebody will build the "Jira for deployments", and be as big as Atlassian or Jetbrains. We think that it can be - and should be - us. 😁
Our long-term goal is to build a company that is around for 50 years, with 50,000 customers, that's known for building a best-in-class product with amazing customer service.
Octopus is playing a different game to all of the companies in this space. We're bootstrapped and profitable. Our competition is "mostly everyone" and “no-one” at the same time.
Cloud vendors like Microsoft and Amazon see automated deployments as an easy way for their customers to deploy to the cloud and thus increase cloud usage, and so they provide free alternatives to Octopus. These tools tend to do a bit of everything, not just deployment, but they don't do deployment particularly well.
IBM and CA offer deployment tools that are usually shelfware - they are bought by CTO's but tend to sit on the shelves, as customers don't really want to use them. They focus on features that demo well to CTO's but don't excite the developers or DevOps team members who actually have to use them.
Xebia, Harness, and Electric Cloud are VC-funded. They take a high-touch approach to sales and their products are designed for very large companies. That said, their products generally have more capabilities than those of the cloud vendors.
In this world, Octopus is different
This is the core of what makes us different:
DevOps automation is a "Fortune 50,000" thing. We think that Octopus - or something like it - that should be adopted by the "Fortune 50,000", not just the Fortune 500. We think long term that there are tens of thousands of companies with tricky deployment problems that Octopus can solve. We think that this is as big of an opportunity as Atlassian had with bug tracking, or JetBrains had with Java IDE's.
Bottom-Up, one team at a time, is the right way. We think that the best way to reach all of those customers, in companies big and small - and to build a better product - is by focussing on bottom-up developer-led adoption and partnerships, not high-touch sales to management. Long term any company that adopts the latter is doomed to be replaced by the company that figures out the former.
Best In Class. We choose to build a "best-in-class" tool over a "does everything" tool because we think that the market will always put downward pressure on the price of basic-level tooling and that only tools that focus on the most complicated use-cases and customizability will be around long-term.
In summary, we think that tens of thousands of software teams will need a best-in-class, cloud-agnostic DevOps platform and that the best way to reach them is by bottom-up developer adoption. Doing this requires building a tool that doesn't just demo well, but that people actually love to use. When they use our software, and when it’s delivering value for them, they are very unlikely to switch to anything else.
