Hi, this is the CTO of Armory. If any of you have questions about cloud adoption or want to learn more about what setup might work for you, feel free to ask me!
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.
As of today, that is main value prop, however over time we hope to add other microservices to Spinnaker that will provide value on top of the control plane.
We believe that DevOps encompasses 3 areas that must change: people, processes, & technology. We’re seeing evidence that the people/culture is already changing organically because companies must change in order to compete in the software era, and the velocity at which we see software-first companies entering traditional spaces like banking/finance, real-estate, hotel is also accelerating.
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.
While we're not currently hosting it now, we did start with a hosted solution which is why it exists on our website. Engineering leaders were hesitant to give access to their AWS accounts so they wanted us to bring up Spinnaker in their accounts. Sometime in the future we do intend to revisit hosted Spinnaker.
Nadya - Thanks the summarizing the video! You mentioned that other lean startups have done this, could you point me to other lean startups working in this methodology? I'd love to learn how others are approaching this idea.
I've also found while many accept that pair-programming increases productivity it's rarely implemented. The video we created outlines an approach that is an alternative to pair-programming but maintains many (if not more) of the benefits.
Colin - Thanks for the feedback. I was trying to put up the content as quickly. I'll go back and update the post with a summary/abstract or talking points.
Yah, it's not easy to find the implicit and definitely need to use a solid IDE to track these things down. I've gained enough experience now that I can track things down quickly but it's taken me a while to get here. I wonder if others will be willing to do the same or adoption of the language will stagnate.
I decided to use the word "better" because for some aspects like design, I'm not sure I would want that to be done more efficiently necessarily, but instead I would want it to be done better and achieve better design even if it costs me a bit more in time/effort. I think better in this sense is more qualitative although we should try to quantify as much as possible.
I agree with most of your points but the major difference here with Play are 2 points
1. This framework is geared to asynchronous/real-time workloads (think node.js)
2. The framework is built for Scala, which they state is a more productive language for the JVM "Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application."
Note: I admittedly don't know much about Ruby so I'm not sure how much it would or would not compare.
yes, we have integration + unit tests for everything that we do. before we release any code the entire suite gets executed and tested which helps catch bugs quickly.
we even use a subset of those tests in production to make sure all sub-systems are working, not just a ping to the api.getsocialize.com domain which isn't sufficient.
When I first started testing I was rather skeptical. But now that I do it, I wouldn't code without it. There are so many other benefits of testing like cleaner code, incremental builds for native apps, and just general confidence in your deployments that allows us to deploy anytime of the day without worry.
are you saying that being a certified ferrari mechanic doesn't make you successful? And if you're really good at it you'd probably get paid well. I dont think it's an either/or situation. If you're good at what you do and you love what you do, isn't that successful?