staging-devopsy.kinsta.cloud

Tag: Armory

  • KubeCon 2023: What’s Next for Managed Deployment

    KubeCon 2023: What’s Next for Managed Deployment

    Mitch Ashley: Hi everybody, welcome back to KubeCon here in Chicago, 2023. Lots of great conversations, and here comes another one with Adam Frank Armory, welcome, Adam.

    Adam Frank: Thanks for having me, pleasure to be here.

    Mitch Ashley: Always, we love having you on. So what’s happening in continuous delivery in this, I mean, it’s evolved so much just in the last even year or so, about how many environmists we’re deploying to and the mix of all that. Most of us don’t live in a greenfield, so we’ve got to deal with lots of variety of things.

    Adam Frank: That’s right, that’s right. And I think one of the biggest things that people are really starting to come across now is the fact that they are looking at multi deployments, multi cluster, multi environments, really trying to orchestrate all of that and coming around to manage delivery. Understanding that everybody from a seed stage to large, large enterprises, they all have at least three dev stage prod, right? So how are you going to orchestrate across that when that just grows to more and more environments, talking about global companies and things of that nature.

    So, I think that’s one of the big conversations that’s been happening around here is about the orchestration of that deployment. So it’s been exciting. It’s been exciting for us. That’s one of the things that we went into from the very beginning was understanding that the deployments have to be orchestrated. There’s a lot of things that have to happen, security scanning, integration, tests, you name it, throughout that deployment. So it’s been quite nice.

    Mitch Ashley: When you mentioned managed deployment, right, it’s not just press the button, everything happens. There’s a lot of variables, things have to be sequenced. Some environments require different things than other environments, some you can do is declarative, you can really build it from the ground up through automation and others. Maybe you can’t do that, you’ve got to work with infrastructure or apps or code that’s already there.

    Adam Frank: Yeah, whether it’s infrastructure, apps, or code, or whether it’s just policies that you have in place that you need manual approval before you go out to production. Or something has to happen in staging, like data. Data needs to be transferred from production into staging to do actual validated tests.

    We had a talk on Monday with Portworx actually, really fantastic use case that we’ve come up with them. There’s a use case with their largest customer where they are actually transferring live production data into staging environments to do real tests, because I know a lot of people today, the code’s the same, the configuration’s the same, the infrastructure’s all the same. Is the actual data the same? Well, not really. Okay, well, how do you know that what you’re actually about to change is going to inflict what you want to change? So the fact that we’ve worked a lot with Portworx to do the actual data transfer, to have real live production data in the staging environment to run those tests and things against, has been pretty cool for our customers.

    Mitch Ashley: That was always one of my biggest challenges, how do you get data, especially earlier in the development of an app or a product, is you don’t have a lot of access to a lot of production data unless you’re in a SaaS, and maybe you can then, but you have to worry about things of anonymizing. But you have data, but not necessarily the right data to test what you’re going to deploy so you’ve got to kind of match that all up. Is there anything in that demo that talked about that, sort of that part of the problem, how do you get the right data in the right environment?

    Adam Frank: Yeah, exactly. One of the big things that the security of data, the management of data, moving data around, and and Portworx has a great solution for it. So it’s nice to partner with them, given that we can do the orchestration of those deployments and have that as a check that’s within that deployment. It’s not going out to production before that data is moved into staging, and tests are run against that and validation has happened.

    So like I said, you can have the manual approval at that point if you want, if that’s a policy within your organization, or you can have that continue on automatically and go straight out to production, which is great. That’s the dream right there, is to have that end-to-end automation and have that deployment fully automated, which a lot of people work towards, which is great.

    Mitch Ashley: Well, let’s talk about that. Is there kind of a life cycle that people go through from, we’re not doing it at all now everything’s manual, and maybe it’s scripted, but it’s not automated in the same way they do through Armory. Is there sort of a step by step phases people usually go to get to a point where they might do some really automated through this?

    Adam Frank: There absolutely is. I mean, we talked to a couple of people yesterday from, I can’t remember what company now, but one of the first questions that we start to ask them is, what do you do for your organization? Okay, great. You’re a DevOps engineer, you’re a platform engineer, you’re an SRE, there’s loads them around. These two particular gentlemen said that they were just automation ninjas they didn’t really have specific titles or roles, and they just helped the organization automate everywhere they could. So the next question is then, “okay, well what are you doing to deploy your software? What are you you doing for deployment?” And they said, “Well, it’s manual right now.” Okay, that’s where most people are starting, it’s going to be manual.

    So, I think that one of the biggest things that we see is people start with CI. They’re going to automate the build and the test of that, and they’re going to have an artifact that they want to be deployed. The next thing they’ll start to do is exactly what you said. They’ll start writing some scripts and they’ll start extending some of that CI until that starts to become a little bit fragile and it doesn’t necessarily provide the developer experience that they’re looking for and enabling blue-green and your canary and things like that to protect your customer experience. So at that point, then they go out and they look for a continuous deployment solution that is going to actually meet that, and that’s where the evolution comes from.

    From that point, they’ll start to have some of the manual checks in place. They might not have integration tests all automated, that’s okay. You can have the deployment go out to dev, you can have deployment, go to staging, you can go run some manual integration tests if you need to, and then you can carry that deployment on. That would be the next piece of it, and making sure that all those pieces are automated that are being orchestrated. And then the final piece is, are you comfortable with all of this to remove that gate, to remove that manual approval to go after production and once people are, then you start to see that end-to-end automated deployment. And it’s really, really fantastic to see.

    Mitch Ashley: Really Cool. So, I’ll make a premise supposition you can tell me if it’s true or not, it seems to me that last step of getting into the, okay, yeah, we’re going to pull the pin and let it go and see and let it automatically deploy. A couple things I would want to have experience with one is, how often do we say no when we’re doing a manual decision about, okay, it’s time to release, and when we do, what are the issues? The other is, well, if something does happen, I want to be able to quickly redeploy a fix to whatever it is, and we might’ve put in production, so in minutes, an hour, hour, whatever, very quickly. If I can’t deliver code that fast then maybe I’m not ready to quite go to the automation fully onto production. Is that a good characterization?

    Adam Frank: That is, yeah. I mean, the fact that we’re talking about that as well, the rollback of that as well, are you comfortable rolling that back? Do you have the mechanisms in place that are going to allow you to roll that back? And that’s again, where a great CD solution is going to enable that both automatically or by a single click. You actually see that the baseline is off and this isn’t behaving the way that it’s supposed to be or the way that it’s expected to be, you can one click and roll that back to the last known working state, or you can have that automatically rolled back based on looking at some of that observability data that might be outside of the expected threshold.

    Mitch Ashley: Interesting. So we’re at KubeCon, let’s talk about Kubernetes, that holds another layer of complexity and technology and challenges. How does that roll into it? What are the things you need to consider about automated delivery deployment with Kubernetes?

    Adam Frank: Yeah, I think one of the big things is people have their repos structured in a way that makes sense for their business. People also have a couple of different choices in the way that they’re architecting Kubernetes, so they’re going single big clusters, are they going multi clusters, depending on what they’re doing there. And one of the mantras that we have at Armory is we’ll meet the customer where they are. So we don’t tell people to structure their repos in a certain way, we don’t tell people to architect Kubernetes in a certain way, we don’t tell people that you have to have a CRD written in a certain format. However you have your Kubernetes manifest today, we’ll deploy that.

    And I think that’s one of the beautiful things that alleviates a lot of that complexity of Kubernetes is giving people that flexibility that allows them to meet their organizational needs. We’ll deploy that, that manifest, we’ll deploy those containers any way that you need.

    Mitch Ashley: Yeah, it could be multi-cloud, could be out to the Edge and whatever regional center. I mean, it’s-

    Adam Frank: The Edge stuff is getting really interesting.

    Mitch Ashley: And multiple Applications. It is, it’s picking up. I hear a lot more about the Edge.

    Adam Frank: Yeah, absolutely. I mean, the fact that people are running pretty small clusters, but still Kubernetes clusters out in cars is a great example. That’s one of the big ones.

    Mitch Ashley: One of the people of the big manufacturers in Germany speak about that.

    Adam Frank: There you go. There you go. I know there’s a big American one that does that as well. And again, that’s one of those use cases, having that data on board, shifting that data back to a staging environment, testing with that, and then deploying back out.

    Mitch Ashley: Maybe that’ll be a light on our dashboard. You’ll see the little captain’s wheel. Kubernetes, come on you’re cluster running somewhere in your automobile.

    Adam Frank: That’s it, that’s it.

    Mitch Ashley: It needs a [inaudible 00:09:33].

    Adam Frank: Yeah, yeah. I was actually really surprised when I first started hearing about that, thinking like well that’s got to be pretty resource intensive in a car, we’ve got to figure out a way to do that without having clusters in every single one of these cars and Edge and things like that. But it seems to be working so far, and we’re talking thermostats and things of that nature as well with some of our customers. So, it’s pretty cool.

    Mitch Ashley: I heard someone describe automobiles now are becoming software platforms with wheels.

    Adam Frank: Oh, yeah.

    Mitch Ashley: I mean, essentially-

    Adam Frank: That’s exactly what they are.

    Mitch Ashley: How much of it is, it’s all software, right? With some electric motors or whatever kind of things. So what’s coming up next, the next six months where we’re going to be at re:Invent?

    Adam Frank: We are, we are.

    Mitch Ashley: Hopefully we’ll see you there. What’s on your mind about the next set of things you want to work on?

    Adam Frank: Yeah, so we’re at KubeCon, we’re talking a lot about Kubernetes, but every single person that we talk to also has something else. And whether they’ve found that Kubernetes is a little bit too complex for them and they don’t want to invest the resources in it, and they move to another container service like ECS or they’ve got some serverless. Everybody seems to have some level of serverless, whether it be Lambda or whatnot.

    So one of the things that we’ve really been working on that we’re going to be revealing pretty big at re:Invent is not only deploying to Kubernetes, but also being able to deploy to Lambda in a declarative way. Kubernetes brought us the world of declarative and gave us that abstraction layer above, the imperative nature of things. So we’re now bringing that to Lambda and full blue green, full canary, and being able to just share that declarative config between your Kubernetes or Lambda deployment, so you can actually deploy to both within the exact same deployment, which absolutely nobody’s doing right now. So we are very-

    Mitch Ashley: To both, but also in parallel, right?

    Adam Frank: Exactly.

    Mitch Ashley: Because apps maybe running in both environments, different parts of it.

    Adam Frank: Precisely. Precisely.

    Mitch Ashley: Well, sounds like you get a pretty good peek into what’s coming.

    Adam Frank: Yeah, we’ll have to get back together at re:Invent and sit down and showcase and discuss that a little bit.

    Mitch Ashley: Yeah, we’d love to hear a lot more about that. That sounds exciting. Well, good.

    Adam Frank: Yeah.

    Mitch Ashley: Well, congratulations. I said you and I have talked before the show seems really great. I mean, the buzz and the traffic and conversations-

    Adam Frank: Yeah, its always good.

    Mitch Ashley: And I’ve been to a session, I never get to go to sessions anymore we’re always talking-

    Adam Frank: Likewise.

    Mitch Ashley: Which is good, I’m good. But I’ve heard that they’re really good as well.

    Adam Frank: Yeah, most definitely.

    Mitch Ashley: Great. Have a good rest of the show and we’ll see you-

    Adam Frank: Appreciate it, thank you much.

    Mitch Ashley: In Las Vegas.

    Adam Frank: See you there.

    Mitch Ashley: Okay, re:Invent.

    Adam Frank: All right.

    Mitch Ashley: All right, man.

    Adam Frank: Cheers.

    Mitch Ashley: Say hi to Adam, stop by the booth, go visit Armory. Check him out online Armory dot… Is it io or .com?

    Adam Frank: .io, Armory.io.

    Mitch Ashley: I thought io.

    Adam Frank: You got it.

    Mitch Ashley: Okay, good. Definitely check them out and lots of good things coming too, as well as where we are today with Armory. Okay, talk to you again.

    We’ll be right back with our next great guest.

  • Armory Extends Scope of Spinnaker CD Distribution

    Armory Extends Scope of Spinnaker CD Distribution

    Armory today updated both the self-hosted and managed editions of its distribution of the open source Spinnaker continuous delivery (CD) platform. The updates support concurrent pipelines and provide tighter integration with open source Terraform infrastructure-as-code (IaC) to better enforce policies.

    Previously, the two platforms were known as Armory Enterprise and Armory Enterprise Managed. They are now being rechristened; Armory Continuous Deployment Self-Hosted becomes Armory Continuous Deployment Managed in part to provide more differentiation from a CD cloud service the company rolled out last month that is not based on Spinnaker.

    Adam Frank, vice president of product for Armory, said other capabilities added to the platform include additional testing tools for contributions to the Spinnaker platform as well as enhanced plug-ins and remediation capabilities for Common Vulnerabilities and Exposures (CVEs) that might impact the Spinnaker platform.

    Despite launching a declarative CD-as-a-service platform that is not based on Spinnaker, Armory remains committed to supporting organizations that prefer to continue to rely on the open source platform, said Frank.

    The number of organizations that routinely make use of a dedicated CD platform is still relatively small. While organizations have been employing continuous integration (CI) within a CI/CD platform, making use of the CD element of those platforms has proven challenging. Each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise. Many organizations that attempted to extend the open source Jenkins CI/CD platform, for example, are now looking to more loosely couple CI and CD processes to make DevOps workflows less brittle, noted Frank.

    Armory is making a case for a distinct CD platform at a time when more organizations are starting to build microservices-based applications on Kubernetes clusters that expose a standard set of application programming interfaces (APIs) regardless of what infrastructure they are deployed on. In many cases, those organizations now need to manage multiple pipelines in parallel as application environments become more complex rather than relying on a single pipeline, noted Frank.

    There’s no doubt that as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. DevOps teams are releasing a larger number of smaller updates to applications and there’s also a need to be able to easily roll back those updates in case an unexpected issue is encountered, said Frank.

    It’s not clear yet how many organizations will be adopting dedicated CD platforms, but as application development continues to evolve many DevOps teams will, at the very least, be revisiting their existing processes. At the same time, there are also many organizations that are just beginning their DevOps journey. Most of those organizations are not committed to one CI/CD approach versus another.

    Regardless of approach, however, the expectation in the era of digital business transformation is organizations will be able to deliver software updates in a timely manner. The only way to achieve that goal, however, will be to have some type of CD capability that reliably operates at the scale required by organizations that need to operate like a true software company.

  • Armory Aims to Turn Continuous Delivery Into a Service

    Armory Aims to Turn Continuous Delivery Into a Service

    Armory this week made generally available a continuous delivery-as-a-service (CDaaS) offering that promises to make it simpler for a much wider range of organizations to programmatically deploy applications.

    The Armory Continuous Deployment-as-a-Service platform has been available in beta since March. It differs from Armory’s existing open source Spinnaker continuous delivery (CD) platform in that it is based on a proprietary declarative platform that is designed to integrate with third-party continuous integration platforms.

    Armory CEO Jim Douglas said the goal is to meet organizations that have invested in CI where they are versus requiring them to rip and replace their entire DevOps platform. The company is still committed to providing a curated instance of Spinnaker, but it’s become apparent there are many organizations that want to experience the benefits of a more opinionated CD platform that is more accessible via a cloud service, he added.

    The Armory Continuous Deployment-as-a-Service offering applies many of the best practices that have emerged for the Spinnaker CD platform without requiring organizations to have a dedicated team in place to just manage the CD platform, noted Douglas. IT teams can start using the service to deploy applications in less than 30 minutes, he noted.

    The first edition of Armory Continuous Deployment-as-a-Service is optimized for deploying microservices-based applications on Kubernetes clusters, but Armory will soon extend the reach of the service to platforms running monolithic applications, said Douglas. The company also plans to make available an on-premises edition, he added.

    In either scenario, IT teams will be able to engage in everything from canary testing of deployments to automatic rollbacks in the event an application fails, said Douglas.

    The number of organizations that routinely make use of a CD platform is still relatively small. Historically, each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise.

    Douglas said that as more IT teams start to build and deploy microservices-based applications, it’s only a matter of time before CD becomes a more distinct IT discipline. The challenge is enabling IT organizations to achieve that goal without necessarily having to hire a small army of site reliability engineers (SREs). There will still be plenty of DevOps teams that will prefer to deploy Spinnaker, but Douglas said there will also be plenty of instances where a less complex approach to CD will suffice.

    It’s hard to say whether there might soon be varying levels of DevOps platform services that organizations might invoke depending on the complexity of the project and their own internal cultural preferences. However, as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. There may be many ways to achieve that goal, but if history is any indication, the path of least resistance is likely to be via the cloud.

  • Armory Launches Continuous Deployment-as-a-Service Product

    Service allows developers to focus on building code rather than deploying it

    San Mateo, CA, June 16, 2022 – Armory, the continuous deployment (CD) company empowering development teams to easily, reliably, safely and continuously deploy software at any scale, has announced general availability of Armory Continuous Deployment-as-a-Service. The product delivers declarative deployments across multiple environments that support advanced progressive strategies, allowing developers to focus on building great code rather than deploying it, enhancing their customers’ experience and avoiding outages.

    “Our goal is to give companies a solution that’s simple to use but will grow with them as complexity increases,” said Jim Douglas, Armory president and CEO. “The new product enables development teams to confidently deploy their software every time without worrying about reliability and security.”

    Operational downtime can result in hundreds of thousands of lost revenue for many companies. Armory Continuous Deployment-as-a-Service prevents this type of loss, both as a standalone product for cloud-first companies and as an extension of a leading Continuous Delivery (CD) solution — Spinnaker™. Armory Continuous Deployment-as-a-Service provides easy-to-use, environment-specific controls and advanced deployment strategies such as blue/green and canary to specify how much traffic is exposed to new changes and when to automatically roll back if needed.

    This enables development teams to automatically and continuously verify a service is healthy before routing all traffic to the new version, limiting risk exposure, avoiding outages and protecting the customer experience.

    Upwave, a marketing analytics company, has embraced Armory’s new product. Previously, Upwave leaders said CD solutions were too cost-prohibitive and too heavy-weight for the relatively small company but decided to implement the new Continuous Deployment-as-a-Service because of its scalability. Upwave has since enabled continuous deployment and increased to over 100 deployments per week with a mean lead time of less than 20 minutes.

    “The main benefit is that we have converged on a simpler model of continuous integration/continuous deployment, enabling us to do more. It’s easier, it’s simpler, and we have more functionality,” said Christopher Baldwin, chief architect, Upwave. “Simply put, it raises the bar for quality across our engineering organization as a whole. Isn’t that part of the software development dream?”

    You can sign up for Armory Continuous Deployment-as-a-Service here.

    About Armory

    Armory makes continuous deployment achievable and effortless, at any scale, for all developers. Easy-to-use continuous deployment solutions eliminate the need to migrate away from existing tools and minimize disruptions to an existing software delivery lifecycle. Developers can easily and confidently deploy updates that improve and protect their customer experience.

    Founded in 2016, Armory is funded by B Capital, Insight Partners, Crosslink Capital, Bain Capital Ventures, Mango Capital, Y Combinator, and Javelin Venture Partners. Learn more at www.armory.io.

  • Armory Makes Continuous Deployment Achievable and Effortless, at Any Scale, for All Developers

    Armory makes continuous deployment to Kubernetes, easier, safer, repeatable, and reliable.

    San Mateo, CA, May 16, 2022 — Armory, the Continuous Deployment company empowering development teams to easily, reliably, safely, and continuously deploy software at any scale, today announced public early access to their new Continuous Deployment-as-a-Service product. Armory Continuous Deployment-as-a-Service delivers declarative deployments, across multiple environments, that support advanced strategies, so developers can focus on building great code rather than deploying it.

    “We believe deploying software continuously, at any scale, should be achievable and effortless for all developers of the world, not just the likes of Google and Netflix” said Jim Douglas, President and CEO, Armory. “It’s our vision and mission to unlock innovation through software to make software continuous, scalable, secure, and safe, so developers can improve and protect their customers’ experience with confidence and ease”.

    To effectively compete in a software-defined world, development teams must ensure a stellar customer experience. Some do this by focusing on velocity, others do this by ensuring their software is both always available and reliable. Delivering on both velocity and stability has remained difficult and elusive… until now. Armory Continuous Deployment-as-a-Service plugs into any existing Software Development Lifecycle (SDLC) and can be invoked from any existing toolchain or Continuous Integration (CI) system, including Amazon CodePipeline. This allows development teams to easily leverage the power of Armory Continuous Deployment-as-a-Service when deploying to Kubernetes services like Amazon Elastic Kubernetes Service (Amazon EKS).

    A single hour of downtime can cost more than $100,000 for many companies. Armory Continuous Deployment-as-a-Service prevents this type of loss, both as a standalone product for cloud-first companies — and as an extension of a leading Continuous Delivery (CD) solution — SpinnakerTM. Armory Continuous Deployment-as-a-Service provides easy-to-use, environment-specific controls to specify how much traffic is exposed to new changes and to automatically roll back if needed. This enables development teams to continuously verify a service is healthy before routing all traffic to the new version, limiting risk exposure and protecting the customer experience.

    “I really like Armory Continuous Deployment-as-a-Service. It’s also a fantastic extension for our Spinnaker users. I don’t see anyone else doing that in the industry, which is really cool.” — Damian Myerscough Software Engineer, DoorDash

    Additional Resources

    About Armory

    Armory enables developers to continuously improve and assure their customer experience.

    Software developers should be able to deploy their code effortlessly, without writing scripts, managing underlying tooling, or worrying about whether their customers are going to experience an outage. But, software deployment often is complex and full of manual process that leads to customer outages and less time spent on innovation. The bottom line, it remains disruptive, time-consuming, and unreliable.

    Armory makes continuous deployment achievable and effortless, at any scale, for all developers. By providing easy-to-use continuous deployment solutions that eliminate the need to migrate away from existing tools, minimizing disruption to an existing software delivery lifecycle; developers can easily and declaratively deploy new versions alongside live versions, incrementally scale up new versions, enable manual reviews prior to scaling up, effortlessly rollback to an old version, and, manage the deployment across multiple targets and environments; continuously improving and protecting their customer experience.

    Founded in 2016, Armory is funded by B Capital, Insight Partners, Crosslink Capital, Bain Capital Ventures, Mango Capital, Y Combinator, and Javelin Venture Partners.

    Learn more at www.armory.io.

    Contact
    Adam Frank
    adam.frank@armory.io

  • Armory Joins Continuous Delivery Foundation As Premier Member

    Armory provides enterprise version of Spinnaker, open source continuous delivery multi-cloud project housed under CD Foundation

    SAN FRANCISCO, April 13, 2021 – The Continuous Delivery Foundation (CDF), the open-source software foundation that seeks to improve the world’s capacity to deliver software with security and speed, today announced that Armory has joined the CDF as a premier member. Armory adds enterprise-grade proprietary features and support to the open-source Spinnaker project under the CDF.

    Spinnaker is a free and open-source multi-cloud continuous delivery software platform originally developed by Netflix and extended by Google. It is designed to work with Kubernetes, Google Cloud Platform, AWS, Microsoft Azure and Oracle Cloud. It has released hundreds of thousands of changes into production at Netflix and many other industry-leading companies like Adobe, Airbnb, Cisco, Grubhub, The Home Depot, JPMorgan Chase, Salesforce, Sony PlayStation, and Target.

    Armory joins CDF premier members CircleCI, Cloudbees, Fujitsu, Google, Huawei, IBM, jFrog, Netflix, and Salesforce in working together to make continuous delivery tools and processes as accessible and reliable as possible and  grow the overall ecosystem. Armory has been a General member since 2019.

    “We are moving up to Premier membership because the CD Foundation is the right governance model for continuous delivery software in general and Spinnaker specifically. This strong foundation directly benefits development teams by continuing to improve and strengthen the Spinnaker community. And with Armory providing needed enterprise-grade features and support, development teams can ship better software, faster,” said Daniel R. Odio, co-founder and CEO of Armory. “The CD Foundation is the exact right organization to help steer the course of development of Spinnaker, and we are enthusiastic about increasing our leadership role as part of the CDF.”

    Open source technologies such as Jenkins, JenkinsX, Spinnaker, Tekton, Screwdriver and Ortelius, which the CDF hosts, help development teams from companies of all sizes and industries improve their speed and productivity when creating cloud-native, legacy infrastructure, mobile, IoT, and bare metal applications.

    “Armory has been a part of CDF since the beginning, and this move to increase its participation in CDF is excellent for its customers, for CDF, and the broader continuous delivery software ecosystem,” said Tracy Miranda, Continuous Delivery Foundation Executive Director. “We know Armory well, and we’re thrilled to be working even more closely as we help enterprises worldwide accelerate the adoption of continuous delivery technologies and best practices as quickly and easily as possible.”

    Armory provides a collaborative software delivery platform with Spinnaker at its core. Amory’s enterprise-grade version of Spinnaker adds enterprise-grade features that make software delivery continuous, collaborative, scalable, and safe. Armory is a top contributor to the Spinnaker open source project.

    Spinnaker Summit

    The third annual Spinnaker Summit will be co-located with the CD Foundation’s cdCon (June 23-24, 2021). Registration for cdCon is free. Attendees need to add Spinnaker Summit registration as part of registering for cdCon.

    Options to Sponsor

    Spinnaker Summit and cdCon expect to host 3,000-plus virtual attendees, offer 45-plus sessions with 5 project-focused learning and collaboration tracks, plus engaging and inspiring keynotes on each day. The cdCon and Spinnaker Summit 2021 Sponsor Prospectus is available here (PDF).

    To find out more information and register today, see: https://events.linuxfoundation.org/spinnaker-summit/

    Additional CD Foundation Resources

     

    About the Continuous Delivery Foundation

    The Continuous Delivery Foundation (CDF) seeks to improve the world’s capacity to deliver software with security and speed. The CDF is a vendor-neutral organization that is establishing best practices of software delivery automation, propelling education and adoption of CD tools, and facilitating cross-pollination across emerging technologies. The CDF is home to many of the fastest-growing projects for CD, including Jenkins, Jenkins X, Tekton, and Spinnaker. The CDF is part of the Linux Foundation, a nonprofit organization. For more information about the CDF, please visit https://cd.foundation.

    About cdCon (June 23-24, 2021)

    Join Continuous Delivery leaders, industry icons, practitioners, and open source developers for a two-day virtual experience as we improve the world’s capacity to deliver software with security and speed. cdCon is the annual event by the Continuous Delivery Foundation that brings together technology teams, enterprise leadership and open source communities to drive the future of software delivery.

    This year’s sessions are designed for 3 different types of audiences:

    • Technology Teams: geared towards application developers, infra folks, DevOps engineers, security professionals, testers and any other practitioners involved with delivering software.

    • Enterprise Leadership: for senior leaders and decision-makers from organizations interested in measuring DevOps, scaling, transformation, security, FinOps, and developer productivity.

    • Open Source Communities: tailored for open-source core contributors and maintainers running and growing CDF projects and special interest groups, as well as folks looking to get involved with open source for the first time. This includes Jenkins, Spinnaker, Tekton, Jenkins X and other CDF communities.

    cdCon is a chance for our global community to come together to meet peers, share best practices and ideas, learn from each other and hear about the latest trends in software delivery.

    # # #

     

    The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

  • DevOps Chats: Plugins Extend Spinnaker for the Enterprise

    DevOps Chats: Plugins Extend Spinnaker for the Enterprise

    Spinnaker Summit 2019 Preview: Secrets management is vital to any vibrant DevOps and GitOps toolchain. As part of its open source maturation and thanks to the contribution of our DevOps Chat guest, Spinnaker now has a secure secrets management capability enabling GitOps, taking non-application secrets out of plaintext in hal config files.

    Cameron Motevasselani, software engineer at Armory, is giving his talk “Spinnaker Plugins: Extending Spinnaker for the Enterprise” on Sunday, Nov. 17, at 10:45 AM PT.

    In addition to his contributions to Spinnaker’s new secrets management facility, Cameron shares the work in progress to create an extensible Spinnaker plugin system. The current work is an early MVP to be followed by the implementation of PF4J and concrete extension points as part of Spinnaker stages.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Cameron Motevasselani—Motevasselani, thank you [Laughter]—a software engineer. He’s also a speaker at Armory. He has a couple of talks that are at the upcoming Spinnaker Summit 2019 in San Diego. First one—I guess this first one is on the plugin system and the second one is on secrets management.

    So, Cameron—welcome to DevOps Chat.

    Cameron Motevasselani: Hi. Thanks for having me.

    Ashley: Glad to have you on. Well, tell us a little bit about yourself. Introduce yourself and tell us a little bit about what you do at Armory and what Armory does.

    Motevasselani: Oh, totally. Yeah. So, I’m Cameron Motevasselani. Thanks for the quick introduction. Let’s see, I’ve been at Armory for about a year now. I joined and hopped feet first and started working on this secrets management project. So, that was pretty cool. And then, now, recently, I’ve been working on this plug-ins system. Yeah, that, I think, about sums it up.

    Ashley: Great. What does Armory do? Yeah.

    Motevasselani: Yeah, Armory, we basically have an enterprise offering for Spinnaker. So, we have some extensions that we’ve written on top of Spinnaker, so we don’t fork and have to maintain all that, we just—we extend Spinnaker and provide some extra features that way.

    Ashley: Very nice. Now, the way you phrased that, you’ve been working on secret management and the plugin. Does that mean you’re actually contributing, writing code and contributing it to the open source, or are you primarily an implementer of what’s already been built?

    Motevasselani: Oh, no, that’s a great question. Yeah, for the secrets management as well as plugins, we both, we’re contributing directly to open source for both of those projects.

    Ashley: Awesome. Excellent. Well, let’s start with secrets management. I mean, I think we all kinda have the idea of where we’re gonna keep our keys, our passwords, certificates, all that good kinda stuff. We don’t want that heading into the source code management system or somewhere in the cloud or in someone’s software. Tell us a little bit about the secrets management part of Spinnaker and what you’ve been doing, what you’re gonna talk about.

    Motevasselani: Yeah, totally. So, secrets management really came up as we started talking with customers about their Spinnaker setups and how they deploy and manage the configurations for Spinnaker.

    As you know, Spinnaker has the keys to the kingdom, essentially. It has your cluster keys and your credentials in order to deploy cloud resources that cost you money, right? And those are running—it runs the code that your organization arrives on. You can’t have that in source control. That is not, not good to have.

    Ashley: No-no—a big no-no, though a common mistake. [Laughter]

    Motevasselani: That’s right. Right. [Laughter] I think GitHub even yells at you now, if you have keys—

    Ashley: Oh, does it? [Laughter] Nice.

    Motevasselani: – in there. So, they’ve been adding nice little security features here and there. People would like to move towards this idea of GitOps so that you can manage your configuration via pull requests. It’s a great idea, and a lot of people can’t do that, because the keys are quite literally in the Spinnaker configurations.

    So, we pull those keys out and are essentially referring to them with our secrets management solution. So, you can use different backing stores such as S3 buckets or Vault and store your secrets there and then refer to them in the Spinnaker configuration that way.

    Ashley: Mm-hmm. Excellent, great. So, in your talk, you’re gonna be walking through what you’ve been doing, the functionality of it, how to implement it via GitOps?

    Motevasselani: Yeah, so—that’s right. The functionality, how it differs from, there are other solutions coming into open source now that tackle a slightly different use case. So, discussing the differences there as well as the future, essentially, of secrets management.

    Ashley: Okay. Very good. Great. Anything else to tell us about that before we move into the plug-in system?

    Motevasselani: Yeah. You know, secrets management, it is about the secrets for Spinnaker in particular. It’s not actually tackling the application secrets themselves.

    Ashley: Oh, okay.

    Motevasselani: So, I just wanted to make that clarification. And that’s at the current time. It’s possible that we might have a story for that in the future, but the talk that I’ll be giving is around Spinnaker secrets, not application secrets.

    Ashley: Okay. So, this is just what’s required to run, operate, manage the Spinnaker environment, not your application secrets?

    Motevasselani: That’s correct.

    Ashley: Okay, great. Well, that’s an important clarification. Great. Well, let’s talk about the new plug-in system. What is new about it, other than being new code?

    Motevasselani: Yeah. So, the plug-in system is, we’ve been developing it as a very—it’s been a very alpha, MVP type feature. So, right now in open source, we do have a method for users to create custom stages in Orca. There is quite a bit of knowledge and expertise that you have to have in order to do that, so I don’t quite recommend doing it right now. But we’re building on this plug-in system and we’ll be testing it out with users hopefully in the near future.

    So, right now, there’s currently no UI, but we’re working on a UI and then that should be getting open sourced as well in the future.

    Ashley: Now, that sounds like kind of a tough assignment. How do you create a plug-in system that anybody can do anything they want with, because that’s probably one of the requirements is, you want a lot of flexibility. How do you go about architecting and designing that so what you’re building can be extensible and you’re not gonna have to re-do it in a year?

    Motevasselani: Yeah, that’s such a great question. Because we are going with this MVP model of just getting something working and then getting feedback on it to iterate, we actually are already planning on deprecating this first, let’s say, method of loading plugins into Spinnaker. We’ve already been doing some internal revs on it and we’ve been working with the community, Google and Netflix in particular, on this project. So, we are going to be moving away from our current implementation into another full-fledged plug-in framework, and we’ve chosen PF4J for that.

    Ashley: Okay. Now, I’m not familiar with that framework. Can you tell us a little bit about that?

    Motevasselani: Yeah, so the way we currently did it—and hopefully, this isn’t giving too much of my talk away [Laughter]—but the way we’re doing it right now is essentially shoving JARs into a ClassLoader for Orca. Well, via Quark. So, these are different Spinnaker services and libraries that make up Spinnaker.

    Ashley: Mm-hmm.

    Motevasselani: Right now, it’s a pretty dumb way of doing it, just adding JARs onto a Classpath in order to load it onto the Spinnaker spring application context.

    Ashley: Makes sense. Pretty easy way to do it.

    Motevasselani: Yeah, exactly. But like you’re saying, there’s no—it’s very open ended right now. We are going to, as we move to PF4J, define concrete extension points within Spinnaker so that there’s actually not a sprawl of extension points, there’s clearly defined extension points throughout the code.

    Ashley: Mm-hmm.

    Motevasselani: That will help us iterate on this feature and make sure it’s a good solution as we continue developing it.

    Ashley: Okay, and this is the PF4J that’s on GitHub? I think it’s an Apache license, right?

    Motevasselani: Yeah, that’s correct. I believe it’s Apache. That’s correct. And so, moving into PF4J will give us a lot of really nice features that our current implementation doesn’t have, such as using a different ClassLoader for every plug-in so that it can have its own dependencies, et cetera.

    Ashley: That makes a lot of sense. Are there any unique challenges for implementing a plug-in system in an environment like Spinnaker? You know, this is software to create software, software to deploy software. You know, it’s not an application in and of itself, it’s something that you’re gonna make a key part of your kinda tool chain, your workflow pipeline. I wonder if there’s any unique challenges that come about in trying to build this.

    Motevasselani: Yeah, it’s interesting, because we have been looking at, you know, as you develop something new, you look at prior art in order to determine how to build what you’re building, I guess. [Laughter]

    Ashley: Mm-hmm.

    Motevasselani: For lack of a better word.

    Ashley: Technical speak, I know. [Laughter]

    Motevasselani: That’s correct. [Laughter] So, looking at something like Jenkins or Eclipse that both have plug-in systems, same with WordPress, those are all kind of monoliths, right?

    Ashley: Mm-hmm.

    Motevasselani: Spinnaker is definitely many different microservices composed into one application. Essentially, we’re just kind of turning it into a platform, kind of, by making it extensible and pluggable.

    But that is, to answer your question, a major challenge is, you have all these different microservices. You know, depending on how you deploy and update your Spinnaker installation, they might be on different—I don’t wanna say different versions, but if you’re deploying master all the time, you might have a different set of microservices in production compared to if you’re all running the same release version.

    So, deploying plug-ins into that environment is not an easy task and how you get the versioning done is important, as well as rollbacks.

    Ashley: You kinda have a recursive problem here, right? Because you have to version control the plug-in manager, which then version controls of what plug-ins can work with it, c?

    Motevasselani: Yeah, exactly. Plugins might rely on some functionality that is in one version of a microservice that’s not in another version, and if you need to do a rollback, how does that work, et cetera. That’s correct.

    Ashley: Well, you kinda took my breath away for a moment. You scared me when you said, you mentioned the WordPress plug-in system.

    Motevasselani: [Laughter]

    Ashley: Please, don’t do that! [Laughter]

    Motevasselani: I do think, though, that WordPress is an example of a project that has done very well—

    Ashley: They have.

    Motevasselani:—because it has such as good ecosystem of plugins.

    Ashley: It’s come a long way. It has come a long way. It’s much more, I don’t know, not self-sustaining, but kinda auto updating much better than it used to be. [Laughter]

    Motevasselani: Right, right. And we do hope to take learnings, right, from past projects, let’s say, as well. [Laughter]

    Ashley: Absolutely. I don’t mean to dis WordPress, you know? You gotta every once in a while. Well, tell us a little bit about more about your talk. What are you gonna cover, then? Is this more how to use it, or you’re gonna lay out kinda where you’re going in this next version and you’re looking for feedback? What are you trying to accomplish or get out of it? What would you like to have happen in the talk?

    Motevasselani: Yeah, you know, that’s a really good question. I think there’s a lot of stuff to cover, all the way from our journey running and creating this project, working with the community and those efforts, to showing users, “Hey, this is actually a nice and easy way of modifying or extending Spinnaker’s functionality.”

    The idea here is to—there’s kind of a few ideas here with this project, because we really want to lower the barrier of entry for users, particularly in enterprises, to be able to create extensions for Spinnaker. The method we chose to do this at first was a way that most users interact with Spinnaker, and that’s creating pipelines and defining stages.

    So, let’s say an enterprise has some custom infrastructure at their business running their data centers, running their cloud. If they want to, let’s say, interact with that in a native—in a Spinnaker native way, you would want to have a stage that their users can just choose. So, rather than having to learn how Spinnaker works on a very deep level, you can implement this nice, simple interface and get it going.

    So, at the end of the talk, it would be great for the audience to have an understanding of how to create and implement their plugin on their own.

    Ashley: Oh, excellent. Well, then, hopefully, you can, you’re creating an audience and a community to go out and try your new plug-in system and the variations of it.

    Now, you talked about using plug-ins as extensions to Spinnaker. Do you also see this plug-in system being kind of an integration interface to third party tools, maybe other open source, other commercial tools, or is it more things that just extend the functionality of Spinnaker?

    Motevasselani: Oh, that’s a really good question. So, there is a push to move Spinnaker to be a lean core and an expansive ecosystem, I believe, is the term being used, and this goes directly towards that goal. There’s certain functionality in Spinnaker, the core, Spinnaker core, that doesn’t quite make sense.

    For instance, there’s some stages that are specific to companies. Don’t wanna call Gremlin out, I think they do great work. There’s a Gremlin stage in Spinnaker that should probably be a plug-in. So, hey, Gremlin guys, hit me up. [Laughter] But not quite yet, maybe for the end plug-in system.

    Ashley: It’s that evolution of software, right?

    Motevasselani: Exactly.

    Ashley: I mean, that’s how you get to this point where you need to do that, you need to spin things out, so it’s part of its growth.

    Motevasselani: That’s right, that’s right. Yes. It would be really cool if you could have a Spinnaker installation where you can essentially pick and choose which cloud providers you want to have installed and running. If you only—you know, if you interact with, let’s say, both Google and Amazon’s cloud, maybe you don’t need Oracle’s cloud software to be on your cloud driver. Or maybe you want to have a cloud driver in each of those data centers—sorry, in each of those cloud accounts that only has the code necessary to deploy to that cloud environment.

    Ashley: Mm-hmm.

    Motevasselani: So, then you have a smaller attack surface, just leaner and smaller binaries, et cetera, et cetera.

    Ashley: Great. Well, I think, unless there’s anything you wanna add, I think you’ve given a really comprehensive look to kinda what that talk, both talks are gonna be about.

    Motevasselani: Yeah, that’s—you know, that’s hopefully, just getting the community excited and get some ideas flowing, I think, would be great with those talks.

    Ashley: Well, and I also wanted to just throw in my little thanks just to appreciate what you do and all the other contributors to the projects in software. And I always encourage people who are just using open source, and there are folks at the Spinnaker Summit who are implementing it, not writing code for Spinnaker, but talking about it at a summit like this is another way to contribute to the community. So, great to talk with you who are actually writing code as well.

    Motevasselani: Yeah, thanks. Nice talking with you, too, Mitch.

    Ashley: Great. Well, it’s been my pleasure. You’ve listened to another DevOps Chat podcast. I’d like to thank today’s guest, it’s Cameron Motevasselani, software engineer at Armory, and he is speaking at Spinnaker Summit 2019. The dates for the conference are November 15th through 19th in San Diego, and Cameron has two talks. His talk on the plugins is Saturday, November 16th, at 2:30 p.m. And then he’s also talking bright and early about secrets management—boy, you’re really gonna wake ‘em up here—Sunday morning at 9 a.m., Cameron, so. [Laughter]

    Motevasselani: [Laughter]

    Ashley: So, you know, maybe you serve mimosas at the morning talk. [Laughter] So, it’s been my pleasure to have Cameron on, and thank you to all of our listeners today for joining us. This is Mitch Ashley with staging-devopsy.kinsta.cloud. You’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • DevOps Chats: Spinnaker Extensibility, With Armory

    DevOps Chats: Spinnaker Extensibility, With Armory

    Spinnaker Summit 2019 Preview: Most open source software isn’t one size fits all, and Spinnaker is no different. While it captures the most general use cases of software delivery, most organizations find that it lacks some features they need to automate their entire delivery pipeline, such as integrations with internal tooling or compliance systems.

    Out of the box (figuratively), Spinnaker provides Run Job and Webhook stages that teams can use to build custom integrations to help fill any void and enable adoption by a wide range of users.

    Ethan Rogers, staff software engineer with Armory, joins us on DevOps Chat to share a preview of his Spinnaker Summit 2019 talk on Spinnaker extensibility. Ethan shares how Run Job and Webhook stages are used to build custom stages to capture any number of use cases with no code and simple configuration. He also covers situations when it’s necessary to write code.

    Ethan’s talk, “Making Spinnaker Your Own,” is on Saturday, Nov. 16, 3:45 PM, at Spinnaker Summit 2019 in San Diego. Separately, Ethan appears on the “State of the Kubernetes V2 Provider…” panel Friday, Nov. 15 at 2:30 PM.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Ethan Rogers. Ethan is a staff software engineer and also a speaker at Armory. He’s gonna be talking at the upcoming Spinnaker Summit 2019 in San Diego. Now, Ethan’s gonna be talking about making Spinnaker your own, that’s his talk, and then he’s also gonna be on a panel about the state of Kubernetes V2 Provider, plus improved rollout strategies for deploying Kubernetes using Spinnaker.

    So, let’s get started. Ethan, welcome to DevOps Chat.

    Ethan Rogers: Thank you so much for having me. I’m really excited to be here and get to talk about Spinnaker.

    Ashley: Wow. Absolutely. Great topic. I know you’re passionate about it, so fantastic to have you. Would you just introduce yourself? Tell us a little bit about you, what kinda work that you do and a little bit about Armory, the company that you work for?

    Rogers: Yes. So, like Mitch said, my name is Ethan Rogers, I’m a staff software engineer at Armory. I’ve been actually working on the Spinnaker project for about the last three years. I’ve been at Armory for a year and a half, and then a year and a half before that, I was working for my previous company where we were, you know, I was part of a team for delivery and developer experience. And, you know, we were using Kubernetes for this new project that we were working on and looking for a way to deploy and got involved in Spinnaker super early on. So, I’ve kind of been a part of the community ever since then and it’s been a really great experience so far.

    Yeah, so, that is actually kind of how I found Armory. Closer to the end of my time at my last job, I met the founders, DROdio, Ben and Isaac, and they had just—eh, within probably six to nine months started Armory. And we kinda hit it off. I had a really good relationship with the founders and it was kind of an opportunity to go keep working on Spinnaker full time, which is something I was interested in.

    So, Armory, just a little bit about us—we’re bringing Spinnaker to the enterprise. So, what we’re doing is taking open source Spinnaker and, you know, on top of offering stuff like support and training, we also offer layers on top of open source Spinnaker, various different extensions and features that make it more aligned with what the enterprise is looking for today.

    Ashley: Mm-hmm. Very good. Well, that explains, I know there’s yourself, but there’s also some other folks that are speaking at the conference.

    Now, your topic, you gave a nice introduction about how you got involved with Spinnaker—how long ago was that, when you started using it?

    Rogers: Yeah, it was about three years ago, kind of before the—like, right when the first version of the Kubernetes provider landed. I think, at the time, I didn’t realize how early we were. It kind of explains a lot of the PRs I had to submit when I first got involved.

    Ashley: I’ll bet, I’ll bet. Do you write any code, submit any code or are you primarily on the usage end of Spinnaker?

    Rogers: Yeah, so, I’m actually a developer by training. I got my degree in computer science, and transitioned pretty early on in my career into the ops side of things. So, I’m pretty fluent in both. I actually do write a lot of code. These days a lot less, just because of the role I’m in. At Armory, I do a lot more higher level stuff like BitTorrent, but I still try to get a few PRs submitted every week. I lead a couple of initiatives in the Kubernetes provider itself, so I do a little bit of everything.

    Ashley: Well, I won’t ask you which is the dark side, ops or developing—no, I’m just kidding. It’s DevOps, it’s all together now, right?

    Rogers: [Laughter] Yep.

    Ashley: Okay. So, let’s jump into what you’re gonna be talking about. And, of course, we’re not gonna cover it all here, but I know that you’re focusing on kinda how open source, you usually don’t just use it out of the box, if you wanna use that term. I know it’s free and downloaded.

    Rogers: Mm-hmm.

    Ashley: But that you have to do some customizations to kinda get it working in your environment, and we’re talking about Spinnaker here. What’s your experience working with customers? What’s their expectation when they start to use Spinnaker and what do you have to kinda help them get started with?

    Rogers: Yeah. So, the interesting thing about Spinnaker open source is that it’s actually, like, a very small part of what Spinnaker is at Netflix. For anyone listening who doesn’t know, Spinnaker was a project that was born out of Netflix. They built it, it was the next iteration in deployment technology from a project called Asgard.

    Ashley: Mm-hmm.

    Rogers: And one of the driving principles of Spinnaker was making it extendible. And the primary reason for that was because Netflix has a lot of kind of internal workflows and things that they like to—that make their development experience better, that don’t necessarily apply to the broader community.

    And so, when you start using open source Spinnaker kind of out of the box, there are a lot of things that I think most companies want, right? The same reason that Netflix has those, the things that don’t apply to the community but work for them, every other company has something like that.

    Ashley: Mm-hmm.

    Rogers: So, when I was at my previous company, we had this workflow around our Docker images where we would add labels to our Docker images and then we wanted those labels to show up in the Kubernetes manifest where those images were deployed.

    So, that was something that wasn’t available in Spinnaker out of the box, but we were able to use some of the extension methods to actually go grab that information and inject that stuff, which is kind of the basis of the talk I’m giving around Run Job.

    Ashley: Okay, great. Well, let’s explain that, then, because I know you’re gonna be talking about Run Job and about Webhook Stages. What is Run Job, what is Webhook?

    Rogers: Sure, yeah. So, just kind of, at a high level, Run Job and Webhook are ways that you can extend Spinnaker to kind of make it—to do the things that it doesn’t do out of the box that you need it to.

    Ashley: Mm-hmm.

    Rogers: There are more complicated ways to extend Spinnaker that involve actually taking the code and writing Java code, but we found that the majority of users or operators, I should probably say, are not super familiar with Java. So, that’s a pretty—it’s fraught with friction, I would say.

    Ashley: Yeah, it’s a whole other ball of wax, right?

    Rogers: Yeah, exactly. Yeah. So, the Run Job stage and the Webhook stage give kind of a lower friction way of extending Spinnaker. So, the Webhook stage is a stage within Spinnaker that lets you call out to some API. There’s the, you know, I select it as a stage in my pipeline via drop down and I configure it there. There’s also what we call preconfigured Webhooks or custom Webhooks that allow you to actually configure this as part of Spinnaker’s configuration, and then it shows up like it’s a native stage.

    Ashley: Mm-hmm.

    Rogers: So, under the hood, it’s still calling out to APIs. It’s as if you’ve configured it in line, but it shows up and, to the end user, actually looks like it’s part of Spinnaker itself.

    Ashley: Very nice. So, what are some of the most common uses of that to extend integrations into other things? Is it internal third party tools, internal custom software people who built, is there, you know, typically—the typical use cases for this?

    Rogers: I think that we usually end up seeing people integrating more with internal systems than, say, hosted services like GitHub or other—I don’t know, GitHub’s probably the easiest example. New Relic is another one that we see.

    But I think where, in most cases, Spinnaker has integrations for the public stuff out of the box, but obviously, if the tool’s internal to your company, you don’t have that. So, that is usually where we see it. So, I think there was one company that I had talked to that was, they had this internal integration testing suite or load testing suite that they wanted to call out to, and they used the Webhook stage to make that call and kick off those tests.

    Ashley: Mm-hmm. Great, great. Now, I understand you can do a lot of this without writing code, is that correct?

    Rogers: Yeah. Yeah.

    Ashley: So, what does that entail? What kind of a—what’s the configuration process look like to tie, let’s use that example that you gave of someone that wrote their own test framework of some kind that they wanna call out to in a Webhook stage?

    Rogers: Yeah. So, I guess I should probably back up and clarify my answer a little bit.

    Ashley: Okay.

    Rogers: So, at some level, you will need to write code. The question is whether or not you actually have to write that into Spinnaker itself.

    Ashley: Okay.

    Rogers: One of the, I guess we can call it native extensions, which is essentially using Spinnaker as a library and writing Java and doing some spring magic to make it happen.

    Ashley: Mm-hmm.

    Rogers: So, if you were to use a Webhook or a Run Job stage, for that matter, you would have to write a little code. But the benefit of that, if it’s a Webhook the service, whatever service that you’re trying to connect to can be written in whatever language that you want, right? So, if it’s Go, if it’s Python, if it’s Ruby, if it’s—you know, whatever you wanna do, the service is running in the API as the contract that you expect.

    Ashley: Mm-hmm.

    Rogers: And so, with the Webhook stage, all you’re doing is making a call. You know, you could argue that writing a cURL command is writing code, but I think a lot of people are familiar enough with that, that it’s a pretty low overhead.

    Ashley: Mm-hmm.

    Rogers: So, if you can make a call in your terminal, you can make a call from Spinnaker with the Webhook stage.

    The Run Job stage is actually a little more interesting, because what it allows you to do is run a container as if it were a script that you might be running. So, a really common pattern for doing custom logic in CI systems specifically is, I have a container, the container has all my dependencies and it has a script that I need to run. And we just run it like a one shot, you know—once this script finishes, if it fails, the pipeline fails. If it succeeds, the pipeline continues. And then, like, the world is really open, the world is your oyster at that point, because you can write the script in whatever you are most comfortable writing, and then you can run that within Spinnaker.

    One of the more interesting things that we did with the Run Job stage is that you can actually output—you can output these special markers in your logs and Spinnaker will go grab those and inject them back into the pipeline so that you can use them in downstream stages. So, maybe your job is going off and collecting some information for you. You can actually use that in, like, say, your deploy stages or a downstream Run Job stage or Webhook stage as, like, arguments you pass down.

    Ashley: It’s almost used like the log is like an asynchronous message bus, to make it more complicated than it is, but a super simple version of that.

    Rogers: Yeah, yeah.

    Ashley: Some down stage version where you could look at what happened before it and take appropriate action.

    Rogers: Yeah. Yeah, and that’s really—you know, we heard, the motivation kind of behind that feature is, we heard a lot of users, like, you know, they wanna be able to extend Spinnaker, but they don’t wanna write Java code, you know? And containers, for the Run Job stage specifically, containers are obviously super prolific in our industry today. I’ve built my career off of Kubernetes and containers, so.

    Ashley: Mm-hmm.

    Rogers: Containers are kind of like the perfect medium for being able to do this, because you can contain everything that you need—[Laughter] you can contain everything that you need in this container, and then, because Spinnaker can run containers in Kubernetes, it’s kind of like a natural fit, right?

    Ashley: Mm-hmm.

    Rogers: We can kind of take advantage of the fact that it doesn’t matter what your code is, the interface that we need is a container and then the logs, and we can get all of that information out.

    Ashley: I’m curious—this is totally a side question, but did you learn anything in college about containers and that kind of thing in software architectures, or is this something that you really started in after you graduated?

    Rogers: I wish I had learned something in college about this. So, I actually, I graduated college in 2013, and got my start writing PHP and doing a lot more software development. But in the back of my head, I’d always been like—I am very interested in servers.

    Ashley: Mm-hmm.

    Rogers: So, writing the code was interesting to me, but it always seemed like the people with all the power and all the really, people that I looked up to, they were the guys, like, in a shell, deploying software, checking, like, “Is this server overloaded?” It was very much not DevOps, but it was something that really interested me.

    Ashley: Sure, yeah.

    Rogers: And I—you know, I kind of, I spent probably three years as a software developer without having done that. But once I transitioned kind of into this CI/CD space, that really gave me an opportunity to focus more on ops, while doing some development and, you know, we picked up Kubernetes at my last job, and that’s where it all kind of kicked off.

    So, I think we started on Kubernetes 1.4, and that’s really where I learned everything I know about containers and orchestration platforms and stuff like that.

    Ashley: Well, it puts you in a really great position, because you can speak to both sides, both audiences, if you will, you know, developers and operations folks.

    Rogers: Yeah.

    Ashley: And, you know, my experiences before kinda containers and all of this, all the DevOps environment, some of the best developers were engineers who really knew how to write code, but they knew the full stack down to the operating system and the network, right? They kinda knew enough of all of it. Maybe there were really good parts of it, too, besides writing code.

    Rogers: Mm-hmm.

    Ashley: There’s a lot of, I don’t know, power, if you will, in understanding that full stack and how it works.

    Rogers: Yeah. I found that the more you understand about the stack, the better positioned you are to take advantage of it, right, and to actually write better code. You can go back and probably look at the birth of DevOps and see this, but engineers that spend the majority of their time writing code and then throwing it over the wall are more likely to write less performant code, right? Code that is not aware—you know, we wanna write really abstract code, but at some level, you have to be aware of what type of environment you’re running in.

    So, if you’re running on a machine that has 128 cores and hundreds of Gigs of RAM, it doesn’t really matter how inefficient your algorithm is, because it’s gonna run fast. You know, it all depends on scale, but … I’ve found that engineers that understand kind of the cloud and the environments they’re running in and what the actual, you know, where are your network boundaries and what are your actual constraints are writing better code, they’re shipping more frequently, they’re iterating—like I said, they’re iterating more quickly and that all of that is super important.

    I think the other thing that I’ve found is that it’s a growing process, right? I kind of like to look at it as—well, at least in my personal experience, I’ve found that I have a hard time grasping, kind of, the next level of what I’m doing until I’ve fully understood the previous level. And I think that’s really true for a lot of people, right? Until you’ve got a solid grasp of programming, it’s kind of hard for you to imagine what it would be like to understand ops, right? To understand how your program is actually running on servers.

    Ashley: Yeah. I would describe it as kinda context. It helps to know when you understand the environment of what you’re operating in and what you’re doing, what you’re building is going to operate in. And vice versa, right? If you’re in operations or security now, with DevSecOps, understanding now how software is being built. So, it’s the great thing about the accessibility of resources around the cloud and contemporary software architectures and all of that.

    Rogers: Yeah.

    Ashley: Well, we’re running out of time. I wish we had more time to invest in this, but the great thing is that you have your talk coming up, so that’s where you’re really gonna get into more details about that. And Ethan, I thank you for being on the podcast.

    Rogers: Of course, man. Thanks for having me.

    Ashley: Absolutely. Ethan Rogers, staff software engineer and also speaker from Armory, he’s speaking at Spinnaker Summit 2019, which is on November 15th through the 19th in San Diego. Now, he has a topic that we were just talking about, “Making Spinnaker Your Own,” that’s on Saturday, November 16th, 3:45. He’s also on the panel about the state of Kubernetes V2 provider. That is on Friday, the day before—the 15th at 2:30.

    So, thanks to you, all of our listeners, for joining us for this episode. This is Mitch Ashley with staging-devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory this week committed to advancing adoption of the open source Spinnaker continuous delivery (CD) platform in enterprise IT environments after revealing it has raised an additional $28 million in funding.

    Company CEO Daniel Odio said Armory will add proprietary tools to a curated distribution of Spinnaker that will make it easier for the average IT organization to deploy and manage Spinnaker. Developed by Netflix, Spinnaker is gaining traction as a CD platform in the wake of becoming one of the four projects being managed under the auspices of the Cloud Delivery Foundation (CDF), an arm of the Linux Foundation.

    Spinnaker is designed to be a CD platform that includes all the management tools required to manage that process. While continuous integration/continuous deployment (CI/CD) platforms such as Jenkins have addressed aspects of CD, most of the daily usage of those platforms has been squarely focused on continuous integration. As part of an effort to meld CI/CD platforms and Spinnaker, the CDF has accepted both Spinnaker and Jenkins as part of the first four projects that will be developed under its auspices. The other two are Jenkins X, a CI/CD platform specifically designed for building microservices-based applications on top of Kubernetes, and Tekton, a set of pipelines also designed specifically for Kubernetes.

    Odio said there are already more than 500 organizations using Spinnaker, and each one is not standardized on a specific CI/CD platform. Armory is part of the CDF but also sees a need for a curated instance of Spinnaker that is optimized to meet the needs of enterprise IT environments, he said.

    In general, Odio said a “flywheel effect” manifests once an organization launches roughly its eighth project using Spinnaker. From that point on, adoption of Spinnaker starts to accelerate to the point where an organization sees the need to standardize on a single curated instance of Spinnaker, he said.

    The bigger issue as far as adoption of Spinnaker and other DevOps tools remains cultural, Odio added. Many organizations still don’t accept the fact that CI/CD platforms are intended to foster a level of accelerated development that makes it more feasible to experiment and innovate. There are, of course, inherent risks to that approach in the sense that many of those projects might fail. Many enterprise IT organizations are still coming to terms with the need to accept higher levels of failure as the price of learning, he noted.

    In the meantime, many organizations that have embraced DevOps now find themselves on the cusp of a major transition as the shift toward cloud-native applications increases. Most CI/CD platforms today were designed to accelerate development of monolithic applications. Now what’s needed is a new generation of CI/CD platforms that are designed to accelerate development of microservices-based applications based on containers. As a result, many organizations will end up employing multiple CI/CD platforms. Armory is betting many of them will try to delineate where CI leaves off and CD begins.

    — Mike Vizard