Launch HN: Armory.io (YC W17) – We Make Deployments Boring and Self-Service
Armory.io makes deployments boring (like ‘waiting for your code to compile’ boring), non-events that happen continuously, and always in the background. We do that by simplifying the installation and configuration of Spinnaker - an open source continuous delivery platform from Netflix.
We all worked together at our last company and experienced the pain of scary deployments with low engineering velocity. When I became the SVP Engineering there, I decided that needed to change. We broke a brittle monolith app up into microservices, started deploying with Kubernetes, and created a CI/CD pipeline that allowed us to go from deploying just a few painful times per month (taking weeks and multiple manager approvals to deploy) to 2,000x deployments per month, continuously. The cascading effects were that we started working on parts of the codebase that had been stagnant for years because we were afraid to touch them (the original developers had long left the company). Here’s a screenshot of a chart that shows the delta: http://drod.io/43452e3V0N28 — each color is a different microservice; you can see how those blossomed as we broke the monolith up and started deploying each microservice on the cadence that was best for it. And we had much happier engineers, too, because they could see their code running immediately in production, and they took ownership of it running successfully in prod (as a side effect we went from a traditional ops team to a no-ops approach).
We were so passionate about the transformative effect this had on the company that we started Armory to bring it to any company — which is especially needed in large, low performing organizations that typically deploy just 7x per year (compared to 4,000x per day at Netflix).
We’d love to hear your stories of deployments gone wrong, hear your questions about Armory, or anything else on your mind!
23 comments
[ 3.2 ms ] story [ 71.2 ms ] threadAlso I tried the "try spinnaker" link and it looks like it timed out at armory.formstack.com
Today, our enterprise version of Spinnaker is hosted within your AWS account, not truly hosted Spinnaker as a service, although we def plan to offer that down the road. Our current customers have told us they prefer to run Spinnaker inside their own accounts b/c they fear data leakage.
How y'all are planning to approach the cultural changes companies will have to adopt in order to leverage faster deployments?
That said, in order to make this rate of change to happen faster, instead of trying to convince people through debates, we have to show proof that moving towards a true DevOps model is successful, not just because you get to deploy more, but because it matters to the business. We want to show that CI/CD helps meet SLAs, new valuable features are added and allows the business to address new markets.
We've found that big companies need to see one team achieving success before they'll adopt it throughout the organization.
We've employed this approach successfully with our first several customers. They're going from from one app --> 5 apps --> "GA" rollout internally.
1. Product engineers are embracing ownership, and despite being on-call, they are excited at the prospect of being able to deploy their apps whenever they want.
2. Ops teams are transforming into engineering teams. When you start to automate everything (monitoring, deployments, testing, etc), it frees up ops folks to work on more interesting problems within an organization.
Indeed culture is a big part of the DevOps puzzle besides software. This mentality shift is also a part of what we offer (training and advice). Individual ownership, moving fast, are all parts of the greater strategy. I've found the talk "You shipped it, you fix it" [1] by Ron Cohen (CTO of Opbeat) a great source of solid ideas.
https://opbeat.com/community/posts/you-shipped-it-you-fix-it...
The old model where developers hand off their code to the ops department is fundamentally a bad strategy because it leads to:
There is no accountability. If your code causes problems when deployed to production, ops is the one getting a call/page in the middle of the night, and trying to fix the problem for which they have no domain experience or understanding. However, if you deploy your own code at your own pace, then there is accountability.We especially see this with F500 companies. They insist on multiple manager approvals for deployments. CI/CD is really scary to them because it feels too risky.
One of our prospective customers (at a F500 company) told us about how they have a cross-functional deployment 'swat team' that all gather in a room on a Friday night and literally press a button to deploy the update, then see what happens. They take their website offline in anticipation of errors (and put up the '90s construction worker logo) and then their ops people get paged over the weekend to deal w/ errors. Just ridiculous!
The irony is that the slower deployment velocity creates more risk, making deployments scary affairs. It's a terrible cycle. Deploying 7x per year means each deployment contains many more features/fixes, which introduces more risk. Vs. breaking a monolith up into microservices, and letting each component deploy at whatever cadence is best for it. And with Spinnaker each deployment can be traced back to the original git commit hash / jira ticket / etc., creating much more transparency in the deployment process.
That said, it’s an immense challenge working with the F100, which for some, don’t want to move in this direction yet. We’ve chosen not to focus those laggard companies. Even within our current focus, we’ve found that we actually can’t hire fast enough to support new customers who want to truly enable their deployment teams. And yes, it’s very much a “Wicked Problem” to solve but we’re hoping that with Spinnaker and market pressure it helps loosen those roots.