devopsy.kinsta.cloud

Tag: AWS

  • VMware Cloud on AWS Will Bring DevOps Issues to a Head

    VMware Cloud on AWS Will Bring DevOps Issues to a Head

    Now that instances of VMware are starting to become available on Amazon Web Services (AWS), a DevOps ecosystem is starting to emerge around the management of applications workloads moving into and out of AWS.

    Among the more than 4,500 applications that VMware claims already support VMware Cloud on AWS are those from Blue Medora, CA Technologies, Chef, Cloudbees, Dynatrace, Jfrog, Puppet, SaltStack and the Ansible arm of Red Hat.

    VMware CEO Pat Gelsinger told attendees at the recent VMworld 2017 conference that VMware and AWS are just now scratching the surface of what they plan to accomplish together. AWS CEO Andy Jassy added that, unlike other alliances, which consisted mainly of marketing, engineers at both companies are working closely together to deliver VMware globally across all AWS availability zones. At present, VMware Cloud on AWS is available in the AWS availability zone hosted in Portland, Oregon. The service soon will be extended to the east coast of the United States, followed by rest of the world over the course of 2018.

    The availability of VMware Cloud on AWS should force several DevOps issues within enterprise IT organizations that have deployed the VMware stack of software mainly on-premises. Many of those organizations have also been employing public clouds such as AWS. But because those environments are based on different hypervisors, it was never easy to migrate workloads between the two platforms. There are plenty of options for running VMware software in the cloud, but because AWS is the largest provider of public cloud services, there are many customers who want to seamlessly move workloads between their on-premises IT environments and AWS via a common stack of VMware software.

    In many organizations the desire to shift applications workloads into AWS will bring many DevOps issues to a head, as VMware and AWS use has occurred in independently of each other. There could be many workloads running on each platform, but for all intents and purposes, IT organizations have managed both platforms in isolation. Now that VMware is becoming available on AWS, all the challenges associated with moving workloads between a public and private cloud come to the fore.

    Most of those DevOps issues will be focused first on moving some classes of workloads running on VMware into AWS. Application workloads that don’t need to run constantly will be among the primary candidates followed by a slew of data protection applications that will enable IT organizations to back up and archive massive amounts of data inexpensively. Next up will be applications that need to be distributed globally to increase availability.

    At the same time, a lot of VMware shops will be moving application development into the cloud. But just because an application is developed in the cloud doesn’t mean it will stay there. Many IT organizations have already discovered that when it comes to long-running applications, the total cost of deploying them on-premises is less than deploying them on a public cloud. The DevOps tasks ahead, of course, will start with figuring out which VMware-based applications make the best candidates from a financial and availability perspective to be deployed on AWS.

    — Mike Vizard

  • 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

  • Tips to Optimize the Cloud for Scaling

    Tips to Optimize the Cloud for Scaling

    When I first started migrating companies to the cloud (about seven years ago), companies would ask me, “How come the app isn’t scaling? How come users are still complaining about the slowness?” I would explain that the cloud enables auto-scaling, but you still have to make sure your app can scale in the cloud. In people’s minds, auto-scaling and the cloud was synonyms.

    I don’t get asked that question anymore (maybe people realized the cloud is not as magical as it seems). But now, people think the cloud is synonymous with speed, agility and cost-effectiveness. Sure, cloud enables all that. But you still need to make sure you optimize the cloud to facilitate that. I see many companies in the opposite situation: their accounts full of resources with names such as test1, test2 and finaltest2, or they put together a SWAT team to reduce an AWS bill, or security is an afterthought. So many engineers are making changes, it’s hard to know who is doing what.

    Before you run into this situation (maybe you’re already there), you have to create tools and processes to optimize your cloud for scale.

    Establish Strong Policies

    The magnitude of changes in cloud infrastructure is high. Unless you establish strong policies, managing all the resources across multiple cloud accounts get out of control pretty quickly. The most effective way we have seen is using tags for resources. For example, use tags that identify whether the resource is from a certain department are added to each resource. Typically, it works very well when the tagging process is embedded into the automation. If there are new resources that don’t comply, automation should terminate these resources. You should enforce policies like these sooner than later.

    And just because these resources were provisioned with proper tagging, it doesn’t mean they are provisioned for its full capacity. You should build automation to find underutilized instances and establish a process for downsizing. To ensure everyone complies with these policies, you should also establish change management process.

    Change Management and CMDB

    The objective of the change management process is to ensure all the infrastructure changes cause minimum disruption and meet internal guidelines. Many say that ITIL change management process is not compatible for fast environments such as cloud. I agree that the traditional way of doing change management by tracking changes manually just doesn’t work, due to the magnitude of changes. But in the cloud, you can leverage automation to streamline the change management process; for example, you can use automation to filter normal changes versus manual changes. Once all the AWS changes are reviewed and approved, in addition to bringing visibility to all the changes for security and reliability change management can simultaneously help reduce waste.

    Most companies heavily leverage auto-scaling, where new resources can be launched based on specified metrics. However, this behavior makes approving changes difficult. If new resources are appearing and disappearing, how do we track what truly changed in the infrastructure? To gain a true picture, you need an infrastructure delta, which shows resource updates for the still-running resources for a given time period. You can also use automation to build a dynamic change management database, and use auto-discovery to keep CMDB in sync.

    Shared Responsibility

    DevOps calls for breaking down the walls between operation and development team to deliver code faster. If you release software fast, you can rapidly add value to your customer. The cloud enables this culture because developers no longer have to wait for IT to provision resources. What doesn’t work well, though, is when no one takes responsibility for optimizing cost and maintaining security. If engineers can launch resources, they are also responsible for cost and security—it’s a shared responsibility. You should provide visibility to the cost for each department, based on tagging we talked about earlier, so they know the cloud is not free 🙂 Anyone can launch resources as long as they understand the security best practices for each service they are using.

    Conclusion

    Lean thinking calls for reducing waste. What’s waste? Anything that doesn’t add value to the customer. You should work fearlessly to reduce waste. You move to the cloud because you can innovate fast and it’s cost-effective, so you can quickly add value to your customer. You should continue to optimize your cloud infrastructure to ensure it’s meeting its original intent.

    About the Author / JT Giri

    JT is the creator of nOps – AWS cloud security tool. He spent last 10 years helping companies migrate to cloud and build automated infrastructures. nOps is a next generation security and collaboration solution for the cloud. nOps applies change management practices to deliver integrated security and reduce cloud waste.

  • Why Your Company Needs An Automated Infrastructure

    Why Your Company Needs An Automated Infrastructure

     IT teams and software have started to embrace automation across all levels of the development life cycle, from planning and testing to deployment and maintenance. With the advent of DevOps, and the cloud, it’s now entirely possible for technical teams to spin up new environments in a matter of minutes instead of days.

    The process of applying continual automation to the software development life cycle is known as continuous delivery. With continuous delivery, businesses can continually perform integration tests, unit tests and code analysis. They can provision and configure servers and deploy software into their cloud environments. Each step in the continuous delivery process can be repeated several times a day depending on how much new software needs to be released.

    The Benefits of Infrastructure Automation

    There are several benefits to implementing infrastructure automation and a continuous delivery model in your organization. This blog post will explore five of the most considerable advantages you’ll experience when you transition from manual software development to an entirely automated process.

    Efficient Workflows

    The biggest benefit of continuous delivery is that it allows organizations to automate a variety of tasks with greater efficiency and accuracy. Each task within a workflow also can have separate dependencies to ensure that they are executed only when certain conditions are met. For example, you could set a condition to provision server only after certain tests are done.

    Lower Costs

    Because automation doesn’t require team members to perform a lot of manual steps, companies can save up on staffing costs. For companies that have larger teams and more complex infrastructures, the savings could be substantial. The best part about it all is that reducing staffing costs won’t have an effect on the end-product quality. In some cases, the product quality will be better than if the company used a manual process.

    Better Reliability

    Continuous delivery is typically more efficient and consistent than other software development models. It significantly improves business agility and stability and ensures that companies remain compliant at all stages of the software development life cycle. With an automated infrastructure, companies can also implement sophisticated monitoring and analytics to track the performance of their environment at any given time. By doing so, they’ll be able to identify issues before they pose any serious risks.

    Improved Collaboration

    One of the main reasons why DevOps and the idea of automation have gained popularity in recent years is because they enable collaboration between different teams in an organization. Automation gives software developers and IT teams the ability to communicate, which leads to better efficiency and more releases. This cross-team collaboration becomes especially crucial when working on large-scale projects and releases.

    Faster Updates

    Customers continually demand better and newer products, which why it’s important for software development and IT teams to use automation. Automation not only streamlines the process of releasing new software, it also significantly reduces the amount of time it takes to fix bugs and other issues that may affect the customer’s user experience.

    Summary

    Although the benefits of automation are clear, there are few downsides that you should also be aware of before going all-in and implementing a fully automated continuous delivery model. The biggest downside is that transitioning to an automated process typically has significant costs, which could have a temporary adverse effect on your bottom line. Furthermore, if your business has been using traditional software development models for years, it will take some time before the entire team gets on board with an entirely new system.

    How do you use automation in your organization? Let us know in the comments below.

    About the Author / JT Giri

    JT Giri is CEO of nClouds. He a seasoned DevOps professional with a decade of experience in building large-scale and distributed infrastructures. He co-founded nClouds, a leading DevOps solution provider, which helps companies with cloud migration and DevOps solutions. He is passionate about transforming organizations by implementing DevOps methodologies.

  • 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

  • Puppet Solidifies Enterprise Provider Status With Bevy Of Announcements

    Puppet Solidifies Enterprise Provider Status With Bevy Of Announcements

    Puppet has been maturing from a company with an enthusiastic base of users of an open source tool, to a leading provider of enterprise DevOps solutions for the last few years. Things really accelerated with the appointment last year of Sanjay Mirchandani, as CEO and the group of experienced, A+ players he brought to the executive team. Today Puppet took another step towards solidifying their position as a leading provider of enterprise DevOps solutions with a string of news announcements highlighting new products, accelerated growth and new/expanded presence.

    Lets start with what for many of you will be the most important. Puppet today announced “the general availability of Puppet Enterprise 2017.2, and upcoming availability of Puppet 5 Platform, the latest version of Open Source Puppet.” I had a chance to chat with Puppet CTO Deepak Giridharagopal, Chief Product Officer, Omri Gazitt and VP of Marketing, Tim Zonca. In their considered opinion this new version of Puppet Enterprise, more than just another upgrade, may in fact be the most significant upgrade to Puppet ever.

    From the press release, the most significant of these new capabilities are:

    • Package inspection: Users get started with automation by quickly identifying packages that aren’t being automatically managed, but should be. With package inspection, Puppet Enterprise users report on unmanaged infrastructure, making it easy to see the systems that would benefit most from automation to ensure their most critical software has the right maintenance updates, security patches and licenses.
    • Visual orchestration workflows: Users orchestrate infrastructure and application deployments entirely from within the Puppet Enterprise web UI, without writing a single line of Puppet code. Enterprises can target specific infrastructure environments using drop-down menus and filters, define workflows, monitor deployment status in real-time, and start, stop or restart deployments as needed, all with the click of a button.

    Both of these are much deeper than the few words from the press release. In addition to these though, there are also even more new capabilities packed in to 2017.2. Additionally, the open source Puppet platform 5 has many new innovations and hooks that will continue to keep the large base of open Puppet users happy, if they don’t require or need the greater feature set of the enterprise version.

    Speaking of those many users, that is the lead in to the second announcement. Puppet is growing and growing fast. Over the last 12 months they have added more than 250 enterprise customers to the business. Today over 37,000 companies use Puppet, with over 75 of the Fortune 100 also relying on Puppet. To help satisfy this increasing demand, Puppet announced the opening of a new Asia-Pacific office in Singapore, a large expansion of their existing office in Sydney and the opening of a new R&D center in Seattle.

    Puppet also announced significant additions to its partner program and participants:

    • New AWS Marketplace offering: As enterprises continue to recognize the value of cloud-based environments, they are turning to AWS and other cloud platforms for efficiency, savings and scalability. To support cloud efforts, AWS and Puppet deepened their partnership, making Puppet Enterprise available on an hourly, pay-as-you-go basis. The new offering simplifies installation, provides secure configuration and delivers immediate ROI.
    • Extended Cisco partnership: As software defined networking continues to evolve as a key tenet of the modern data center, Cisco customers want the power of Puppet Enterprise as a unified way of defining, deploying and operating all the software they run. Joint customers can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco VAR.
    • New partners for security and DevOps: Puppet has added a number of important partners as part of its inaugural class to the Technology Alliance Partner Program (TAPP). By collaborating with F5, Splunk, Cumulus Networks, CloudPassage, Conjur, CyberArk, Onyx Point, Intelliment and Sensu, Puppet and its partners collectively deliver a better architecture around security and DevOps.

    Again, all signs point to Puppet’s ascendence to enterprise provider status as it matures into its market leader position.

    The third and final announcement from Puppet is by no means the least of the three. In addition to the first two announcements, Puppet also announced two new offerings, Lumogon™ and Puppet Cloud Discovery™. With these the company expands its enterprise offerings beyond Puppet Enterprise, empowering companies to overcome challenges associated with modernizing infrastructure and application stacks.

    These are first offerings independent of Puppet Enterprise offered by the company. The represent significant new capabilities in two quickly growing markets, cloud and containers.

    Lumogon empowers “anyone involved in running containers, like site reliability engineers (SREs), release engineers, DevOps engineers, and the application developers themselves, now have a tool to gain operational insights into what makes up their containers with Lumogon. Lumogon provides a transparent window into each Docker image and running container, and offers a way to collect, query and report on container application metadata.”

    “Puppet Cloud Discovery collects and visualizes a rich set of system data to give users better awareness of the state of their infrastructure. Unlike other tools on the market that were built for traditional on-premise infrastructure, Puppet Cloud Discovery is cloud-first and is designed to model ephemeral cloud infrastructure. Puppet Cloud Discovery is delivered as a service, making it easy for users to see immediate time-to-value.”

    So Puppet has raised the bar and solidified its position in the marketplace. When taken together these three announcements illustrate that Puppet is accelerating in almost every facet. It will be interesting to see how they continue to build in the months and years to come.

    — Alan Shimel

  • AWS Extends DevOps Ambitions via Managed Services

    AWS Extends DevOps Ambitions via Managed Services

    Amazon Web Services (AWS) is signaling its increased interest in providing managed services spanning multiple aspects of DevOps with the launch of service that promises to make it easier to set up development projects.

    At a recent AWS Summit conference in San Francisco, CTO Werner Vogels described AWS CodeStar as a means for building pipelines using templates that span more than 90 different AWS services. The templates currently support five different programming environments: JavaScript, Java, Python, Ruby and PHP.

    CodeStar automates configuration of a continuous delivery pipeline for each project using CodeCommit, CodeBuild, CodePipeline and CodeDeploy, as well as providing integration with Atlassian JIRA Software for tracking issues via the CodeStar console. There also is a preconfigured project management dashboard for tracking activities such as code commits, build results and deployment activity.

    Over the past couple of years, AWS has expanded the number of managed services it provides considerably, including databases and now various classes of machine- and deep-learning algorithms exposed as a service. In most of those cases, it is replacing a task that previously was performed by IT operations staff with an automated service. That may appeal to IT organizations that have standardized completely on AWS. But in a multi-cloud world where elements of applications are deployed both on-premises and across multiple public cloud services, it remains to be seen the degree to which organizations will want to employ managed services that only automate AWS processes.

    One thing’s for certain: DevOps processes across multiple computing environments are becoming more automated. As microservices architectures become more widely employed, many organizations in the months and years ahead will become a lot more comfortable mixing and matching various cloud services as they see fit. Within that context, automation of DevOps processes will need to be multiplatform almost by definition. As a set of services exposed via application programming interfaces (APIs), it may very well turn out that the automated managed services provided by AWS can be programmatically invoked by other DevOps management frameworks.

    Of course, there are plenty of organizations that, for now at least, have standardized on AWS. DevOps delivered as a managed service by AWS clearly has some appeal for those organizations. But as cloud computing continues to mature, the number of organizations employing only one cloud service is expected to decline.

    While the battle of control of the cloud has been mainly focused on developers, more attention now is being paid to how application development pipelines get managed in the age of the cloud. Each IT organization will have a unique set of processes and requirements for managing those pipelines. In fact, the issue going forward will be to what degree can cloud service providers (CSP) adapt to those processes versus making the IT organization adapt to the CSP.

    In the meantime, IT organizations would be well-advised to establish the roles and functions they need to manage those automated pipelines sooner than later.

    — Mike Vizard

  • DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

    DevOps Chat: Ken Cheney, Chef on AWS OpsWorks for Chef Automation

    devopsy.kinsta.cloud catches up with Chef’s busy CMO Ken Cheney. Ken give us the inside look at AWS’s OpsWorks for Chef Automate. While this is an AWS offering it is based on Chef and is a pretty big bet by AWS on Chef. In addition Ken brings us up to speed (pun intended) on other things regarding Chef. Ken is always a great person to chat with and full of great info. We are going to have Ken on every month or so, we can count on hearing more Chef and DevOps talk soon.

    In the meantime, as usual the streaming audio of our conversation is below and the written transcript of our chat follows. Enjoy!

    Streaming Chat

    Transcript

    Alan Shimel:                Hi, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I am happy to be joined in this episode of DevOps Chat by Chef CMO, Ken Cheney.

    Ken, welcome.

    Ken Cheney:                Alan, nice to hear your voice again.

    Alan Shimel:                Nice to hear from you, Ken. Actually, I think the last time you were on our podcast or the last time we spoke you had maybe just been appointed CMO, or maybe it was even before you were appointed CMO at Chef, but it’s certainly been a busy time for you I’m sure.

    Ken Cheney:                Yeah, it has. There’s been a lot going on in the past two months and some of it we’re going to talk about today, the work we’ve been doing with AWS.

    Alan Shimel:                Yeah. I think the last time I spoke to you was right before AWS re:Invent, and there was some big Chef news coming down the pipe that we weren’t able to talk about then. It was still kind of under embargo, but it certainly is fair game now.

    So, Ken, why don’t you share with our audience what was big for Chef at AWS re:Invent?

    Other Great DevOps Chats to listen to:

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey
    DevOps Chat: Huw Price, Smart Automation Is Key
    DevOps Chat: InterConnect 2017 w/ Randy Newell, IBM DevOps
    DevOps Chats: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Ken Cheney:                First off, AWS re:Invent, a super-impressive show to go to. So if folks haven’t gone, I’d recommend this next year that they pencil it in. But at re:Invent we announced – actually AWS announced, it’s their offering, a new offering called AWS OpsWorks for Chef Automate. It really brings for the first time the full capabilities of Chef’s commercial platform to AWS as a managed service offering. So they provide support and they backup the offering 100 percent.

    So it’s a new offering that makes that job of configuring, deploying, scaling, both in the cloud as well as on-premise infrastructure simple and secure. We get there by really doing what Chef has done best over the years, which is automating infrastructure as code.

    I think to really highlight what I said, Jassy at re:Invent went out of his way to make the point that hybrid is the new normal in their view. So what’s interesting about what we are doing with AWS is you can manage both in the cloud with AWS as well as your on-premise workloads, and you can have that consistency in how you manage your resources across both.

    Alan Shimel:                Absolutely. Now, Ken, our audience may not be aware, but I happen to have known this, that Chef was sort of the dominant tool in use for AWS customers now for a few years; I mean an outrageous amount. If I’m not mistaken, wasn’t it like 65 or 70 percent of AWS customers who use some CM are using Chef?

    Ken Cheney:                Yes. A large proportion of AWS customers use Chef, and AWS themselves use Chef for many of their core services. It’s a platform that is really well suited to the job of: how do you get your workloads to the cloud, and how do you manage those workloads on an ongoing basis in the cloud?

    Alan Shimel:                Absolutely. And of course, Ken, when we talked about hybrid – I actually had a conversation yesterday, actually with maybe some IBM folks. We were talking about mainframes aren’t going away any time soon, obviously, the mainframe market. It’s probably bigger than ever in terms of dollars.

    But the idea of working with your systems of record and systems of engagement, and one is on a mainframe and one is in the cloud, is becoming more and more the norm for large organizations, right?

    Ken Cheney:                Yeah. It really is.

    Alan Shimel:                Yep. I mean they’re not going to just walk away from billions of dollars invested in mainframes and datacenters, but in order to compete with stuff that lends itself to it, it’s hard to beat the economics of the cloud. So for the foreseeable future anyway, probably the rest of our working lives, Ken, hopefully, hybrid cloud is going to be the dominant form there.

    Ken Cheney:                Right. Then if that is the case, then manageability and that kind of consistency in your manageability becomes front and center, and that’s where Chef plays a big role in being that bridge that really allows you to have a platform where you can store those configurations in one place, where your resources are going to work perfectly every time at scale, and you make changes in that single place and propagate those changes across those environments. So whether you’re running under a mainframe environment or you’re doing dev, test, prod in the cloud you get that repeatability.

    Alan Shimel:                Absolutely. Before we leave the AWS stuff though, Ken, I just want to, for our audience that may be interested, this is available now, today, through the AWS marketplace?

    Ken Cheney:                No. It’s a core AWS offering.

    Alan Shimel:                Okay.

    Ken Cheney:                So if you’re an AWS customer, you login through the AWS console and it’s one of the offerings that you can select. So it bills through AWS. It’s managed by AWS. It’s supported by AWS. So it’s very easy if you’re an AWS customer to get started, and you can get started for free, up to ten nodes for free per month.

    Alan Shimel:                Great.

    Ken Cheney:                Yeah. You can get started and get all those advantages.

    Alan Shimel:                That’s cool. All right, so people can go check it out right now. If you’re using AWS, it’s a core offering. And I guess that kind of makes sense because it is an AWS offering after all, isn’t it?

    Ken Cheney:                That’s right. We’re partnering very heavily with them to make sure it gets the kind of traction and success that we have envisioned.

    Alan Shimel:                You know what? That really is big news, Ken. Great job by the Chef people. Give my kudos to the business development guy. He did a hell of a job there.

    Ken Cheney:                Will do. Thanks, Al.

    Alan Shimel:                Weren’t you the business development guy, Ken?

    Ken Cheney:                I was. I’m weird, so –

    Alan Shimel:                Yeah, I know, just a little inside Chef joke. Ken, we talked a little bit about hybrid cloud and this new offering at AWS. Let’s look at the bigger picture. Here we are in January of 2017 and it’s not too late yet for – where do you see DevOps in 2017? Where do you see Chef in 2017? What big picture item should we be looking at?

    Ken Cheney:                What’s interesting right now in the market is that – you and I both see this, Alan – the market is still very young. I saw some Gartner data where you can extrapolate out that 90 percent of the market is still untouched. Even that 10 percent that has started down the path of adopting is only partially adopting.

    Yet what’s very clear, both at an industry level, if you look at industry data, as well as what we see with our own customers, is that DevOps has a significant impact on the bottom line. Companies that adopt DevOps have been shown again and again to outperform their competitors.

    Alan Shimel:                Yep.

    Ken Cheney:                And I think that DevOps – we’ve been talking about this for some time – but it’s really a full-on move from the early adopters, those organizations who figured out how to be disrupters, to the rest of the market who are being disrupted.

    Alan Shimel:                Yeah. It’s DevOps or die, as I like to say.

    Ken Cheney:                That’s a great statement.

    Alan Shimel:                Yep. Ken, I saw some interesting statistics from a study that CNA had commissioned, 1,700 respondents, and it said something like only 34 percent, so just a third of organizations had adopted DevOps.

    Ken Cheney:                Right.

    Alan Shimel:                Which to me and probably to you too, right, because how many organizations do we talk to that either haven’t adopted DevOps or don’t want to adopt DevOps? We live in a DevOps bubble. We think everyone does, but yet the fact is it’s only about a third, 34 percent. When you look at it that way, it’s barely mainstream, right?

    Ken Cheney:                That’s right. And even those who have adopted it typically adopted it in a small silo.

    Alan Shimel:                Right, the pockets of DevOps, as they call them. I continually refine that, Ken. What I mean by that is you’ll have a team – a team – using DevOps, maybe a team here and a team there, but only when those multiple teams come together under a common DevOps sort of processes, framework, manager, whatever, do I really consider the organization doing DevOps. So for me, an organization that’s doing DevOps is doing it with multiple teams.

    Ken Cheney:                Yeah. I totally agree, and I think this is the year where we start to see organizations really at an executive level begin to put their shoulder into what that means. How do you actually begin to go automated scale?

    And at the same time they’re going through the tech modernization investments around embracing the cloud, embracing microservices, containerization. So I think this is going to be a really interesting year, where I expect many traditional shared services organizations are going to be under a lot of pressure to change.

    Alan Shimel:                I agree 100 percent. It goes back to the DevOps or die thing. All kidding aside, if these organizations don’t change you’re going to start seeing them falling by the wayside.

    But you know what else I think, Ken, and I’m interested in your opinion on this. DevOps tools have to change, too. They have to continue to mature. They have to continue to be enterprise-ready. They have to continue to deliver and meet the challenges that organizations are faced with.

    Ken Cheney:                I totally agree. I think that there’s been a Cambrian explosion of tooling.

    Alan Shimel:                Yes. That’s a great phrase for it, a great way to put it.

    Ken Cheney:                Yeah. And there’s been a rapid kind of organic team level adoption, but what’s happening is that there’s been a lack of standardization, a lack of scale. When you look at the disrupters who have been wildly successful, and many of those are Chef customers, they have been successful automating at scale. Automating at scale means you do drive consistency across the board.

    The path to get there though, from my view, is you have to be thinking about vertical integration. If you look at our strategy, like take what we announced at AWS, that is where we are actually vertically integrating into their platform in a very real, meaningful way. And we feel the same way about the broader ecosystem of _____ capabilities that we need to integrate in with, to make that job of automating at scale easy.

    Alan Shimel:                Yeah, agreed. I do think you’re onto something with that, also vertically integrating, but it’s also integrating into the IT stack. For instance, for me and maybe it’s my own personal bias and history, if you look at 2017 as a year where we have to see security integrating with DevOps and we can call it DevSecOps or Rugged DevOps – I don’t really care what you want to call it – but there has to be that tighter coupling, that tighter integration into the IT stack of security shifting left as part of this DevOps.

    I know Chef obviously has now some history in trying to bring compliance at scale and compliance in security and speed. But I think that has to accelerate.

    Ken Cheney:                Yeah, it does. We are pouring the investment into that set of capabilities. When we look at what our customers are trying to get done, there are things like driving known vulnerabilities down to nothing, being able to remediate in minutes as opposed to days. To get there, that concept of shift left that you put forward is front and center. You have to start thinking about shifting risk to the left.

    So we’ve invested a lot in, one, our InSpec open source framework that people should go check out, as well as the overall compliance capabilities, where you can have broad compliance profiles that ensure that the state of your infrastructure and applications is conforming to policy.

    Alan Shimel:                Got it. You know what, Ken? You mentioned open source and it triggered something. What’s happening with Chef Habitat, anything new you can share with the audience?

    Ken Cheney:                Yes. Chef Habitat has been in the market now for about nine months. We have been seeing a tremendous amount of traction. We’re going to be launching a Habitat road show in a few weeks, visiting multiple cities. So people should go to the Chef website and see if we’re going to be coming to a location near them.

    We are really now moving into the phase where we have large enterprise customers moving workloads into production with Habitat, and they’re really targeting that job of: how do I easily encapsulate my applications and manage those applications, in a way that I don’t have to spend a lot of calories worrying about extraneous services and getting true portability out of it, meaning I can move that application workload anywhere I want?

    So Habitat is definitely getting legs at the moment. We’ve had some new product news that will hit in a couple weeks, Alan, so you and I will be talking about that.

    Alan Shimel:                Fantastic. All right, a little teaser. Ken, to tell you the truth, we’ve gone way over our usual time that we allot for podcasts. We don’t want to take up too much of people’s time, but let me just do a quick recap. For people who want to find out more about Chef Habitat, what’s the URL?

    Ken Cheney:                They go to the website, which is Habitat.sh or they can go to the Chef site, which is Chef.io.

    Alan Shimel:                Right, and it’ll just run through from there and they can find out about the Habitat road show there. The Amazon stuff you can get right through your Amazon portal or dashboard, if you’re an AWS user.

    Ken Cheney:                That’s right. AWS just did a webinar yesterday that was recorded that does a nice walkthrough on it. So they are actively out there promoting it and pushing it for their customers.

    Alan Shimel:                And the open source compliance and security?

    Ken Cheney:                You can get that through the Chef website.

    Alan Shimel:                Also.

    Ken Cheney:                Yep.

    Alan Shimel:                Okay. I just want to make sure people get it, Ken. Ken, we could probably spend hours talking. We’ll have to have you back on soon, maybe in a few weeks when you have your next bit of news. But until then, keep up the great work. Oh, we should mention ChefConf.

    Ken Cheney:                Oh yeah, ChefConf coming up May 20th to 22nd in Austin, Texas. People can go and register today. We’re pretty excited. We just closed the call for papers last night and had a record number of submissions. So it’s going to be a great event.

    Alan Shimel:                Cool. I went last year. It was a great event. I had a great time. It was some great content. The Alaskan Airlines was still my favorite, Ken. Actually it got me to fly Alaskan Airlines watching that guy present.

    Ken Cheney:                It was amazing, yeah.

    Alan Shimel:                It was the first time I ever flew them, and I was counting to see how quickly the door closed and how quickly they opened it, from his whole presentation. It was a great one.

    Anyway, Ken Cheney, CMO Chef, thanks for being our guest on this episode of DevOps Chat. Continued success at Chef and we’ll be watching and listening to find out what’s new.

    Ken Cheney:                Thank you, Alan.

    Alan Shimel:                All right. Okay, everyone, this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening and we’ll see you on our next DevOps Chat.

    — Alan Shimel

  • DOES San Francisco 2016: Adrian Cockroft On Retaining Talent

    DOES San Francisco 2016: Adrian Cockroft On Retaining Talent

    Another one of the over 50 video interviews we did at DevOps Enterprise Summit 2016 is our discussion with Adrian Cockroft. Adrian is was one of the last presenters at DOES this year, but that was a good enough reason to stick around until the end. Adrian’s presentation was on the challenges in retaining talent at high tech organizations.

    Before we dive into the talent conversation though, Adrian talks a bit about his own journey from Netflix where he pioneered so much of what we see in the DevOps market today. After Netflix, Adrian joined Battery Ventures, where he had the opportunity to go visit with numerous large organizations and find out what was working for them and what their challenges were. He was able to use that information to help guide Battery in which companies they should invest in to add to their portfolio. After several years at Battery, Adrian has recently left to join AWS where he will once again be directly involved as the VP of Cloud Architecture.

    But as I said earlier, Adrian’s presentation (truth be told he only had one slide or so, it was more of him speaking) was about the lack of enough qualified people to fill the ranks. This pressure results in successful companies having to “grow” their existing talent. But as Adrian points out the very act of letting this talent grow also leads them to move on. As they become more prominent in the field they are more likely to be recruited away. So how do you retain talent? Adrian tells us some of the things Netflix did to keep their engineers. Of course what Netflix did does not translate to many traditional organizations though.

    Obviously, monetary compensation helps an awful lot. But there are things beyond money (sometimes). Things like giving people titles like distinguished engineer for example.

    Adrian also brought up the example of Brent in the Phoenix project. How by giving him a different role, you not only remove the bottle neck, but also keep him happy in his new role.

    As usual, it was great listening and learning from Adrian. His reputation as one of the leading lights in the DevOps space is well earned and well deserved. Enjoy the conversation!

    devopstvsquareYou can see over 50 video interviews we did at DOES 2016 on our YouTube channel, DevOpsTV.

    — Alan Shimel

  • 3 AWS Design Patterns to Maximize DevOps Value

    3 AWS Design Patterns to Maximize DevOps Value

    Many business leaders are planning to make DevOps the cornerstone of their IT transformation strategy. But, as surprising as it might sound, skepticism abounds regarding how major vendors address the DevOps transformation challenges—they confuse DevOps with continuous delivery (CD) infrastructure.

    “We wanted DevOps and we got after a nine-month-long implementation a continuous delivery platform which speeds up IT operations without significant business value. How differently can you help?” the senior business executive of a major financial institution in New York sarcastically asked me during a conversation three months ago.

    The business executive is right: DevOps isn’t a technology as I’ve been implementing it, it’s primarily an accelerated application delivery approach implemented in the form of a technology-enabled application delivery operational model. Adam Jacob, CTO of Chef, substantiates that fact in “The Secret of DevOps: It’s Always Been About People, not Technology,” when he says, “DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible towards their goals.”

    Agile Admin’s Ernest Mueller in, “DevOps: It’s not Chef and Puppet,” confirms Adam’s point: “Chef and Puppet are individual tools that you can use to implement specific parts of an overall DevOps strategy if you want to use them—but that’s it. They are fine tools, but do not solve DevOps for you.”

    How can we implement DevOps in line with business leader expectations? Three Amazon Web Services (AWS) Design Patterns I developed can help to get the best of DevOps on AWS cloud: Software Organization Factory, Digital Organization Factory and CD Infrastructure Factory. This article discusses the Software Organization Factory.

    The Foundation of DevOps Value: Consequences to IT Service Delivery

    Before delving into these AWS design patterns, a quick reminder of what DevOps is, its value propositions and, more importantly, what changes are needed in how IT services are delivered.

    The Ignored DevOps Business Logic We All Must Consider

    The combined effect of cloud adoption and the rising digital economy is changing competitive environments; it forces business leaders to focus on innovation and market responsiveness as the competitive differentiators.

    The fact of the matter is, by facilitating access to technology, cloud accelerates entrance of several thousands of tech startups that take advantage of the recent technology innovations to substitute traditional products and services into digital. This creates a context where new entrants increasingly compete with established brands, forcing business leaders to seek value paradigms other than IT efficiency.

    The business executive argues, “In these new markets, our concern is to increase customer value by delivering the right services to the right segments at the right moment. You guys need to change the IT paradigm; IT alone does not create that kind of value.”

    Then, what should be changed in today’s IT approach?

    The Two Dimensions of Modern IT: The Operational Model and the Continuous Delivery  Infrastructure

    The new IT paradigm advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps,” is the idea that business value results from two dimensions: organizational agility and technology efficiency. In other words, it defines modern IT as a two-dimension asset including the operational model and the continuous delivery infrastructure.

    The timely delivery of innovation transcends IT issues; it not only cuts across your sales, marketing, post sales, application development and  IT operations, but also demands concrete answers as to how to accelerate business prioritization, decision-making and problem solving. The operational model is where business and IT people, processes, practices and tools are combined to create agile and cross-functional environments. The following exhibit shows a typical DevOps operational model:

    Typical DevOps Operational Model
    Typical DevOps Operational Model

    Organizational flexibility for the sake of flexibility doesn’t make sense unless technology is leveraged to speed processes. This is where CD infrastructures come into play; throughout the delivery process, they build on IDEs to accelerate coding and testing, on versioning tools to convert software version into releases, on continuous integration (CI) tools to build releases and on delivery pipelines to ensure continuous delivery.

    So, what is DevOps?

    DevOps is a Technology-Enabled Application Delivery Model

    DevOps is a combination of value, principles, processes and practices shared not only by developers and IT operations but also by the business. The goal is to help the organization deliver the right service to the right market segments at the right moment.

    DevOps from the Business Perspective
    DevOps from the Business Perspective

    As I’ve been implementing it, it’s a cross-functional application delivery model involving the business and IT and enabled by continuous delivery infrastructures.

    By enabling and automating agile practices, the continuous delivery infrastructure makes the operational model agile and provides the business with the flexibility and velocity needed to meet competitive challenges.

    Design Patterns as DevOps Implementation Engineering Framework

    As suggested by the business executive, today’s DevOps implementations struggle to deliver the promised business benefits. The reason is, the operational model dimension is ignored in favor of tools and infrastructure.

    Another reason is, DevOps is young and is still at the early stage of the technology maturity model; the expertise and engineering methodologies to implement it as what it is—a technology-enabled application delivery model—are lacking. That’s where DevOps transformation design patterns help.

    What are DevOps Transformation Design Patterns?

    In this article, the term DevOps transformation design patterns refers to general reusable architectures addressing specific DevOps strategy. They’re not necessarily implementable solutions, their primary goal is twofold:

    • Offer a neutral language for designing and implementing technology-enabled operational models
    • Offer an engineering approach that reduces design and implementation duration and effort

    They’re formalized architecture design and implementation best practices for DevOps and platform-as-a-service (PaaS) services.

    Design Pattern as DevOps Implementation Engineering Methodology

    To meet its goals—technology-enabled application delivery model—the design pattern is structured around four items including purpose,  principles, general solution and implementation techniques.

    Purpose: Clarifies the purpose of the design pattern along with the DevOps strategy to address.

    Principles: Are best practices formulated as rules and beliefs supposed to guarantee expected DevOps strategy benefits? They’re the determinants of the solutions to implement the DevOps strategy.

    General solution: Are blueprints resulting from the application of principles? They summarize the functional and technical architecture of the DevOps platform to implement.

    Implementation techniques: What are recommended technical approaches, solutions and tools to implement the general solutions?

    Why AWS? Why would it be the catalyst for DevOps value?

     AWS-ome Design Patterns That Will Change DevOps Implementation

    AWS offers such a rich, varied and easy-to-implement services portfolio that it would be unfortunate not to take advantage of it to modernize IT. The rationale underpinning the value businesses can derive from their DevOps transformation experience with AWS is summarized in the following figure:

    Rationale of the DevOps Design Pattern
    Rationale of the DevOps Design Pattern

    It’s the belief that:

    • Certain principles determine the AWS services needed to deliver the application delivery model (ADM) architecture that guarantees value.
    • The implementation of the ADM using these AWS services results in AWS-based DevOps platforms that tangibly deliver expected benefits.

    The Four DevOps Principles that Yield AWS Value

    Let’s explore the principles I’ve been using to make CIOs happy with their AWS cloud:

    1. Think holistic, not only IT: Reminds that transformation isn’t only about IT but the entire organization’s value stream from marketing and sales to development and IT operations.
    2. Think cross-functional, not only IT: Reminds that the bottom line is to set up a cross-functional application development environments to accelerate business prioritization, problem-solving and decision-making, and meet time-to-value objectives. They’ll be the core value propositions of the DevOps platform.
    3. Make it agile, flexible, and speedy: Reminds that agility, flexibility and speed are the catalysts for competitiveness and business value. They’ll be part of the DevOps platform.
    4. Think PaaS: Reminds that AWS provides varied services for implementing state-of-the-art CD infrastructure.

    Let’s illustrate three AWSome design patterns that’ll change DevOps experience with AWS!

    Implement a Startup Mindset with the Software Organization Factory

    The purpose is to implement DevOps strategies focused on time-to-market and time-to-value. It’s adapted for tech startups.

    To implement the startup mindset, the DevOps four principles for AWS are implemented as follows:

    • Think holistic and cross-functional, not only IT: Relevant business and IT resources are put together in a single and dedicated service development team supported by appropriate Scrum and XP agile practices.
    • Make it agile, flexible and speedy: PaaS services building on agile practices and AWS infrastructure-as-code are provided to make application delivery processes agile, flexible and speedy.
    • Think PaaS:  AWS infrastructure as code and DevOps tools are combined to implement a CD infrastructure in the form of a PaaS platform.

    The DevOps platform resulting from the principles application is illustrated below:

    Software Organization Factory
    Software Organization Factory

    The “Startup Mindset” platform is structured around three components including the cloud-enabled operational model, PaaS and the CD infrastructure.

    The operational model builds on a three-stage application delivery life cycle:

    •  Plan & measure: It mobilizes business users, development, QA and operations staff on business prioritization issues using agile practices such as Scrum product backlog planning or XP’s user stories.
    • Develop & Test: It mobilizes business users, development, QA and operations staff across the development life cycle using agile techniques such as Scrum iterations, XP’s test-driven development (TDD) and behavior-driven development (BDD).
    • Release & Deploy: It leverages continuous integration practices to build and test releases prior to deploying to production.
    • Monitor & Improve: It’s outsourced to keep the service development team on its core business: developing software.

    The CD infrastructure combines the followings services:

    • AWS CodePipeline and CodeDeploy to set up the delivery pipeline.
    • AWS infrastructure as code including CloudFormation, OpsWorks and Elastic Beanstalk to generate the CD infrastructure.

    Summing It Up

    The DevOps business benefits are real, yet, it’s young and is still at the early stage of the technology maturity model. The expertise and engineering methodologies needed to implement it as what it is—a technology-enabled application delivery environment—are lacking.

    DevOps design patterns such as the software organization factory fill the gaps of today’s transformation practices:

    • They provide the architect team and the executive team a neutral language to discuss the business, technological and technical challenges and solutions.
    • By pointing out the agile practices to leverage, they simplify and accelerate the design and deployment of the operational model.
    • By pointing out the AWS services and features to leverage they facilitate the design and implementation of the CD infrastructure.

    The DevOps implementation process described in this article is fully documented in my recent book, “Reinventing Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps.”

    In my next article I’ll tackle the Digital Organization and the CD infrastructure design patterns.

    — Philippe Abdoulaye