Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Yeshim Deniz, Elizabeth White, Liz McMillan, Pat Romanski

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
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility.
The Kubernetes vision is to democratize the building of distributed systems. As adoption of Kubernetes increases, the project is growing in popularity; it currently has more than 1,500 contributors who have made 62,000+ commits. Kubernetes acts as a cloud orchestration layer, reducing barriers to cloud adoption and eliminating vendor lock-in for enterprises wanting to use cloud service providers. Organizations can develop and run applications on any public cloud, such as Amazon Web Services, Microsoft Azure, Red Hat OpenShift and Google Cloud Platform.
Because Linkerd is a transparent proxy that runs alongside your application, there are no code changes required. It even comes with Prometheus to store the metrics for you and pre-built Grafana dashboards to show exactly what is important for your services - success rate, latency, and throughput. In this session, we'll explain what Linkerd provides for you, demo the installation of Linkerd on Kubernetes and debug a real world problem. We will also dig into what functionality you can build on top of the tools provided by Linkerd such as alerting and autoscaling.
With container technologies widely recognized as the cloud-era standard for workload scaling and application mobility, organizations are increasingly seeking to support container-based workflows. In particular, the desire to containerize a diverse spectrum of enterprise applications has highlighted the need for reliable, container-friendly, persistent storage. However, to effectively complement today's cloud-centric container orchestration platforms, persistent storage solutions must blend reliability and scalability with a simple, cloud-native user experience. The introduction of Elastifile's CSI driver addresses these needs by augmenting containerized workflows with highly-available, scalable NFS file storage delivered via Elastifile Cloud File System...and with no complex, manual storage provisioning required.
Applications with high availability requirements must be deployed to multiple clusters to ensure reliability. Historically, this has been done by pulling nodes from other availability zones into the same cluster. However, if the cluster failed, the application would still become unavailable. Rancher’s support for multi-cluster applications is a significant step forward, solving this problem by allowing users to select the application and the target clusters, providing cluster specific data. Rancher then initiates deployment to those clusters.