After watching this video, you will be able to: describe problems with the Waterfall method and describe the typical relationship between software development and
operations prior to DevOps. It's important to understand what brought
us to DevOps in order to fully appreciate the problem that it solves. Architects would spend months and
months designing the system on paper, creating requirements documents,
creating design documents, and making high-level designs, low-level
designs, system level designs. Then finally we'd get to a development phase, where development worked for months and months on features
in an isolated development environment. As they developed the code, if
the designs were wrong it was very expensive to go back to the architects. Once we developed all the code,
we would get to a testing phase. We would test all the code at once. Testing would open defects and
send the code back to development until no more severity 1 or 2 defects were found. At some point, development would release
the code to operations for deployment. This release for deployment
would happen several months after the code was written,
maybe even a year later. Some of these projects took up to two years. Then the operations team would take
what seemed like forever to deploy it because they had no idea what
the developers had built. And the operations team kept
it running from that point on. We call this way of working the Waterfall method. With Waterfall, everything happens in phases. Requirements are gathered and a
requirements document is generated. Then that phase ends. The artifacts for that phase
flow down into the next one. In the next phase, we do all the design and the
design is documented in high-level designs, low-level designs, system-level
designs, and then that phase ends. Those artifacts get passed down to the
next phase and the coding begins where developers take the low-level design documents
and write the code that implements those designs. There are entrance and exit
criteria to each of the phases. So, all along, we're coding in isolation, we're not integrating my module
with the next person's module. Finally, you get to the integration phase
when all those modules come together. This is the first time we realize, we don’t know
whether all these pieces even work together. And then we move on to the testing phase, because
now we've got a system that people can test. And as they find bugs, they must
go swim back, up the waterfall, and open some bugs in the coding
phase and do some re-coding. Finally, after all the testing,
we deploy the software. It is called Waterfall
because if there is a problem, it is very hard to go back,
like trying to swim up a waterfall. You have to go all the way
back to the design phase. In fact, because we treat software
development like civil engineering projects, sometimes some of those architects
have moved on to the next project, and you've got to go find them and
then get them to change the design. You get the developers to change the code
and hope that it integrates this time. This process was very error prone and there was
no room for making changes late in the process. You didn't know whether it worked until
the end, so it was very high risk. But we developed software like this for years. What is wrong with this approach?
Well, there's no provision for change. Every phase has entrance and exit criteria. When one phase ends, the next one begins. There's just no provision for
going back and changing the design or changing the requirements
or anything like that. Another problem is that you don't
know if it works until the end. There is no intermediate delivery. Nothing is delivered, until that last step, when we give it to the operations team and
say, go deliver the thing to production. In addition, with each phase, there
are issues that are just passed down. And, of course, every one of
these is an opportunity to lose information, and to have a mishap. People get blocked, because they can't accept the work from the previous phase.
And then the next phase is delayed. Mistakes that are found later are very,
very costly, it is especially costly to find something that's designed wrong in the testing
phase and go all the way back and redesign it. Finally, these delays create long
lead times between deliveries. Also, the overall problem with Waterfall is that the teams are working separately, they're
unaware of their impact on each other. Designers are unaware of the impact on the code,
the coders are unaware of their impact on testing or impact on integration
before we get all the code together. So everybody is working in
their silos for their phase. And the scariest thought is that the
people who are furthest away from the code, the poor operations team, have to deploy
it, and run it, and manage it in production. They know the least about the code, and
they're the ones expected to run it. In this video, you learned that: Traditional Waterfall development creates
problems such as delays, frustration, long lead times, expensive late changes,
and operations managing unfamiliar code. And that in the past, software developers and operations worked
in silos, rather than working together.