Welcome!

@DevOpsSummit Authors: Dalibor Siroky, Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog

Related Topics: @DevOpsSummit

@DevOpsSummit: Blog Feed Post

A Brief History Of DevOps By @F5Networks | @DevOpsSummit [#DevOps]

Before jumping into what DevOps is, I think it's helpful to look back at the evolution of software development

DevOps 101 - A Brief History Of Time

If you have anything to do with developing products or working in IT helping to deploy and run them, chances are you have heard the term "DevOps" in one form or another.  Just like the ubiquitous "Cloud" floating out in the Internet somewhere, DevOps has become a catch-all phrase for anything that is Developer or Operations related.

Before jumping into what DevOps is, I think it's helpful to look back at the evolution of software development which will make it clear why DevOps was inevitable.

First Came The Developer And QA

I'll start be looking back a few years when software was primarily developed and targeted as software installs on end users computers with physical media (DVDs, CDs, or dare I date myself and say Floppy Disks). Development teams would work tirelessly 6+ months on the next release of their product.  When the development team gave it the green light, it would go to the quality assurance engineers to perform end user testing, then back to Dev to fix things, then back to test and so on.  When QA gave it the green light, it would go to pressing and packaging and ultimately end up at the end user.

Next Came The Internet

Once companies discovered they could distribute their applications in "soft" copy, they eliminated the overhead and costs for physical media, paper manuals, and shipping costs while providing almost instantaneous access for their customers to their latest and greatest software.

Then The End Users Got Greedy

I'm not sure who first thought of a "hotfix", but whoever did is somewhat responsible for the current need for the agile philosophies in application development.  Users no longer had to wait 6 months for a "bug" to be fixed in their local copies of the software.  Hotfixes brought an interesting dilemma as they only contained a fraction of the code needed for a major release and, consequently, needed to be produced on a much shorter timeframe and at a much higher frequency.  Developers and QA need to come up with a better way to handle the more frequent development cycles and came up with a solution with development methodologies like Agile and Scrum.  That helped them maintain sanity in their development processes. But Dev and QA needed to come up with solutions to make the delivery process more seamless.

Then Came The Web Application And Network Ops

Someone sat in a meeting in some conference room and said "We have a website right?  Why don't we build a version of our product to run on the web?"  Reducing the users need to physically install software is a big bonus as they always have access to the latest and greatest.  If the hotfix wasn't a turning point, then the migration of apps from standalone to web-based definitely was.  Network Operations (Net Ops) came into the scene here as they were needed facilitate distribution of the downloadable images.  This helpful IT folks make it their life's goal to have the bits accessible and the download as fast as possible to all users across the internet.  They took the files, put them in their distribution channels such as ftp/web servers and Content Delivery Networks, checked the box on the release document and waited until the next request.  (Ok, I know I'm simplifying things and IT does a lot more than than, but this is going somewhere I promise).

Then Came The Pain

What that guy, or gal, in that conference room didn't think of was the issues that would arise with the deployment of an application from physical media to the network.  No longer are the Ops folks just responsible for the "bits" passed to them to be accessible, they were now responsible about minor things like user experience, access controls, hackers, availability, compliance, etc.  Up until this point, the development and release process was fairly painless but now it just got a whole lot messier.  The Ops team's jobs are now at stake for maintaining all of those "minor" things and much more.  No longer can they just take the word from the development team that a product is "ready" for distribution and blindly "check" the box on the release.

Then Came The Brick Wall

Needless to say, things went from good to worse. It started enforcing process that infused them with the dev-test-production migration.  Change tickets, request queues, and delays ensued.  A brick wall was being built between Dev and Ops.  Dev would toss a release over the wall to Ops.  A response would be tossed back over the wall to Dev with either the successful QA and deployment or rejection to fix something and try again.  Dev started seeing Ops as those trying to stifle their innovation while Ops saw Dev as reckless with no regard for how the apps run in the real world.  Distrust then led to a slow development process with logs of back and forth.

Introducing Some Sanity

Since the Agile development process was so successful in helping put sanity in the code production process, at the Agile 2008 conference, Andrew Clay Shafer and Patrick Debois discussed the new concept of "Agile Infrastructure"  and afterwards created the "Agile System Administrators" group on Google.  The term "DevOps" was then born and made popular through a new "DevOps Days" set of conferences that started in 2009 in Belgium.  DevOps takes the Agile development processes to the next level by adding Ops into the mix.  Welcome to the club Ops, now you are a developer too!

Enter DevOps

DevopsTo put it succinctly DevOps is a set of tools and methodologies to help Dev and Ops work together to enable pushing more software updates out faster and more reliably.  Regular communication, small batches of work, and an iterative approach are just a few pieces of the puzzle.  DevOps methods stress the following pillars which I'll refer to as the MICCAM model:

  • Management
  • Integration
  • Communication and Information Sharing
  • Collaboration
  • Automation
  • Measurement

By now you see how the DevOps methodology came to be and the problems that it is trying to solve.  It's important to keep in mind that "DevOps" is not a end-all-be-all solution that fits everyone to a “T”.  Just as Agile and Scrum are tweaked and adjusted by developers, the tools and execution will vary based on the companies requirements and dependencies.  To help with the execution, several companies like Chef, Ansible, and Puppet Labs are building products and solutions to help companies adopt these ideas and become productive with application development and deployment.

In upcoming articles, I'll dig more deeply into the different pillars of DevOps, how companies are implementing them, and the various companies that are helping with the execution.

More Stories By Joe Pruitt

Joe Pruitt is a Principal Strategic Architect at F5 Networks working with Network and Software Architects to allow them to build network intelligence into their applications.

@DevOpsSummit Stories
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
"Storpool does only block-level storage so we do one thing extremely well. The growth in data is what drives the move to software-defined technologies in general and software-defined storage," explained Boyan Ivanov, CEO and co-founder at StorPool, in this SYS-CON.tv interview at 16th Cloud Expo, held June 9-11, 2015, at the Javits Center in New York City.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacenter.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.