There’s a lot of hype around DevOps; some even call it buzzword. We look at DevOps’ origin and discover a logical progression in software development from Waterfall and Agile, with genuine business benefits.
The Waterfall Model
This has long been the dominant model for software engineering. It’s called the waterfall model because of it’s a sequential nature, but it’s really more like water running over a series of tiers in a rice field. ‘Once a phase of development is completed,’ says TechTarget’s definition, ‘the development proceeds to the next phase and there is no turning back.’ There is, but would take the strength and determination of a spawning salmon.
waterfall-project-management
Source: Agile vs Waterfall, Jim Bowes, manifesto.co.uk
That makes it crucial to eliminate errors at each phase, therefore the design specs have to define every detail and the documentation tends to be exhaustive. The ‘tiers’ or phases are the familiar ones of design, development, building, testing, deployment, troubleshooting, operation and maintenance. One advantage of the waterfall model is its clearly demarcated teams and their assigned tasks, each with clear deadlines. Everything is neat and manageable.
The disadvantage lies in the rigid walls it creates between different teams, and the slow work cycle imposed by the sequential process. It’s not just ponderous and inflexible, it also delivers large chunks of code in between long intervals. The time taken to deliver new systems also means that business needs have often changed by the time they’re delivered, making a major update essential. That’s how some systems end up like dogs chasing their own tails.
Agile Development
This philosophy evolved from several lightweight software methodologies such as Scrum, XP and Kanban. While they have distinct differences (more details here), the common thrust is their focus on leaner structures and greater agility, and on delivering demonstrable value to stakeholders, more often and in smaller increments. In other words, developers saw that they had to do better so their employers could meet the challenges of a faster-changing, more competitive global world.
The Manifesto for Agile software development, written in 2001, stresses the importance of incremental, iterative development using cross-functional teams of designers, developers and testers that work on successive ‘iterations’ of the product over shorter time spans (Sprints). Every iteration is meant to yield a production-ready version of the system. The advantages of Agile are described by Jim Bowes on the Manifesto blog:
- Working software is delivered much more quickly, and successive iterations can be delivered frequently, at a consistent pace
- There is closer collaboration between developers and the business
- Changes to requirements can be incorporated at any point of the process – even late in development
- It gives the opportunity for continuous improvement for live systems
- It is highly transparent
Another change in Agile Development are the ‘User Stories’ that replace the detailed specifications of the Waterfall model . User Stories are high-level definitions of requirements that provide enough information for developers to define the amount of work needed for an application or system. During the development process, these stories are sequenced into iterations that can be reappraised and reprioritized at each iteration boundary. More detail Here
Why DevOps?
DevOps is a logical evolution of Agile Development, which has often failed to deliver on its promises. Chris Reilly at DevOps.com says, ‘ … the methodology was only implemented during the development phase and created backlogs for operation teams which failed to push product releases fast enough.’ He adds that the outcome was ‘short sequences of fast Waterfalls’ that didn’t improve productivity or the bottom line.
Daniel Greene at TechCrunch argues that code wasn’t released to production often enough, and adds that, ‘more often, the output of an iteration makes it only as far as a “test” or “staging” environment, because actually pushing to production requires many more steps: bundling the code, packaging the product, provisioning the environment, and coordinating with the operations staff.’
Another reason is that Agile and its Sprints have more appeal for creative developers than for hardened operations people whose lives revolve around making sure that software is stable, that hardware is reliable and that critical data are protected. DevOps has the same objectives and closes the loop with its end-to-end delivery pipeline of inbuilt tests and checks, but it will take a culture change in your organisation to make it work.
How DevOps Delivers
Developers love DevOps because it enables rapid development, testing and delivery of software, with instant feedback on any defects in their code, while operations staff tend to view DevOps enthusiasts as dangerous speed freaks. DBA Mike Fal describes their perspective this way: ‘Operations staff take the view that speed invites chaos, resulting in instability, downtime, and a lack of sleep.’
A key tenet of DevOps is automation, because keeping manual intervention to a minimum ensures software of high quality, reliability and consistency. Automation works hand-in-glove with Continuous Delivery through the stages of continuous development, integration, testing and deployment. The DevOps Delivery Pipeline is designed to move applications or updates and bug fixes from concept to production as fast as possible.
DevOps-Infinity
Can DevOps really deliver the best of both worlds: greater speed and greater quality? The 2015 State of DevOps Report supports that claim in a recent survey which shows that quality improves with increased velocity when enterprises embrace DevOps.
As Mike Fal explains: ‘The reality is that chaos, instability, and downtime are not the result of speed, but the result of variance … DevOps drives us to improve and fine tune our process. The goal is to enforce consistency, and to manage our resources so that software is deployed in the same way that a car factory builds an automobile. Components should be standardized, builds made consistent, and tasks automated. The result is speed’, yes – but speed that is the result of control and standardization.’
Cloud & DevOps Made for Each Other
According to David Lincthicum at Tech Beacon, some people ‘attribute the rise of DevOps directly to the rise of cloud computing, because it’s easy to continuously update cloud-based applications and infrastructure.’ Cloud platforms have matured in the last few years, and its providers have developed tools that make deploying new applications fast and easy. That makes the cloud a perfect platform for DevOps.
Today’s enterprises operate in a fiercely competitive marketplace, and market leaders are those who’re first to respond to new opportunities. The DevOps delivery pipeline provides a fast track for new or updated code to go from development to operations, and the best cloud platforms let you spin up new applications and business initiatives much faster than ever before.
The only remaining obstacle is the culture change that is needed to achieve end-to-end cooperation from Dev teams to Ops teams. With DevOps, they become one team and that leaves no room for the old stand-offs between developers and operations. Culture change is always painful but, when enterprises pull down the walls around the old silos, they tend to see communication and collaboration between teams improve dramatically. More detail in our post How to tame Cloud Deployments with DevOps.
these two groups are ultimately the same team. The largest hurdle to making DevOps work is to dissolve the antagonism that has grown between development and operations. Operations must reach out and get involved in the development process. If not, they abdicate total control to the development teams to define and build, leading to the kind of team division we see today. This division is what causes outages and issues, not bad code or buggy deployments. If operations and development are working together towards common goals, stable code and stable environments, it is easier to achieve.
Infrastructure & Security as Code
Developers build many checkpoints and tests into their DevOps Continuous Delivery Pipelines, which contain several stages that verify the quality of new features from different angles to validate their function and catch any errors. A typical CD pipeline includes build automation, continuous integration, test automation and deployment automation.
Even security and compliance tests can be incorporated in the delivery pipeline as code, and so can the infrastructure of specific cloud platforms. Chef CEO Barry Crist frames the resulting business advantage this way: ‘When the whole stack – infrastructure, compliance, security, microservices and apps – are all expressed as code, IT is able to deliver value more quickly.’ For more details, please check our posts Is DevOps an Obstacle to Application Security? and Is DevOps a Threat to Compliance?
Deploy code to any environment
You should have the ability to deploy your applications, databases and infrastructure where you want them: in public or private clouds, hybrid clouds or in a mix of cloud and on premise scenarios, and you should be able to do so with high-level tools that take care of the nitty-gritty details.
That’s why we developed the EnvironMint Smart Suite for DevOps, which has been tested and proven in some of the largest and most complex environments in Australia, including top tier banks and financial institutions.
EnvironMint consists of two key products with complementary functions for DevOps:
- MintPressbuilds high quality Oracle environments rapidly, repeatedly and reliably (for Continuous Delivery) and
- DriftGuard monitors and troubleshoots operational systems (for Continuous Operation).
Smart suites like EnviroMint make it a whole lot easier to realise the enormous benefits that DevOps can provide. Find out more here.
