Author: Parker Yates

  • Sonatype Announces Free Git LFS Support for Nexus Repository

    Fulton, MD – April 20, 2017 – Sonatype, the leader in software supply chain automation, today announced that Nexus Repository is first to market with free support for Git Large File Size (LFS) artifacts. With the addition of Git LFS, Nexus Repository now supports eight of the most popular software component types, including Docker, Java, npm, NuGet, PyPI, Bower, and RubyGems.  

    Downloading or sharing large binary files, such as videos, images, audio recordings, and database files, can slow down the development process and negatively impact the performance of a DevOps tool chain. By managing these components in a local repository manager such as Nexus Repository, organizations can save time and benefit from increased availability, ease of file sharing, and the ability to better control access to Git LFS components.

    “DevOps practices have chosen Nexus Repository as their de facto standard for all of their build, test, and deploy artifacts — large and small,” said Wayne Jackson, CEO, Sonatype. “Their choice is evidenced by 300 percent growth in the adoption of Nexus Repository over the last three years as organizations have come to value the free, universal component support that Sonatype provides.”

    “Though not as widely used as Continuous Integration tools, artifact repositories are just as essential”, wrote analysts Kurt Bittner and Diego Lo Giudice in the May 2016 Forrester report entitled The Quest For Speed-Plus-Quality Drives Agile And DevOps Tool Selection.  “As companies have embraced open source components as important application building blocks, standardizing component versions helps them improve quality and manage security vulnerabilities by selecting the best available components from the best sources.”

    Additional Resources

    ●     Learn more about the Nexus 3.3 release

    ●     Join our webinar on May 10th to learn more about the Nexus 3.3 release

    ●     Learn more about Nexus Repository

    ●     Read the latest on the Sonatype blog

    ●     Follow Sonatype on Twitter: @sonatype

     

    About Sonatype

    Last year developers requested 31 billion components from the Central Repository to manufacture the software applications that run the world. Additionally, with more than 120,000 installations, companies around the globe use Sonatype’s Nexus solutions to manage reusable components and improve the quality, speed and security of their software supply chains. Sonatype is privately held with investments from New Enterprise Associates (NEA), Accel Partners, Hummer Winblad Venture Partners, Morgenthaler Ventures, Bay Partners and Goldman Sachs. For more information, visit: www.sonatype.com

     

    Media Contact
    Jennifer Edgerly
    SpeakerBox Communications for Sonatype
    jedgerly@speakerboxpr.com
    703-287-7809

    — Parker Yates

  • ThreadFix Platform Provides Application Security at DevOps Speed

    Integrates Application Security into DevOps Pipelines to Find and Fix Vulnerabilities Faster

     SAN ANTONIO, TX – April 18, 2017 –Denim Group, the leading independent application security firm, today announced the release of the latest version of ThreadFix, the company’s application vulnerability resolution platform for developers and security professionals. ThreadFix 2.5 automates application security in the DevOps Continuous Integration/Continuous Delivery (CI/CD) pipeline, enabling applications to be delivered more rapidly without sacrificing security. The upgrades in this release make it possible for security teams to centrally enforce pre-defined application security policies, and development teams to automatically orchestrate application testing resulting in seamless incorporation of security testing into the CI/CD pipeline.

    Businesses and development teams are driven to embrace DevOps so they can be more agile, deploy code more quickly, and provide more value to their customers. To that end, it is incredibly important for DevOps teams to have up-to-the-minute feedback on the status of their development efforts so they know if a build is ready for production. The feedback cycle should include testing quality, performance, and security. By incorporating application security testing into the DevOps CI/CD pipeline, security vulnerabilities are found quickly and reported to developers in the issue and project tracking tools they’re already using, ultimately removing friction from the remediation process and keeping costs down.

    “It’s our goal to take the pressure off DevOps teams,” said Dan Cornell, CTO, Denim Group. “Regardless of the timeline to which they are held, ThreadFix allows them to have a clear path towards securing their new releases. No other platform ingests existing application security testing tools that are prevalent in enterprises and makes them accessible to software development teams to ensure that application security is a part of every build.”

    ThreadFix 2.5 provides the ability for development teams to take advantage of application security testing tools in their CI/CD pipelines by orchestrating both Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools, automatically making pass/fail decisions for builds based on the results of application security testing and creating software defects in defect tracking systems. This allows for development teams to easily access and control application security testing capabilities through existing tools and platforms to run their CI/CD pipelines resulting in vulnerabilities being found earlier in the application security process.

    As executives drive enterprises to adopt DevOps to support innovation and keep pace with customer and stakeholder requirements, the need for security to be included in the DevOps process is at an all-time high. ThreadFix 2.5 provides enhanced integrations based on the ongoing feedback from enterprises deploying and extending their ThreadFix installations. These enhanced integrations include HPE Fortify on Demand and HPE Fortify Software Security Center (SSC).

    For more information about ThreadFix: https://www.threadfix.it/

    About Denim Group

    Denim Group is the leading independent application security firm, serving as a trusted advisor to customers on matters of application risk and security. The company helps organizations assess and mitigate application security risk. Denim Group’s flagship ThreadFix product accelerates the process of application vulnerability remediation, reflecting the company’s rich understanding of what it takes to fix application vulnerabilities faster. To learn more, visit www.denimgroup.com.

    Caroline Dobyns

    Account Manager

    410-353-5340

    caroline@golaunchtech.com

     

    — Parker Yates

  • Resin.io Addresses Containers for IoT with New Release of OS

    Resin.io is announcing the production release of resinOS 2.0, its purpose-built OS designed for running Docker containers on resource-constrained, embedded devices. This new release of resinOS is available both as part of the company’s resin.io managed platform solution and as a standalone open source OS for containers in the IoT.

    With resin.io, organizations can address the management challenges of building, deploying and maintaining IoT devices in the field. Based on the Yocto framework, resinOS handles all aspects of OS-level virtualization of Linux containers and provides a productive development workflow proven in several years of deployments and thousands of devices in the field.

    Links: https://resin.io/blog/

     

    Contact @ DockerCon:

    Alison Davis, Director of Product Marketing & Strategy

    Resin.io, Booth #S31

    +1.206.384.1862

    — Parker Yates

  • Sonatype Nexus Launches into Mesosphere DC/OS

    Delivers first free Docker private registry for DC/OS users

    Fulton, MD – April 18, 2017 – Sonatype, the leader in software supply chain automation, today announced that its Nexus Repository has received certification to run in Mesosphere DC/OS environments.  Nexus Repository is the first to offer DC/OS users a free, private registry for Docker containers in addition to enterprise-scale artifact management for the most popular development languages. Nexus Repository offers the best way to organize, store, and distribute software components critical to DevOps and CI/CD toolchains.

    Mesosphere DC/OS users can take advantage of one-click installation of Nexus Repository.  Where Mesosphere DC/OS provides a unified platform for container orchestration and data services automation, Nexus Repository brings the benefit of an enterprise-scale, private Docker registry.  The addition of Nexus Repository for DC/OS users means that entire Continuous Delivery toolchains can now be rapidly deployed on-premises and on the cloud.

    Mesosphere DC/OS users concerned with the security profile of their containerized applications, can also take advantage of Sonatype’s Lifecycle Container Analysis which enables software teams to quickly assess security at the application layer of the container.

    “With more than 120,000 active installations and millions of users, Nexus is the repository manager of choice for many DevOps and CI/CD toolchains,” said Wayne Jackson, CEO, Sonatype. “Mesosphere DC/OS offers DevOps teams a great way to run containers and data services anywhere and Nexus Repository provides the best place to store containers.”

    “Our goal when we started Mesosphere was to make it possible for all organizations to quickly deploy the best technology available at any scale,” said Florian Leibert, CEO and co-founder of Mesosphere. “The addition of Sonatype’s Nexus repository manager with free support as a private container registry will make it easier for Mesosphere DC/OS users to deliver applications faster without sacrificing quality or security.”

    Interested parties can also see a demonstration at DockerCon, April 17-20, 2017 in Austin, TX.

    Additional Resources

    About Sonatype

    Last year developers requested 31 billion components from the Central Repository to manufacture the software applications that run the world. Additionally, with more than 120,000 installations, companies around the globe use Sonatype’s Nexus solutions to manage reusable components and improve the quality, speed and security of their software supply chains. Sonatype is privately held with investments from New Enterprise Associates (NEA), Accel Partners, Hummer Winblad Venture Partners, Morgenthaler Ventures, Bay Partners and Goldman Sachs. For more information, visit: www.sonatype.com

    Media Contact
    Jennifer Edgerly
    SpeakerBox Communications for Sonatype
    jedgerly@speakerboxpr.com
    703-287-7809

     

    — Parker Yates

  • Let DevOps be a business process

    Let DevOps be a business process

    I just returned from an amazing time at the first Camp DevOps in Boulder, CO. It was held at University of Colorado, Boulder and in conjunction with Gluecon 2014. This is the first conference I have attended that was singularly focused on DevOps.  I found the three track format at the show had something for everyone. A technical track, a business track and some great DevOps round table discussions with great panel speakers. My takeaway was that DevOps is not just a cultural thing as some claim. DevOps needs to be perceived more as a business process or it will just be a passing fancy. Some may disagree with that view but 35+ years of IT industry experience gives me a bit of a long view.

    Gene Kim enlightened me on some issues in his recent response in the Wall Street Journal with some facts about what is going on within traditional legacy Fortune 500 companies. They are implementing DevOps strategies in a big way. My take is that it is not noticeable within the Fortune 500 because DevOps is viewed by the Fortune 500 as a business process, as opposed to being an implementable organizational structure. Sort of like the DevOps is not really a job title argument.  If it is a business process, no one has DevOps in their title, but it doesn’t mean DevOps is not being done there.

    I think most of us want to see DevOps cross the chasm and become a de facto standard. Since Patrick Debois first coined the term “DevOps” there is no question that DevOps has developed into a global movement. Of course DevOps has its cynics. Pessimists say DevOps is a new name for a Sys Admin,  the flippant say DevOps is just a front for some fanatical developers trying to liberate the world from operations or DevOps is just some foolish operations people trying to make nice with Developers. That it means the extinction of QA job is another familiar mantra.

    I’ve spent a lot of time trying to understand the lack of cohesiveness within the DevOps movement and everyone telling everyone else what DevOps is and what it should be. As with anything else the marketplace will decide the future and fate of Devops. During this process, I’ve begun to notice a common misconception that I think is fueling much of the reactions that some people have to DevOps ideas. Holding DevOps back is not a technology problem or a cultural problem.

    In order for DevOps to happen I realized we all need to keep pushing this philosophy forward.  We cannot worry ourselves with culture, commercialization or technology. Technology plays a critical role in facilitating solutions to DevOps problems. However, DevOps itself is, at its core, a business issue. The most fundamental business process in any company is getting from concept to completion with the end result of profitability.

    If you remove the perspective of the business process, what is left? You’ve got a whole lot of people and groups doing their own thing. Lost is the motivation to battle inefficiency, duplication of effort, turf wars, and disparate groups. It’s a free for all.

    If we don’t let DevOps take its course within the market place and embrace the business process, jobs are lost. We are able to do what we do because of the business of DevOps. If we don’t all push the commercialization of DevOps then we have nothing but a chat room to talk philosophy.

    The sole purpose of DevOps is to enable, big and small alike, business to react to market forces quickly, efficiently, and reliably. Without the commercialization, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.

  • DevOps developers; don’t be a DevGoof

    DevOps developers; don’t be a DevGoof

    There was a lot of brush back last week over Jeff Knupp’s post about how DevOps is killing the developer. Frankly I wasn’t shocked by Knupp’s opinion that developers “are the dentists in the dental office”. In my 30+ years of involvement in the IT industry my experience is that developers often think of themselves as the only smart person in the room. Often times that is the reason they are are the only person in the room, lol. The fact is many developers relate better to code than to people. For me all this talk about DevOps killing the developer is akin to saying power steering killed the driver. Just because you can do more with new technology, does not mean one dies, one just has to pivot and in this case become business social.

    Now the sociable part may be the problem. Sometimes I feel that DevOps is trying to create a love fest between Ops, Developers, QA, security and the rest of the IT stack. While they may not have to love each other, I do think they all need to be nice to each other as opposed to ignoring  or just going around each other, as was all too often done in the past. A common scenario I have seen for example is for developers to rollover Ops by stating this is mission critical for the business. These tactics will no longer work to let developers have their way.

    Developers need to realize they need to become a normal part of the business social structure. They will be required to talk and work with people, not throw tantrums when they don’t get their way. Left unchecked, certain developer personality types can sabotage your project, or worse, make themselves no fun to work with.  I am sure we have all met and unfortunately had to work with people like that. In my career, I’ve encountered virtually every personality type. In fact, I’ve also knowingly hired all of them. They know who they are; they are the developer that if challenged or worse accurately taken to task for lack of being part of the team; quit cause they can’t manage the confrontation, thus interpersonal stress. In the old days they would not come out of their house for weeks continually playing Leisure Suit Larry, if your not familiar with it Google it

    I remember one of my good friends telling me this story that sums this whole developer persona issue perfectly. This company, we will call DevGoof, was a well funded start up. Every quarter they held a meeting with all the employees to let them know how the company was doing. Most employees had some kind of equity play in the company, so everyone was incented and theoretically interested in company performance. Several quarterly meetings came and went and not one developer showed up. Eventually DevGoof management got concerned and called a mandatory meeting for all developers’.

    DevGoof management put out some pastries, juice and coffee for the brain trust. Then proceeded to tell them why these meetings were important to them and their fellow employees. Notably pointing out how it is not just about them but also about the rest of the DevGoof team. This meeting went on for about one hour and not one developer asked a question. So eventually this meeting was over and everyone went back to developing. The next morning,   about 50% of the developers quit and some in a not so professional fashion.

    The moral of this blog is the DevOps is going to force the development community to become more interpersonal within the business environment. This will lead to personal success within the new world of DevOps. The DevOps Developer/Engineer that can demonstrate leadership and compassion for team will be the one leading the DevOps way within the organization. Don’t be a Devgoof!

    If you would like say something; email parker@devops.com and don’t forget to comment here.

  • Technology’s effect on religion

    Technology’s effect on religion

    Today being Good Friday, with Easter being Sunday and in the midst of Passover; it is a time for reflection. Instead of thinking about DevOps, today I ponder life and religion. What comes to mind is the future of religion in these technological times. The number of Americans with a religious affiliation continues to decline, less and less of us make an appearance at a Synagogue, Church or any house of worship for that matter. In my childhood we would at the very least make an appearance a few holidays a year, notably at the annual pancake breakfast.

    From the calculator to the computer, from mobile devices and the Internet, advances in technology are creating monumental changes in our lives and in turn the way religion is practiced.  The universal acceptance of mobile devices, like the iPhone and iPad, is provoking a profound social change. The dependence on these devices is eliminating the individuals need for traditional religion and going to traditional houses of worship. The problem is, without the traditional religious brick and mortar upbringing, the youth of today forgo a key element of the religious experience. Religion was never just about a supreme being, the social gathering and interaction of those with similar beliefs and values is also a critical part of the experience. Religion is losing the youth.

    It seems there are now thousands of apps which allow parishioners to bring Bible quotes, Torah-chanting practice and Buddhist prayer wheels anywhere, anytime day or night. My concern is how many of our youth are downloading religious apps as opposed to angry birds. The challenge is how to mobilize religion while still achieving all the religious personal support and socialization benefits that are realized from real life interaction in attending a place of worship. Is the virtual congregation a realistic way to gather people and practice religion? I have a hard time thinking the young will embrace religion without the real life experience which creates the feeling of being at peace with oneself.

    The virtual congregation will be effective fill in for those who have already experienced religion in the traditional sense. Worshippers who cannot find their way to their house of worship for services will pray online with their fellow believers via the latest technology, confident that the other worshipers are doing the same on their devices. How powerful that will be is the question, it has been relatively effective via Television. But those are already followers seeking religious celebrities, not new believers.

    There is no denying religious leaders who conduct services via technology to a geographically wide spread audience will notice a significant difference in how worshippers experience the event. Religion is very much an emotional event and technology can be a non starter for the holy rollers. Gathering around technology in smaller groups may be an answer.

    The religious apathy of the young produces a serious problem for religious leaders looking to grow shrinking congregations. The lack of formal religious upbringing has lost many of the young and younger worshippers that do exist expect any religious event  to embrace technology use. Device multitasking has become such a pervasive part of their life that quiet,  hard cover book based religious ceremonies seem awkward and therefore not compelling.

    Technology may represent the end of traditional religious worship, and the beginning of a new age of worship, the form of which no one can reasonably predict or control. The bottom line is if you look at technology and say how does this change people going to house of worship? You miss the point, because religion is a much deeper set of beliefs. The question is without new young followers, what does the future hold for organized religions?

    If you would like say something; email parker@devops.com and don’t forget to comment here.

     

  • DevOps Needs a Tsunami To Jump The Chasm

    DevOps Needs a Tsunami To Jump The Chasm

    All start up business endeavors must go through the phase of crossing the chasm.  Most of those business endeavors usually fall prey to the chasm. The chasm is this black hole that everyone claims to understand but no one truly does. We have all seen businesses cross the chasm or fail to cross the chasm and fall into the black hole. But no one seems to understand why and how that crossing happens. The bestselling book by Geoffrey A. Moore titled “Crossing the Chasm,” is all about the heart and soul required to get early stage technology across the chasm, from early adopters to mainstream customers.

    There is a big difference between people who are enthusiastic to try leading edge technologies and the rest of the inhabitants, who tend to be much more conservative. The reasons that people spend time trying to figure out how to cross or jump, if you will, the chasm is because that black hole is what stands between them and making their fortune. The early adopters are just a small sample of the market and there is no money in building a business or technology around them. To make real money, you need to cross over into the mainstream.

    In Geoff’s model, the innovators are all about technology.  You know those people, when a new iphone is released, they spend days standing on line to get latest and greatest new technology.  The early adopters are the visionaries that are always on the bleeding edge. The mainstream are the pragmatists, the people who practice risk avoidance. These pragmatists are the key to jumping the black hole, they move the needle.

    DevOps first order of business was getting on the curve and to that end DevOps has evangelists. But, understand that what worked in converting these early adopters probably won’t work for the pragmatists. These DevOps evangelists and visionaries want DevOps power tools, as opposed to the pragmatists who simply want to push the button and say “that was easy”.

    By all appearances DevOps has been accepted by the early adoption set. Just how does DevOps cross the chasm? Jumping the black hole after all can be quite a daunting task. To do so DevOps has to create what I refer to as the tsunami effect.

    The Tsunami effect is where DevOps gains acceptance in multiple industries or markets in what seems like a gold rush, it’s here that fortunes are made. More accurately, it’s where cult communities transform overnight into mainstream communities.  Many technologies simply create a single tornado which remains in a silo forever never gaining enough momentum to really emerge. Another common path what I call an earthquake, there is a lot of hype but it tends to fizzle out quickly, if not tended to properly. Right now DevOps has all the appearances of an earthquake, Devops evangelists have created a lot of buzz, but acceptance beyond a set of power tools is still a huge question.

    Considering DevOps is in the earthquake phase, as opposed to the tornado phase, DevOps cannot be successful converting one group at a time. The strategy in the tornado phase is convert industries and markets one at a time, via tornados forming within industries or markets. The tactical execution is to get smaller industries or markets committed and therefore the larger industries or markets will then embrace the movement. That is simply crossing the chasm. DevOps has too many cultural implications to convert believers over a long period of time; DevOps requires reorganization, not a subtle shift.

    Since I consider DevOps to be in the earthquake phase, crossing the chasm is not an option. DevOps must jump the chasm in a surge of overwhelming momentum, hence creating a tsunami. DevOps has created a very closely knit culture, DevOps needs to push hard to create a tsunami and flood the pragmatic population. But, be advised, DevOps has to be all but universally accepted, there is no almost in bringing together Dev and Ops. But if DevOps wins, it wins big, DevOps will go from being a niche culture to a truly mainstream practice.

    So what’s the strategy to create a tsunami? And more importantly, how do you move beyond the earthquake phase? Here’s how I see it according to Geoff, with my DevOps spin: First, DevOps must clearly establish that the mission-critical software development process is broken and is causing management enough pain that it would gamble on unproven methodology that is populated with a bunch of prima donnas. I am not convinced the DevOps cult has clearly established this as fact. Is the development and operations process broken or have just new power tools been created to improve speed and accuracy? Second, DevOps needs to present the total solution, not just tools. Overwhelm the community; each new DevOps tool should leverage the success and technology of the last hence creating a methodology. Even more importantly, because the DevOps tools are closely related, credibility can cross industries and markets and create the momentum required for a tsunami.  Once Devops has reached critical mass by providing the total solution in a few industries or markets simultaneously the tsunami is created and DevOps has jumped the chasm.

    The tsunami will emerge suddenly with everyone seeming to adopt DevOps all at once.  This will result in explosive growth and will pull, willingly or unwillingly, everyone into its path. It’s driven and sustained by the pragmatists.  Here, everybody has to get the latest thing all at once; the masses have been converted to DevOps. DevOps needs mass-market success, DevOps needs to become a tsunami and everyone will want to play DevOps.

    Now that you know the formula, go forward and create the perfect storm.

    If you would like to say something; email parker@devops.com and don’t forget to comment here.

     

  • THOUGHT LEADERS OR NAVEL GAZERS?

    THOUGHT LEADERS OR NAVEL GAZERS?

    I get tired of hearing what is DevOps? It just tells me that no one really has got it exactly right, but everyone longs to be the authority on the topic. Everyone writes their perceived answers ad nauseam. Reading all the different definitions is kinda like listening to infomercials. An individual puts themselves out there as an expert simply because they have an audience and the topic is in vogue.

    But before I go any further let’s put the “What is DevOps?” questions to bed once and for all. Of course the only real source to turn to is Wikipedia, as that is the definitive source and because it’s on the Internet you know it has to be true. Did I tell you I was a French model; bonjour.  Now to the definition you have been anxiously anticipating:

    DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals. DevOps is a response to the interdependence of software development and IT operations.

    There you have it; DevOps is a methodology not an industry. Now that that question has finally been answered, I hope that I never hear about it again, let’s turn back to those thought leaders. Let’s go back to time when many of today’s thought leaders were still asking what the internet is. Once again I refer to my expert source Wikipedia:

    A thought leader can refer to an individual or firm that is recognized as an authority in a specialized field and whose expertise is sought and often rewarded. The term was coined in 1994 by Joel Kurtzman, editor-in-chief of the Booz & Co magazine Strategy & Business, and used to designate interview subjects for that magazine who had business ideas which merited attention.

    Everything on the internet is about branding and the marketing of the brand. Thought leaders typically write a blog, column, book, record a podcast or webinar.  As long as the message resonates they don’t care about the delivery mechanism. So called thought leaders are simply marketing their brand whether they truly have the expertise to do so or not.  It is a simple process when you have a topic that is loosely defined in an early stage of development, as there is no objective measure of what is correct.

    Thought leaders typically are an individual or firm that profit from being recognized as such. I submit many are truly mere navel gazers, as a navel gazer is derived from the phrase “contemplating one’s navel” or “navel-gazing” if you will, typically referred to in jocular fashion, to refer to self-absorbed pursuits. Please someone explain to me the difference between thought leaders and navel gazers?

    We have so many self anointed thought leaders I am beginning to wonder is there anyone out there actually practicing DevOps or is everyone just talking about it to make a fast buck. If you are a thought leader why can’t you tell me if and when DevOps is going to cross the chasm?

    What have I learned from all this? DevOps needs an infomercial to cross the chasm, not thought leaders. Don’t even get me started on chasms.

    If you would like say something; email parker@devops.com and don’t forget to comment here.

  • DevOps Dirty Little Secrets

    DevOps Dirty Little Secrets

    By all outward appearances DevOps is gaining real velocity within IT shops worldwide, Duh tell you something you don’t know. I have read much on this topic as I am sure you have, but I never seem to read much with hard data results, other than we are doing great with some very broad  metrics. What are the hard numbers as compared to the legacy IT shop?  So my search begins; where in the world are devops metrics in Fortune 500/Enterprise organizations?

    What got me thinking about this were a couple of recent AppDynamics blogs “Measuring your devops success” and   “Quantifying the value of devops”.  Both blogs do an excellent job at breaking down DevOps to the implementation level. Hard data creates metrics that set a baseline with the legacy system that is the critical measurement component, without a baseline there is nothing to compare or measure against. This approach creates a meaningful way to measure the success of executing a DevOps strategy within an IT shop.  The blogs also point other factors not quite as easy to measure, particularly human elements. Many others have written on measuring DevOps, you need to adopt the approach that makes sense for you and your organization.

    At that point I figured it was time to visit Puppet Labs, when you think DevOps Puppet Labs and their survey’s comes to mind. I utilized the 2013 State of DevOps Report; the 2014 report is not available yet. I believe that in order for any new philosophy to be adopted as a true standardized practice, the C-level in Fortune 500 organizations need to embrace it. In my long experience, typically the first sign of acceptance in traditional Fortune 500 organizations is when the financial vertical embraces it.  As an example, Wall Street traders will pay good money to save two milliseconds on a trade.

    The Puppet Labs report numbers demonstrate real velocity in the adoption of DevOps as an accepted business practice. The first takeaways I had from the report were that organizations ship code 30x times faster with 50% fewer failures. The numbers paint a glowing picture for DevOps. But looking beyond the glowing numbers, I see something else. DevOps is at a critical fork in the road and needs to cross the chasm before it loses its luster and becomes just another application development tool, as opposed to a practice.

    Only 17% of the respondents were Managers or C-level, with only 22% of respondent companies having 10,000 employees or more.  It is essential to look at individual Fortune 500 companies IT shops and measure them with hard data before and after the implementation of DevOps.  I would love to read some in depth case studies of the Fortune 500 with hard numbers and metrics; I did not find anything with the legacy baseline data. A huge benefit of DevOps to the Fortune 500 is it will enable them to fail fast as opposed to continuing an implementation that will inevitably fail anyway and consume a huge amount resource in the process. Anyone who has worked for a Fortune company I am sure has witnessed this.

    In truly understanding what DevOps is and is not, certain questions need real answers; Are Enterprise/Fortune 500 companies really doing the same old thing and just need to write better code utilizing some new application development tools, does that make it DevOps or just continuous improvement? Will some IT execs change the organizations title from sysadmin to Devops Admin to protect their silo and make them seem kinder gentler Ops? Are the DevOps tools available today ready for prime time in the Fortune 500 IT environment? Is Devops about technology and metrics or really about culture? We can speculate, but time will tell us the real answers. I am looking for good metrics on what does DevOps do to a Fortune 500 company Not some so called Unicorn that was born with a DevOps spoon in its mouth, but a good old fashioned Wall Street firm who adopts DevOps. Until then call me the DevOps skeptic.

    If you would like say something; email parker@devops.com and don’t forget to comment here.