devopsy.kinsta.cloud

Tag: chat

  • A Failure to Communicate

    A Failure to Communicate

  • Implementing ChatOps Using Open Source Tooling

    Implementing ChatOps Using Open Source Tooling

    ChatOps is an exciting proposition for organizational Ops communication. Throwing development and operational tooling into the chat conversation can ease the development pipeline, increase transparency and increase security by streamlining bug detection and remediation efforts.

    At the heart of ChatOps are bots, scripts and chat clients; many are pre-built and open source. In this article, we’ll review a completely open source method for building out your ChatOps setup. We’ll cover integrating with Hubot, using CoffeeScript commands, and how building custom scripts can ignite ChatOps in your own environment.

    Why Open Source for ChatOps?

    Many arguments have been given as to the benefits of open source. Building upon open source inherently evades vendor lock-in, enabling more security and service longevity. Furthermore, to avoid reinventing the wheel, forking existing open source ChatOps projects naturally will be more efficient than purely greenfield initiatives.

    Open Source Chatbots

    There are many Chatbots available for use; each with unique capabilities, varying types of integrations out of the -box, and different ways to extend functionality with custom scripts. Take Lita, for example, an open source chatbot built with Ruby. It works with IRC, HipChat and Campfire. Many other open source chatbot options exist, such as Errbot, Jarvis and Lazlo.

    Example: Hubot

    By far the most adopted open source ChatOps companion is Hubot. Designed and open sourced by Github, Hubot takes market share in the ChatOps discussion. Described as “a customizable, life betterment robot,” Hubot is written in Node.js and takes commands with CoffeeScript.

    Using Hubot, developers can initiate commands with Hubot scripts to perform actions such as post images, translate languages and integrate with maps, but also initiate vital commands to your favorite DevOps cloud tools. A full catalog of scripts can be found here, and it’s quite easy to craft your own CoffeeScript commands as well.

    Example Hubot Scripts

    The community scripts that support Hubot are similarly open source, meaning that you can repackage these implementations to suit your own needs. Let’s take a look through the catalog of Github-supported Hubot scripts to see what sort of pre-constructed extensions we can seamlessly add to a Hubot environment.

    With Hubot, you can ping your major cloud development platforms, such as Heroku. Some example commands for returning status of issues on Heroku include:


    hubot heroku status - Returns the current Heroku status for app operations and tools

hubot heroku status issues <limit> - Returns a list of recent <limit> issues (default limit is 5)

hubot heroku status issue <id> - Returns a single issue by ID number

    Or perhaps you want to conveniently check PagerDuty from your chat client to see who is on call within your incident response team, or to gather details on current incidents. Hubout has a script for that. Using pagerduty.coffee, some example requests might be:


    hubot who's on call - return the username of who's on call

hubot pager me trigger <msg> - create a new incident with <msg>

hubot pager me incidents - return the current incidents

hubot pager me notes <incident> - show notes for incident #<incident>

hubot pager me problems - return all open incidents

    Another example could be direct interaction with the Twilio API for sending SMS. Using sms.coffee you can initiate a command with the following syntax:


    hubot sms <to> <message> - Sends <message> to the number <to>

    Configuring sms.coffee is easy, all you need to insert are:


    HUBOT_SMS_SID

HUBOT_SMS_TOKEN

HUBOT_SMS_FROM

    Of course, there is no shortage of Gifs, cat memes, and other scripts to add some humor to your workday, such as mustache insertion using image detection.

    Generating Your Own Hubot Scripts

    Aside from using third party scripts, you can always craft your own. To be an executable Hubot script, your code must be in .coffee or .js, and it must be in the correct directory (src/scripts and scripts by default). It must also export a function, as in the following:


    module.exports = (robot) ->

# your code here

    Essentially, Hubot listens to all chat communication; it will hear commands and respond accordingly. To configure what it must hear in regards to your script, you must specify what to listen for, and what to respond with. For example:


    module.exports = (robot) ->

robot.hear /badger/i, (res) ->

# your code here

robot.respond /open the pod bay doors/i, (res) ->

