devopsy.kinsta.cloud

Category: Blogs

  • Case Study: Pearson Weaves ThreadFix into AppSec, Part 2

    Case Study: Pearson Weaves ThreadFix into AppSec, Part 2

    In part one, we discussed how education content publisher Pearson applied ThreadFix to its AppSec request workflow needs. Here’s the rest of the story.

    The ThreadFix Implementation

    Senior software security engineer Matt Tesauro added ThreadFix to Pearson’s workflow in the following steps:

    1. Using FPM, Tesauro created a Debian Linux package internally to deploy the ThreadFix Tomcat Package (ThreadFix also offers its own Debian package for this).
    2. Tesauro hooked ThreadFix into each of Pearson’s toolsets using the tool scanner file formats ThreadFix understands.
    3. Using the importers built into ThreadFix, Tesauro connected it to the Checkmarx, Veracode, BurpSuite, ZAP, WhiteHat, AppScan and Qualys testing tools Pearson uses.
    4. To make that happen, Tesauro pointed ThreadFix to an API.
    5. Tesauro then set up an API key.
    6. The system was then set to fetch the test results.
    7. If necessary, Tesauro wrote glue code to upload the results to ThreadFix.

    Pearson used ThreadFix to normalize and de-dupe what had proceeded from manual assessments, dynamic scans on applications and static code analyses of source code, directing those outputs into ThreadFix. “So if a static tool and a dynamic tool both found the same cross-site scripting issue, we fed those into ThreadFix, which de-duped those and gave us just one issue to report so that we didn’t bury two teams with fixing the same single coding error,” says Tesauro.

    “ThreadFix became the one source of knowledge for all of the output of our team, which for us is the security vulnerabilities we find in the applications that we either created, bought or had a third party create,” says Tesauro. That enabled Pearson’s AppSec team to feed tickets into JIRA of backlogs from development teams, which made it easier to produce metrics and do reporting. ThreadFix made it easier to feed data into governance, risk, and compliance tools such as RSA Archer. “That enables visibility into work in progress and workflow and into areas of the business that affect AppSec’s work,” Tesauro notes.

    Additional Capabilities with ThreadFix

    Tesauro eventually expanded ThreadFix to other departments beyond AppSec to benefit from its capabilities and the metrics it could produce regarding app progress.

    Tesauro notes a point between the “Bag of Holding” and ThreadFix in the AppSec pipeline that required some work. He used a StackStorm orchestration and layered ChatOps on top to enable new developer capabilities at that point in the process.

    “Now you can go into our private channel and use HipChat to ask the system, for example, to set up Checkmarx for a particular application in a particular business unit. You give it the URL pointer to that unit’s Git repository and off the system goes, setting up the application profile in the Bag of Holding and in ThreadFix and then talking to Checkmarx to set up weekly scans of the code that sits on the master branch. It set that all up in a minute,” says Tesauro.

    HigherEd was the first additional group inside Pearson to benefit from ThreadFix metrics. One such metric was a 44 percent decrease in time-to-fix after adding a JIRA integration into the mix, according to Tesauro. “Once we started producing those numbers, we had a lot of other business units ask, ‘Hey, why does HigherEd get these great time-to-fix numbers? We want them too for our apps.’ It was a great way to get buy-in,” says Tesauro.

    Further Results

    AppSec saw a 5x increase in throughput for the request workflow and went from 44 application assessments in 2014 to fewer than 200 in 2015, Tesauro notes.

    “In 2015, we lost two and a half people and still sped up the process,” he says.

  • How to Find a Tech Conference

    How to Find a Tech Conference

    — ROELBOB

  • Devops freestyle friday

    Devops freestyle friday

    Following up with yesterday, today marks my favorite day of the work week.  It’s Friday, which means another round of #DevOpsFF (Devops Freestyle Friday).  In order to be considered to win you must create a captivating/funny/intelligent short freestyle/rhyme, in a style of your choosing.  Whether that be a meme or a text tweet to display your creativity  You can use https://imgflip.com/memegenerator as an easy source for generating memes if you would like to submit in that style.

    To submit your entry for a chance to win a t-shirt (top 5 TBT entries receives a t-shirt), simply post it to twitter tweeting @DevOpsDotCom and using the hashtag #DevOpsFF.

    Here’s a quick freestyle to help you:

    Bob is stuck in his old ways, he doesn’t like to continuously deliver. He’ll be rethinking his outdated behavior when he’s sent downriver. #DevOpsFF @DevOpsDotCom

  • Case Study: Pearson Weaves ThreadFix into AppSec, Part 1

    Case Study: Pearson Weaves ThreadFix into AppSec, Part 1

    Pearson is a publisher of education industry content to meet the needs of teachers and students from kindergarten/early learning through higher education and continuing education (for professionals). The company uses a mix of software, from legacy third-party software and “classic ASP apps that are on life support to auto-scaling systems on Amazon,” says Matt Tesauro, senior software security engineer at Pearson. “It’s a very diverse development environment.” Which meant it was no easy task keeping it secure.

    Pearson Before DevOps

    Prior to adopting DevOps, Pearson was bogged down by manual processes, especially in application security. “People sent requests buried in email or, if you were lucky, in a Google spreadsheet. There were very few clear lines and hand-offs between the different activities that were the responsibility of the AppSec group,” explains Tesauro. It was a very manual, custom approach in terms of request handling: someone would respond to a request with an activity, which would require a report that was then emailed.

    At the time, Pearson had no single, well-established methodology or workflow for these activities. There was no particular look and feel or design for creating dynamic, manual or static assessments. There was no list of inputs into the process or outputs to expect at the end of the process. “At best, everything flowed in an ad hoc fashion,” says Tesauro.

    Then, about two years ago, Tesauro and a senior-level peer at Pearson attempted to prioritize those apps the company most needed to assess for security and related issues. They had hoped and planned it would be about 10 apps, to keep the number and the workload manageable. For political reasons, they were able to settle on no fewer than 64 apps that needed appraisal. “We ended up being able to assess only 44 out of the 64 top apps. There are 2,000 and some-odd apps at Pearson, in rough numbers. Just the scale told us we were going to fail in the long run,” says Tesauro.

    Ramping Up to Change

    To resolve this app assessment challenge, Tesauro looked to institute DevOps and Build Pipeline approaches to lay the groundwork for eventually integrating security into the various development teams at Pearson. “I made equivalents of DevOps and Build Pipeline approaches for how we did work in the AppSec program at Pearson,” says Tesauro. These included standard methods of input and intake of service requests similar to how the business produces software development targets for a DevOps shop to hit. That’s when Pearson began to work on instituting and leveraging ThreadFix.

    “ThreadFix was one of the first two parts of that pipeline,” he says. The other part of the AppSec pipeline solution was what Tesauro calls the “Bag of Holding,” a mechanism and repository for tracking all the team-to-team interactions and work assignments. That feeds into ThreadFix.

    During that time, and for about the first half of 2015, Tesauro and a teammate automated a number of manual steps by creating code to perform the “mindless work” so developers could concentrate on their core business instead. “Now when the static code analysis tool Checkmarx finishes its analysis, it generates a report, washes the directory and pushes the report into ThreadFix,” says Tesauro. He also automated a number of other test applications and tools.

    Stay tuned for part two of this case study, coming soon.

  • A Day in the Life of a Remote Contract Developer

     

    — ROELBOB

  • Devops throwback thursday

    Devops throwback thursday

    Today marks one of my favorite days of the work week, besides Friday, my favorite of course.  It’s Thursday, which means another round of #DevOpsTBT (Devops Throwback Thursday).  In order to be considered to win you must create a captivating/funny/intelligent throwback thursday entry, in a style of your choosing.  Whether that be a meme or a sentence such as “Remember when….#DevOpsTBT”.  You can use https://imgflip.com/memegenerator as an easy source for generating memes if you would like to submit in that style.

    To submit your entry for a chance to win a t-shirt (top 5 TBT entries receives a t-shirt), simply post it to twitter tweeting @DevOpsDotCom and using the hashtag #DevOpsTBT.

    Here is your only winner from last week (it’s really simple to win a t-shirt, just play along):

    Here are some examples of DevOpsTBT to help get the wheels spinning:

    tbt1 tbt2 tbt3

  • An Inconvenient Truth about DevOps

    An Inconvenient Truth about DevOps

    In a company’s early stage, the focus is on producing features for the customer. When the focus is tangible value, it’s natural for a software-as-a-service (SaaS) startup to fill its ranks solely with application developers. But when should a company invest in development operations, and at what level? If it has enough capital to hire four developers, should one of those four be DevOps?

    Over the last few years we’ve continued to wrestle with this question. The value from an app engineer was so tangible, but DevOps was something else. Though no visible product was created, DevOps produced many accelerants. Incorporating development operations promised to make the other engineers faster, more effective and happier, but we always feared a sacrifice in features. The decision was similar to setting up robust automation testing—the value accrues, but the upfront cost is a hard pill to swallow.

    We did it too late, and learned some interesting things along the way.

    The Benefits/Advantages of DevOps

    The benefits to incorporating development operations early on are many. As an immediate ROI, DevOps will add a lot of agility to your team by allowing your other engineers (and your quality control team) to focus on what they do best: create your product.

    What is interesting is that the role always exists implicitly within your development team, but is more effective when explicit. If added early, this position can accelerate your team. If not added in time, each developer will play the role in part. The biggest difference between the traditional engineering role and DevOps is the context required: It is possible for a DevOps person to not really know the business rules of your system and still add tremendous value. This means anyone skilled in the craft can be put to work, which allows for quicker onboarding.

    To better illustrate this, let me start by explaining deeper the importance of DevOps in a startup (and in companies of all sizes, actually). By implementing DevOps practices you will enable quicker product iterations. This is vital for a startup, as much of the success of a new venture depends on meeting release dates and getting new versions of the product in the hands of your users as quick as possible. Also, configuration management (CM) tools provide an inventory of all your software and configurations as a living documentation. Your infrastructure setup will be more predictable, you’ll have a better understanding of your stack. Centralized logging solutions and performance monitoring tools will enhance your monitoring and alerting. In short, investing in DevOps in the beginning yields valued dividends over time as you scale.

    How DevOps Has Impacted Our Business

    Establishing DevOps deeply improved our release process. We used to release new versions of our product much less frequently, taking  30 to 40 hours per month of a developer’s time. Now we are able to release much more often—at least three times a week. In the past we would barely release three times in the same month! Now it takes just a few seconds of a developer’s time, only requiring the push of a button in our continuous integration/continuous deployment tool (CI/CD) Atlassian Bamboo. Builds are run and the application is deployed continuously to our test environments over the course of a few days. After successful rounds of testing performed by our quality control team, we are then ready to push our new release to the production environment by hitting the little icon named “Deploy.” It is enabling.

    This successful implementation of a CI/CD strategy also added much more transparency to our pipeline. Now everyone can see in a central place all the metadata about a release, including what product version is deployed to which environment, what is being deployed and by whom.

    Another result we achieved directly with DevOps was agility in setting up our cloud infrastructure. In the old days we would have to log in to our cloud provider control panel and manually spin up new instances, waiting long minutes for them to start only so we could then secure shell (SSH) into them and make all the necessary installations and apply the required settings. Now, we can simply a run a script in Ansible (our CM tool) that sets up an entire environment for us. And since it is much cheaper now to provision and configure new infrastructure, we are now able to create an entire new process for testing new epics completely segregated from our main infrastructure. This has greatly improved our development processes, allowing for more flexibility, speed and control when developing and testing new product epics.

    DevOps Excellence

    During the past year, we have come across different DevOps professionals and learned a lot about the good, the bad and the ugly DevOps engineer. More importantly, we’ve learned what makes a great one. Topping the list of attributes is extreme attention to detail. Managing an entire infrastructure isn’t easy; it has a lot of moving parts. Being able to not get lost in the details is essential.

    A great DevOps engineer also possesses strong process orientation and a passion for automation. To be supportive to the engineering team, he or she needs to understand deeply the current engineering processes and think of ways to streamline and automate them. The questions the DevOps engineer should ask include:

    • What is our build process?
    • When do we deploy to QA?
    • How do we notify the Quality Control team that a new version is ready to be tested?

    You need someone who can challenge the enterprise status quo and help to define best practices for developing and deploying systems.

    Finally, as happens with the definition of the word, there is no definitive answer on where a DevOps team or individual fit in the engineering organization of a startup. At our company, the DevOps engineers report to the Enterprise Architect, who reports to the CTO. In other organizations we have seen DevOps engineers report to the Head of Infrastructure (who reports to the CTO), or report to the Head of Infrastructure (who in turn reports to the VP of Engineering).

    It really doesn’t matter where it fits in your company architecture. First, define your company and vision, then define your org chart. Just remember to include a box for your DevOps engineer from the beginning!

    About the Author

    Rafael_NevesRafael Neves, head of Enterprise Architecture at ALICE, has more than 8 years of experience with technology, having worked in the financial industry both in the sell-side and the buy-side for most of his career. Prior to joining ALICE, he served as head of Engineering at investment advisory startup Monetar. Before that, he was the head of IT Quality & Process of Brasil Plural, engaging in prominent projects such as the technological structuring of the bank’s Broker Dealer in New York. In 2010 he became the head of Algorithmic Trading in the first electronic trading desk in Brazil at Agora CTVM, the leading brokerage house in the Brazilian Exchange which he joined in 2008. Rafael earned a Bachelor’s Degree in Computer Science from Universidade do Estado do Rio de Janeiro.

  • Continuous is the Engine that Drives DevOps

    Continuous is the Engine that Drives DevOps

    It has been stated time and time (and time and time) again that DevOps is primarily a matter of shifting IT culture. The tools and practices that comprise DevOps play a secondary role. But that is only partially true: In reality, the culture shift revolves around continuity, and the applications and tools that fuel continuous delivery drive the DevOps engine.

    I alluded to this point in a post in early 2015. I stated, “Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response … or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.”

    That post last year was a bit tongue in cheek. I have since refined my position, however, and come to the conclusion that the hint of sarcasm was perhaps unwarranted. That continuous continuousness is the crux of the culture shift. It is the thing that separates DevOps from non-DevOps.

    On the Continuous Journey

    Speaking on the topic of continuous security, Andrew Storms, vice president of Security Services at New Context, explains, “Smaller incremental changes are always easier to handle than a large behemoth of a release that can include hundreds of changes. Try finding the single change in a monthly release that resulted in an unexpected security hole in your database configuration vs the release with only two changes that was just developed and released in the last few hours. Security practitioners cannot continue to rely on manual, human-controlled processes to defend against attacks. Automation is a requirement for the next evolutionary phase of security protection.”

    That sentiment extends beyond security to all of IT. When we talk about the culture shift in IT required for DevOps, we are generally talking about breaking down silos and removing the barriers between different teams. The goal of the culture shift is to shed tedious bureaucracy and red tape and empower employees to freely collaborate and cooperate to get things done. In other words, we want to eliminate barriers and roadblocks so productivity can be more continuous.

    Assuming the DevOps transformation begins at that level, it creates an environment of continuous collaboration which becomes continuous development. What follows is a natural evolution of continuity. Continuous development becomes continuous delivery, which requires continuous testing and continuous deployments, followed by continuous monitoring, which provides the metrics and feedback that take you back to the beginning of the loop.

    All of the “continuous” tools and solutions may seem to be part of the technologies and practices that come after the DevOps culture shift, and to some extent, that is true. However, they are also indispensable and inseparable from that DevOps culture shift because without all of the various gears meshing together smoothly—and continuously—what you’re left with is a more traditional approach to IT where everything comes to a halt.

    Is DevOps more of a cultural shift than a collection of tools? Absolutely. That culture shift revolves around continuity, though. Continuousness is the culture shift that drives DevOps.

  • Performance Testing: The Unexpected Missing Link in DevOps

    Performance Testing: The Unexpected Missing Link in DevOps

    It is no secret that DevOps and continuous delivery goes hand in hand in the enterprise, but how do processes such as performance testing fit in to the equation?

    Many enterprises still harbor the traditional way of thinking—that the QA and performance testing group is completely separate from the development group. A widely held myth is that each has different roles, responsibilities, backgrounds and areas of expertise. However, with DevOps gaining popularity in the enterprise, the distinct separation between testing, development and operations is no longer. In fact, to successfully implement performance testing, the once-siloed departments must work together.

    Creating a Culture for DevOps

    The most common purpose of DevOps is to have an automated pipeline of software and application deployment updates. An enterprise cannot implement DevOps unless all are on board, from the top down. To do this, there must be buy-in from not only the software engineers and technology buyers, but also the C-suite. This ensures DevOps processes and strategies are being implemented appropriately.

    However, it’s not just about getting the tools needed for DevOps; there must be a culture shift toward collaboration for it to be effective. That is when an enterprise gets the most from the shift to DevOps and becomes the most agile.

    Once DevOps is embraced, experts and power users can help facilitate how it is being used to drive maximum benefit and help the organization get more from it. The key way to determine and evaluate this maximum benefit is through continuously testing throughout the development process. While the first thought may be for “functional” testing (to ensure code operates without errors and to provide fast feedback to developers when things go wrong), no organization can afford to release applications that deliver slow user experiences, and so “performance” testing with fast feedback is equally critical. Continuous testing is only scalable and sustainable if it is automated.

    DevOps Makes Load Testing Easier

    A key benefit of DevOps is that automation makes everything—from implementation to functional and performance testing—faster and more predictable. Tool chains ensure that the “right things” are done with every code push. A concern commonly cited by those who have not yet implemented performance testing is that it is “too time consuming” and they will be unable to facilitate different tests at the rate they need to be done to be effective. But surprise! Organizations that already practice DevOps are in a better position to add performance testing to the mix, in a fully automated fashion. A solution like BlazeMeter takes just minutes to get API tests up and running, by just adding the HTTP transaction for specific pages or endpoints to test. Once set up, these tests will continuously run automatically and will notify the team when there are any problems or potential problem areas. When there are known surges in website traffic, more Uniform Resource Identifiers (URIs) can be added to the test, but this will not impact the autonomy of it.

    Another key function of DevOps is scalability through the enterprise, and scalability of user traffic is extremely important. While performance testing would still scale without DevOps, operating on the same principles makes each concept more relevant to the folks who are analyzing the outcome of both. The key is to integrate performance testing directly with an already existing continuous delivery or integration pipeline, such as Jenkins or CircleCI. Here, fast, small-scoped performance tests are able to run in parallel to ensure performance is as expected before promoting a build to the next stage. Tests run in staging or QA environments, such as IBM BlueMix or Chef, can also be automated and integrated.

    Performance testing is also important not just because of its easy integration into DevOps practices and how it fits into the CD pipeline, but the overall customer experience as well. A properly functioning webpage or mobile application is the connection between your brand and your target customer, and if it doesn’t load properly or in a timely manner, you may lose a customer to a competitor. Performance testing ensures the user doesn’t experience slowdowns or the dreaded downtime, which is often the result of a poorly functioning back-end system. Incorporating performance testing into workflows creates a centralized environment where all team members have what they need to design, run or analyze tests, while communicating quickly and clearly with each other and everybody in the enterprise.

    Performance testing and DevOps are not opposing forces; and performance tests run automatically within the tool chain save time, rather than consuming more. The reality is that during this age of rapid software delivery, testing is the glue that keeps the development process on track and high quality. Performance testing should be part of every software delivery workflow, and DevOps is allowing that to happen.

    About the Author/Michael Sage, Chief Evangelist

    unnamedMichael Sage brings a 15-year career of enterprise software pedigree and customer success to BlazeMeter. Prior to BlazeMeter, Michael (better known as “Sage”) was a solutions architect and consultant in software delivery and performance management. He has worked with industry-leading companies including Mercury Interactive, Hewlett-Packard and New Relic, helping teams implement integrated solutions that enhanced the performance and experience of their customers. A self-taught hacker and open source evangelist, Sage always has the pulse on the cultural zeitgeist inflected with a heathy dose of humor.

  • DevOps Chat: Dan Berg on Open Technologies and the Open Enterprise

    DevOps Chat: Dan Berg on Open Technologies and the Open Enterprise

    I had a chance to speak with Dan Berg, distinguished engineer at IBM. Dan and I discussed open technologies, open enterprise and open tool chains. A whole lot of open there.  We also talked about how open technologies will be part of the upcoming IBM InterConnect event.  Below is the stream of our conversation and below that is the transcript if you would like to read along.

    Enjoy!

    Alan Shimel:                Hi everyone, this is Alan Shimel, Editor and Chief of DevOps.com, and welcome to another DevOps chat. Today, our guest on DevOps chat is Dan Berg of IBM, and we will be talking about DevOps and open technologies. Dan, welcome to DevOps chat.

    Dan Berg:                   Thank you, Alan.

    Alan Shimel:                So Dan, before we jump into the whole open technologies, open enterprise subject, can you give our listeners just a little bit of background of who you are, what you do and why you’re here today?

    Dan Berg:                   Sure. So as you pointed out, my name is Dan Berg. I do work for IBM. I’m a distinguished engineer, working in our cloud platform organization, which fundamentally means I’m responsible for working with a set of very energetic teams that are building out services in our cloud foundation. So the IBM cloud platform, specifically in IBM Bluemix, things like our container service, log-in and monitoring services, several DevOps based services. So services such as things like we call active deploy that help deploy microservices within a cloud architecture. So I do a lot in that space, helping the teams identify the strategy and the architecture that we’ll use. I’m also very much involved in our DevOps organization within IBM cloud, focusing on both cloud native applications, as well as hybrid cloud applications.

    Alan Shimel:                That’s fantastic, and Dan, you know, we talk about DevOps, and certainly when we talk about cloud, one could say we’d have no DevOps or no cloud without open source. What do you think about that statement?

    Dan Berg:                   I think that’s a pretty profound statement. Open source is a strong component of cloud strategies.

    I think almost all customers are looking at cloud as a direction. I talk to a lot of our customers, and I can’t say any of them that do not have a cloud strategy or at least pursuing a cloud strategy.

    And one of the areas that comes up quite often is this notion of being able to have the flexibility of choice. I want to be able to choose my cloud provider and I might want multiple cloud providers.

    And the only way to really achieve that is to have an open community and open standards that allow you to develop your workloads, develop your applications in such a way that you can move them from one provider to the next in their run, as you would expect them across multiple providers.

    And as I pointed out, you’re not gonna get that unless you’re focusing on a strong open community that is driving open standards.

    Alan Shimel:                Yeah, you know Dan, so I’m old and I remember when I first got into IT and technology, there was a time where there was tremendous pushback about open sourcing the enterprise.

    We’ve all read the books and we’ve listened to Richard Stallman and the book is escaping me now. What’s the great book about open source? Something about the bazaar and the – oh, whatever.

    Gosh, I’ll find it but the more important thing is you know we’ve – and what was the pushback?

    How can the enterprise rely on open source without support, without vetting and all of that?

    And really it’s been companies like IBM and dare I say, even Microsoft now that have kind of helped pave the way for open source into the enterprise. What do you – what’s your thoughts on that?

    Dan Berg:                   Well, so it’s interesting to see how the open source has evolved, how developing in the open has really changed the way in which developers learn, and how they adopt technologies.

    You first and foremost look to the open communities as a way to understand new technologies and to join a community in which those technologies are evolving and you’re right.

    Enterprises often look at or have in the past looked at open source as, okay, that’s cheap software that people are doing on the side. They’re not part of any company. How can we trust this?

    Is it enterprise ready? We’d better not touch it. Right, we’d better develop our own. I think that mentality has changed dramatically for a number of reasons.

    One, the communities have become extremely large. I mean look at things like the open stack community or the cloud foundry community, the Docker community.

    These communities have established a base set of users and contributors, and have grown substantially over the last several years, and what they’re developing is being developed with an enterprise mindset. I mean it’s not just for kicking the tires or playing around.

    We’re developing enterprise grade solutions in the open, and the reason why it’s being done in the open is because with the community around these initiatives, you end up getting more input from various stakeholders and ultimately at the end, you get better solutions that cater to a larger set of stakeholders.

    I know within IBM, I mean we’ve been developing in the open for many years. I can remember way back, 15 years ago, working in the open.

    While it may be difficult initially, when you’re thinking oh, I’ve got to work with a community of people and get agreement, that is true to some degree.

    But what you find is that as more people start working together and collaborating across the globe on a set of technologies, an open set of technologies, it actually picks up pace and you can innovate much faster, because you just have a larger pool of resources and developers working on that code base.

    And that’s what we’ve been seeing, and adopting that back into an enterprise and using it has become easier because you’ve got enterprises like IBM, like Microsoft, like others that are contributing to these open communities and ensuring that enterprise requirements are added into those code bases, so that they can be consumed by an enterprise.

    So it is shifting. I think more and more, enterprises are adopting open source capabilities because of the innovation and the enterprise grade quality that’s coming out of those communities.

    Alan Shimel:                Absolutely. By the way, Dan, the book was The Cathedral and the Bazaar.

    Dan Berg:                   Yeah.

    Alan Shimel:                By Eric Raymond, and I’m sure you read it too. It’s – you know what, at this point, I’m ashamed to tell you. It’s like 15, 20 years old but, whatever, it’s still good.

    So Dan, let me pivot a little bit with you and let’s quickly turn. This month we have the IBM interconnect show, which is sort of IBM’s big cloud in mobile and I like to say DevOps event as well.

    And the open enterprise and open source is front and center, and rightfully so, in light of what you’ve just told us.

    What can you highlight for us a little bit maybe about the open source, open enterprise at Interconnect this year?

    Dan Berg:                   Yeah, so there’s gonna be a number of exciting things. I mean we do really drive the notion of open source and open technologies.

    We’re gonna be discussing obviously some of our core initiatives around open stack, around node and JavaScript, Docker as well.

    We’ve got a number of exciting sessions and activities that we’re driving within those communities.

    The open container initiative, another big one that we’re involved with and discussing the direction that we’re helping to forge in that community to drive where we see containers going.

    So that’s Docker based containers and other containers, really driving a stronger community around the container movement. Even around DevOps, the great, great thing that we’ll be showing off there is some of the work that we’ve done with the IBM garage method.

    So it’s an open set of processes and practices that we announced late last year, and then moving into this year in the envelope a little bit further, and what we’re doing is associating with the practices, a set of tools.

    And these tools are obviously some tools that we provide, services that we provide, but a lot of them are open tools as well that are being developed and made available in the open communities.

    But one of the exciting things in this area that we’re driving is something we call the open tool chain, and open tool chains are a set of capabilities that allow organizations to define their best of breed practices and DevOps capabilities in a tool chain.

    An integrated set of practices and tools that can be instantiated by other parties.

    So we’re pretty excited about that initiative. It’s still early days but we do see the potential there and the flexibility that’s being achieved by bringing together these open technologies into a unified tool chain that drives cloud native deployment and delivery mechanisms.

    So we’re very excited; lots going on in these communities and we’re really excited about sharing that information at Interconnect in about two and a half, three weeks.

    Alan Shimel:                Absolutely, you know, Dan, I think I might have been out with you in San Francisco when they announced the open garage method at – I forgot what conference it was but in any event, it was a DevOps enterprise summit.

    Dan Berg:                   That’s right.

    Alan Shimel:                As you mentioned.

    Dan Berg:                   That’s right.

    Alan Shimel:                And you know, to me that was a little different, especially for an IBM in that it wasn’t an open source project. Right, it wasn’t a particular tool.

    This was really more of an open methodology with tools tied into it and you talk about a supply chain.

    It is a sort of that software supply chain where the software or the app you’re developing, not all of it is going to be open source.

    But there are open source components that make it easier for us to develop apps in real time continuously, with continuous delivery and integration, and all of this goodness we see in DevOps.

    And to me that was sort of the power of the garage method, right, was this software supply chain, if you will, with open source components, making up a lot of it, wrapped around IBM’s experience and know-how in bringing this together. I think it’s powerful.

    Dan Berg:                I definitely agree, and as I pointed out it’s still early days but it’s showing the promise. I mean we all know how difficult it is sometimes to piecemeal together your delivery tool chain with the various open source tools as well as third party vendor specific tools.

    It can be quite complex and what’s really nice about the open tool chain is it takes some of that complexity out of your way and really helps you focus in on your key initiative, and that is deliver high quality code as quickly as possible.

    So I’m really excited about it. It does build upon some of our core technologies, but I’m really excited about how it brings in some of these key open technologies and open communities to drive better DevOps experience overall.

    Alan Shimel:                Yeah, agreed. You know, Dan, unfortunately we’re coming up on the clock but this is – you know, the whole subject of open source of software supply chains, of the open enterprise.

    And how enterprises are incorporating open source components into their supply chain is one that fascinates me and one that I think you’ll see more of on DevOps.com, as well as it sounds like quite a bit of it at Interconnect later this month.

    Dan Berg:                   Absolutely, and if anyone’s gonna be out at Interconnect, definitely look me up. You can find me. I’m doing a number of different sessions, and you can grab me on Twitter at DanCBerg.

    Alan Shimel:                Yeah, well and they could also look for you on the Interconnect site, Dan and probably search by speaker.

    Dan Berg:                   Absolutely.

    Alan Shimel:                Just we don’t have any time but which of your talks or sessions are you most looking forward to?

    Dan Berg:                   Oh gosh, there’s a number of sessions but there is one, and I’d have to look. I forget the name but it’s a DevOps panel that I’m looking forward to.

    And there’s a number of us on there including myself and Gene Kim are gonna be on the panel. I believe it’s on Tuesday, if I’m not mistaken.

    Alan Shimel:                I believe that would be my panel.

    Dan Berg:                   I’ll have to look in my —

    Alan Shimel:                What does DevOps look like in the next five years?

    Dan Berg:                   Ah, that’s right, it’s yours

    Alan Shimel:                Thanks for the plug, Dan

    Dan Berg:                   Not a problem.

    Alan Shimel:                I welcome people to come out and check it out. We’re looking forward to a great panel. What a way to end our conversation.

    Dan Berg, distinguished engineer for IBM, thank you so much for joining us today on DevOps chat, and I’ll see you later this month at Interconnect.

    Dan Berg:                   Absolutely, looking forward to it.

    Alan Shimel:    Okay, bye bye. This is Alan Shimel for DevOps.com and we’ll see you on another DevOps chat.