Launch HN: Armory.io (YC W17) – We Make Deployments Boring and Self-Service • Hacker News Board

Re: Launch HN: Armory.io (YC W17) – We Make Deployments Boring and Self-Service

#21

Post by danielodio » Thu, Mar 02, 2017, 10:52 PM UTC

nodesocket wrote: post #20

georgeaf99 wrote: post #12

Hey y'all, I recently started working on a CI/CD product at an organization where the number of deployments per month is in the same ballpark as Netflix. In my experience, adopting systems for rapid deployments also requires adopting new processes. For example, products that are deployed frequently need to have developers on call during deployment windows. These developers tend to have a specialized skill set that ma…

I just founded my third startup Elastic Byte ( https://elasticbyte.net ), which is a DevOps and infrastructure consulting company operating as SaaS (public monthly pricing plans). 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 "Y…

Yeah that mindset shift was the hardest part of transitioning from a traditional ops to a no-ops approach at our last company. The technology has no chance if the culture isn't ready.

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.

Re: Launch HN: Armory.io (YC W17) – We Make Deployments Boring and Self-Service

#22

Post by lintoma » Thu, Mar 02, 2017, 11:16 PM UTC

IgorPartola wrote: post #18

danielodio wrote: post #7

Here's a deeper dive on Spinnaker, and on how Armory is commercializing it for enterprises: http://go.Armory.io/Evaluate

I love that there is a service named Igor. Could never find my name on a keychain or a door sign, but now I have a service named after me :)

We called it Igor because it was a friend of Jenkins. It's named after https://en.wikipedia.org/wiki/Igor_(character) . There is another service internally called Woodhouse

Re: Launch HN: Armory.io (YC W17) – We Make Deployments Boring and Self-Service

#23

Post by devonkim » Fri, Mar 03, 2017, 3:46 AM UTC

I haven't gotten very deep into the guts of Spinnaker, but how are you expecting to handle the enormous number of organizations that prohibit developers from having production access and require someone in operations to perform a deployment? Even if you do all the necessary steps of API versioning, feature flags, blue / green deploys and such, most of these start to break down fast in velocity when there's a requirement for removing control away from developers to those that have less familiarity with the impact of changes. I absolutely agree something needs to address low-performing software organizations because oftentimes they're among the highest-impact organizations out there such as the Fortune 100 and public sector (as opposed to some SaaS company with a whole 1000 customers) but I haven't been able to crack the problem of many different reasons for dysfunctions leading to such low rates of deployments (it's invariably a Wicked Problem due to being almost entirely social in roots rather than technical I've observed so far).

Re: Launch HN: Armory.io (YC W17) – We Make Deployments Boring and Self-Service

#24

Post by imosquera » Fri, Mar 03, 2017, 8:36 PM UTC

devonkim wrote: post #23

I haven't gotten very deep into the guts of Spinnaker, but how are you expecting to handle the enormous number of organizations that prohibit developers from having production access and require someone in operations to perform a deployment? Even if you do all the necessary steps of API versioning, feature flags, blue / green deploys and such, most of these start to break down fast in velocity when there's a requirem…

We believe that engineers should have access to deploy, manage and ultimately own their own deployments. This fundamental change is more commonly known as DevOps. In our interviews with over 100 enterprise companies, before we even incorporated the company, we observed a strong desire for teams to move in this direction. While we are aware there are many laggards, we’re making a bet, with Armory, that companies must move in this direction or die.

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.