devopsy.kinsta.cloud

Category: Features

  • Wake Wants to Help Streamline Your Collaboration

    Wake Wants to Help Streamline Your Collaboration

    Effective collaboration is imperative to DevOps success. DevOps has many moving pieces working simultaneously and things happen fast, making it crucial that teams and individuals have an easy way to communicate and keep everyone on the same page. Wake is a collaboration tool that may help you do just that.

    “Collaboration across the enterprise is critical for DevOps success,” I wrote recently in an article on the importance of effective collaboration. “Great code and development needs to make it over the finish line to production to benefit customers. The challenge organizations face is how to do that seamlessly and with as much speed and automation as possible without sacrificing quality or performance.”

    “Just as open source is associated with cost savings and flexibility, DevOps is associated with speed and responsiveness,” stresses Jay Lyman, enterprise software analyst for 451 Research. “Enterprises are increasingly interested in initiating or growing their DevOps thinking and implementations, but they must be aware of the dramatic change it brings not only for technology and tools, but for people and process as well.”

    Wake is a collaboration platform used by teams and developers at Facebook, Instacart, Zendesk and other organizations to communicate effectively and share work with others. Wake was created as an internal project at digital agency Bakken & Baeck by Chris Kalani, a former Facebook designer. Silicon Valley companies Medium and Airbnb loved it and begged to be able to use the product themselves, so it was spun off into its own company. When Wake launched last fall, 350 companies signed up in the first month, including Cisco Systems, OpenTable and Uber.

    “Adjacent trends such as cloud computing, DevOps and containers are all speeding up the time it takes to iterate and deploy software and the movement of applications and workloads from test and dev to production, but the reality for enterprises is they cannot simply start fresh with a DevOps approach,” Lyman says. “Existing infrastructure, applications, people and process must be considered and integrated so that the transition to DevOps is not only less painful, but more realistic as well.”

    Wake ostensibly helps facilitate the increased speed and agility by simplifying communication and collaboration. It has a bit of a Pinterest look and feel to it, but Wake makes it easy to share your progress on what you’re working on without leaving the application you’re working in. It connects with messaging systems such as Slack and HipChat, and you can find what you’re looking for quickly by searching for specific people or tags.

    A Wake spokesperson tells me that Wake will soon launch significant updates to its enterprise product as it builds momentum with bigger brands including Capital One, Netflix and Mozilla. You can check out some use cases of Wake at Instacart, GoPro, Intercom, OpenTable and other places in this post on Medium.

    Pricing starts at $125 per month for five contributors and 10 spectators. There is a Plus subscription for $350 per month that includes 15 contributors and 30 spectators. Beyond that, pricing is negotiated for larger organizations. You can try Wake for free for 30 days.

  • Q&A: Full City Tech’s Higbee on Culture, Part 1

    Q&A: Full City Tech’s Higbee on Culture, Part 1

    Every day, more people are hopping on the DevOps magic bus, drinking the spiked punch and singing “Kumbaya.” I imagined everyone I interviewed would offer tales of instilling this undefeatable, undeniable, brand-spanking-new rapid development culture.

    It was refreshing to discover that I was mistaken. Apparently, DevOps is just another methodology for accelerating business success—one for software development.

    In part one of our latest Q&A, we chat with Wes Higbee, software developer, business consultant and president of Full City Tech Co. Higbee ably defends his stance on how special DevOps and instilling a DevOps culture is or isn’t in the grand scheme of things.

    devopsy.kinsta.cloud: So you say that DevOps is nothing new; that you have books collecting dust from the mid- to late-20th century describing similar organizational and management philosophies. What are some examples from those books you have collecting dust?

    Higbee: DevOps is the latest reincarnation of a lot of management philosophies that have been around for a long time. There are a couple of examples to reference. Alan Weiss, author of the book, “Best Laid Plans: Turning Strategy Into Action Throughout Your Organization,” wrote about functional organization at an insurance company that employed him. They had a functional department of typists and a functional department of people that would check the typist’s work.

    Underwriters sent requests to the typists to type up contracts. Typists would type up those contracts and then someone collected those for a separate group of checkers. The checkers would then check them and there was a lot of back and forth correcting errors. This led to a lot of inefficiencies.

    The solution was to take the checkers and pair them up with teams of typists. So a checker could review the work of several typists. That group of people worked together, and it turned out to be much more efficient, productive and effective.

    This is the heart of a cross-functional team, which is a fancy word for teamwork. This is one of the many ideas in the DevOps space, specifically taking developers and ops and putting these two groups of people together instead of having them as completely separate functional units inside the organization.

    Another reference is to pretty much everything Peter Drucker wrote. Specifically with regards to the people who are talking about focusing on the big picture. This is one thing that some people in the DevOps space are getting right. They’re talking about the big picture and not making optimizations to small parts of the picture that then jeopardized the whole, so optimize the whole. This comes from the work of Peter Drucker, “Managing for Results: Economic Tasks and Risk-Taking Decisions.”

    devopsy.kinsta.cloud: You say the danger is in the term DevOps itself; that as with agile, people slap a new name on what they’re already doing and think everything is better. If it’s not the terminology that needs to change to ensure a DevOps cultural transformation, then what is it?

    Higbee: I can’t tell you how many times I’ve encountered DevOps where devs and ops were still siloed. If you want to be successful—and this applies to any methodology—you have to start with real problems and real opportunities, because somebody else’s best practice is your own worst practice. If your customers are happy and your company is successful, you are seeing great profit margins and great growth, why would you change anything?

    Automated tests are something that people extol a lot in the DevOps space. You should have automation of your entire test suite and it should be part of your release process that’s also automated. But if you have no bugs in production, there’s no reason to go adding a bunch of tests to your release process.

    However, if your users routinely experience bugs in their production environment, then it would make sense to start talking about some testing and maybe even some automated testing during your release process. But don’t start with blindly writing tests of everything in the system. Start with the specific parts that are buggy, and you might be surprised how fast you can get those parts covered with some good tests. And then once you’ve done that, stop there.

  • Q&A: CNCF on Instilling a DevOps Culture, Part 2

    Q&A: CNCF on Instilling a DevOps Culture, Part 2

    In part one of this two-part series, devopsy.kinsta.cloud introduced the Cloud Native Computing Foundation (CNCF), a nonprofit organization with 49 members engaged in promoting the development of cloud native applications. Let’s continue with the CNCF’s thoughts on instilling a DevOps culture.

    devopsy.kinsta.cloud: Why do developers need the freedom to choose how they build software? What kinds and levels of freedom? Is this about approaches, development tools or something else?

    Brian Grant: All of the above: approaches, tools, languages … Different solutions work better for different workloads, scenarios, environments and people. Even new applications developed from scratch to be cloud-native aren’t typically developed in a vacuum—their developers may be familiar with particular languages or tools, the new application may need to interact with legacy applications; it may need to be built with and/or deployed onto existing infrastructure, etc. Often developers need to be able to adopt new technologies or approaches incrementally.

    devopsy.kinsta.cloud: How do you recommend providing this freedom to developers? How do you help provide it?

    Grant: Containers provide an ideal mechanism for providing this freedom, since they can be used to deploy both new and legacy applications, written in any language, built by any tool, into any environment. It’s a goal of the CNCF to foster an ecosystem of composable technologies, such as Kubernetes that facilitate the management of container-packaged applications.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: Because containers are small and fast, one application can be packed in each container image. Consequently, immutable container images can be created at build/release time rather than deployment time, since each application doesn’t need to be composed with the rest of the application stack nor integrated into the production infrastructure environment. This empowers developers to deliver deployable artifacts to operations.

    devopsy.kinsta.cloud: How is code reuse a need of the developer?

    Craig McLuckie: The vast majority of the actual code that is run in any given deployment is written by others. Only a tiny fraction of code in any given instance is actually written by the developer. The rest is everything from common libraries, to full OSS subsystems, to commercial software that systems, to adjacent software projects that provide some business functions. Developers need a common way to integrate with existing systems (when it makes sense) or to find and reuse existing code in a way that is controlled and operations-friendly.

    devopsy.kinsta.cloud: How do you recommend giving developers the ability to reuse code? How does your organization help with this?

    McLuckie: CNCF stands behind two technologies that are critical to code reuse. The first is the use of containers, which represent an intrinsically easy and predictable way to reuse even a relatively complex piece of software. The second is microservices-based architecture that make it easy to wire together systems and reuse existing services versus having to build their own.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    McLuckie: Containers make operations far more predictable and reduce possible avenues of error when deploying and updating systems. Rather than run potentially error prone imperative configuration systems to reuse code, containers are simple, lightweight and predictable, and reduce the potential for errors.

    Microservices allow for better operations specialization and create systems that are more intrinsically agile and easy to evolve. They allow for smaller teams that are focused on delivering a specific function versus having to align around large system boundaries. This creates a more productive and operationally viable environment.

    devopsy.kinsta.cloud: What is cloud-native? What does that mean?

    McLuckie: For CNCF, ‘cloud native’ is about a new pattern of application development that was pioneered by the internet companies, but that is equally applicable to developers and operators running more traditional workloads.

    We see three common attributes that make systems ‘cloud-native’:

    Container-packaged: Applications and processes are run in software containers as a unit of application deployment, which facilitates reproducibility, transparency and resource isolation. This improves overall developer experience, fosters code and component reuse, and simplifies operations.

    Dynamically managed: Applications are actively scheduled and managed. This radically improves machine efficiency and resource utilization while reducing the costs associated with maintenance and operations.

    Microservices-oriented: Applications are loosely coupled, with dependencies explicitly specified. This significantly increases the overall agility and maintainability of applications.

    Together, these three capabilities allow developers to build systems that are intrinsically agile and scale well. They significantly reduce the operational complexity of running an application, allowing operators to be more focused on application-level concerns and relying heavily on smart systems to do the operations heavy lifting.

  • Continuous Delivery Dependent on Who, What, Where

    Continuous Delivery Dependent on Who, What, Where

    Without the right people, positions and talents, it is difficult for a business to engender a DevOps culture. It is even more frustrating to facilitate a continuous delivery pipeline successfully producing quick bursts of innovative genius, without a full complement of qualified souls harmonizing on the same DevOps theme song as they toil away on the company’s next release.

    Some enterprises have a handle on the go-to people or hired guns they need to help spread a DevOps mindset—and exactly where to plug them into the organizational hierarchy. Other organizations have progressed to cloning these folks across Dev, Ops and the rest of the business. Some of those have laid some pipe as they extend a conduit from build to production. Those that are, by now, the “old guard” of DevOps have well-run pipelines brimming with fresh, robust software goodness.

    No one company has a “secret sauce” that works across all industries and organizations. How your company should connect the dots depends on who you ask. This time devopsy.kinsta.cloud has asked Renato Quedas, vice president of Solutions and Enablement at Micro Focus.

    Wrong People, Wrong Result

    The right people will produce significant changes to code, creating new value that is worthy of promotion to production. The right people will ensure that the release is ready, reliable and fit to go live anytime the business wants to give its blessing.

    “If a continuous feedback loop doesn’t exist between everyone involved in defining, building, testing, releasing and operating an application, the right people will not understand or feel enabled to pull the trigger in a release. Essentially that ‘any time’ will turn into ‘sometimes,’” says Quedas.

    The company must maintain business continuity/disaster recovery (BC/DR) while accelerating continuous delivery; if continuous delivery moves too fast, it will push BC/DR off the rails and into disaster. Testing is an important ingredient in ensuring BC/DR remains once the software reaches the end of the development pipeline. “Customers will not care if applications are delivered faster if they don’t perform or function properly on their platform and devices of choice. Not having the right people involved will turn continuous delivery into an unreliable minefield and create an uncertain application delivery pipeline, which businesses will never accept as part of any improvement initiative,” he says.

    The Right Stuff

    According to Quedas, the following positions or profiles are examples of people who would have the communications skills, ruthless negotiation tactics, sound decision-making processes and customer-first mentality—with little tolerance for poor quality—that are necessary to make a DevOps culture and continuous delivery work:

    • Product Managers who own responsibility for product quality can keep software product focus and development on track. They can communicate the business needs for the software, the capabilities it must have, and mediate the sometimes chaotic process that comes with continuous delivery. “Product Managers are used to prioritizing the work based on market trends, competitive landscape, customer requests and other internal/external pressures. Product Managers are accustomed to making decisions based on trade-offs, which helps CD focus in delivering the right outcomes to the business faster,” says Quedas.
    • QA Managers who readily communicate to test, development and operations teams as well as nontechnical folks about what is necessary to maintain software reliability. They also can bring development to a halt and send innovations back to the drawing board when validity and reliability are at risk.

    Creating the DevOps Culture

    A thriving DevOps culture will build a software delivery pipeline that can duplicate quality results—as any truly repeatable business endeavor should be able to do. To bring this culture to life, the company must demolish team and departmental silos to get everyone on the same page regarding what the organization must do and when it should do it. “Companies will need to streamline production via automation in order to make decisions faster,” says Quedas.

    A working, vibrant DevOps culture should give everyone a voice and ownership of a certain amount of control of their part of the process. “There is always pressure on information technology but there needs to be an understanding that it should be acceptable to put pressure back on the business,” says Quedas. “The business expectations need to be realistic or it won’t work. All sides need to be responsive.”

    A healthy DevOps culture and mindset includes a shared understanding that scope with value must be achievable in a reasonable amount of time. “The faster you demonstrate value, the easier it becomes to earn the right to continue in the journey and on to the next phase of development,” he says.

    Right People + Right Careers + Right Culture = Continuous Delivery

    Having the right people in positions such as the aforementioned product manager and QA Manager gives an organization the ability to hone its continuous delivery pipeline. The right culture ensures that everyone will follow these and other leaders and stakeholders so that each new innovation comes as quickly and smoothly as it can.

  • DevOps Security in Spotlight as Gartner Names vArmour Cool Vendor

    DevOps Security in Spotlight as Gartner Names vArmour Cool Vendor

    News Reports vArmour CEO Eades Nabbed $41 Million Ahead of Trump Presidency

    In May, Gartner named 2016 Cool Vendors in several security categories. Given the focus of this column, I was interested in several of the companies chosen for the designation, especially those named in the Cool Vendors in Cloud and Emerging Technology Security 2016 report. Interestingly enough, only vArmour, one of the new-era cloud security and visibility providers, was noted for supporting security in DevOps environments.

    Click to Tweet: Cloud Security #CoolVendor @varmour noted by @Gartner for #DevSecOps, datacenter vis. The latest @devopsdotcom: http://ctt.ec/uSRLd+

    In the report, analysts Joerg Fritsch and Brian Lowans wrote:

    Supporting the vision of a software-defined data center, all of the capabilities of the vArmour platform are exposed and consumable programmatically via APIs, providing support for highly automated and DevSecOps-type development workflows.

    The analysts also noted vArmour enables application-aware microsegmentation anywhere, from the data center to the cloud and all hybrid points in between. They also highlighted its capabilities that extend security to virtualized environments and containers—security anytime and all the time. Pretty cool, indeed.

    The report provides deep validation for a message vArmour has been pushing since its emergence from stealth—visibility. While many security vendors have interlaced the keyword into their marketing content, this report makes the claim for vArmour all the more true. According to the report:

    vArmour’s distributed security platform combines a scalable fabric with advanced security analytics that offer full visibility from a deep packet inspection engine. This deep visibility enables other cool use cases, such as network-based threat detection and the visualization of workload traffic. This is required in environments where the workload, the network and the security policies are interacting much more closely than we have been used to in traditional environments.

    Validation from firms such as Gartner can carry heavy weight among buyers, especially among deep-pocketed enterprise influencers. I’ve had conversations with C-level security execs at numerous mega corporations in the past who have stated point-blank that they won’t approve expenditures for any technologies that aren’t noted in recognized industry reports.

    vArmour also announced recently the closing of a $41 million round led by Redline Capital and Telstra. This D round lifts the software-defined security provider’s total investment to $83 million.

    In the official company release, vArmour stated it will use the capital for “global expansion and to accelerate worldwide software distribution of its Distributed Security System (DSS) through strategic partners in Asia-Pacific, EMEA and in North America.”

    Although the Presidential race wasn’t mentioned in the release, it was reported by CNBC’s Ari Levy that the real reason CEO Tim Eades sought funding now was in anticipation of a Donald Trump presidency. Eades was quoted in the CNBC story as having said:

    It really does matter what people think of the U.S. as we lead up to the election,” said Eades, a native of the U.K. who moved to the U.S. 18 years ago. With Trump, “the conversation he’s had around Mexico, trading abroad, his position on immigration — everybody outside America looks in and says, `What’s going to happen?’

    Levy continued:

    With Trump having closed the gap on Clinton in the polls less than six months before the election, Eades said it’s definitely time for start-ups to be padding their cash positions. He isn’t comforted by the fact that Trump is a businessman himself.

    To most reading this, vArmour being named a Cool Vendor and handily raising $41 million likely isn’t coming as a surprise. Starting with Eades, the company has an impressive cybersecurity and business leadership pedigree, especially when it comes to startups that are shaking up security thought and practices around the data center, cloud and DevOps movement. Eades is even viewed as a thought leader—likely one of the reasons why he is an occasional guest on global news shows such as Fox and Bloomberg, where he has been called to provide expert analysis on everything from cyberwar to breaches to investment.

    His vision to extend security to the rapidly growing trends of DevOps, cloud, containers  and automation is certainly smart, as these are directions most enterprise IT organizations are headed. Said Eades in a company issued release on the funding:

    It has been an amazing 18 months since we launched our company. We now have hundreds of customers adopting the vArmour Distributed Security System on a global scale, including some of the world’s largest telecom companies, banks, healthcare, retailers and U.S. government agencies. We believe Gartner’s ‘Cool Vendor’ recognition further validates the positive impact and true value we’re providing our customers. We’re offering them the industry’s simplest, integrated data center and cloud security solution to prevent, detect and remediate advanced persistent threats inside their network.

  • Q&A: CNCF on Instilling a DevOps Culture, Part 1

    Q&A: CNCF on Instilling a DevOps Culture, Part 1

    The Cloud Native Computing Foundation (CNCF) is a non-profit comprised of some 49 industry participants that have come together to drive development and adoption of cloud-native applications and services. The CNCF is uniting such giants as Google, IBM, Intel and Cisco Systems to distill a collection of container technologies that end-user companies deem praiseworthy to reach its goal.

    The CNCF intends its membership to represent end users (the CNCF website lists one end user, Goldman Sachs), cloud and container technologies, online and IT services, and academic institutions.

    On behalf of the CNCF, Craig McLuckie, its Governing Board chair, and Brian Grant, its Technical Oversight Committee representative, weigh in on leading the DevOps transformation and instilling a DevOps culture in this two-part Q&A.

    devopsy.kinsta.cloud: How is the CNCF specifically involved in leading the DevOps transformation by instilling the DevOps culture, in the industry or in member companies, for example?

    McLuckie: We believe that at the heart of the DevOps culture is the need to reduce the friction and, indeed, the barriers between teams that build an application and the teams that run an application. Developers learn to think about an application as a living service that evolves continuously and rapidly to meet the evolving business needs. Operations is there to deliver the tools and environment needed for them to successfully drive their application.

    devopsy.kinsta.cloud: Why do developers need an environment that is safe to change? What kind of change? Safe how?

    McLuckie: Safe change has many potential meanings: The first kind of “safe” is about creating deterministic behavior in operations. Does the system handle a change correctly every time? If I make a change to two systems, will they have the same state? How about to 1,000 systems? It’s important to focus on creating strong determinism by removing the moving parts in a production deployment.

    The second kind of “safe” is about being able to validate that a change is good—not just in pre-production environments, but in the actual production environment—with a simple and deterministic rollback. It is important to make it trivial to replicate environments, and offer a way to run a simple experiment in production (e.g. route 1 percent of my traffic to this new version) with the option to deterministically roll forward or backward without effort.

    A third kind of “safe” is about being able to ensure that every change is deliberate. One of the problems we often see in production systems is “configuration drift” that isn’t driven through any kind of formal process. This should be addressed by creating a strongly declarative toolset that makes every change deliberate and trackable.

    devopsy.kinsta.cloud: How do you recommend providing these things that developers need? How do you help provide them?

    McLuckie: There are multiple issues like data, security governance and applications that need to be addressed. Additionally, companies want to deliver apps with high velocity. How do you solve all of this? A vendor-neutral organization that can harmonize emerging technologies is important for facilitating cloud-native. Given the large number of players in the marketplace with competing approaches, having an open source way to solve this is also important.

    Grant: Cloud-native infrastructure enables self-service and “hands-off” operation, including provisioning, deployment, scaling, healing, discovery, monitoring and more, with relatively little marginal effort for specific applications. By supporting open source projects such as Kubernetes and Prometheus that provide such functionality, the CNCF hopes to democratize high-velocity application delivery, which was previously achievable mainly by web-scale companies.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: In a DevOps culture, operators are both partners and customers of the developers. Developers take responsibility for meeting operational requirements: security, reliability, availability, scalability, efficiency, actionable monitoring and logging output, necessary configurability, compatibility with the production environment, etc. Cloud-native infrastructure provides mechanisms developers and operators need to facilitate and capitalize on those capabilities.

    Stay tuned for part two of the CNCF interview.

  • DevOps Chat: Nathen Harvey, Chef

    DevOps Chat: Nathen Harvey, Chef

    I recently had the pleasure of catching up with Nathen Harvey of Chef. And I do mean catch up. As VP of community development, Nathen keeps up an amazing pace of visiting Chef communities around the world. In this role who better to understand what DevOps practitioners are seeing? Nathen and I spoke about several things including Chef’s security and compliance capabilities.  Below is the streaming audio of our conversation and below that is a transcript of our discussion to follow along.

    Enjoy!

    Alan Shimel:                Hi. This is Alan Shimel for another DevOps Chat here on devopsy.kinsta.cloud. Today’s guest is Nathen Harvey, VP of Community Development at Chef. Hi, Nathen. How are you?

    Nathen Harvey:           Great, Alan. How are you doing today?

    Alan Shimel:                Good. Nathen, I’m going to bet that most of our audience already knows who Nathen Harvey is and what your role is at Chef, but maybe for the few who are unfamiliar, why don’t you give our audience a little bit about what it is you do as a VP of Community Development at Chef?

    Nathen Harvey:           Yeah. I get asked that question a lot, Alan, and I’ll tell you that the real definition is this. There are two parts to it. The first being VP of Community Development means that none of my code runs in production and that makes the world a much safer place, if we’re being honest.

    Alan Shimel:                Okay.

    Nathen Harvey:           The second thing is before I joined Chef I did actually have code that ran in production. I actually managed a bunch of production infrastructure. So when I moved from an operations role into a community management role, the thing I like to say about that is I put down the pager and I picked up the bar tab. Oddly though, I’m up at 3:00 AM either way.

    Alan Shimel:                Yeah. Well, I think that’s just part of today’s work environment, where everyone is up it seems at 3:00 AM, depending where you are in the world.

    Nathen Harvey:           But joking aside, it’s really about going out and meeting with our community and helping fuel the love of Chef, helping folks in companies large and small get better at automation, get better at dev-ops, get better at great software development and infrastructure practices.

    Alan Shimel:                Yeah. And, Nathen, you’re not kidding about seeing people the world over, too, as part of your role, because I follow you on Twitter, I follow where Nathen is speaking, and whether it be a local meet-up group or a Chef users’ group or a conference or customers, you literally are traveling the world constantly.

    Nathen Harvey:           Yes indeed.

    Alan Shimel:                Yes, preaching the Chef message. Nathen, I wanted to focus our talk a little bit today around one of my favorite subjects, security, infosec, whatever you want to call it. Chef has become one of the leaders and has been for some time – one of the leaders in security within the dev-ops movement, if you will.

    I had the pleasure of becoming friends with Justin Arbuckle a year, year and a half ago. Justin was out preaching – what was it – compliance at Velocity or something? I may be mistaken.

    Nathen Harvey:           That’s right, compliance at Velocity. You bet.

    Alan Shimel:                You know, for a long time and it resonated with me. Then of course I think Chef made an acquisition, a European company who sort of had a compliance vulnerability scanning for code.

    Nathen Harvey:           Yes.

    Alan Shimel:                And now you guys have really kind of laid down the gauntlet on this and really put the pedal to the metal in talking about why it’s important to do this and why it’s important to do it earlier. I don’t want to steal your thunder. Can you give our audience a little bit of your opinion on why it’s important and what should be done?

    Nathen Harvey:           Yeah, sure. Look, Alan, in a traditional way of developing our software we all fall under some sort of regulatory burdens. We all have auditors or other security controls that we need to make sure are implemented within our production systems, and the traditional way of doing that, at one point in your development workflow you might introduce a security scan into the development workflow itself before you go to production, but usually that ends up just being a blocker for moving flow, moving change across your organization.

    So you’ll oftentimes pull that security scan out and then just start scanning your production systems. But for me, scanning the production system is kind of like the oil light on your dashboard. When it comes on, it’s too late. You have to have solved that before you get into the production environment.

    So at Chef, really we look at our roots with automation and our ability to fully customize and fully automate the buildup and the maintenance, configuration management of your infrastructure over time, your infrastructure and your applications. We say that we need to make sure that we’re always in compliance, but it’s also very important for us that we start to adopt more of the development workflow, more of the software engineering principles.

    One of those principles of course is that we should do test-driven development. Well, why not take those controls and those audit controls that you have to enforce and move those directly into the development workflow? You certainly see many cases where you’re doing, say, static code analysis during your continuous delivery pipeline or during your continuous integration. But what about moving that even further back and doing not only static analysis of your code, but also actually testing what does the running application actually look like? Is it exposing ports that it shouldn’t? Is your infrastructure configured properly? And can you do that on the developers’ workstations, move that -? We like to say you’re moving compliance to the left. If you think about your change flows from left to right, from your developer’s workstation all the way out to production, how do we get and start thinking not about how to scan the production environment better, but instead how to start making those controls into your developer’s workflow?

    Alan Shimel:                Yep. Nathen, as a security person that’s almost radical to me. I will tell you, having spoken to many security people about this, we actually put on a DevSecOps day, a Rugged DevOps day at the RSA conference last year in San Francisco and Justin spoke there. A lot of security people, this makes them very nervous, believe it or not, Nathen, because it’s not them doing the scan. We’re going to ask developers to scan their code on their workstation, while I’m not there to see it, right, or not there to make sure that the code is right?

    Nathen Harvey:           Right, right.

    Alan Shimel:                Go ahead. I’m sorry.

    Nathen Harvey:           Let’s look at that. In the past, and I understand where these security folks are coming from, but if we look at today’s enterprise and the way that software is built today, security folks want to be the ones that are doing all of the scans, that want to be the ones that are making all of those assessments. On the one hand that’s fine. They should absolutely be involved in those assessments. But, frankly, if it’s the security team only that’s responsible for that, it’s simply not going to get done. The security teams aren’t big enough; don’t have enough capacity to keep up with the rate of change. They’re going to become a blocker in the enterprise and that’s going to become a real problem.

    So it’s really that security professional’s goal or the way that they need to look at this is, first, automation makes their job much, much easier. Not only can we remediate things that are found much, much faster, but we also gain consistency and things like that.

    But if we can then partner with the development team, with the engineers that are building out those systems and get them to think of security as a first level concern and compliance as a first level concern and start being partners with us, like we’re partnering with them, we’re not abdicating our responsibility to them. Frankly, some of the scans that the security team is going to run in the production environment, they’re still going to run those, but what we’re going to find by giving developers better tools to run those scans sooner, to ensure compliance earlier in the process, that those scans are going to find fewer and fewer vulnerabilities, and those vulnerabilities that are found we’re going to be able to address and remediate much, much faster.

    Alan Shimel:                And I might add, Nathen, not only much, much faster, but much, much cheaper. I mean I’ve seen studies where it’s something like 10x to 100x cheaper to take care of a vulnerability or a compliance issue at that shifted left stage, where it’s still on the developer’s workstation rather than on some cloud instance. Right?

    Nathen Harvey:           Absolutely. That may feel radical, but it’s really just we’re going back to our roots. I mean we’ve known for decades that fixing a bug in the development process is much less expensive than fixing it after that bug has been released into your production environment. The same is true for a security control or a compliance control.

    Alan Shimel:                I agree. I agree with you. Nathen, I have another issue I wanted to touch on with you, and that is some people get hung up on the compliance, the C word, so compliance versus security. They’re not synonymous, right?

    Nathen Harvey:           They are not. They are not at all synonymous, no. I think that compliance – Alan, let’s think about this. You have a CEO at a company who has to sign off and agree to – have auditors come in and assess whether or not they are compliant. Frankly, when an auditor walks in the building, there are many, many organizations who say, “Our number one objective when the compliance person walks in, when the auditor walks in is to get them to sign off on our audit and leave as quickly as possible. I don’t want them meddling in my business. I want to get them out of here.”

    Alan Shimel:                Yep.

    Nathen Harvey:           So with that approach, what we really do is try to make sure that we can run compliant systems, and compliance is there so that we can assess whether or not we are secure, but security really needs to – it’s a different mindset than compliance. Compliance sometimes is the easier place to start. I want to make sure that my audits are passing. When I have audits that are passing, I can sleep at night knowing that my audits are going to pass. Then I can start to look broader at the system in terms of: am I actually building a secure system? But, frankly, security is the foundation and compliance is what sits on top of that.

    Alan Shimel:                Yes, absolutely. Nathen, the other thing I think that really has enabled – and maybe it’s a little bit of a chicken or an egg kind of issue – does this enable them or they have enabled the compliance issue? Developers are taking to heart the fact that security is everyone’s responsibility, and the fact of the matter is it starts with them. Right?

    Nathen Harvey:           Absolutely. Alan, we’ve seen similar things in the past. Look at QA teams, where developers have said, “You know what? We’re going to start doing test-driven development. We’re going to adopt some of those practices.” And the QA teams get nervous, “That’s my job.” The problem with having it be someone else’s job is you’re not going to do it. You’re not going to be concerned with it.

    So, really, just like our QA professionals are now partnering with the devs, the security professionals and compliance officers are now partnering with the development teams. Frankly, that’s what dev-ops is all about. It’s about this working together towards those common goals and getting there as quickly as we can.

    Alan Shimel:                Yeah, absolutely. And it’s good. It’s good on so many levels to have the security team integrated with the devs, to be working closely with both dev and ops, dev-ops, and making it happen because, frankly, that’s what attracted me to dev-ops to begin with, was the promise of being able to do that instead of being the appendage at the end of the Rube Goldberg kind of –

    Nathen Harvey:           Absolutely. Alan, what you’re really looking at there is we’re talking about a partnership. So there are some cultural or some workflow changes, some partnering that we have to do across the organization. The thing that helps enable that also is the tooling. The tooling definitely matters and the two, culture and tooling, are there to reinforce one another.

    So with Chef, we have a new open source language called InSpec and that’s the tooling that allows the developers to actually write these compliance controls, execute them locally. Frankly, it allows them to write them in a way that’s delightful, in a way that a developer understands, that a business analyst can look at those tasks and understand exactly what’s happening.

    Then with Chef compliance we also introduce those same compliance controls into our own scanner capability, where you can scan against your production environment, find vulnerabilities, go back into your automation code, remediate those, and watch that remediation happen across the entirety of your pipeline.

    Alan Shimel:                Fantastic. Nathen, as I had told you earlier, before we started recording, our time is limited, but for folks who maybe want to find out more about compliance scanning, more about Chef’s capabilities in this area, where can they go to get more?

    Nathen Harvey:           For sure the place that they can go is www.chef.io/compliance. Again, I just want to stress that the scanning capabilities are absolutely important, but really what we need to do is shift our mindset and think about: how do we start writing tests for those controls and do those early on in the process? Not that scanning should be an afterthought, but we really do need to focus on that beginning stages of our development process.

    Alan Shimel:                And automation, automating that is key. Nathen, we’re almost out of time here. Unfortunately, it always goes too quickly. But I wanted to ask you one last question, which we usually ask our guests here on DevOps Chat. That is one book, if you had to recommend one book to our listeners that they should read maybe over the summer or in the near future, what book would that be?

    Nathen Harvey:           I would recommend Lean Enterprise: How High Performance Organizations Innovate at Scale. It’s a book by Jez Humble, Joanne Molesky, and Barry O’Reilly.

    Alan Shimel:                It’s actually on my bookshelf. Cool. I love it when someone suggests a book I’ve read actually. Very cool, Nathen, and it is a great book. Jez’ Lean Enterprise book is great as of course is the Continuous Delivery book.

    Anyway, Nathen, we’re about out of time here. So I wanted to thank you for being our guest on DevOps Chat. Continued success with your globetrotting VP of Community Development role at Chef, and continued success to Chef in general there. It’s one of our favorite companies in dev-ops and we love what they’re doing.

    Nathen Harvey:           All right.

    Alan Shimel:                And maybe we’ll get you back on again soon.

    Nathen Harvey:           Yeah, that sounds great. Thanks so much, Alan.

    Alan Shimel:    Okay. This is Alan Shimel with Nathen Harvey, VP Community Development of Chef for DevOps Chat. Thanks and we’ll see you next time.

  • Black Duck Targets Open Source Code Security Flaws

    Black Duck Targets Open Source Code Security Flaws

    Open source platforms and projects offer a wide variety of benefits for organizations and developers, but they also can introduce vulnerabilities if you’re not careful. That’s why Black Duck has released Security Checker, a free tool based on its Hub open source security tool to help you identify those vulnerabilities so your applications will be secure.

    One of the advantages of open source is also a potential concern. Open source software has benefits from community cooperation and collaboration. More eyes and more hands contributing to the development allow for faster evolution and greater innovation. However, when all of the code is available to the public, and any developer can add or change the code, it also is an opportunity to introduce problems.

    While theoretically it is possible for a malicious developer to intentionally add vulnerabilities or exploits, the collaborative nature of open source projects actually makes it less likely. Any obvious attempt to insert malicious code would be detected and thwarted by other developers. The communal nature of open source development is not infallible, though, as evidenced by recent major revelations such as Heartbleed.

    Open source projects that are active and properly maintained address these issues fairly quickly. The problem, however, is that organizations and developers need to be able to easily determine whether their existing applications are affected and apply the appropriate patches and updates. There also are many open source tools that are not being actively developed or supported, which means known vulnerabilities may be left unfixed.

    Security Checker from Black Duck can help minimize exposure to these risks and give organizations and developers an opportunity to address any known issues. The tool is a drag-and-drop solution that allows you to scan code contained in an uploaded archive file, such as a .tar or .zip file, or in a Docker image. Security Checker then generates a report that shows identified vulnerabilities and security issues.

    A recent report from Black Duck found that 67 percent of audited applications contain known open source security vulnerabilities. More than a third of the vulnerabilities identified were classified as “severe.” The most notable finding, however, is that 10 percent of the applications surveyed still contain the Heartbleed vulnerability, which was discovered in April 2014.

    “Applications represent the greatest level of risk on the security threat landscape, and we expect that Security Checker scan results will provide an ‘a ha moment’ for many open source users,” said Black Duck CEO Lou Shipley in a press release statement. “Their findings will focus attention on the need to regularly review application code to ensure it’s free of known open source vulnerabilities.”

    The process of scanning and generating the report takes about 15 minutes, according to Black Duck, which also noted the maximum file size Security Checker can scan is 100MB.

  • Open Source Is the Secret Sauce of DevOps

    Open Source Is the Secret Sauce of DevOps

    DevOps is a relatively recent phenomenon—especially compared to the world of open source. While DevOps and open source are two entirely separate things, though, the reality is that it’s difficult to separate the two at this point. Many open source projects rely on DevOps tools and principles, and DevOps depends heavily on open source applications as both the glue that binds it all together and the engine that keeps everything moving. A new report from devopsy.kinsta.cloud, “DevOps and Open Source,” digs in to understand the symbiotic relationship driving the next generation of IT.

    “DevOps and Open Source” examines the role of open source in DevOps, whether DevOps can succeed without open source, the unique challenges of leveraging open source tools, and the benefits of open source partnerships with large corporations such as Microsoft and IBM. The report also includes a list of some of the most widely used open source tools for DevOps, including Chef, Puppet and Docker.

    Leveraging open source tools gives organizations and developers much more flexibility and control. Because the underlying code is available, it provides an opportunity to customize it to fit unique scenarios or to create the necessary APIs to integrate the open source software with other tools. The fact that there is no single vendor that “owns” the software also means that organizations and developers can build on open source tools with the confidence that the apps will not arbitrarily disappear one day.

    You can definitely develop or use open source applications without embracing DevOps, but is it possible to do DevOps effectively without using open source? “Maybe,” says Randy Kilmon, vice president of Engineering at Black Duck. “But who would want to do it that way? With so many great open source tools and components out there, deliberately shunning them would be a mistake. Besides, there is a piece of open source somewhere in your stack, whether you know it or not.”

    That statement seems to be more true with each passing day. The growing momentum of DevOps and the mainstream acceptance of open source software form a powerful partnership that is transforming how applications are developed, deployed, monitored and maintained.

    “Organizations want to advance their technology practices and stay ahead in very competitive industries, and do so in a mindful way,” explains Jose Miguel Parrella, senior product marketing manager of Cloud Platform Marketing for Microsoft, in the report. “DevOps can help reconcile the organizational needs, add value to the business, streamline the IT value delivery process and leverage open source innovation.”

    The report sums up with this: “The simple fact is that the fundamental concept of DevOps—the culture shift organizations embrace to change how teams cooperate and collaborate so that projects can be delivered more effectively and efficiently—more or less requires a dependence on open source tools. A DevOps environment is too fluid and evolving to sit idly, waiting for a commercial vendor to develop a product with just the right set of features and capabilities.”

    The report is available for download here.

  • Q&A: Quali’s Wrabetz on Security Testing

    Q&A: Quali’s Wrabetz on Security Testing

    DevOps is the perfect storm of automated testing and development that should make secure software commonplace. Yet, there are hurdles to testing for security. devopsy.kinsta.cloud asked Joan Wrabetz, CTO of Quali, about security, DevOps and her laundry list of those testing challenges.

    David Geer: Isn’t secure software important to DevOps?

    Wrabetz: DevOps is a practice of continuously deploying applications into production clouds. In order to automate the deployment of applications into production, it would seem essential for security testing to be a part of that automated process. In fact, when talking with one financial services firm, they said that they don’t deploy continuously into production because they are concerned that to do so would break the law. They are required by law to ensure that applications comply with their regulatory and privacy requirements before they are deployed into production. The only way to do that is to perform security testing. Thus, in order to achieve continuous deployment, they would have to integrate security testing into their DevOps flow.

    Geer: So, why isn’t security testing a core part of DevOps already?

    Wrabetz: The reasons are both technical and organizational. Organizationally, security testing is usually handled separately from development or product release-oriented testing, often by a completely separate group. As a result, it is not necessarily associated with the application release process.

    The technical reasons are related. Historically, security testing has involved reproducing the production infrastructure and network configuration as accurately as possible so that security vulnerabilities can be identified. Often, development and test teams working on DevOps do not invest in creating accurate reproductions of production infrastructure for their normal development and testing. So, they are not prepared to perform security testing as part of their normal DevOps flow.

    Security testing at many financial services firms exemplifies both of these issues. These firms typically outsource their security testing to one of a number of service firms who perform that testing on their own networks or in the cloud. The outsourcing of the security testing process is a big inhibitor to incorporating security testing into a continuous and automated DevOps process. In addition, when we asked these financial services firms how well their outsourced security testing represents their real production information technology infrastructure, they really have no idea. Clearly, any testing that does not match the production environment is not helping to reduce the security risk that the organization faces.

    Geer: What kinds of security testing do you feel is most relevant to DevOps?

    Wrabetz: The type of security testing that is most relevant to the DevOps flow is application compliance testing. For this type of testing, new applications are inserted into a network that emulates the information technology production network as accurately as possible. Testing with load, traffic and disruptive events is performed to determine whether the new application or upgrade might open up a vulnerability in the production environment. That includes privacy and data protection regulations, security requirements and any other business compliance standards that the organization is subject to. This testing is performed before pushing any new upgrade or application into production to ensure that compliance requirements will be maintained.

    Geer: What are some common problems with security testing as part of DevOps?

    Wrabetz: There are some common problems that make this type of testing uniquely difficult as part of a DevOps process, and in many cases, much harder to perform than other hardware and software testing. For example:

    • The tests must run in a configuration that exactly matches the current production configurations.
    • Security tests are systemwide tests, not tests of a single piece of hardware or software.
    • The tests must run with realistic traffic that simulates typical production traffic.
    • Security testing must allow automation of setup, configuration and testing processes in order for it to be incorporated into a DevOps flow.
    • Networks are large-scale and difficult to reproduce in a test.

    Security Testing Critical

    DevOps is in its infancy, but it won’t be forever. Now is the perfect time to surmount these obstacles, test for security and feed the results back into coding for security early and often.