devopsy.kinsta.cloud

Tag: Puppet

  • Puppet Enterprise Raises the Bar for Enabling Fast, Reliable Software Change

    San Diego, CA – October 20, 2016 – Puppet, the standard for automating the delivery and

    operation of the software that powers everything around us, today at PuppetConf

    announced the availability of major updates to Puppet Enterprise 2016.4, including a new

    integration with Jenkins. New reporting capabilities give teams significantly greater visibility

    into change, while new orchestration capabilities intelligently enable teams to segment

    their infrastructure and execute phased deployments so they can deploy faster, more

    frequently and more reliably. With this latest release, Puppet Enterprise deepens the

    foundation for building DevOps practices by making it easier than ever to gain situational

    awareness and orchestrate software change confidently, no matter what your software

    runs on.

     

    “In today’s software-driven world, organizations need to ship new releases fast and error

    free,” said Jamie Hull, vice president of product at Puppet. “Making things even more

    difficult, they need to be able to do both these things in increasingly complex, mixed

    environments. The latest features in Puppet Enterprise help our customers confidently

    navigate this complexity by providing more direct control over deployments, as well as

    greater insight into what changed on their systems, why and by whom.”

     

    Richer Situational Awareness

    All too often, changes to infrastructure and applications can be a black box, with little

    visibility into who changed what and when, heightening security risks as a result. It’s critical

    to understand what’s happening across all your software so you can more effectively react

    and take control directly and confidently. While many tools can tell when a change

    occurred and what changed, they don’t have the situational awareness to tell you why

    something changed or who changed it.

     

    Without this awareness into the state of infrastructure, and the origins and impact of

    changes, it’s difficult for organizations to deploy change confidently. This is especially

    problematic for large organizations with independent teams that span infrastructure and

    applications.

     

    Puppet Enterprise 2016.4 solves this problem by providing deeper visibility into the cause

    of change across an organization's infrastructure with reporting that identifies intentional

    changes (changes you’ve defined) versus corrective or unexpected changes (manual but

    unplanned changes or configuration drift), which Puppet is designed to automatically

    correct.

    ● Know exactly when unexpected changes occur so you can alert security teams

    quickly when needed, troubleshoot faster and reduce mean time to recover.

    ● Drill into specific configuration resources to understand exactly when unexpected

    changes occur and what changed to identify potential security issues faster.

    ● Know whether changes occurring across infrastructure are the result of drift from a

    desired state to identify lapses in process within an organization’s use of Puppet.

     

    Orchestrate Phased Deployments with Puppet

    Modern infrastructure and applications are incredibly complex, which can make it difficult

    to maintain centralized control and quickly and reliably deploy changes in a way that

    accounts for all infrastructure dependencies. Traditional approaches to orchestration lead

    to conflicting configurations or undocumented, ad-hoc changes because they lack the

    intelligence of dependencies and the automated workflows to ensure that proposed

    changes won’t cause failures.

     

    Puppet Enterprise 2016.4 gives organizations full and direct control to drive change

    confidently and easily orchestrate ordered deployments across infrastructure and

    applications. This approach reduces risk when rolling out changes by running phased

    (canary) deployments, whether to an isolated set of your infrastructure, a specific

    application or your entire data center. With Puppet Enterprise, IT teams now can:

    ● Orchestrate phased deployments of change by targeting specific portions of their

    infrastructure and applications for updates.

    ● Segment their infrastructure and applications based on any facts stored in Puppet,

    such as location, environment, configuration resources applied, resource events

    (successful vs. failed changes, time of most recent Puppet run), and deploy changes

    only to those targeted segments.

    ● Gain even more control to run phased deployments and execute coordinated roll-

    outs of change.

     

    Puppet Enterprise 2016.4 is available today.

     

    Optimizing the Software Delivery Pipeline with Jenkins Integration

    Increasingly, IT teams are seeking to adopt agile practices with a unified DevOps toolchain

    that includes automated configuration management, orchestration and continuous

    integration. A new integration with Jenkins enables Puppet Enterprise and Jenkins users to

    combine the continuous delivery and automation strengths of both solutions to build

    continuous delivery pipelines with an “everything as code” approach to software delivery.

     

    The Jenkins Pipeline plugin for Puppet Enterprise enables IT teams to build continuous

    delivery pipelines in Jenkins, with Puppet Enterprise orchestrating all application and

    infrastructure deployment tasks. Using the plugin, Jenkins users can set up continuous

    integration pipelines and push and create Puppet orchestration jobs targeting

    deployments to specific applications or portions of the infrastructure.

     

    Additional resources

    ● Read about all the exciting PuppetConf announcements.

    ● Follow PuppetConf on Twitter @PuppetConf and #puppetconf.

    ● Learn more about Puppet.

    ● Try Puppet Enterprise for free.

     

    About Puppet

    Puppet is driving the movement to a world of unconstrained software change. Its

    revolutionary platform is the industry standard for automating the delivery and operation

    of the software that powers everything around us. More than 33,000 companies —

    including more than 75 percent of the Fortune 100 — use Puppet’s open source and

    commercial solutions to adopt DevOps practices, achieve situational awareness and drive

    software change with confidence. Based in Portland, Oregon, Puppet is a privately held

    company with more than 470 employees around the world. Learn more at puppet.com.

    — Jules Louis

  • Puppet Announces New VMware vRealize Automation Plugin for Puppet Enterprise

    San Diego, CA – October 20, 2016 – Puppet, the standard for automating the delivery and

    operation of the software that powers everything around us, today at PuppetConf

    announced a new VMware vRealize Automation plugin for Puppet Enterprise. The new

    vRealize Automation plugin for Puppet Enterprise enables self service provisioning of

    compliant infrastructure across on premises and multi-cloud environments, as quickly as

    the business needs to deliver new software, faster.

     

    Though virtualization and the cloud have dramatically reduced the window between a

    developer requesting infrastructure to the operations team delivering it, it can still take

    days to provision a new resource to ensure it meets all compliance requirements. To meet

    the needs of today’s software-driven world where slow processes can impact a business,

    Puppet has worked with VMware to develop the new vRealize Automation integration for

    Puppet Enterprise which accelerates the delivery and operation of infrastructure

    throughout its lifecycle with a fully-automated, self-service provisioning workflow.

     

    “IT teams are under tremendous pressure to deliver and operate infrastructure rapidly to

    support the needs of the business and its customers,” said Nigel Kersten, CIO at Puppet.

    “By combining enhanced governance from vRealize Automation with Puppet’s ability to

    dynamically provision and configure infrastructure on demand, a developer can now make

    a request and receive fully compliant and provisioned infrastructure whenever it's needed.”

     

    “VMware Cloud Management customers value agility and control along with the flexibility

    to choose the tools to manage their application environments,” said Purnima

    Padmanabhan, vice president, product management, Cloud Management Business Unit,

    VMware. “The new vRealize Automation plugin for Puppet Enterprise enables our mutual

    customers to deploy, configure and manage applications by using vRealize Automation's

    powerful blueprinting and service orchestration along with Puppet's industry leading

    configuration management capabilities. This is yet another example of VMware's

    commitment to our ecosystem partners to help bring best-of- breed solutions that benefit

    IT and DevOps teams.”

     

    The new vRealize Automation plugin for Puppet Enterprise enables organizations to create

    blueprint templates for virtual machines using vRealize Automation’s graphical user

    interface, and then triggers Puppet Enterprise to configure and continually manage the VM.

    This lets IT teams provide automated, self-service provisioning on day one while continually

    enforcing desired configurations on an ongoing basis. As a result, IT can instantly deliver

    fully configured infrastructure to developers who request it.

     

    “Puppet Enterprise and VMware vRealize Automation are a critical part of the Kovarus

    Cloud Enablement Framework,” said Erik Melander, executive vice president, solutions at

    Kovarus. “They provide our customers the automation and orchestration technology to

    manage applications during their entire lifecycle. We are proud of how we partner with

    Puppet, VMware, and our customers to develop workflows improving software delivery and

    infrastructure operations. “

     

    The vRealize Automation plugin for Puppet Enterprise will be generally available November

    2016.

     

    Additional resources

    ● Read about all the exciting PuppetConf announcements.

    ● Follow PuppetConf on Twitter @PuppetConf and #puppetconf.

    ● Learn more about Puppet.

    ● Try Puppet Enterprise for free.

     

    About Puppet

    Puppet is driving the movement to a world of unconstrained software change. Its

    revolutionary platform is the industry standard for automating the delivery and operation

    of the software that powers everything around us. More than 33,000 companies —

    including more 75 percent of the Fortune 100 — use Puppet’s open source and commercial

    solutions to adopt DevOps practices, achieve situational awareness and drive software

    change with confidence. Based in Portland, Oregon, Puppet is a privately held company

    with more than 470 employees around the world. Learn more at puppet.com.

    — Jules Louis

  • Puppet Enterprise Raises the Bar for Enabling Fast, Reliable Software Change

    San Diego, CA – October 20, 2016 – Puppet, the standard for automating the delivery and

    operation of the software that powers everything around us, today at PuppetConf

    announced the availability of major updates to Puppet Enterprise 2016.4, including a new

    integration with Jenkins. New reporting capabilities give teams significantly greater visibility

    into change, while new orchestration capabilities intelligently enable teams to segment

    their infrastructure and execute phased deployments so they can deploy faster, more

    frequently and more reliably. With this latest release, Puppet Enterprise deepens the

    foundation for building DevOps practices by making it easier than ever to gain situational

    awareness and orchestrate software change confidently, no matter what your software

    runs on.

     

    “In today’s software-driven world, organizations need to ship new releases fast and error

    free,” said Jamie Hull, vice president of product at Puppet. “Making things even more

    difficult, they need to be able to do both these things in increasingly complex, mixed

    environments. The latest features in Puppet Enterprise help our customers confidently

    navigate this complexity by providing more direct control over deployments, as well as

    greater insight into what changed on their systems, why and by whom.”

     

    Richer Situational Awareness

    All too often, changes to infrastructure and applications can be a black box, with little

    visibility into who changed what and when, heightening security risks as a result. It’s critical

    to understand what’s happening across all your software so you can more effectively react

    and take control directly and confidently. While many tools can tell when a change

    occurred and what changed, they don’t have the situational awareness to tell you why

    something changed or who changed it.

     

    Without this awareness into the state of infrastructure, and the origins and impact of

    changes, it’s difficult for organizations to deploy change confidently. This is especially

    problematic for large organizations with independent teams that span infrastructure and

    applications.

     

    Puppet Enterprise 2016.4 solves this problem by providing deeper visibility into the cause

    of change across an organization's infrastructure with reporting that identifies intentional

    changes (changes you’ve defined) versus corrective or unexpected changes (manual but

    unplanned changes or configuration drift), which Puppet is designed to automatically

    correct.

    ● Know exactly when unexpected changes occur so you can alert security teams

    quickly when needed, troubleshoot faster and reduce mean time to recover.

    ● Drill into specific configuration resources to understand exactly when unexpected

    changes occur and what changed to identify potential security issues faster.

    ● Know whether changes occurring across infrastructure are the result of drift from a

    desired state to identify lapses in process within an organization’s use of Puppet.

     

    Orchestrate Phased Deployments with Puppet

    Modern infrastructure and applications are incredibly complex, which can make it difficult

    to maintain centralized control and quickly and reliably deploy changes in a way that

    accounts for all infrastructure dependencies. Traditional approaches to orchestration lead

    to conflicting configurations or undocumented, ad-hoc changes because they lack the

    intelligence of dependencies and the automated workflows to ensure that proposed

    changes won’t cause failures.

     

    Puppet Enterprise 2016.4 gives organizations full and direct control to drive change

    confidently and easily orchestrate ordered deployments across infrastructure and

    applications. This approach reduces risk when rolling out changes by running phased

    (canary) deployments, whether to an isolated set of your infrastructure, a specific

    application or your entire data center. With Puppet Enterprise, IT teams now can:

    ● Orchestrate phased deployments of change by targeting specific portions of their

    infrastructure and applications for updates.

    ● Segment their infrastructure and applications based on any facts stored in Puppet,

    such as location, environment, configuration resources applied, resource events

    (successful vs. failed changes, time of most recent Puppet run), and deploy changes

    only to those targeted segments.

    ● Gain even more control to run phased deployments and execute coordinated roll-

    outs of change.

     

    Puppet Enterprise 2016.4 is available today.

     

    Optimizing the Software Delivery Pipeline with Jenkins Integration

    Increasingly, IT teams are seeking to adopt agile practices with a unified DevOps toolchain

    that includes automated configuration management, orchestration and continuous

    integration. A new integration with Jenkins enables Puppet Enterprise and Jenkins users to

    combine the continuous delivery and automation strengths of both solutions to build

    continuous delivery pipelines with an “everything as code” approach to software delivery.

    The Jenkins Pipeline plugin for Puppet Enterprise enables IT teams to build continuous

    delivery pipelines in Jenkins, with Puppet Enterprise orchestrating all application and

    infrastructure deployment tasks. Using the plugin, Jenkins users can set up continuous

    integration pipelines and push and create Puppet orchestration jobs targeting

    deployments to specific applications or portions of the infrastructure.

     

    Additional resources

    ● Read about all the exciting PuppetConf announcements.

    ● Follow PuppetConf on Twitter @PuppetConf and #puppetconf.

    ● Learn more about Puppet.

    ● Try Puppet Enterprise for free.

     

    About Puppet

    Puppet is driving the movement to a world of unconstrained software change. Its

    revolutionary platform is the industry standard for automating the delivery and operation

    of the software that powers everything around us. More than 33,000 companies —

    including more than 75 percent of the Fortune 100 — use Puppet’s open source and

    commercial solutions to adopt DevOps practices, achieve situational awareness and drive

    software change with confidence. Based in Portland, Oregon, Puppet is a privately held

    company with more than 470 employees around the world. Learn more at puppet.com.

    — Jules Louis

  • So Long to Configuration Management Systems?

    So Long to Configuration Management Systems?

    When I was an operations architect at Ning way back in 2009, we were struggling to manage our deployments and configurations of more than 50 different application servers, or what the cool kids today call microservices. Applications were deployed across three distinct environments: development, staging and production. None of these environments were exactly the same as another, and differences in these dependencies, together with human errors, frequently broke our deployments.

    Ning was nowhere near the first company to encounter such problems. In the mid-1990s, as the public internet emerged, much of what was understood at the time about IT operations was challenged by the need to scale internet-facing systems. For many years preceding the internet boom, the maximum number of users was strictly limited to the number of employees in a company. That all changed with the World Wide Web, where the need to serve thousands and millions of simultaneous users easily exceeded the computing capacity of even the largest and most expensive computers.

    As three-tier application architectures were broken down into services and distributed across dozens or hundreds of individual servers, this proliferation of servers proved to be far too much for operations teams to handle. The worst problems lived within application deployment processes, where environments and requirements were ever-changing in successive releases of software. The lifetime of a server was a long one. Once deployed, servers were subjected to repeated changes by operations and developers in what would come to be called “configuration drift.”  The combined effects of changes, human errors and unknown states would create disastrous outages that damaged brands and destroyed online revenue. It would take sites days and even weeks to recover from these outages. Some would never recover.

    It was in the midst of this chaos that modern configuration management systems were born. CFEngine was the first to emerge in academia, where the need to manage multiple UNIX systems was felt early on. Later, Puppet, Chef, SaltStack and Ansible emerged directly from web-scale systems. Configuration management systems fulfilled several important needs. First, they abstracted the differences between operating systems, providing a high-level language for the system administrator to describe the desired state. Second, they automatically synchronized the desired state across large numbers of servers, reducing costly human errors. Finally, they provided idempotency to ensure that destructive operations were not applied unnecessarily.

    There is never a free lunch. The benefits of better abstraction were offset to a degree by the need to build and maintain evermore complicated recipes. Recipes frequently broke from time to time as package management features were updated, renamed or otherwise changed from the time the recipe was first written. Even when recipes worked, they were frequently broken by differences in environments or runtime errors. The configuration management systems themselves began to suffer from scale challenges, and evolved message bus architectures to improve their speed and responsiveness. By overcoming many of these obstacles, configuration management systems have now become a first-line tool for managing web-scale systems.

    But back at Ning, modern tools such as Puppet and Chef were still in their infancy and simply could not cope with the scale of our 60,000+ node virtualized environment. Ning had a lot of brilliant software engineers floating around, and they set about creating their own deployment automation system called Galaxy, and later a meta-orchestrator called Cosmos. Galaxy and Cosmos were great tools, but they required constant care and feeding and suffered from severe scale problems. There was just a lot of complexity in dealing with these automation systems while also trying to scale a top-tier social network for a hot startup company.

    As we began to analyze and post-mortem our deployment failures, it became clear that a majority of the problems stemmed from host and environment configuration errors. We needed a simpler way to deploy our software. Virtual machine images were a promising way to ensure consistency between environments with the tried and true “gold master image” approach. The problem with this approach was that building full system virtual machines was difficult in automation terms. Once deployed, virtual machines are also subject to configuration drift. Furthermore, while we were eager to adopt virtualization to get better resource isolation, we were wary of the overhead that hypervisors would create. Our benchmarks showed that if we adopted virtual machines, we would need to increase our physical server capacity to accommodate the overhead.

    At the time, Linux containers were already available in the kernel, but the distributions had almost no support for managing them. At the insistence of our VP of Operations, I cooked up an alternative solution based on jails, writing a small hack of a program called Warden to build and manage them. (Note: Totally unrelated to the Warden in Cloud Foundry). Jails gave us bare metal performance, resource isolation and a way to consistently deploy the entire environment for each application server.  With Warden, we could build jail images on the fly automatically and deploy them consistently with our existing tools, galaxy and cosmos. Hey, it was a Band-Aid for a difficult situation, but my experience with building Warden flipped a switch in my brain. I had seen the way lightweight virtualization could eliminate complexity, and I knew right then this was the way of the future.

    Today, with the success of Docker we are finally experiencing sweeping changes in the processes and tools we use to build, deploy, and manage distributed applications. At the same time, we are about to enter a brief period of containers disillusionment as early stage solutions get washed out. When that is over, what comes afterward is something of a golden era for distributed applications. I call it the container application platform, and its somewhere between what we think of as platorm as a service (PaaS) and Serverless today. In that not-too-distant future, containers will be the default output of the software build process, and where that container gets deployed will hardly be an afterthought. This unicorn magic will come from the ability to introspect containers to determine their environment dependencies, and a fully integrated tool chain that deals with deployment, scaling and dependency resolution automatically. I will give you just one guess which company is in the best position to own that future. “One ring to rule them all.”

    What happens to our beautiful configuration management systems? There has been much debate about this among smart people over the last few years. Most of these arguments boiled down to some kind of coexistence model. Indeed, configuration management systems are useful for dealing with a wide range of operational problems outside of the container platform. While it’s no surprise that Chef, Puppet, Salt and Ansible all moved quickly to include Docker support, I think we will see these tools begin to focus more on what Rob Hirschfeld calls achieving “ready state”. That is to say, everything that still needs to be done before you can lay down your container platform also still needs to be automated. Right now, that is still a great deal of work, and it’s a pretty safe place to draw the line on using the right tool for the right job.

    About the Author / James Thomason

    james-thomason_dsc0492James Thomason is chief technology officer at HyperGrid from Dell, where as CTO he led the vision, technology strategy and product road map for Dell Cloud Marketplace. He joined Dell through the acquisition of Gale Technologies in 2012, where as CTO he headed the product road map, architecture and engineering of the company’s flagship cloud and converged infrastructure automation software, GaleForce. Prior to joining Gale Technologies, Thomason was the CTO and Founder of Virtiv, a San Francisco cloud automation startup focused on Linux virtualization, acquired by Gale Technologies in 2011. For over 17 years, as a specialist in distributed systems and large-scale infrastructures, Thomason has been an entrepreneur and innovator at a number of notable Silicon Valley startups, including Exodus Communications, Digital Island, Netli, NetVMG, Netscaler, 3Leaf Systems and Ning. Connect with him on LinkedIn / Twitter.

  • DevOps Chat: Michael Olson, Puppet, A Roadmap for DevOps Success

    DevOps Chat: Michael Olson, Puppet, A Roadmap for DevOps Success

    devopsy.kinsta.cloud editor-in-chief Alan Shimel sat down with Michael Olson, senior product marketing manager at Puppet, to discuss a number of topics including the recent DevOps Salary survey that Puppet released. Another topic of discussion was the webinar Puppet is sponsoring and Michael is taking part in Sept, 27 titled, “A Roadmap for DevOps Success.”

    This webinar is a great jumping-off point for those who are looking to set off on their DevOps transformation or even anyone looking for a DevOps reset. Please click the link to register if you are interested. In the meantime, Michael gave us a great amount of information about the topic and DevOps in general. I think you will find it very interesting and useful. This interview is a little longer than our usual (about 20 minutes), but well worth the listen.

    As usual, the streaming audio is embedded below with a written transcript of our conversation below that. Enjoy!

    Shimel: Hi. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Here for another DevOps Chat. Very happy to be joined for this episode of DevOps Chat with Michael Olson, senior product marketing manager at Puppet. Hey, Michael. How are you?

    Olson: Alan, I’m doing great. How about yourself?

    Shimel: Great. You know Michael, it’s a very exciting time here for Puppet obviously. A lot going on in the world of DevOps, in the Puppet world and everything else. So before we get started with anything, what I wanted to talk about, our upcoming webinar. Why don’t you give our audience a little bit of background? What’s the latest with Puppet?

    Olson: Sure. Yeah. Happy to address that and also say thanks for having us on the DevOps Chat today. It’s always good to catch up with you.

    Shimel: Thank you.

    Olson: So for folks out there who may not be familiar with Puppet, we provide a software platform that really helps companies and organizations automate the delivery and operation of all of their software. And the idea there being that you know in today’s world, software powers everything around us. More and more companies are recognizing the need to behave like software companies as a competitive differentiator, as technology is perceived as more of a way to improve the customer experience and kind of deliver better value to end users. And so we’re seeing organizations that are looking for automation as a way to ultimately deliver better software to their customers and end-users faster. And that’s really why Puppet exists. So, in terms of what’s new for the company, I would say it’s a great time to be here. We’re growing pretty rapidly. You know we’ve been adding new customers at a pretty astounding rate and really growing the organization and seeing a lot more momentum for organizations that are looking to adopt DevOps practices and more of a DevOps way of working, as well as seeing the role that automation plays in helping them get there faster.

    Shimel: Sure. It’s a great time to be alive in the DevOps space. You know Michael, I wrote an article just this week on the results of your DevOps salary survey, which was just released. You know coming out of the Puppet DevOps State of DevOps Survey. And it’s certainly a good time if you have DevOps skills and you’re looking for a job. It seems to be you know an employee’s market. So no doubt you know what we’re seeing and what you’re describing is playing itself out in that way as well. It’s where the jobs are.

    Olson: Yeah. For sure.

    Shimel: Yeah. Crazy. You know I have friends who aren’t in IT and I posted the article on Facebook and some of them read it and saw kind of what the salaries were. And they were like you know do you have to be a rocket scientist to work in DevOps that you know those are the kinds of salaries. And I was like no, but you know it helps. But honestly you don’t obviously, right. You just gotta be into it. But that brings us actually Michael, to kind of the subject matter of our talk today. Which is this webinar we have happening on I believe it’s September 27th. Correct?

    Olson: Yeah. That’s correct.

    Shimel: And Michael, why don’t you share with our audience a little bit about kind of what the subject matter of our webinar is going to be.

    Olson: Sure. You bet. So you know we spend obviously a lot of time at Puppet consulting with organizations that are either you know at a stage where they’re trying to build the business case if you will for change and for kind of evolving the way that teams work to deliver better software out to their customers and end-users faster. And we also talked to a lot of organizations that are you know looking for guidance on kind of you know how to scale a DevOps practice within their organizations. And you know I think the common thread that we’re seeing is that you know in this day and age in 2016, that DevOps really isn’t just for the unicorn companies out there if you will. You know the Googles and the Apples of the world. We’re seeing a lot more evidence that DevOps practices are really hitting the mainstream as more organizations you know realize they need to behave like software companies and improve the way that they work. And so really the goal of the webinar that we’re gonna be digging into on the 27th is kind of to provide a roadmap based on findings from the 2016 State of DevOps Report.

    Ways of driving adoption of DevOps practices within your organization. And we’ll kind of cover that from a few different points of view. One of which is you know how to sort of build the business case for a DevOps way of working. If you’re maybe sold on the need to change, but trying to get either peers or managers to buy into your point of view. And then we’ll also address some of the cultural changes that we see our customers implementing and share some ideas on ways to align incentives and teams to improve collaboration. And then we’ll dig into you know some of the key technical practices that we see high performing IT teams implementing. And then some guidance on just you know where to get started to start to scale a DevOps practice within you know an enterprise organization. So it’ll be a lot to chew off in an hour Alan, but we’ll do our best to –

    Shimel: I was gonna say Michael—

    Olson:  —hit all those subjects.

    Shimel: —yeah, it sounds like a full hour of webinar right there. But you know Michael, one thing I want to stress and it goes back to what I was saying earlier about my friends who saw the article on the DevOps salary survey. Thinking about my goodness, you know you must need to be uber smart or something you know to be able to do something like DevOps. But so much of what you need to you know make a horse you know have a successful DevOps journey and transformation, I don’t know if it’s really sort of book smart, or intelligence, or you know rocket science. A lot of it is cultural and you know we tend to poo poo it. But a lot of it is about working together as a team. Getting buy-in. Getting buy-in from your boss and his boss. Getting buy-in from your team members. Getting buy-in from other team members. And I don’t know if that’s really you know “intelligence” or you know it’s more of social aspect. Do you agree or what do you think?

    Olson: Yeah. Honestly I think that’s a pretty great point, Alan. And I’m a big believer here that you know DevOps is not something you can buy and it’s not specific technology. And I would be very skeptical of any software company or vendor that claims to be the DevOps tool. Because what we tend to see and hear is DevOps is really more about the cultural changes and the technical practices required to you know help teams improve the way they work. To deliver better value to customers and end-users. And so from a cultural perspective, I think you’re spot on. It’s you know how do we move from a culture of lack of alignment, of low trust, of silo-ed teams, to you know cross functional teams that share incentives, that are aligned around a common set of goals. That have that high trust where you can kind of complete the no look pass so to speak to other groups. And you know the outcome ideally being you know reducing cycle times. Getting software out the door faster that meets the needs of customers. And then being able to iterate and kind of foster an environment of continuous improvement. I see those as some of the key drivers behind you know what’s required for success with DevOps.

    Shimel: Agreed. But you know I don’t want people to think I’m giving them a false sense of it either, Michael. You have to have a good understanding of environments, of tools, of what it takes for a successful software release, of what it takes actually for you know IT to help the business, right. I don’t want people to think that DevOps folks are a bunch of dummies who happen to just be really social, right. There are tools and skill sets that you know are kind of required. And so that being said, why don’t we go in a little bit deeper in terms of things we want to you know kind of peel the onion back a couple layers in this webinar. You’ve kind of given us a high level. But if we can go a little deeper.

    Olson: Sure. Yeah. Let’s do it.

    Shimel: So, let me start with this then. And that is sort of getting the buy-in on you know going forward with DevOps, right. Some people say it’s best to go top down. Some people say no, you gotta have buy-in from the bottom up. Some people say you got go top down and bottom up and meet in the middle. And I’m sure any and all of them can be successful in a particular given situation. But I think the issue then is how do you make that happen, right. I mean we recognize that’s an issue. Just if you can give a little preview, Michael of what we’re gonna do on the webinar. What would be some tips people can follow-up with?

    Olson: Yeah. I think it’s a great question, Alan. And you know my take based on what we tend to see from our customers that have been down this path is its super important to start with the why. And what I mean by that is really focus if you’re trying to you know get buy-in for implementing a DevOps way of working within your organization, it’s really important to start with what are the problems we’re trying to solve and what is kind of the end state or outcome that we’re hoping or looking to achieve. And so one of the ways that we tend to see our customers be more successful at you know getting buy-in for a DevOps initiative is you know by focusing on the benefits that other organizations have seen from implementing you know a DevOps way of working. And we’ve got some pretty awesome research that we’ll share on the webinar next month that you know talks about just how much more agile and how much more fast moving high performing IT organizations that are implementing DevOps practices actually are you know around being able to deploy applications and infrastructure changes much more frequently than their lower performing peers. And doing so with you know much shorter lead times or cycle times.

    But also being much more reliable. Actually seeing kind of a higher change success rate. You know faster meantime to recovery when things do invariably go wrong. And then we’ll also share some data that really shows and correlates kind of IT performance around you know moving faster, doing so more reliably with how that’s actually helping organizations win the  marketplace. You know become more productive, become more profitable and achieve higher company growth at the end of the day.

    Shimel: And that’s really what it’s about, right. I mean and you know what Michael, for those who are listening and it sounds easy because it relatively is rolling off your mouth. The language that you’re using, the terms that you’re using. You know I learned this in many years of security when I used to hear from so many security people. I can’t make the executive team understand why I need this IPS. Why I need this Intrusion Prevention System. And because they were talking to their executives about snort signatures and capturing packets, right. And executives don’t talk that language. I think it’s important to take note of the language you’re using Michael, you know again, not that you have to be a rocket scientist to do DevOps. But there’s a certain language of business. There’s a language of you know what is gonna be important not only to me and my team, but to my boss and his boss as well. So for those of you listening to this on streaming, you should rewind it to hear what Michael said again. Because I think you might understand more of what we’re talking about in hearing how he’s describing these things.

    Olson: Yeah. And I think that’s a good point Alan, if I can interject. I think one of the things that we tend to see is adopting a bit of a chameleon approach if you will actually can be effective. And what I mean by that is you know really knowing your audience and making sure that you’re speaking the language of the people that you’re trying to sell on the value of doing DevOps. And so if you’re talking to folks in IT leadership roles, I think they’re gonna be more attuned to the notion of becoming more agile and improving the frequency of speed of software delivery and improving the reliability and quality of that software. But certainly stakeholders on the business side are probably gonna be more focused on how does this actually impact our ability to deliver value to customers and help the business grow and be successful. And so being able to tailor the message if you will you know to the people you’re speaking with, I think is an important skill and a trait when it comes to you know navigating an organization to build a case.

    Shimel: Absolutely. So Michael, you know I mean obviously to me anyway, this sounds like we’re gonna have a great webinar on the 27th. And I hope people listening in at home will join in. You can find out more information by the way if you’re interested in registering for the webinar on devopsy.kinsta.cloud if you go to our Events section under Webinars. The webinars we’re doing are in chronological order and you can click on the graphic or the link and register from there and of course that’ll set you up to get reminders and everything else. Michael, we’re kind of running a little low on time. I’ve got two last questions for you. For people who maybe they haven’t heard enough yet about the webinar or maybe they have, but they have questions, anything else you want to tell them why this is a good webinar to attend. It’s worth their time.

    Olson: Yeah. Sure. I would say you know the companies and IT professionals you know that certainly I talk to on a daily basis you know frequently fall into one of three camps if you will. The first of which is still trying to figure out what this DevOps thing really is and what it means. You know there’s still a perception at some level that it’s a loose and evolving collection of practices. And you know you walk into a room and you ask a room of 10 people to give their definition of DevOps, you’ll get 10 different responses.

    Shimel: Yeah.

    Olson: So I think if that’s the stage you’re at is still trying to kind of develop a deeper understanding of what it means to bring DevOps practices into your organization, we’ll definitely address that. If you’re sold on the value and just trying to you know get buy-in from peers or from executives within your organization, hopefully you’ll walk out of this with some ammunition in your toolkit to be able to have those conversations within your organization. And then I think the third camp is if you’re you know sold on the value, you’ve got buy-in from the rest of the team and you’ve started to implement more of a DevOps way of working and are looking to kind of scale that across the rest of the organization, hopefully we’ll provide a roadmap for you know ways to do that and ways to kind of take it to the next level. So ambitious agenda but if any of those three kind of current states apply to you, then definitely look forward to seeing you on there.

    Shimel: Perfect.

    Olson: All right. Michael, we’re over time but I’ve got to ask you my last question anyway. So, people listening, if you’re gonna recommend one book that they read, just one, what book do you recommend, Michael?

    Olson: Oh, man. That is the million-dollar question, Alan. It’s a tough one to answer but you know there’s so many good books out there that I think cover kind of this and adjacent topics. I’m sure you know folks who are listening in have either read or heard about the Phoenix Project by Gene Kim. That’s a must-read in my opinion. Another one that I really enjoyed and I found really informative was a book by Jez Humble. It was co-authored by Barry O’Reilly and I think Joanne Molesky. And it’s titled Lean Enterprise.

    Shimel: Yep.

    Olson: And the focus is really kind of how high performing organizations innovate at scale in response to you know evolving customer needs and response to new technology. You know it provides kind of a roadmap for some of the methodologies that organizations need to become more efficient and ultimately deliver better value to their end users. So definitely would recommend that. It’s also you know a nice quick read that you can knock out. You know I’m a pretty slow reader so for me we’re talking a couple weeks. But I’m sure for most folks on the podcast we’re looking at maybe a few days or less.

    Shimel: You know what Michael, it has a treasured place on my bookshelf here in the office and my copy is pretty dog-eared already. I’ve looked at it and referred to it many times. It’s an excellent book. You know a lot of people think you tell a Jez Humble book and they’re thinking the CD book. But the Lean Enterprise book in a lot of ways is a superior book. But anyway, great suggestion. We highly recommend it. And Michael, thank you for being this episodes guest on DevOps Chat. Again, we’re doing this webinar with Puppet on the 27th of September. So a little more than a month from when we’re recording this which is on the 26th of August. So, plenty of time to register. We want to see you there. Michael, continued success at Puppet. Continued success to Puppet. A lot of interest. As we said early on, it’s a great time to be alive. It’s a great time to be in DevOps. It’s a great time to be a Puppet. So you know do keep us posted. We’d love to have you back again in the future.

    Olson: Absolutely. Always a pleasure, Alan. And appreciate the time and we look forward to seeing everybody next month.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud on a DevOps Chat. And we’ll see you next time. Bye, bye.

  • Puppet 2016 State of DevOps Salary Report: Where the Jobs Are

    Puppet 2016 State of DevOps Salary Report: Where the Jobs Are

    Puppet has released its 2016 State of DevOps Salary Report,. The report is based on the over 4,600 responses to its State of DevOps survey by IT professionals all over the world. This year’s report answers the question every politician would like to be able to answer: Where are those good jobs? The answer is easy, the good jobs are in IT. And good news for those in the United States: The highest salaries are in the United States, followed by Australia, New Zealand and Canada. Western Europe is a little behind that pack, and Asia Pacific behind that.

    IT salary

    In addition to the fat salary for IT workers, the United States pays the highest salary to IT managers also. In a nod to the income inequality issue that we have heard so much about in this U.S. election season, the gap between workers and managers was wider in the United States than it was in other areas. The difference in salary between managers and workers in the United States is illustrated from the report here:

    managers workers

    Other good news for U.S.-based IT pros is that both workers’ and managers’ salaries increased in 2016. In case you are interested in how Puppet divided workers from managers, it was done by title:

    job titles

    The good news wasn’t only for U.S. workers, though. It seems IT workers the world over are being pretty well-paid. In an era where so many ask, “Where are the good jobs?” the answer more than ever is IT. The disruption caused by the digital revolution is truly resulting in those with digital skills becoming the haves and those without those skills being the have-nots.

    nigelIn addition to IT workers in general being well-compensated, IT workers in certain industries actually tend to be better paid than IT workers in other industries, noted Nigel Kirsten, CIO of Puppet. It would seem if your employer is in the technology, media/entertainment, retail/consumer/e-commerce or finance vertical, you stand a better chance of making a higher salary.

    Additionally, Kirsten noted  that if you work for a larger organization (more than 10,000 servers), you generally have a better chance at earning near the top belt of compensation. Also, more good news for the DevOps team, the more mature the DevOps practices at an organization, the higher the compensation tends to be. Both of these metrics point to the fact that larger organizations with mature DevOps practices value the investment made in not only infrastructure but also people.

    One dark spot on the report is that, once again due to the overwhelming majority of respondents being male (94+ percent), we really don’t have enough data to see if gender pay equality exists in the IT and/or DevOps world. I look forward to the day that the number of female respondents increases and we have more insight into this important metric.

    In the meantime, this is just a quick take on the report. I encourage you to go download the report and read it for yourself. You can even see how your own salary compares.

  • Orchestration: How To Get Everyone in Tune

    Orchestration: How To Get Everyone in Tune

    Automation is key to success in the cloud. When your entire infrastructure is accessible via an API, it doesn’t make sense to configure and install your applications by hand. This is where orchestration tools come into play.

    Simply put: You will not have long-term success in the cloud unless an orchestration tool is a core part of your strategy.

    Orchestration Tool Uses

    Each orchestration tool works in roughly the same manner, taking a set of instructions (Chef uses recipes, Puppet uses manifests and Ansible uses plays) and applying them to one or more systems. The syntax of the instructions and how they are applied changes with each tool, but the principles are consistent.

    This leads to the most common use case: configuring a new server.

    Instead of manually installing all of the required libraries, applications, config files and other tools, you simply run the matching set of instructions. Need a new web server? One command and you’re set. Need a database server? Another command has it up and running quickly.

    That’s the basic idea, but with each of these tools you easily can build out a more complex configuration by nesting sets of instructions. Taking the two examples above, you could have a baseline server configuration with all of the common tools and configurations, then customize each server with a smaller set of configurations specific to web servers and database servers.

    Does a new utility need to be on all of your systems? Do you have a new version of your app? Do you need to push out a new configuration file for your data stores? Send one set of instructions through your orchestration tool and you’re done.

    It doesn’t take long to see the value of these tools and to mandate their use for all of your cloud deployments.

    Not So Fast

    Like most challenges in the DevOps space, orchestration isn’t that simple. You can’t just wave your magic wand and get all of your teams using a centralized orchestration tool. This is not a new challenge, we’ve been trying to get this right since the early ’90s (remember Novell ZenWorks or the first version of Microsoft Systems Manager?) and are just now starting to see wide(r)spread success.

    Culture is the No. 1 blocker when it comes to this category of tool.

    You’ll hear some common objections from teams:

    • The choice of technology (is Chef versus Puppet versus Ansible versus the Emacs versus Vi?)
    • It wasn’t built here.
    • The manual process works just fine.

    These objections rarely hold up to scrutiny, but that doesn’t matter. Any objection raised needs to be addressed in some manner until you’ve got enough people on the target team to sway the rest over to the direction you’re trying to head.

    When you’re facing a cultural challenge, you have to address the people side of the equation in your strategy!

    3 Steps to Take

    No solution is going to work in all cases, as every organization is unique. You know the culture of your organization best, so go with your gut. With that in mind, here are the three approaches that tend to work best for most organizations.

    1. Empathy

    No one likes to be told what to do from up on high. While mandating that a team switch over to this shiny new orchestration tool might get the work done initially, it also will build resentment. That’s the opposite of what you want. You want buy-in.

    Odds are, each team in your organization already has a to-do list a mile long. Regardless of the benefits, your orchestration project probably isn’t very high on the list. Accepting that your priority isn’t their priority is a key step toward understanding and empathy.

    2. Pitch In

    One way to help move up the priority list is to offer to help out and pitch in.

    Learning a new tool and new way of conducting ops doesn’t just happen overnight. Have a strong, step-by-step plan to help bring other teams up to speed. A core part of that plan has to be one of your team working with the new team for as long as it takes to get them comfortable with the new tool.

    Take a patient, hands-on approach. Let other teams learn by doing … and by making mistakes. Your role is to guide them along the path of adopting the new tool. Time and time again, this type of approach has proven to be far more successful than other options.

    3. Duct Tape

    As your efforts progress, you may reach the point where the other teams are comfortable with the tooling, understand the workflow and are ready to adopt the new tool.

    The problem is now either:

    1. Developing new sets of instructions or
    2. Converting old scripts or hacks to the new tool.

    To tackle the first challenge, make sure you’ve set up an easy way for teams to share sets of instructions. A centralized set of git repos work great for this. This will reduce the overall workload and encourage collaboration. It’s better to borrow than to rewrite.

    You’ll also want to make sure there is a regular communication highlighting successes with the new tooling. This will help remind teams of the value of the new way of working.

    To tackle conversion (problem No. 2), plug your nose and use this messy hack. All three major orchestration tools allow you to execute another script or program. If you already have working sets of instructions, keep using them. Just wrap them in the new tool to gain the workflow benefits.

    Eventually you will replace them with native instruction sets, but if it’s working “as is,” that’s one less set that you need to build.

    Smoother Operations

    A lot of operational issues happen because of a manual error. Asking someone to make the same configuration change on six systems is bound to lead to a mistake. By moving to the cloud, you’ve already accepted the ability to program your infrastructure. Manually configuring the assets in that infrastructure doesn’t make any sense.

    Orchestration tools allow you to reduce the number of mistake made, ensure consistent results and amplify the productivity of your teams.

    What’s not to love?

    What have your experiences moving a number of teams to a common tool been like? What tips and tricks did you learn along the way? Share in the comments below or on Twitter, where I’m @marknca.

  • State of DevOps Report: Reaping Results

    State of DevOps Report: Reaping Results

    The newly released 2016 State of DevOps Report concludes that DevOps is “no longer a mere fad or buzzword,” but rather an established set of practices and cultural patterns. Yet, a closer look at this year’s findings reveals progress is far more substantial than any matters of perception.

    The report was conducted and analyzed by the experts of DevOps Research and Assessment (DORA) and sponsored by CA Technologies. Among its findings is proof that high-performing organizations that have embraced agile and DevOps methodologies deeply are outperforming massively those that have not. And the gap is widening.

    The State of DevOps Report also shows leading DevOps practitioners are appreciating benefits that span nearly every area of their business. If I know my colleague Gene Kim, he will assert this point exuberantly on our upcoming State of DevOps Report Webcast.

    It’s noteworthy that high performers are surpassing incredible milestones related to core elements of the applications life cycle. Examples include deploying code 200 times more frequently than low performers, driving 2,555 times faster lead times, 24 times faster recovery times and producing three times lower change failure rates. This is evidence that DevOps is having the desired outcome on applications delivery, software quality and organizational velocity. It also shows organizations truly committed to wholesale transformation of culture and process are actively succeeding.

    At the same time, the State of DevOps Report shows employees working at organizations enjoying this success are more satisfied with their jobs and more closely engaged with their companies. Chalk this up to the halo effect of operating in a fundamentally more sensible, innovative fashion. Cultural change is undoubtedly the greatest hurdle to DevOps advancement. Here’s proof that if you can navigate the process, your workers will be happier and more productive.

    Using Employee Net Promoter Score (eNPS) as a barometer, the report finds that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work. They also were 1.8 times more likely to recommend their team as a great working environment. Previous studies have found that such an air of positivity can be directly correlated with improved business outcomes, researchers noted.

    Shifting the manner in which you build applications to better adapt to changing customer expectations is a necessity. That’s what began driving this movement years ago. That said, proof it also makes it easier to keep valued software engineering and IT operations employees should not be overlooked.

    In addition to positive conclusions on the impact of continuous delivery and improvement of test data management, the report offers some important metrics related to return on investment. This is nothing short of landmark, as for decades we have struggled to make a hard case for IT investment beyond implied competitive advantage. It actually was impressive that last year’s report highlighted such a “predictive relationship between IT performance and organizational performance.”

    One such new measurement of note is that high-performing teams occupy the least amount of time responding to unplanned work and rework—efforts widely recognized to be results of flawed processes. On a related note, DevOps leaders spend 49 percent of their time on new work‚ surely, in many cases, the next “must-have” feature which impacts competitive standing and, ultimately, the bottom line.

    This report is fantastic. It reaffirms powerfully that so many of the promises made about DevOps over the last few years are neither hype, nor overstated. The gap between the leaders and laggards is growing. Industry landscapes and business models are being redefined.

    This is critical transformational work that every organization must adopt to survive.

    Are you on board? Download the full State of DevOps Report here.

  • Puppet 2016 State of DevOps Report Addresses the Most Pressing Issues in DevOps Today

    Report Helps Organizations Understand the ROI of DevOps, Why Quality and Security Should Be Built In, and More

    PORTLAND, OR–(Marketwired – Jun 22, 2016) – Puppet, the standard for automating the delivery and operation of the software that powers everything around us, today announced the findings of the 2016 State of DevOps Report. Over the past five years, Puppet has surveyed more than 25,000 technical professionals, making the State of DevOps Report the largest, most comprehensive and longest-running study on the topic of DevOps. Written in partnership with DevOps Research and Assessment (DORA), the fifth annual State of DevOps Report includes findings on some of the most debated topics in DevOps, including understanding the ROI of DevOps; how building quality and security into the development cycle affects business outcomes; the role of lean product management; and the relationship between employee engagement and organizational success.

    “Today, every company is a software company. Yet there’s a huge delta between the organizations that get it and are able to ship software on demand, and the organizations that take days, weeks or even years to ship simple upgrades,” said Nigel Kersten, CIO of Puppet. “The 2016 State of DevOps Report shows that gap is widening. We hope the report will help organizations identify their own inhibitors of change so they can drastically increase their competitiveness and ultimately, their revenue.”

    The Widening Performance Gap
    The 2016 State of DevOps Report shows that high-performing organizations are widening their lead against lower-performing organizations. Compared to low performers, high-performing organizations deploy 200 times more frequently, have 2,555 times faster lead times, and recover 24 times faster from failed changes, with three times lower change fail rates. Because high performers build quality into each stage of the development process, they also spend 22 percent less time on unplanned work and rework than lower-performing organizations, and thus are able to spend 29 percent more time on new work.

    Understanding the ROI of DevOps
    Since the first State of DevOps Report was published five years ago, it’s been widely accepted that DevOps significantly affects IT performance and organizational performance. The 2016 State of DevOps Report builds on this body of knowledge and provides example formulas (based on survey findings and industry averages) to help organizations understand the potential cost savings of DevOps practices, and the additional value to be gained from investing in DevOps.

    Security
    All too often, security testing is tacked on at the end of the delivery process, leading to expensive and painful fixes once development is complete. The 2016 State of DevOps Report confirms that integrating security into each stage of the development process has a positive impact on IT performance and security outcomes. Organizations that better integrate information security objectives into daily work spend 50 percent less time remediating security issues than low performers.

    Employee Engagement (eNPS)
    Employee engagement is more than a feel-good metric: Companies with highly engaged workers have been shown to increase revenues two and a half times as much as companies with lower engagement levels. The 2016 State of DevOps Report found that employees in high-performing organizations are more than twice as likely to recommend their organization to a friend as a great place to work. This indicates a high level of engagement and identification with the company, and as many business studies show, highly engaged employees are more productive and creative, and provide better experiences to customers.

    Lean Product Management
    The 2016 State of DevOps Report looked at lean product management practices to see if changes upstream in the product management process affect downstream business outcomes. Analysis shows that teams that implement continuous delivery practices and take an experimental approach to product development build higher-quality products and feel more connected to the overall organization.

    The 2016 State of DevOps Report also reveals:

    • Respondents who report they are part of a DevOps team increased from 16 percent in 2014 to 22 percent in 2016.
    • High-performing organizations get more new or planned work done, because they have less unplanned work to cope with.
    • And more insights into how organizations are transforming their cultures and outcomes.

    Sponsors
    Atlassian, Automic Software, CA Technologies, Hewlett Packard Enterprise, IT Revolution, Splunk Inc., and ThoughtWorks

    The full 2016 State of DevOps Report is available for download athttps://puppet.com/resources/white-paper/2016-state-of-devops-report

    Additional resources:

    About Puppet
    Puppet is driving the movement to a world of unconstrained software change. Its revolutionary platform is the industry standard for automating the delivery and operation of the software that powers everything around us. More than 32,000 companies — including more than two thirds of the Fortune 100 — use Puppet’s open source and commercial solutions to adopt DevOps practices, achieve situational awareness and drive software change with confidence. Based in Portland, Oregon, Puppet is a privately held company with more than 400 employees around the world. Learn more at puppet.com.

  • Continuous Delivery: The Atlassian Way

    Continuous Delivery: The Atlassian Way

    Sonatype’s Mark Miller (@TSWAlliance) caught up with Ian Buchanan (@devpartisan) for our 2016 DevOps Leadership Series. Ian discussed his experiences at Atlassian, including continuous delivery, ChatOps, and use of tools such as Bamboo, Nexus, Puppet and Datadog.

    https://www.youtube.com/watch?v=MgRaYKHGqeQ

    Buchanan: I’m Ian Buchanan. I’m a Developer Partisan at Atlassian, which is developer advocacy for our developer tools.

    Miller: Ian, most people know Atlassian from solutions like JIRA and Bitbucket.

    Buchanan: Yeah, I focus mostly on Bitbucket and Bamboo. Bamboo’s our continuous integration and deployment tool.

    Miller: Good. One of the subjects we talked a little about at dinner last night is how Atlassian is using Nexus. Can you give us some background on that?

    Buchanan: Yeah, that’s right. Well, we’re a big Java shop. We have been for a very long time and have a lot of Maven dependencies for external reasons; we also store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     We’re a big Java shop. We have been for a very long time … we store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     Miller: As far as a binary repository, are you using it for anything other than components?

    Buchanan: Not that I’m aware of. I know that we’ve recently started to get into Docker quite a bit and Nexus is a good fit for that as well. I don’t know the extent which we’re using Nexus for that purpose yet, as Docker’s still quite new for us.

    Miller: What does your continuous integration pipeline look like?

    Buchanan: It certainly varies by product in the details. Of course, we have our own continuous integration product, Bamboo. Bamboo is the most pervasive tool we have.

    For the Java stuff it’s pretty simple pipeline where libraries get built and published into Nexus so that they can be used downstream. We also have some interesting, newer cloud products that are built with Python. A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    Miller: Are you guys using continuous delivery in house for your workflow?

    Buchanan: We’re in an interesting position that I think I see a lot of companies in. We have some behind-the-firewall products (our server products) and then we also have cloud products. In the cloud side, continuous delivery is used when we want to go very fast. But we also have to balance that with the approach we take for our server products so that they don’t fork terribly. We have continuous delivery up until there’s a product delivered. At that point, there is another kind of pick up—where the cloud products engage with other things like Puppet and Ansible to configure the environments with products that other people can pick up and run on premises.

    Miller: I was talking to your team in San Francisco. How are you guys using ChatOps with HipChat?

    Buchanan: I’ve been talking about ChatOps for quite some time. We do a lot of very interesting things with ChatOps. They play a very important part of our continuous delivery pipeline in that we publish build results in there. People can see when pull requests are ready and check those out. We get to see what’s happening from production as well. We have integration with Datadog; it tells us some of the monitoring things that are going on. It’s not just information coming into the chat room. There are also commands that folks can issue to make the continuous delivery pipeline move along. There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

    _________________

     There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

     _________________

     Miller: Anything coming up in the future you guys are working on that’d be fun?

    Buchanan: Well, a lot of the innovation really happens at our quarterly “Ship It” events. That’s where our developers spend 24 hours doing whatever kind of innovation interests them. A lot of time is spent scratching an itch they have. Some of the things that I saw there were about having more information coming back upstream, not just into the chat rooms, but into JIRA where more of the longer-term tracking is going on. They’re experimenting a lot with putting more information into JIRA.

    Miller: Nice. Final question, if you were going to be a superhero, would it be Dev, Sec or Ops?

    Buchanan: I’ve played Dev roles and Ops roles and I almost feel like I know those much more. But from a lot of the sessions at DevNexus, I have to feel like Sec is the superhero. They’re the superheroes because they solve some unsolvable problems in a lot of ways. But I don’t feel ready to play that role at the moment, myself.

    Miller: It’s interesting. I agree with you that they are unsung heroes. Most of the time they just get hammered for what they’re doing.

    Buchanan: That’s true. Yesterday I was in a session about securing REST endpoints. The speaker went through problems with BASIC off , DIGEST off and J2EE—all of these things which we use in our products. At the end we’re left with, “What is the answer?”

    Well, the answer is that for each of these, there are different problems. So we have to identify the right context. We have to understand where some things are broken, know that those things aren’t perfect, and design for that imperfection. That’s a mindset that we have to carry through dev, ops and sec. I hope more security folks step up and start telling those stories.