# your code here

    For further details, see the documentation on Scripting here.

    Getting The Most of Chatbots

    Once integrated into a chat platform such as Slack, your chatbot configuration can truly thrive. Given the wide breadth of community generated and Github-maintained scripts, DevOps teams have near unlimited potential for uniting their tooling into a single, human-readable CLI. Another benefit of choosing open source tools for such projects is that you can detach your bot and integrate with whatever chat client you prefer.

    ChatOps can add fun and efficiency to the remote workspace. We’ve covered high-level methods for adopting this into your team’s space, and hopefully, a helpful foundation into the power of open source for streamlining the power of ChatOps.

    — Bill Doerrfeld

  • 6 Must-Haves When Using Chat for Incident Management

    6 Must-Haves When Using Chat for Incident Management

    Over the last few years, teams have realized the benefits of sharing and distributing knowledge in chat applications such as Slack. Today, teams are extending the use of these applications beyond collaboration by embracing ChatOps. ChatOps empowers teams by bringing complex day-to-day operational work into shared chat channels. If done correctly, it drastically reduces context switching and increases the speed at which teams can tackle tough challenges.

    Companies are realizing incredible benefits by incorporating ChatOps into their incident management workflows. Chat channels provide hyper-effective means to alert teams of issues, take immediate action and collaborate with clarity and urgency. It is for this reason that companies including OpsGenie, PagerDuty and VictorOps have invested in integrating their incident management applications into chat applications such as Slack, HipChat and Microsoft Teams.

    ChatOps to the Rescue

    Ideally, users of a modern incident management solution need to have access to a multitude of features so that they can address specific challenges directly within the chat tool. During an incident, switching between applications to access and collaborate on the actionable data is a waste of time. Keeping the conversation and action in one place, where team members already are, is the key to a fast and successful incident resolution process. That is why ChatOps has emerged as an alternative to the war room concept.

    To get the most out of the technology and resolve problems more quickly and easily, here are six tips to consider when using ChatOps for incident management:

    1. Post Messages with Clarity

    The basic requirement for integrating any application within chat tools is to simply have messages posted within chat channels. However, there are three additional needs to consider when integrating an incident management tool into chat when increasing efficiency is the goal.

    • The integration must be able to post chat messages regardless where the incident originates and additional information added (monitoring, ticketing, or collaboration tools).
    • Messages need to be customized based on the specifics or severity of the incident. Often the basic message needs to be appended with tags or additional information fields.
    • If possible, include a button in the message that allow responders to take instant, prescriptive actions.

    2.  Control How Information is Shared

    Posting every alert and comment into a shared channel can quickly become overwhelming and is considered bad practice. A strong integration enables the creation of separate channels for specific responders and have direct control over what types of alert and follow-up messages are shown.

    A seamless integration also provides the flexibility to receive only the incident actions that are decidedly relevant. Low-priority issues that don’t require immediate action can be filtered and not sent to the chat stream, ensuring the team stays focused on what really matters.

    3. Accelerate Actions

    ChatOps transforms chat into a vehicle through which users take actions and deploy solutions. This virtually eliminates the need for operations teams to switch between applications when responding to an incident.

    Most integrations enable users to execute incident actions using text commands. This method is valid and often preferred. However, deeper integrations simplify tasks by providing interactive buttons that enable users to begin working on incidents with just a click.

    The value of responding to an alert by clicking a button extends beyond simple alert acknowledgement. Enabling all common responses (i.e. assigning an alert, taking ownership, adding notes, muting incidents, etc.) to be executed in this manner accelerates resolution and unlocks the real power of ChatOps.

    4. Instantly Retrieve Supporting Information

    A challenge of a long chat thread is that critical information can get lost within the communications or additional information may be needed. A user might have to leave the channel to look up important details and related information, such as looking at other open incidents, for example.

    The integration of an incident management system into the chat environment needs to allow users to access supporting information at any time. The ability to query not only additional details about a specific incident but also general information regarding on-call schedules and alert policies is a requirement. By empowering team members to access this data directly within the chat interface, they stay focused and are able to respond in the most efficient manner possible.

    5. Create New Alerts

    A common task when managing an incident is to create manual alerts. Again, requiring people to switch applications to complete this task is a distraction and slows the progress.

    Creating new alerts for a team or service right within the chat channel is a necessity. The incident management system then notifies the person on-call automatically. Having the ability to create an alert directly within chat empowers individuals that may not have direct access to the incident management system to report problems efficiently.

    6. Control Access

    When an incident occurs, it is important that corrective action is taken by only the people who are authorized to respond. Mapping (or linking) the chat users to the users within the incident management system enables this level of control.

    Linking the user profiles between the chat and incident management has additional benefits. As alerts are acknowledged and responded to within the chat environment, the events are recorded within the incident management solution. A clear history describing who took each action is recorded for future reporting and analysis.

    While there are many things to consider when integrating incident management into a chat application, the benefits are clear. Response time, ability to collaborate, and team access to incident details are crucial factors for incident resolution.

    About the Author / Serhat Can

    Serhat Can is a Technical Evangelist for OpsGenie. He has contributed to different parts of OpsGenie as an engineer and now tries to spread the word by coding, writing and talking about DevOps. He is still a proud member of the on-call schedules. Follow him on Twitter and connect with him on LinkedIn.
  • DevOps Chat: DevOps and the Road to Cloud with JT Giri, CEO, nClouds

    DevOps Chat: DevOps and the Road to Cloud with JT Giri, CEO, nClouds

    For many of us in the IT industry, migrating to the cloud is old news. Even the concept of how DevOps can help on the road to the cloud is not a novel idea. However, we need to remember that while many organizations have some cloud-based infrastructure, the real migration to the cloud is still ahead of us. By the same token, while DevOps is more popular than ever, the percentage of organizations that have fully adopted DevOps is still small.

    My talk with JT Giri, CEO and co-founder of nClouds, dives into this truth and how companies like nClouds are helping organizations big and small to make the move. As usual, the streaming audio of our conversation is below, followed by the transcript of our chat.

    Audio

    Transcript

    Alan Shimel: Hello, everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s DevOps Chat guest is JT Giri, CEO of nClouds. JT, welcome to DevOps Chat.

    JT Giri: Hey Alan, great to be here. Thank you.

    Shimel: Thank you. Thank you for being here. So JT, let’s start off a little bit about – before we get to nClouds, let’s start off – I don’t know if everyone in our audience has heard of JT Giri and your background. So why don’t we go there first, so you can give us a little background.

    Giri: Absolutely. I spent the last ten years doing DevOps consulting before it was called DevOps – so helping companies to streamline their operation and managing complex infrastructure and helping them to put processes in place. My end goal was always to make sure the customer could focus on their end goal, like delivering greater value to their clients. So that’s what I’ve been doing the last 10 years. 

    Shimel: Got it. And then you founded nClouds. When was nClouds founded?

    Giri: Yeah, so it was kind of a transition from consulting to founding this company with the mission of helping companies with cloud adoption and helping them to manage modern infrastructures that would integrate continuous delivery, continuous integration, building better culture. So we transitioned from consulting to a company.

    Shimel: And you know what? You’ve done it and congratulations. I’ve done it now several times. And it’s scary, right? It can be a little scary when you – you know, it’s a big responsibility, but ultimately that’s what makes an entrepreneur, right?

    Giri: Yeah, absolutely. And I think at some point you realize you can add far more value to your clients if you grow it as a team, especially 24/7 support. One of the DevOps principles is to take ownership, right? So we wanted to provide that to our customers and every gig we do, we make sure we are there for them. You know, we provide 24/7 support and make sure we are responsible for their infrastructure. It’s just simply very hard to do it yourself, you know? So that’s why we transitioned into a company and it’s been great. We’ve done over 100 AWS implementations and the transformation for our clients has been amazing. Before where it used to take them three months to deploy code, now they can deploy everyday. So it’s just been an amazing journey. 

    Shimel: Yeah, it has. And I mean, you know, again, as an entrepreneur and you having done this too, JT, it’s nice to get some recognition beyond – I mean other recognition is putting the money in the bank and growing the business, right? But it’s also nice to get awards, kudos or some industry recognition that things are moving in the right direction or the arrow is pointing up, as they say in football. And JT, recently nClouds received some recognition like that, didn’t they?

    Giri: Yes. Yeah, so we’ve been nominated in the 20 most promising DevOps providers of 2017 and as I was saying, it’s really exciting for us, because we’ve been doing great things for our clients and the transformation has been amazing, where now the customer can focus on delivering value to their clients faster. You know, we help them with cloud migration and streamline their operations. So it feels good to be recognized, definitely. [Note from Editor: Just after our interview, nClouds was named to CIOReview’s 20 Most Promising DevOps Solution Providers – 2017.]

    Shimel: Got it. And JT, you know, nClouds is working pretty closely with Amazon AWS, isn’t it?

    Giri: Yes, we are an Advanced AWS consulting partner. We’re also an AWS Managed Service provider and DevOps competency partner.

    Shimel: Got it. And how is that, JT? Because again, for our folks out in the audience, I’m sure many of our listeners are actually working on AWS-hosted infrastructure right now. But you know, from my experience anyway, there’s people who work directly with AWS and they muddle through it. They may get some training and maybe they’re old hat at it. And then there’s a large segment of I think the industry and of the customer base who really, they need the nClouds of the world. They need AWS expertise to help them make it happen. And I’ve got to assume that that forms a good chunk of your customer base right now, yeah?

    Giri: Yeah, absolutely. So Alan, you know, you’re in the space and you know how confusing things are right now. You know, there’s people already moving to server-less and there’s Kubernetes, Nomad, and you know, there’s like five or six container schedulers … They want to be like Amazon or Netflix or Google of the world, but it’s very hard to get there. Since we’ve done this so many times, we have experience working with the client and taking one step at a time. Because if you’re starting out it can be intimidating, because you don’t know – you have a good vision and you want to release code fast and you want to make sure you can innovate fast. You want to migrate to AWS, but it’s very, very tough. And Alan, when we speak with customers, some of them are still starting with the config management conversations, right?

    Shimel: Mm-hmm.

    Giri: And so we have to kind of tone it down for them. For them, the next step is, “Hey, let’s figure out – maybe we need to work on implementing some kind of config management for you before we even think about micro services,” right? So that’s when someone like us can come in and help you to understand, where can we get the biggest bang for the buck? What should be the next step? And really help you pave the way to go to this transformation with a DevOps path.

    Shimel: Yep, agreed. So JT, you know, when we start talk about it though – I want to turn back – you actually wrote an article back in May that was up on devopsy.kinsta.cloud about why your company needs an automated infrastructure now. And when you were talking it kind of triggered that for me. For our listeners out there, why do their companies need an automated infrastructure right now?

    Giri: So if you subscribe to lean thinking, anything that doesn’t add value to your customer is a waste, right? So you need to define your work rigorously to be used that way. With automated infrastructure you can actually facilitate that. You can scale up and down based on your customer needs. And then you can focus on adding value to your customer and you can also lower the cost, where you just scale based on the client’s needs – and all this can yield better reliability. You know, the customers will be happy. If you’re not leveraging automation and if you’re treating the cloud infrastructure like on-prem, then you’re not really getting any value out of the cloud. So that’s why I wrote that article, just illustrating that you have to focus on automation and the cloud so you can lower the cost, have efficient workflow, and in return deliver better reliability and better customer experiences.

    Shimel: Excellent, excellent. So you know, JT, you and I and people like us, we’re living in a DevOps bubble. We think DevOps is great. We think this type of methodology, this way of thinking, this kind of cultural organization is a no-brainer and of course it has to make things better. But there are a lot of people who maybe haven’t drunk the Kool-Aid, or they just don’t see it. And they’re saying, “Okay, that’s cool. That’s this week’s buzzword. What’s next? How do we keep this going?” Where do you see this going, JT? And when I say this, I mean this whole sort of – I call it Agile IT, because I heard someone at Gartner use the term. But DevOps, Agile, this new way of doing things – where do you see it going

    Giri: Yeah, so I think we have a long way to go, Alan. As I mentioned earlier, you know, we are in the Valley and we are drinking this DevOps Kool-Aid. And because we have experienced this, right? Like I’ve done a lot of DevOps transformations and I can see before and after and it’s just amazing when you get the results. But there are a lot of companies out there, as I was mentioning earlier – they’re still beginning to think about config management systems, right? And they’re still doing config management in Pearl. And another challenge I face, especially when we’re working with enterprises, people have gotten used to doing things a certain way and all of a sudden there’s like so many better ways to manage your infrastructure.

    So Alan, I think we have a long way to go and I think when people feel like, “Oh, this is just a buzz,” what we try to do with companies is take small steps, right? If they’re still working on config management, try to implement that and show them metrics on how things were before the implementation.

    Shimel: So JT, what about nClouds? What’s next with nClouds? I know recently you guys have added some talent there and you’ve got this award going on and you’re getting buzz in the industry. Where do you see the company going?

    Giri: Yeah, so our mission from day one has been to drive this cloud adoption and help companies with DevOps transformation. So companies like Google or Netflix, the unicorns, they can really attract a lot of DevOps talent. But there are a lot of companies and a lot of enterprises out there and they’re not able to attract that kind of talent. So our mission is to bring DevOps transformation to all of these companies, right? That’s why we’ve been hiring. And Randy Newell joined recently, so we’re very excited about that, and we have been hiring very talented engineers.

    And we also released a product called nOps.io, which manages security and change management of the cloud. So over the last several years the focus has been a lot on infrastructure tooling, like Terraform and (AWS) CloudFormation. And I think we’re missing the process piece of the puzzle in this DevOps. So that’s what we’re trying to bridge, where if there’s a hundred people or ten people making changes in your infrastructure, how do you manage those changes? How do you make sure security is not an afterthought? How do you make sure every single change is documented and traced without slowing people down? So we’ll continue to innovate and help companies in the DevOps space, yes.

    Shimel: Got it, got it. All right, well JT, we’re about out of time here. Thanks for coming up and appearing on this episode of DevOps Chat. Continued success with nClouds. And we’d like to see more articles from you up on devopsy.kinsta.cloud, actually. I’m sure our audience – our audience really liked the first one, and we’d like to see a lot more.

    Giri: Thanks, Alan. Thanks for having me.

    Shimel: But good luck. Thank you. All right. Hey, JT Giri of nClouds – CEO and founder of nClouds, thanks for being this episode’s guest on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We’ll see you on the next episode of DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

    DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

    Puppet made three major announcements today around new versions of their flagship products, new products independent of Puppet Enterprise and a major expansion of partner programs and offices in the face of record growth over the last 12 months. As I detailed in my article on these announcements, these 3 taken together paint a clear picture of a market leader solidifying its position as an enterprise DevOps solutions provider. I had a chance to speak with Michael Olson of the Puppet product team about what these announcements mean.

    As usual, the streaming media player of our conversation is below. The transcript of our conversation follows immediately below (transcript will be updated shortly)

    Streaming Media

    Transcript of our Conversation

    Alan Shimel:                Hello everyone. This is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here on another DevOps Chat. Very happy to be joined on this episode of DevOps Chat by Michael Olson from the Puppet Product Team. Michael, welcome to DevOps Chat.

    Michael Olson:           Thanks Alan. Thanks for having me. Good to be here.

    Alan Shimel:                Pleasure. Pleasure to have you here Michael we always – actually we’ve had more than several people from Puppet over the years appear on DevOps Chat and we always – that’s always a great conversation.

    But today Michael you’re on here regarding several news announcements that Puppet put out recently today on May 11 and wanted to kind of go over them with you and cue our audience in to what I think are several major announcements coming kind of down the pike from Puppet.

    So if it’s okay with you Michael, you know the news as well as I do, do you want to lead off with what you think is the most important one or do you want me to pick?

    Michael Olson:           Sure, I’m happy to dig in. And today’s been certainly a pretty big day at Puppet, we’re pretty excited to announce a very significant set of investments that we think really continues to deliver on our mission of empowering IT to deliver better software faster, so looking forward to digging in to what that entails.

    It’s really around new products that help IT manage the complexities of their evolving and modern infrastructure as well as updates to some of our existing products that give really IT better control and situational awareness for the software that they deliver and run.

    And then new partnerships and company investments that are really focused on ensuring that Puppet is where our customers need us to be, that our customers and our community and ecosystem really have the talents and the support needed to scale their success wherever they are, so looking forward to digging into it with you.

    Alan Shimel:                Okay. So if you don’t mind Michael I’d like to start off with the announcements around new products – Puppet Cloud Discover – and if I mispronounce it I apologize – Lumigon? Is that how you pronounce it?

    Michael Olson:           Alan, you nailed it. Well done.

    Alan Shimel:                Okay. Well every once in a while even a blind squirrel finds a nut. But anyway, so we have Puppet Cloud Discover and Lumigon – and these are offerings in the container and cloud native technology areas, but beyond that Michael why don’t we dig in a little bit. What exactly is Cloud Discovery first?

    Michael Olson:           Sure. And you’re exactly right. And I think before we dig in it’s useful just to set a little bit of context Alan and I’ll start by saying that our heritage really at Puppet has been rooted in helping IT professionals cope with sort of the complexity of managing an ever-growing infrastructure and application estate really by kind of harnessing automation.

    So for more than a decade our core focus has really been around helping our customers define a desired state model for their infrastructure and applications and then providing an engine that translates that desired state of how they want their infrastructure and applications to look into reality.

    So that has benefits of doing things like preventing configuration drift and eliminating manual intervention from the software delivery process.

    And one of the things that we’ve seen is – you know, over the course of this journey over the past 12 years is we’ve been very fortunate to be supported by a passionate open-source community that’s helped refine our offerings, coving every aspect of systems management so that our new users that are getting onboard with Puppet can hit the ground running so to speak as opposed to having to start from scratch.

    And so in light of that we are making investments to better support that journey for our customers and answering some of the common questions that we’re hearing from them. Things like, “How do we get started with automation and modeling?”

    And one of the most common starting points that we see our customers looking to solve for is just know what software they have running across their datacenter and their cloud and container environments: answering a simple question of, “What resources and applications do I have running today? How do I bring those resources under management?” And I kind of refer to that general category of problems as discovery

    So what we’re announcing today is really a new set of investments and offerings that are intended to give IT teams much better situational awareness into what they have running across their application and infrastructure estate regardless of whether that’s running in the cloud, in containers or on their traditional on-premise datacenter.

    Alan Shimel:                Got it. Got it. So Michael I think that kind of explains a little bit what Cloud Discover is – Puppet Cloud Discover. And I’m looking at these two names of Cloud Discover and Lumigon – I’m reminded back to my days at one of the security companies I helped co-found – Still Secure – but we always had this sort of battle between descriptive names or kind of catchy marketing type of names.

    And when I look at Puppet Cloud Discover that’s certainly a descriptive name, right? I think you almost get what it is from the title and it obviously fills a real need in the market as we get these – I guess you call it cloud sprawl – of an ever-expanding infrastructure and understanding what we’ve got there.

    Talk to me a little bit about the other one though, Lumigon. How did we come up with that name and what does it do?

    Michael Olson:           You bet. Yeah, Lumigon is a new offering from Puppet. It’s open-source so it’s something that is available for our community as well as anyone who is responsible for managing containerized environments within their organizations to go to our website and just simply pull down and start using today.

    And I think as we all know containers have really emerged as a new and common way of packaging applications with that container image being the artifact that’s handed off from development into operations, and we think containers represent a really big opportunity for orgs that want to accelerate their product delivery.

    But today what we’re often hearing is that those container environments are largely black boxes from an operational standpoint. What’s more, since there’s so many of them, containers tend to be ephemeral, so to speak, they tend to have shorter lifespans than VMs and that brings a whole set of challenges where you’re looking at bringing containers into production environments.

    So what we’ve announced today is a new offering. It’s open-source and free and available for anyone to go and pull down and start using of Lumigon which is an offering that really focuses on discovering what’s running inside all of those container environments and giving operators really better visibility and control around their container estate.

    So because this Lumigon effort is an open-source tool that can analyze applications – you know, we’re initially targeting docker containers and exposing application metadata about those but certainly looking at extending that over time as we continue to get feedback from the community.

    Alan Shimel:                Great. Now Michael over the years we’ve spoken to several Puppet people – among them Gareth Rushgrove, D-Pack, Sonja himself – and we’ve talked here at devopsy.kinsta.cloud about Project Blue Shift at Puppet which is kind of, as you probably are well-aware – Puppet looking at new technologies and making sure that they – that Puppet’s mission encompasses working with these new technologies.

    Is Lumigon something that maybe comes out of Project Blue Shift or independent of that?

    Michael Olson:           I think it really represents a common vision from Puppet which is you know we see a lot of organizations in our customers that are really looking to automation as a bridge to their future. As organizations look to modernize physical infrastructure and move it into the cloud, adopt containers in production environments they’re looking to have automation really baked in from day zero as they look to do that.

    And so Blue Shift is, as we’ve talked about in the past, really represents Puppet’s vision for helping our customers adopt the cloud and containers in consistent, repeatable and reliable ways. So it encompasses things like using automation to install docker or lay down operating environments in docker, for example, as well as do things like define and deploy the services that run inside of docker containers giving our customers really better portability to be able to kind of lift and shift workloads that they may have defined and are running on virtual infrastructure, for example, and getting that running in containers without having to adopt platform-specific tooling to do so.

    Alan Shimel:                Make sense. And certainly – I mean I’m fresh out of Docker Con two weeks ago now – it seems like two weeks – maybe it was last week – but in any event I mean the shift to a containerized application infrastructure is well underway and so a product such as this obviously I think should find a ready market and the fact that it is an open-source tool and everyone can get involved.

                                        Michael what is – or other – I know it’s early in the game but are there any plans to have an Enterprise or pay-for version of Lumigon out there?

    Michael Olson:           You know it’s certainly something that we’re looking at longer-term is as we continue to build off of this foundation, you know, ensuring that we’re meeting the needs of our large Enterprise customers as well as the broad community of more than 36,000 organizations that rely on Puppet technology today to deliver and operate their software

    And I think what we’re focused on right now is really making sure that we’re nailing that core set of problems with a sledge hammer which is, “How do I expose the black box and know what’s running inside of my container environments so I can do things like identify if I’m vulnerable to a potential CVE or if I’m vulnerable to a bug in a library dependency. You know, to know if for example my OS standards are being followed and adhered to within my organization.” These are the types of questions that Lumigon will help users answer today.

    And then shifting to the Cloud Discovery announcement that we talked about briefly earlier we’re also introducing a new offering here at Puppet that’s really focused on giving IT teams better situational awareness into what’s running in their cloud infrastructure specifically in AWS.

    And so it’s really focused on helping IT teams go back and discover all of the resources and applications that are running in AWS. This is a limited preview that we’re offering for Cloud Discover today really to give those teams a better sense of what they have running in the cloud so they can make better decisions about how they want to bring them under management through automation.

    Alan Shimel:                Great. So Michael both the Cloud Discover and Lumigon in some ways are maybe the cabooses on the engine here with the announcement of a new version of Puppet Enterprise – or at least the availability of a new version of Puppet Enterprise.

    Why don’t you tell our audience a little bit about that?

    Michael Olson:           Sure, yeah. So Puppet Enterprise – we’ve introduced a new version, we call it 2017.2 per our naming conventions – and I’ve been at Puppet for a few years now and in my opinion it’s really not an exaggeration to say that it’s one of the more significant releases that we’ve had in several years, really with a focus on giving our customers better visibility into the software that they have running on premise in their datacenter no matter how they’re managing it, as well as easier, simpler tools to be able to orchestrate deployments and run deployments across infrastructure and applications using visual workflows.

    So the first set of innovation that we’ve introduced into the latest version of Puppet Enterprise is really around being able to inspect software packages that are running across your datacenter.

    And one of the areas of feedback that we frequently hear from IT teams is it’s hard to know what software packages are running across their infrastructure, what versions they’re running, for example, in order to easily identify packages that may be vulnerable to security risks.

    So we’re introducing some new reporting for our Puppet Enterprise customers in this version that’s really focused on giving IT easy visibility into the software packages that they’re running regardless of whether they’re being managed today by Puppet in order to really provide that insight to identify potential security issues a lot faster

    And then as our customers look to use automation in order to drive change across their software stack we’ve also introduced a whole set of orchestration capabilities over the course of the past year-and-a-half. With this release we’re extending that to the Puppet Enterprise Web UI essentially giving our customers the ability to define, run and monitor deployment jobs entirely using visual workflows within the Puppet Enterprise Web UI.

    So it’s easy to do things like define a deployment job, target a specific portion of your infrastructure, run a phase deployment for doing things like canary workflows, and then monitor the status of that deployment in real-time so if things aren’t going well you can hit the stop button, investigate, tinker as needed and then restart that deployment; so giving our customers a lot more flexibility into how they drive change across their software.

    Alan Shimel:                Fantastic. And I love the naming conventions here – I remember speaking earlier about it – I think it makes it easy for people to see where they are and what they have – but the simple naming kind of hides the fact that there’s a lot more punch in here. And by the way, that’s available now Michael?

    Michael Olson:           Correct, it is. Yeah. It’s available today for – certainly for current Puppet Enterprise customers – and for anybody who’s new to Puppet out there you can simply go to our website and pull down a copy, it’s free to try on up to 10 different servers, devices or applications.

    Alan Shimel:                Sure. Michael, and I didn’t ask this – my apologies – for the Cloud Discovery and Lumigon – what’s their availability?

    Michael Olson:           Yeah, Lumigon, which is really around, again, kind of exposing the black boxes of containers, is – that offering is available to try today and you can find a way to get there directly from our website at Puppet.com. And then the Cloud Discovery offering is available as part of a limited preview so what we’re really looking to do is if you’re interested sign up through our website and we’ll be in contact with you if you’re interested to discuss next steps.

    Alan Shimel:                Perfect. Next Michael let’s talk a little bit about the last announcement today, and this one was more around sort of momentum – it looks like a bunch of new Enterprise customers added as well as new locations and partners and partner offerings. I don’t know if I left anything out but give us some of the details there if you can.

    Michael Olson:           Sure, yeah, happy to do so. And you know you get this Alan, obviously you and I have talked before, but what we’ve really seen over the course of the past several years is just a huge surge in growth and momentum for Puppet and I think it’s been fueled by growing demand in the market for dev-ops and for digital transformation.

    So we’re really taking that momentum and using it to grow more aggressively and really help our customers be more successful, you know, laying the foundation for dev-ops wherever they are in the world.

    So what we’ve also announced today is a new set of partnerships with organizations like AWS and Cisco and others as well as global expansion for Puppet: we’re opening up new offices in Singapore really to better serve the needs of our customers internationally and ensure that Puppet is with them wherever they are and however they want to engage with us.

    Alan Shimel:                That’s great. What about from a partnership point of view though? Any new partners to announce or just partner offerings?

    Michael Olson:           Yeah, from a partnership perspective – I’ll touch upon a couple things – one of which is we have a new marketplace offering up on AWS that we also made available today and really the key takeaway there is as our customers are increasingly looking to kind of recognize the value of cloud-based environments – they’re using AWS – we’ve really deepened our relationship with Amazon Web Services and deepened that partnership with a new offering that basically makes Puppet Enterprise available on the AWS marketplace on an hourly pay-as-you-go basis.

    So it’s really focused on simplifying the installation of Puppet Enterprise and providing a way of securing configuration and getting better visibility into your AWS infrastructure through Puppet directly from within the AWS marketplace.

    Alan Shimel:                Yeah. You know, to me Michael that’s a huge winner, right, because number one – I’m familiar with the AWS marketplace and there’s no lack of solutions up there – but once you’re in there and you have the ability to kind of piggyback the AWS billing, if you will, for hourly service and hourly offerings – it allows people to consume their services in the manner that they’re used to consuming them in AWS, right?

    I think early on there was a big rush to the AWS marketplace but if you weren’t truly integrated into AWS it just, you know, from a billing perspective and usage monitoring and all that, it – I think their customers just did it – it was just too clunky frankly, right? So this makes things a lot smoother in you’re an AWS customer.

    Michael Olson:           I think that’s spot on Alan. Like the constant feedback that we hear from our customers is they want us to meet their needs and engage them how they want to be engaged, so to speak, and I think this is a marker that helps payoff that objective that customers have is, you know, if you’re looking to bring automation into your cloud environments – you know, looking to get started for the first time – just, you know, click a few buttons and spin up Puppet directly through the AWS marketplace.

    And we’ve also really extended our partnership with Cisco in some of the partner-related announcements that came out today as well as we see more Cisco customers that want the power of Puppet as a way of defining, deploying and operating all of their software. So with our expanded partnership joint customers of Puppet and Cisco can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco value-added reseller.

    Alan Shimel:                Cool. Very cool. Okay. Michael, you know, I promised you we were going to do 15 minutes and here we are for over 20 – I apologize – but before we wrap things up did we miss anything in the announcements?

    Michael Olson:           I don’t think so Alan, this has been a great conversation and I think we touched upon most of the highlights.

    Alan Shimel:                Yeah, I think so too. You know not everything fits into a 15-minute bucket though in life so I apologize but I think it was well worth the time spent digging into these new, exciting developments and announcements over at Puppet.

    Michael Olson from the Product Team at Puppet thanks for being this episode’s guest on DevOps Chat. Hope to have you on again soon.

    Michael Olson:           Likewise. Thanks for having us Alan and it’s always great to catch up with you.

    Alan Shimel:                All righty. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening everyone and we’ll see you on another DevOps Chat hopefully very soon.

    — Alan Shimel

  • DevOps Chat: Rosalind Radcliffe and Bimodal IT

    DevOps Chat: Rosalind Radcliffe and Bimodal IT

    I had the pleasure of sitting down with IBM distinguished engineer Rosalind Radcliffe the other day to talk about bimodal IT, systems of engagement, variable speed DevOps and IBM’s upcoming InterConnect 2016 event.  I have interviewed Rosalind many times over the last few years and it is always informative and interesting. I hope you find it to be so as well.

    Below is the SoundCloud streaming audio interview, followed by the transcript of our talk.  Enjoy!

    Alan Shimel:                Hi, Alan Shimel here with another DevOps Chats, and my guest is – for this session is a friend of mine, Rosalind Radcliffe of IBM. Rosalind, welcome.

    Rosalind Radcliffe:      Thank you. 

    Alan Shimel:                Rosalind, I think you’ve appeared on DevOps Chats before, and of course we have done webinars and videos together, and so many other things. But for members of our audience who may not be familiar with who you are; do you want to give a brief background?

    Rosalind Radcliffe:      Sure. So I’m Rosalind Radcliffe, I’m a Distinguished Engineer at IBM, and I’m responsible for our DevOps strategy for Enterprise Systems. So I am not only responsible for driving our product direction, but I really spend a lot of time with clients helping them with their DevOps transformations for their Enterprise Systems – mostly mainframe, and their systems of record.

    Alan Shimel:                Excellent. Rosalind, of course, we’re going to talk a little bit about today about this term that’s been creeping up, Bimodal IT, and then I want to spend some time talking to you about the upcoming InterConnect Conference as well. Maybe we can combine Bimodal IT and InterConnect; I don’t what we would call that, but Trimodal. Anyway, so Rosalind in talking offline before we jumped on here I think we both agreed that we weren’t big fans of the term Bimodal IT, and all that seems to have entailed now. Do you want to share with our audience why you may not be a fan?

    Rosalind Radcliffe:      Yeah. I think the term and the way it’s used isn’t implying that there is a defined slowness for the systems of record. I think it’s important instead of saying Bimodal to say more variable speed IT or something that implies that the systems may move at different speeds. I’m not going to disagree with that, but it’s not that one is inherently faster and one is inherently slower. It’s that hopefully for your system of record you’ve built that as a set of API’s or services, and so you don’t have to change the services as often as you need to change that system of engagement to entice the users to stay connected.

    So it really should be about how the systems of record and the systems of engagement can work together through loose coupling, and through proper services. I do think that is going to happen; there are going to be different speeds at different times. Sometimes, honestly, the systems of record might be moving faster than the systems of engagement, because there are changes needed – regulation changes, etc. But it’s – we need to pay attention to it from that standpoint and that’s the reason why I don’t like Bimodal IT. It’s really variable speed.

    Alan Shimel:                Yep. The other point that gets me with it is this whole idea of Bimodal IT, it almost takes that we have two tracks if you will, that move at different – or two trains on a track that move at very different speeds. But they never interact; it’s almost – it almost reminds me of civil rights, separate but equal. We have the water fountain for the mainframe guys, and a water fountain for the cloud dudes, and they both serve water so that’s okay. But the mainframe guys can’t drink from the cloud dude’s water fountain.

    It didn’t work for civil rights, and – I don’t think it works for IT either. I think a better model when we talk about systems of record, systems of engagement, and this whole world, is more – I call it the Swiss watch model. Where you have gears that turn at different speeds, but they all mesh together in a fine tuned timepiece. To me, that’s a much better model than this idea of separate tracks, if you will. What do you think about that Rosalind?

    Rosalind Radcliffe:      I actually think that’s a wonderful way of putting it. Because I think that – it would be a much better interpretation with the gears and the Swiss watch, and Swiss watch timing is always excellent with their gearing system; so that’s exactly what it is. The teams need to work together, and they need to be using the same tools, the same practices, the same processes, and each system needs to go at the speed that is required for the changes that they need to make. But they’re obviously interacting. Your systems of engagement is nothing without your systems of record. So they need to interface properly, they need to work together to provide this end-to-end solution for their end users.

    So they have to be collaborating, and I – honestly I think the organizations that have brought the teams together, that do the systems of engagement and the systems of record into one team, actually do the best. They’re the most efficient; so they may have variable ability in the speed they’re delivering on different parts. But they’re all working together, they’re all collaborating, they’re all one team; not this separation idea. I think your example is very good, it’s not separate, but equal, it’s one team.

    Alan Shimel:                I agree wholeheartedly. I’m not here blaming Gartner for pushing this whole Bimodal IT name and paradigm. But, Rosalind at last year’s InterConnect I remember having a bunch of conversations with you and Sanjeev Sharma and Carmen Diardo, and we were using the term variable speed IT. Right?

    Rosalind Radcliffe:      Yes, absolutely.

    Alan Shimel:                To talk about it – the similar thing, and, of course, I – we’ve heard other people use the term two speed IT. But I think in larger organizations, there’s actually more than two speeds; there’s a lot of different pieces that move at different speeds.

    Rosalind Radcliffe:      That’s really the right answer. I really think it’s important have that ability to move at the speed required by businesses – the business demands, and that’s why it’s necessary. I think there’s a lot of thought process about Bimodal IT, because there are still or there seem to be people out there that still think the mainframe can’t move as fast, that it can’t use DevOps practices. I think that’s actually the core of the issue. We have to break down this thought process that the systems of record – the mainframe can’t move as fast, can’t be DevOps. It really can be, and it’s a reality – I guess it’s a hot button in a sense right now. I’ve just spent the last two weeks with two different clients, and this week with one of them – the first principle they put up was that there’s nothing about the mainframe that means it shouldn’t be DevOps. That the first principle is it needs to be DevOps, it needs to take advantage of the same pipeline, the same functions, the same capability to be able to move as fast as required in a reliable, consistent way with all the advantages of automated testing and automation.

    Alan Shimel:                Absolutely. Rosalind, let’s turn a little bit to this year’s InterConnect where we will have – whether you want to call Bimodal IT, variable IT. There are out of the 200 or 300, I forget how many DevOps related tracks there, there will be some great ones, and I want to talk to you a little bit about that.

    Rosalind Radcliffe:      Yeah, I’m looking forward to the event as well, though I’m not ready for it yet. There will be a lot of discussion and a number of sessions, both customers as well as IBMers talking about the variable speed IT or the different ways that different parts of the application development need to interact, and need to work together. One of the clients I was speaking with this week will be there talking about their DevOps development, particularly about how they’re literally building brand new applications on the in COBOL CICS applications using DevOps principles. So I look forward to all the different client discussions that are held there, bringing their teams together, and I think your Swiss gear interpretation is a good way of putting it. Because that’s what they’ll be talking about, how they’ve geared the teams together to be able to work together to provide the value the company needs.

    Alan Shimel:                Absolutely. Rosalind, are you allowed – can we mention to our audience what company is that presenting? Are you allowed to say at this point or no?

    Rosalind Radcliffe: So in that case, it’s Rabobank, because they’re published as a session speaker; so they’ll be speaking. There are actually quite a few. Rabobank’s one, UBS is another; there are numerous speakers scheduled – client speakers scheduled who are going to be speaking about their efforts and their transformations.

    Alan Shimel:                Rosalind, what about you? I’m sure you’re speaking.

    Rosalind Radcliffe:      Yeah, I have quite a few sessions that I’ll be discussing DevOps overall, working with clients and their transformations, the capabilities available, as well as having more discussions on the ops side of DevOps. I think one of the things that has been an interesting challenge is the how do we really bring ops into DevOps since we really do have ops organizations. That’s going to sound really strange, but when we think about DevOps a lot of the discussion has really focused on automation and delivery, not really focused necessarily on running the systems. So I’m trying to help some of the discussions bring more of the ops side in. How do we really get the ops collaboration coming in? How do we tie the teams together from a complete end-to-end standpoint?

    Alan Shimel:                Excellent. Rosalind, it’s hard to pick among many, but what do you – besides the ones you just mentioned, give our audience – if they’re wondering should I go, should I not go, not sure; what are the two or three biggest either sessions or points of learning that you think people should know about to jump in here?

    Rosalind Radcliffe:      Honestly, I think there are too many sessions to name, but the way to think about it is there are too many sessions to name. There are lots of client sessions, we’re going to be discussing their experiences. So the value out of a conference like this, one of the key values is the ability to hear from your peers, and to network with your peers to understand how they’ve done this, how they’re getting value. That’s the best way to learn from other people who are already experienced or who are experiencing. You’re going to learn from people who are headed for you, and you’re going to be helping people who are behind you. So it’s the networking, it’s the opportunity – hear those sessions, and the opportunity to meet all of the different people who are working in this space.

    I think that’s the value of conferences like this; the chance to network and take advantage of that. Many people I’ve met in prior InterConnect’s have said it’s the collaboration, it’s the conversations, it’s the meeting of people that have given them the most value. Attending the sessions is also very important, but it’s the sessions that give them those contacts. So they learn in the session, and then they have this contact that allows them to continue to discuss. You always get fun – learn something new, you get some fun stories, you get something you’re really going to be able to take back and provide value to your organization.

    Alan Shimel:                Absolutely. Rosalind, believe it or not we’re just about out of time; we probably have gone over. As usual it’s always — when this happens whenever we talk I apologize. But, I am looking forward to seeing several of your sessions at InterConnect, as well as I should mention – this is a quick plug, I am moderating a session myself on what DevOps will look like in the next three to five years, and I have none other than Gene Kim on the panel with me, which should be a lot of fun. So if anyone listening is attending Interconnect, please come on down for that one.

    But, Rosalind, it should be quite a show, and I’m looking forward to how this whole Bimodal IT, variable speed IT, how it plays out. We’ve said it before, mainframes aren’t going anywhere, and the new way of doing things like DevOps and Agile and stuff it’s going to influence how we use our systems of engagement, but it’s not going to negate them. It’s always a pleasure to speak with you, and look forward to seeing you in Las Vegas February 21 to the 25th correct?

    Rosalind Radcliffe:      Correct. I’m looking forward to it as well, and as you mentioned the panel discussions, those are always wonderful. I’m hoping that I can make it to your session with Gene Kim if I’m not in another session myself. So I’m looking forward to it, and it’ll be a great week.

    Alan Shimel:    Absolutely. Rosalind Radcliffe, Distinguished Engineer IBM, thanks for joining us today on this edition of DevOps Chats

  • DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    tyler jewellI had a chance to sit down with Tyler Jewell, CEO of Codenvy.  Tyler is an experienced tech exec and VC participant.  I met Tyler recently at the CloudBees CD Summit and Jenkins User Conference in Santa Clara. Tyler’s present company is Codenvy.  I spoke to Tyler about why and how leadership should engage DevOps.  Tyler says leaders need DevOps. You can listen below or read along. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505270?secret_token=s-gFEIj” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Alan Shimel:                Hi, Alan Shimel, devopsy.kinsta.cloud here for another Devops web chat on the Leadership Suite. Our guest today is Tyler Jewell who’s CEO of Codenvy. Tyler, welcome to Devops chat.

    Tyler Jewell:                Thanks for having me.

    Alan Shimel:                Tyler, I guess we should start off with those of our listeners who may not be familiar with yourself or Codenvy, why don’t you give us a quick background?

    Tyler Jewell:                I have been working at Enterprise Software for 25 years. I started off as a software engineer and then held a number of positions in product management at companies like BEA and Quest Software. The past six years I have been a venture capitalist, a partner at Toba Capital, investing in midware, Devops, and developer related technologies and while there at Toba Capital I founded and run Codenvy, which is now three years old.

    Alan Shimel:                Great. So another overnight success, huh?

    Tyler Jewell:                Business is good and there’s a lot more to be had.

    Alan Shimel:                So Tyler, for those of our listeners who may not be familiar with Codenvy, what are you guys doing over there?

    Tyler Jewell:                We are in the business of providing continuous development solutions, which is a part of Devops and continuous delivery. We do that by delivering on demand develop or work spaces that are easy to replicate, are constraint free, and collaborative.

    Alan Shimel:                Great. So Tyler, our audience for these chats are really managers, executors who are managing software – well, every companies a software company today, right? But these are people who are managing software departments and managing software delivery. Why should they care about what problems Codenvy is solving?

    Tyler Jewell:                Well, I think that there’s an interesting statistic that says 88 percent of organizations are now pursuing a Devops strategy and that’s just a phenomenal statistic in my mind considering that the term Devops did not appear before 2010. So in five years we have had essentially market saturation, and so why is that? And that’s the case because ultimately organizations that can release more frequently are able to drive customer happiness and this ceiling, this philosophy, has so many truths to it that software organizations are assessing their ability to deliver continuously at all stages of the pipeline.

    Where Codenvy fits into this is that we are providing continuous concepts to the pre-commit or the pre-merge phase of the pipeline, which is where the developers spends his time, and frankly where the developer spends a lot of their time configuring it and not coding.

    Alan Shimel:                Tyler, what about sort of system architects, system planners? Are they part of the Codenvy value chain as well, sort of even before the code, the proverbial papers taken into pen to paper, when we’re planning new apps and new software?

    Tyler Jewell:                Well, I think that historically the code has been the domain exclusively of the developer and there’s really no reason for that and that the code can become the domain of all audiences that are part of the software team, including the architect, but also the QA engineer, the product manager, the project manager as well. And essentially if you’ve been someone who has wanted to bill code or to run or debunk the code you needed to be a developer and set up a developer work space.

    That was a very technical skill set that you needed to have. In this day and age with the advent of containers and a lot of the automation that has been built into our technologies there is no reason that you need to be technical to recreate a developer environment. You can do that with URLs. You can do it online without installing software. And when you do you can allow users, your QA engineers, and product managers to get a feedback on to the code along with the engineers having these environments without overhead.

    Alan Shimel:                Got it. And Tyler, so we have this – to many people and especially to a lot of managers, execs, Devops is sort of developer led, but we’re also seeing this movement of IT ops, right? And as IT ops folks between to code more and infrastructure code starts happening more do you think we’ll see a migration from sort of Devops to IT ops being dominate here with this?

    Tyler Jewell:                Well, I think what we’re looking at is it’s a feedback driven initiative here. So whether it’s a developer or a development organization or an operations organization that is the driving initiative, the common goal here is to find ways to get feedback earlier into the life cycle. So whether that is an operation’s engineer or a developer it’s really about the people who value that feedback the most and can benefit from it.

    And feedback exists at every stage of the pipeline among all the different departments that are there and they all benefit from having that feedback as well. So I think they’re all gonna become drivers in their own way and they’re – any barriers that exist between them are gonna increasingly come down including perhaps their titles and job responsibilities as well.

    Alan Shimel:                Sure. Tyler, one of the functions of executives, especially IT executives, is we service somewhat of a translator between our very technical teams that we work with such as developers, such as IT ops or QA and even security. Between that group and then translate that into business speak for our peers who are perhaps CFOs or CEOs or nontechnical executives in the team. When we talk about the kinds of problems that Codenvy tackles, how can executives translate that into business speak that they’re CFO and CEO understands?

    Tyler Jewell:                Well, I think that if you are an organization that depends upon software either to be differentiated with your products out in the market place or to just be more efficient, the leap that CIOs need to make with their peers is that software teams that are high functioning are those that are able to release the most frequently here.

    So having a benchmark of release frequency, comparing that to your own ability, and then assessing your technological people in cultural capabilities along those lines is a simple way that you can start to communicate the benefit of having a very efficient software development organization that is embracing these technologies and philosophies. If that kind of assessment and narrative does not work then I think you have to take it back to perhaps manufacturing fundamentals, the theory of constraints here, which goes that if you want to produce a high volume, high quality parts, physical parts, you have to focus in on the portion of the work flow that is the slowest and most _____. And by resolving that and making that the most efficient then the entire manufacturing process becomes more efficient and software is the same philosophy. It’s just done with bits as opposed to screws and bolts.

    Alan Shimel:                Got it. Tyler, let me ask you to step back from your role as CEO of Codenvy for a second and put on your hat as someone as you said has 25 years’ experience in IT who’s served on the venture side of the house. What do you see as the biggest innovations or trends that executives should be watching around this whole new way of doing software and apps?

    Tyler Jewell:                Well, I think that they’re – as an investor at the very basic investment thesis in that the demand for software is increasing at a faster pace than the supply of engineers exist to produce it here. And so the only way to revolve this demand supply curve or this inequality that exists is that there’s gonna have to be tremendous innovations that show up that allow us to create software 10 or potentially even 100 times faster than we have in the past. And businesses and technologies that play to those trends are going to have outsized returns versus vendors who are not playing to those trends.

    So I think that’s the way I think about it and that’s abstract level. At a very concrete level the things that are playing to that, containers are absolutely fantastic. They provide low overhead. They also provide the programmatic definition of infrastructure which is something that we’ve never had before. So their rising adoption and popularity are a reflection of that. At the same time we’ve started to see new evolution of programming languages.

    Programming languages that are special purpose or domain specific are particularly geared towards Cloud development and those are making developers a ton more productive. And at the same time I also think that we’re continuing to see the rapid mobilization of knowledge workers around the world. We still have not seen a high penetration of that and there’s a lot more penetration to come. So those trends are inevitable trends that are playing into this Devops’ philosophy.

    Alan Shimel:                Got it. Last question, Tyler, and it’s the same one we ask everyone who appears on our show. For your executors out there, if they should read one book that will really help them with trampling with all of these kinds of issues and further their careers, what would you recommend?

    Tyler Jewell:                I’m a huge fan of Stephen O’Grady’s book that he wrote. It’s a two hour read. The title of that book – and this is my older age slipping my mind here – it is Developers are the New Kingmakers.

    Alan Shimel:                I know the book.

    Tyler Jewell:                It’s a fantastic read and I think that the book provides a very non-emotional explanation for why developers and development teams behave the way they do.

    Alan Shimel:                Yep. Excellent. Hey, Tyler, Tyler Jewell, CEO of Codenvy, thanks for being this week’s guest on Devops chats and much continued success with Codenvy and we hope to have you on again soon.

    Tyler Jewell:                I look forward to coming back. Thank you so much for having me today.