devopsy.kinsta.cloud

Category: Features

  • How Google’s Acquisition of Apigee Impacts Developers

    How Google’s Acquisition of Apigee Impacts Developers

    Google revealed a few weeks ago that it is acquiring Apigee for approximately $625 million. The deal demonstrates both the increasing demand for APIs (application programming interfaces) and Google’s desire to remain on the cutting edge of providing a platform for APIs. The purchase also underscores some important trends for developers.

    If nothing else, Google’s purchase of Apigee validates the importance of APIs for online commerce, as well as for businesses and developers in general. I had an opportunity to get some insight and feedback from Steve Davis, CTO of Four51, a provider of B2B ecommerce solutions, regarding the Apigee news.

    As DevOps and microservices continue to gain momentum, APIs play a very pivotal role. According to Davis, the API is the product for Four51, which makes it the foundation for the company’s DevOps strategies. “Most microservices are API-based as well, so the role is simply that they are the heart of these strategies. The concepts of DevOps relate to continuous delivery and all of the stages from development to deployment and operation. APIs allow developers the tools and visibility they need to work in this environment of delivery.”

    I asked Davis if he believes that it was a smart decision by Google to acquire Apigee at this time. “It was a wise move by Google to jump in, as the API economy is accelerating faster than other areas,” Davis answered. “The corporate customer appetite is increasing for APIs as companies continue their digital transformation, and API management is a critical discipline for security, scalabilty and reliability.”

    Davis pointed out that Google’s primary competitors—Microsoft and Amazon—have been out there with AWS and Azure cloud services for a while, and they’re doing quite well. He suggested that Google has some catching up to do, and that Apigee—as a best-of-breed independent platform—made a lot of sense for Google to target.

    For developers, Google’s acquisition of Apigee elevates Google as a cloud-hosting option—putting it on a more even footing with Microsoft and Amazon. The presence of an API management services enables developers to offload that tedious work and focus on more important things—such as continuing to innovate and bring value to their products.

    Davis also shared some thoughts on what the Apigee acquisition means for Four51. “Though we aren’t directly impacted by this acquisition, it does validate the path we’ve taken with our API-first eCommerce platform,” he said. “Many of the same enterprises looking to tap into the API economy are doing so to improve security, scalability and efficiency in their e-commerce and order management with their customers. We’re a big believer in the benefits of cloud infrastructure, as we recently moved hosting of our OrderCloud.io platform to Azure, and we’re utilizing the services there.”

    DevOps and microservices are all about streamlining productivity and operating as efficiently as possible. APIs play a major role in that effort, because they allow much of the heavy lifting on the back end to be automated. The acquisition of Apigee makes Google more competitive with its primary rivals, and highlights just how important APIs are—and will be for the foreseeable future.

    — Tony Bradley

  • CD Summit/Jenkins Days with John Willis, KK & Mustafa Kapadia

    CD Summit/Jenkins Days with John Willis, KK & Mustafa Kapadia

    JohnWillis1Our fall lineup of DevOps Connect: CD Summit/Jenkins Days are coming on fast. We kick off this fall’s schedule of seven events in Atlanta on Oct. 4 and 6. The speakers and subjects are up on the site, but I wanted to highlight the three keynote speakers: Our three headliners for Atlanta are Mustafa Kapadia of IBM, Kohsuke Kawaguchi (KK), the founder of Jenkins and CTO of CloudBees and, finally, the one and only John Willis (@botchagalupe). Each one of these speakers would be a great listen by themselves, but getting all three in one morning should be great!

    But wait, there’s more. In addition to Mustafa, KK and John, we have a full day of kohsuke-kawaguchiDevOps learning in store. The afternoon features three separate tracks with four or five sessions per track. On track is solely on Jenkins, one is DevOps in general and one is on automation and interoperability. Some of the other speakers include Ben Bomhoff from Security First Insurance and Daryl Bower from Accenture. Check out the website to get more information.

    Mustafa KapadiaAll of the above speakers are on the second day of the event, Oct. 6. The first day, Oct. 5, features several great workshops on Jenkins, Blue Mix and a DevOps Foundation workshop by the DevOps Institute.

    You can check out the full line up of speakers, schedules and topics at the DevOps Connect website. The cost without workshops for the day conference is just $99 and includes lunch, refreshments and access. If you would like to attend the first day of workshops as well it is just another $99. If you are in the Atlanta area, this is a great day of DevOps!

    If you are not in Atlanta, be sure to check out http://www.devopsconnect.com for the full schedule for the fall. Other cities we are visiting include:

    • Amsterdam
    • Berlin
    • Denver
    • Austin
    • Seattle
    • Los Angeles

    If you are in any of these cities, please come spend a day or two with us. Also be sure to stay on the lookout for additional conferences we are planning including DevSecOps events at RSA and InfoSec World 2017.

    — Alan Shimel

  • Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 2

    Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 2

    As we covered in part one, DevOps’ best asset and biggest risk factor may be one and the same: swift and precious change. In part two, we continue our discussion of the challenges and solutions with Deena Coffman, managing director of BDO Consulting’s Technology Advisory Services practice.

    David Geer: What specific tools and technologies can help DevOps teams to address change management in these ways?

    Coffman: There are a variety of tools and technologies to address some of the inefficiencies in change management, allowing DevOps teams to automate most of the process. For example, teams can leverage change management software to build pre-authorization processes and workflows to speed up change management approvals. On the security side, infrastructure monitoring tools will alert an organization when a discrepancy is discovered on the network, providing application visibility to the users and monitoring for unauthorized changes. DevOps teams should also consider using a collaboration platform like Slack to improve communication via virtual meeting places.

    Geer: What will these tools accomplish and how should teams be using them?

    Coffman: These tools are only useful if used properly. Deployments that require change management approval can go through the automated workflows. If a change requires approval, developers can use Slack or any other collaboration platform to contact the required party and explain the reasoning behind the modification. DevOps teams must also take the time to identify and automate as many “standard” changes as possible to reduce the reliance on change control meetings to speed up their deployments.

    Additionally, DevOps teams need to consider using an infrastructure monitoring tool to ensure all changes to the production environment are known and authorized. If a change finds its way to production without getting the appropriate authorization, the monitoring tools can detect it and report it to the team so they can rectify the issue.

    Geer: What kinds of things do DevOps teams need to do to address security to the satisfaction of the business?

    Coffman: The development team and security do not need to be at odds. By working in unison, both sides can reach their objectives.

    The InfoSec team would help the development team by making efforts to reduce the latency of security projects. The development team would help not only the InfoSec team—but potentially the entire organization—by preventing an expensive and embarrassing security incident by diligently supporting tools that automate security checks.

    Additionally, the build process needs to run unit testing, integration testing, functional testing, regression testing and information security testing before the code reaches QA. Security testing is often insufficient or not performed at all. DevOps teams need to understand that security testing performs an important function of catching issues early so as to avoid expensive, embarrassing issues downstream.

    Geer: What specific tools and technologies can help DevOps teams to address security in these ways?

    Coffman: Several tools are available to help DevOps teams address security in many different capacities, including setting up continuous integration/continuous delivery processes, automating server configuration, automating UI testing and functional security tests, testing the security requirements of applications and automating the vulnerability scan of applications and infrastructure.

    Geer: What will these tools accomplish and how should teams be using them?

    Coffman: DevOps teams should integrate these tools as part of their continuous delivery process. As soon as a developer checks his code in, the continuous delivery system should run the functional security tests, non-functional security tests and the security scan to ensure that the developer did not introduce a security vulnerability to the application and the infrastructure. These tools are only as powerful as the test scenarios they run. Therefore, teams should write exhaustive test cases to ensure the security of the application.

    Geer: How can teams do all these things and still maintain all the benefits and expectations that people have of DevOps itself?

    Coffman: By deliberately working toward improved collaboration and communication, teams can take advantage of the integration and efficiency benefits of a DevOps structure without sacrificing security or quality. Technical knowledge is important, without a doubt. To be exceptional, though, teams need equally strong teamwork and communication skills to actively support all important functions in the organization.

    — David Geer

  • The devopsy.kinsta.cloud Containerization and Microservices Survival Guide

    The devopsy.kinsta.cloud Containerization and Microservices Survival Guide

    Containerization and microservices seemed to have leaped out of nowhere and smack into the center of the enterprise IT scene. But neither leaped from nowhere. Both containerization and microservices have been part of the fabric of enterprise tech for some time—within Linux for containers and service-oriented architecture for microservices.

    Largely, thanks to containerization, both now are moving quickly to become central components of enterprise tech. Containers in recent years—and especially in recent months—have moved from tools used in development environments to production. And the ability to manage containers as discrete services is enabling enterprises to be able to respond quickly and be agile to technology demands.

    According to a recent survey from app performance vendor NGINX, of roughly 1,800 IT professionals, while container and microservices software adoption is limited it’s use is accelerating. The survey found that only 20 percent of respondents said they are using containers in production, while about one-third are doing the same for microservices.

    That survey, not surprisingly, indicated that microservices and container use will continue to accelerate, as roughly two-thirds of respondents said that they are currently evaluating containers and 70 percent microservices.

    Microservices are workloads that perform a single task and they are not dependent on the infrastructure or other applications for their ability to complete their designated task or “service.” Microservices are very effective at providing enterprises the ability to rapidly build software that solves business problems. They also make it possible for development teams to scale their efforts and build a more resilient architecture.

    With all of that in mind, and considering the nature of the inflection point most enterprises find themselves in now, we’ve assembled this microservices and containerization survival guide. The guide consists of some of the most important storage on microservices and container management that we’ve ran in the past year.

    DevOps Teams: Containers Will Help You Become Future Ready

    According to The State of Containers 2015 Docker Adoption Survey, more than 70 percent of respondents are either using Docker or evaluating for future use. Given the overwhelming popularity of containers, this post provides three trends that DevOps teams must be prepared for.

    7 Web Interfaces for Container Management and Orchestration

    Managing containers used to be a command-line affair. But a rich and growing ecosystem of web-based interfaces for containers has now emerged. This post provides an overview of the different web UIs available for container management and orchestration.

    ‘Containers-as-a-Service’ Is a Hot Trend

    Containers are still sort of the new kid on the IT block, but already containers-as-a-service is emerging as a thing. Here’s what you need to know.

    A Closer Look at Container Monitoring

    Enterprises have to ensure that all of their microservices perform well and provide their services as designed. Beyond that, how much do they really need to know about what’s going on inside their containers? The answer to this question varies. In this post Gerald Haydtner provides an overview for container-monitoring options.

    Containers: Not One to Rule Them All

    When it comes to the container platform ecosystem, not all container platforms are created equal. This post will help you sort through the options.

    Building Microservices: A Few Considerations

    An experienced practitioner details the top five design considerations when building microservices.

    5 Docker Best Practices You Should Follow

    Support for Docker has been integrated into many products and platforms and a lot of organizations are either already using Docker containers or trying to understand how to do so themselves. Our Tony Bradley provides the Docker best practices one needs to know to succeed.

    How to Choose a Cloud Platform for Containers

    Containerization has broadened from one or two vendors to a broader, more container-agnostic world and a drive to better scalability, redundancy, interoperability and security. Amazon, Google and Microsoft each have their own unique approach to addressing these cloud container concerns as they battle each other for supremacy. Here’s a look at how to evaluate each.

    Container Security: Why Bother?

    Are containers secure? Probably not. But knowing each approach’s strengths and risks—and available options—could help ease adoption.

    Container Security Challenges: Are Container Scanners Enough?

    How secure are containers? Not very, according to open source company Red Hat, which has published a blog post blasting the container ecosystem for lacking good security processes. Here’s a synopsis of what Red Hat has to say about container security, and some additional perspective.

    For Container Security, Automation Is Key

    Regardless of the IT infrastructure element in question, if it connects to a network—even through proxies or human intermediaries—eventually someone will find a security flaw and exploit it. Compatibility issues with new applications or infrastructure elements will emerge. Because of these reasons, all IT infrastructure elements need to be managed, without exception.

    Containers and Security Q&A: Putting a Lid on Risk

    How do containers affect security? And how can IT teams do everything they need to do in order to ensure the containers in use are as secure as they reasonably can be?

    — George V. Hulme

  • Industry Alignment: Supporting Real-World DevOps Workflows

    Industry Alignment: Supporting Real-World DevOps Workflows

    In our ongoing work to advance the interests of customers around adoption of Agile, DevOps and continuous delivery, the theme of evolving workflows to better suit human-scale work cycles often comes to the fore.

    While  it’s easy to say that build, test, release and monitoring capacities should feed into each other to promote continuous collaboration, realizing this vision in the form of integrated tooling is still no trivial feat. And it is further exacerbated by the reality that DevOps teams typically utilize a wide range of products built by a diverse set of providers, from larger players such as CA Technologies to open-source projects.

    If the goal is to drive  application lifecycle processes and supporting technology to better support human work cycles—along with accelerating organizational velocity and improving quality—somewhere in this domain of tooling integration there’s a need for relevant vendors to participate.

    That work officially begins today.

    At the Jenkins World 2016 conference this week, CA, along with a dozen other leading DevOps solutions providers and the DevOps Institute, announced the DevOps Express consortium. Joining us, along with CloudBees and Sonatype, which spearheaded this effort, are Atlassian, BlazeMeter, Chef, GitHub, Infostretch, JFrog, Puppet, Sauce Labs, SOASTA and SonarSource.

    So what’s the big deal? The direction of this initiative—which will focus first on supplying reference architectures that describe field-tested integrations of best-in-breed solutions—strikes directly at the heart of the central DevOps tenet: collaboration.

    The immediate result is that these providers are moving to boost interoperability across a typical production DevOps toolchain. It is truly noteworthy that these solutions providers, some of whom maintain palpable competitive interests, are putting aside those considerations to advance the interests of end users; that is a very DevOps phenomenon.

    In many other areas of IT, this type of cross-pollination either never commences or doesn’t emerge until the sector is so well-established that industry collaboration seems more of an effort to fend off perceptions of commoditization. To anyone familiar with the incredible pace of innovation ongoing in the automation sector, and the potential for competition between many of the companies involved in DevOps Express, it should be immediately obvious that this is a partnership that truly puts customers first.

    Yet, if we’re serious about empowering the kind of wholesale software factory reinvention that we espouse around DevOps, this is something that had to take place. How can an industry talk endlessly about eliminating stovepipes and marrying long disparate processes, and then defer to a walled garden worldview as it relates to the enabling products? That certainly wouldn’t really add up.

    It’s amazing to see what’s going on in the world of technology these days, and ever more exciting to be a part of it. We’re proud to be a member of DevOps Express.

    It’s a great time to be involved in this space.

    — Jeff Scheaffer

  • Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 1

    Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 1

    DevOps’s best asset is swift and valuable change, which also may be its biggest risk factor. DevOps certainly challenges change management and security. We recently discussed these challenges and the solutions with Deena Coffman, managing director at BDO Consulting’s Technology Advisory Services practice. Here is part one of that exchange.

    David Geer: What kinds of challenges does DevOps create for change management? Can you illustrate with an example?

    Coffman: By combining the sysadmin and developer functions, DevOps can lend to “shortcutting” the change management process in the interest of expediency. It may also undercut the value of having a critical eye from both a distinct system administrator and a distinct development reviewer. DevOps is designed to move quickly, and while the pace of change is accelerating, speed is often an ingredient for a security incident. Much like having the same individual who approves invoices also issue a check, DevOps makes for a faster, but not always secure, process.

    When the system of checks and balances can be purposefully circumvented, that privilege tends to be invoked more often than necessary. As a result, developers may bypass change management altogether far too frequently. The collaborative benefits from DevOps integrating typically siloed functions such as QA, software development, security and information technology operations are important, so long as they aren’t offset by compromises in quality and security that result from the reduction in the review and approval process.

    The expedient nature of DevOps can also lead to error, given the absence of human experience involved in the evaluation process. Before DevOps, if a developer needed to change a setting on the web server, they would submit a change request and wait for approval. Under a DevOps structure, though, the developer simply scripts the change and commits it to the repository—automatically kicking off the build process. The process runs unit testing, integration testing, functional testing and regression testing against the new code, and then pushes the new code to the staging environment and finally, to production.

    Geer: What kinds of challenges does DevOps create for security? Can you illustrate with an anecdote?

    Coffman: The biggest security challenge in a DevOps environment is that speed becomes paramount, which reduces critical evaluation on security risks. Developers incentivized to quickly deploy new capabilities are naturally pushed toward productivity and efficiency, which often run counter to security. DevOps can skew that balance so that security is only lightly or sometimes insufficiently considered. Automated testing will test for known exposures, but a trained, experienced human may be able to anticipate a risk before it materializes.

    Geer: How can flaws in change management in DevOps approaches lead to security issues?

    Coffman: Flaws or inefficiencies in the change management process reinforce the views of those who are prone to bypassing what they perceive as tedious process requirements. If a change management process is too burdensome or seen as lacking value, people will avoid it at any opportunity—not just when an exception permits a bypass. Since technology professionals tend to have a bias against waste and inefficiency, introducing a process requirement that consumes time and effort without returning value has a high probability of triggering a wholesale negative reaction.

    Geer: What kinds of things do DevOps shops and teams need to be doing to address change management so that they continue to meet the expectations of the business?

    Coffman: When it comes to ensuring that change management meets business expectations, it really comes down to several key ingredients: flexibility, speed, efficiency and risk management.

    DevOps teams should design and manage the change management system to be efficient, responsive, and flexible enough to accommodate cursory reviews for low risk scenarios and careful, in-depth reviews for other changes. Leadership needs to also set a tone of support for the change control process so it is not dismissed or marginalized. Additionally, engaging outside expertise and/or including additional quality and security measures for higher risk projects are recommended.

    A risk review that identifies projects with security and privacy risk and distinguishing types of changes supports the automation decisions and builds a DevOps program that balances its benefits with risk management.

    Stay tuned for part two.

  • HashiCorp Vault Enterprise Secures DevOps Infrastructure

    HashiCorp Vault Enterprise Secures DevOps Infrastructure

    HashiCorp, a DevOps infrastructure company known for its Atlas platform that combines a variety of powerful open-source tools, recently announced Vault Enterprise. HashiCorp describes Vault Enterprise as a comprehensive security solution for DevOps infrastructure. Vault Enterprise is the foundation for security in the HashiCorp DevOps infrastructure suite.

    Open source is a virtual necessity for effective DevOps—forming a close symbiotic relationship. I explained in the DevOps and Open Source report published earlier this year, “There are some significant advantages with FOSS (free and open-source software). With a proprietary, closed-source application there are very few people with access to look at the code. Recent incidents with SSH backdoors demonstrate that closed most certainly does not mean secure. When the code is open those types of backdoors can be quickly spotted and resolved.”

    With the addition of Vault Enterprise, the HashiCorp suite is now comprised of:

    • Vault Enterprise – Empowers security teams to collaborate, validate, and enforce security policies
    • Terraform Enterprise – Empowers operations teams to collaborate, validate, and provision infrastructure
    • Nomad Enterprise – Empowers development teams to collaborate, validation, and deploy applications
    • Consul Enterprise – Empowers all teams to monitor the complete stack

    Vault Enterprise is not entirely new. It builds on the open-source Vault to enable security teams to define and enforce security policy and secrets management across distributed infrastructure.

    “The shift to highly elastic, microservice architectures requires a different approach to security. Static network-based security is poorly equipped to handle the dynamic application-centric infrastructures being built today,” said Armon Dadgar, co-founder and CTO of HashiCorp. “Vault Enterprise enables organizations to adopt DevOps practices in their approach to security and keep pace with development and operations teams that are adopting DevOps.”

    Vault Enterprise includes Hardware Security Module (HSM) integration, which enables developers to integrate Vault Enterprise with HSMs using Vault’s simple API rather than more complex HSM interfaces. According to HashiCorp, there are also a variety of enhancements and new collaborative features in Vault Enterprise, including a new UI for managing secrets, health alerts and monitoring and an intuitive workflow for initializing new Vault clusters.

    “Deploying enterprise software to both public and private cloud infrastructure requires a security solution that works everywhere. As we adopt DevOps practices that make our applications and infrastructure more dynamic, we need bullet-proof security,” said John Mitchell, Architect at SAP Ariba. “HashiCorp’s Vault is the only offering that meets these requirements—one workflow across providers and dynamic secrets management.”

    DevOps is a culture and a process—not a silver bullet solution or a single product. HashiCorp understands this while still trying to provide a DevOps infrastructure platform that’s as complete as possible. HashiCorp pulls a variety of effective and useful leading tools together, and delivers them in a modular fashion that allows you to embrace DevOps at your own pace.

    There are plenty of vendors out there creating proprietary tools and platforms. What I like about HashiCorp is how it is harnessing the power of an array of open source tools to provide a whole greater than the sum of its parts. Vault Enterprise is available now.

  • DevOps Chat: CJ Paul, IBM, on DevOps, ITSM, Cloud and More

    DevOps Chat: CJ Paul, IBM, on DevOps, ITSM, Cloud and More

    devopsy.kinsta.cloud editor-in-chief Alan Shimel sat down to speak with Dr. CJ Paul, Distinguished Engineer, DevOps Methods & Tools, IBM Cloud. CJ is someone we have interviewed previously on video at IBM InterConnect and is always a great source of information. In this interview Dr. Paul discussed DevOps, ITSM, Cloud, Bluemix, Bluemix Garage method and more. 

    As usual, the streaming audio of our discussion is below. You can also find it on SoundCloud and iTunes. Below the audio player is the transcript of our conversation so you can follow along. Enjoy!

    Shimel:  Hi, everyone. Alan Shimel here for another DevOps Chat on devopsy.kinsta.cloud. Thanks for joining us. I’m happy to be joined on this episode of DevOps Chat by a friend of mine CJ Paul of IBM. CJ, are you there?

    Paul: Yes. Hi, Alan. How are you?

    Shimel:  Good. Good to have you on DevOps Chat with me today, CJ. Of course you and I have done several video interviews from various conferences we’ve both attended. But you know we haven’t had the pleasure of having you here, so welcome. CJ, I’m gonna bet not everyone in our audience knows who you are. Why don’t you give a quick little background on who you are, what you do, where you work and so forth?

    Paul: Yeah. Definitely. So my name is CJ Paul. I work at IBM. I’m a Distinguished Engineer in the cloud unit. And focused on DevOps methods and tools. So some of the things that my team puts out are the Bluemix Garage Method. It’s out as a website at IBM.com/devops/method. Then we also work on the Bluemix DevOps services and you know I work with a lot of clients as they do their transformation to the cloud. And trying to develop DevOps practices along the way.

    Shimel:  Great. So CJ, you know just kind of off the beaten path here, but we’ve had several guests on DevOps Chats that are distinguished engineers at IBM. And for our listeners who you know maybe are not familiar with what that means and it’s more than just a pretty title. Can you give our listeners a little bit of insight into what it is to be a distinguished engineer at IBM?

    Paul: Oh, definitely the focus of a distinguished engineer is to leave a portfolio of products in a particular domain. So in this particular case you know I have several product teams that work on different offerings in the DevOps space. And I’m responsible for crafting the technical strategy and providing architecture and technical direction to multiples of these teams.

    Shimel: Got it. So CJ, as I think I mentioned to you in our off camera or off microphone conversations, you know the month of September is gonna see devopsy.kinsta.cloud focusing a bit on APM and DevOps. And of course this is a subject that you are you know very familiar with. And part of what you do in Bluemix and all of these things, obviously APM’s a part of it. But why don’t we start with this? Can you define for our audience, when we talk about APM and DevOps and maybe it’s in relation to ITSM, right? IT Service Management which is something you’re also very familiar with. Can you kinda pull this all together for us?

    Paul: Yeah. Definitely. Traditionally operations teams have always worried about application availability and performance. Where performance includes you know how the application might respond from different locations around the world and how the response time evolves or changes for different types of transactions. Now, as we look at DevOps and the role of the DevOps teams becoming more cross functional, a lot of the focus is shifting to how do we get the synthetic monitoring, the configuration of the monitoring and all of that to be handled much earlier in the development cycle. In fact, in an ideal world, just like our source code is written to the specs of the product, we would also create the associated operational configuration of the monitoring tool, as well as the creation of the synthetics scripts, along with the source code. And so in the ideal case you would have all that be checked into the same repo. And then as part of your continuous delivery process you’d want to make sure the operations tool is configured to monitor that particular build that is deployed in a particular environment.

    So that’s the shift in thinking that we see a lot of the teams going through is how do we actually make this possible you know where all of the setup and configuration is treated as an extension to the source code of the product and worked through the lifecycle. Because it gives various advantages. Let’s say a new build comes out and you’re going to go deploy that new build in a particular environment or perhaps even introduce it to a small subset of your users in production. When you introduce that new build with a new feature, you want to monitor that new build or that new feature. And take all of that data and make decisions on whether you now ramp up to your full population. So what we see happening is in the new world of DevOps and especially on the cloud, you know monitoring has to go very much hand in hand with the features that the development team has built. And so it’s no longer just an after the fact operations thing to worry about. It is something you have to worry about as an integral part of the DevOps lifecycle. So that’s why I think this is a really exciting time. Especially the cloud enables application teams to do A/B testing and evaluate you know performance of new features, the response times of new features as it compares to their existing version of the application that is running.

    Shimel:  Sure.

    Paul:  And so all of the new capabilities you know that are the focus area in the application performance management space.

    Shimel:  Sure. Exciting times indeed. CJ, I would be remiss if I didn’t mention on this very topic that we actually have a webinar scheduled, I believe it’s Tuesday, September 20th at 1 p.m. Eastern Time with a colleague of yours at IBM, Arun Bilgiri.

    Paul: Yes.

    Shimel:  Are you familiar? Yeah.

    Paul: Arun Biligiri.

    Shimel:  Yes.

    Paul: Yeah.

    Shimel:  And Arun is gonna be doing this on Learn Why We Must Shift APM Left in the DevOps Lifecycle. And he’s gonna be also joined by Dan Kern, Solution Architect over at Prolifics. So you know if you’re listening to this and this is a topic of interest to you, not you CJ, I know you’re interested. But our audience, I’d highly recommend. You can probably register for this off of our devopsy.kinsta.cloud. Go to the Webinar and Events page and you can register there. But it should be dead on on topic for this. So CJ, I wanted to focus back on though this idea of shifting APM left, right. So when we talk about DevOps and how we fit in things like security and QA, now APM, that seems to be a common theme of shifting these things left. Get them earlier into the development process, right. Because the earlier it’s in, hopefully the better it comes out in the end, right. I guess my question to you CJ, is can we just continue shifting everything left, right. You know what I mean? Is there a point of diminishing returns of shifting left?

    Paul: Yeah. I think in this particular case especially, you know it’s something that is a good thing to think about right from up front. Especially as the velocity of deployments increases, we would expect the development teams to be more and more you know working the monitoring of the applications in conjunction with the code. Because you’re just kind of thought to have a throw it over the wall kind of syndrome. Because you know that would be too slow in this world to make it successful. So that’s why I think the shift left is almost an inevitable side effect of the need to go faster. And also with some of the shift to cloud, you know the way things are done are also different. So more and more the application architectures and topologies are becoming more complex to handle geographically distributed deployments and so on.

    So more and more we expect the development teams that are involved to be doing some of these operations automation just like they would work on you know features for the product. So some of these concepts surround you know cycle liability engineering and so on that are being out in the industry are just examples of why you know we’ll get more and more of a DevOps perspective on things that used to be just purely operations activities in the past.

    Shimel:  Got it. CJ, my next question with you on this is and by the way we’re running low on time so I only have one or two more questions left. Is you mentioned earlier one of my favorite things happening in IBM and that’s the Bluemix Garage method, which is an open source methodology kind of taking best practices and lessons learned from IBM themselves, as well as your partners into this methodology. Talk to us a little bit. Where does APM fit into there?

    Paul: Yeah. So with this Garage method what we’ve been doing is to take the learnings from across the industry on agile practices and design thinking and you know the latest DevOps practices and lean practices and so on. And organize it in such a way that enterprises can learn how to act like a startup but do it at enterprise scale. So within that method, we talk about how you think and plan, and code, and deliver, and run, and manage, and learn around a whole culture of DevOps. So in this particular case as we talk about application performance management, we typically think of it in managed. But as we have been discussing here, it kind of permeates through the lifecycle because you have to think about the availability of your applications as you design and build them. And you have to write the code for the synthetic monitoring steps, along with your features of the product. And you have to deploy them as part of delivery. And then clearly you’ll collect and analyze the data as part of manage and learn. So I think this whole shift left of APM fits in very nicely with the Garage method and its different lifecycle phases.

    Shimel:  Got it. CJ, I apologize, but just as I promised, yeah, we’re way over 12 minutes already and we’re gonna need to wrap things up here. But before we do, I wanted to just ask you one final question which is usually one that I ask most of our guests here on DevOps chats. CJ, for our listeners out here, if you had to recommend one book that they should read, what should be the next book they read?

    Paul: I would highly recommend folks read the Site Reliability Engineering book that has come out of Google. They talk about how engineers with development skills can automate a lot of what used to be production activities. That’s a very good read. Within IBM we’ve been doing these kinds of activities ourselves. You know me make sure that the individual squads are also responsible for their performance. But I find this is a good book for teams to look at if they haven’t already read it.

    Shimel:  Got it. Okay. CJ Paul, Distinguished Engineer at IBM. Thank you for being this episodes guest on DevOps Chats. Look forward to seeing you in person at some conference or another soon, CJ. And until then, keep up the great work.

    Paul: Thank you, Alan.

    Shimel:  This is Alan Shimel of devopsy.kinsta.cloud for DevOps Chats. Thanks everyone. Have a great day.

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

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

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

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

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

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

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

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

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

    Shimel: Thank you.

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

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

    Olson: Yeah. For sure.

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

    Olson: Yeah. That’s correct.

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

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

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

    Shimel: I was gonna say Michael—

    Olson:  —hit all those subjects.

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Yeah.

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

    Shimel: Perfect.

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

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

    Shimel: Yep.

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

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

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

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

  • Sounding the Death Knell for Agile: Not so Fast!

    Sounding the Death Knell for Agile: Not so Fast!

    Some say DevOps is the next step in Agile’s evolution.

    Software development is changing rapidly; if you don’t change with it, modern development may leave you behind. DevOps connects information technology operations with development and vice versa; this is a big change for the art of software creation. Agile was not designed with this new level of focus on information technology operations in mind, and must change to include this focus to thrive.

    According to Tony Higgins, CTO of Blueprint, the hot new trends that are supposed to replace the methodology actually are extensions of it. DevOps, for example, aims to extend the collaboration happening between development and QA teams to the operations people who are running the production infrastructure. “It’s the next step in the Agile process,” he says.

    Survey data correlates with assertions it is growing in large enterprises even as DevOps is expanding. According to VersionOne’s 2016 State of Agile Report, more than 24 percent of respondents who use the methodology work for organizations with more than 20,000 employees, compared to 21 percent last year.

    Addressing the State of Agile

    Some enterprise software development stakeholders are shifting their sentiments by moving into enterprise Agile from software project-based/development side-only Agile.

    To some, the original creed should be unwavering, even though it addresses only software development and not information technology operations. “In an ISV context, which is where Agile ‘grew up,’ this understanding did really well. But now with [it] making rapid inroads into information technology, the context is very different and, in a nutshell, the manifesto is insufficient,” says Higgins. The needs of information technology operations such as those that DevOps is meeting are driving new frameworks so it also can morph to include a Dev and Ops methodology.

    “Rather than dying, Agile is transitioning from a competitive differentiator to a core competency,” says Higgins. Whether as part of Agile, what the industry calls DevOps or some new methodology, development is accelerating by building new features and innovations in small, rapid, incremental trips through the pipeline; that approach is originally a core concept of Agile. “Industry folks declaring it’s dead don’t realize that businesses have not given up on it; they’re just looking for better ways to do it,” he adds.

    Agile is Growing

    According to Higgins, the methodology isn’t something that just “happened” in 2001 when its manifesto came to into existence. “Software development organizations were practicing and evolving the various principles of Agile all along and the manifesto was really a culminating event that codified it,” Higgins explains.

    The methodology is spreading much like DevOps, appearing in executive groups such as marketing, sales and information technology. “In marketing, they’re time-boxing their work into iterations with tangible outputs/deliverables. You’re seeing regular ‘stand-ups’ happening with the inside sales group. Agile is making fast and strong inroads into information technology, driving tighter collaboration with operations, and enabling faster delivery,” says Higgins. It is proving to be a repeatable business model that applies to every part of the organization that cares to use it.

    Proof it is a core competency lies in the fact that technology must now be able to support it. “Analysis tools that help determine requirements must be able to do so in an Agile environment,” says Higgins.

    Enterprises are approaching the methodology in better ways as organizations are seeing that requirements are keys to its effectiveness. “Requirements often have been overlooked in Agile processes, but recently we have seen research firms (Gartner, Forrester) and the market shift their focus to requirements to improve their deployments,” says Higgins.

    Both Agile and DevOps are useful in extending the collaboration of development and QA not only to operations people but ultimately also to other departments. “Instituting DevOps, continuous integration tools or any type of automated deployments will inherently require collaboration between departments; this must actually extend well beyond just Dev, QA and Ops and to the rest of the business to ensure that end-to-end visibility is achieved and decisions are not made in isolation,” says Higgins.