Detailed Notes
DevOps is a hot topic in recent years. However, it is often misunderstood or ill-defined. This presentation tries to correct that. We look at its short history and how DevOps is used. Likewise, we look at the pros and cons involved when your team embraces this facet of software development.
DevOps Is a Steadily Growing Area While a young way to look at a part of the software development process, it is still rapidly growing. The tools available to assist in this area grow daily. Also, the growth of the Cloud and systems deployed there make DevOps more and more a necessity for developing modern solutions.
Transcript Text
[Music] so we want to automate our builds because more or less because we can but also because we need to because we're talking about just a large number of environments it's manual is too error prone devops is going to give us this continuous integration appointment it is very much a uh goes hand in glove with infrastructure as code it's like i said earlier you don't build you don't have you can't build a physical server with code but when you get into the cloud when you talk about virtual machines and virtual resources you very much can and if you've ever spent much time getting going a little bit into the azure or amazon web services or google you'll see that that's a lot of what is there is how to script out creating all of those different services which is perfect when you want to be able to do so and replicate an environment you see this in and we've it's been around for a while even without the cloud when you've had containers uh docker is another you know classic script the whole thing out you can script out a vm all the different software you want to put on it and then you're you're off and running so instead of saying to a new developer here's all these different things i need you to install and you got to try to make sure they all work instead you just give them a docker script and say here you go run this it's going to spin up a vm and you can go do what you need to with it with this with the infrastructures of code and build automation there's also a configuration management piece to this because we've you know touched on the idea of development and staging and testing and production environments those are going to be configured differently maybe for a number of users maybe for security purposes maybe the different data sets or resource sources and targets and so each of these there is a configuration of those that goes on as opposed to building something like the whole infrastructure's code we're not having to build that whole script but we do have to send certain parameters with into that code when that environment is built that is your configuration management side and this again falls under the the dev ops auspices orchestration is in the same vein as um really the infrastructure code and that and this is making sure that all of these things work together properly that we are spinning up and and turning down turning off situations and resources as needed that we are integrating them as needed that we are making sure that the steps that need to be automated are automated properly so it's things like you know on a code commit do i kick off a bill or do i kick off a test or do i kick off a a code review alert or something like that and then of course operations like the grandfather of operations was just monitoring stuff are the systems up are they not are they working completely are they sort of working are there issues with them um performance it you know is it responding in the time it needs to is it a little slow today things like that that still falls into the world of of devops because once we get all this stuff out we want to make sure that we're keeping an eye on whether or not it it works whether it's up and functional or not because that's sometimes what we run into is that you've got a because now devops is supporting everybody so it's not just production where you've got a production server down and people are you know crying and screaming and saying hey i can't get to the server you may now also have it with your qa people or your developers or anybody like that so you want to add you want to have some monitoring tools or scripts or processes out there to make sure that you're keeping an eye on what you know what is it that is up what is this functional what is it's not and hopefully you're ahead of the game so if something goes down you can notify that the group or groups that are impacted by it so getting better oh i don't know why i have okay i had a couple of slides that i need to yank back out um [Music] sometimes you do such things so let's go back to so let's talk about the usage of devops in various methodologies how does this fit in because we've touched on a little bit but it it's worth it to spend a little time thinking through them so i'm going to take this a little out of order so let's look at waterfall first in the world of waterfall methodology if you don't remember you you have these steps that are taken in order and you don't take a next step until the prior steps completed so you you gather requirements and then when you're done gathering requirements and documenting those you put together design and when you're done with the design and have that documented you go into implementation when your implementation is done and you go over to testing when testing is done you go to deployment the dev ops world is not it it pushes against waterfall methodology because devops wants all of those things to be much more fluid and not such hard steps along the way if you think of with waterfall they sort of think the reverse would be like a stairway you take a step and you you know where you can't go back you step up okay now you got to step up to the next one you can't step back down and that's you know sort of the hard and fast rule of waterfall and with that it doesn't necessarily make sense to have the continuous integration and appointment because you're not you don't really have the the visibility from the later steps like when you're in implementation you can code and you can deploy but it doesn't really help the testers because they're not even involved yet because the coding's not done so devops does push well it can work with waterfall because you still have more or less in most cases you're going to have development environments that you could orchestrate and make sure that those are kept in sync particularly when you get large development teams so that all the developers have access to what they need to see the system as it's being built even if they're not testing it officially there's some level of that that goes on plus uh integration type steps and work that needs to be done that is much more it's much more feasible to do that when you've got environments that are similar or ideally the same and you can compare those and you can have access to all the different pieces of the system that sometimes you don't have as a developer in particular waterfall you may be working on one section of code and you never really have an opportunity to see how that integrates with others because there is no platform where those things can be built together and actually the integration tested so it can well devops can be it can great against some of the waterfall methodology it can also improve waterfall within each of those steps with each of those silos and make things a little a little more stable but also just i guess get ahead of the game a little bit so that you're more confident coming out of your step particularly implementation side you're much more confident that what you built and what you did is correct and will pass testing as opposed to i don't know wrote a bunch of code think it works we'll see what happens when you start integrating it so devops although it may feel very different or not it may feel completely foreign actually i guess with waterfall but it's not it can work with that agile is again it's going to push agile to be more agile when you think about the idea of scrum and sprints within agile you have these you know one two three week four week whatever it is sprints and at the end of those you do a bill you bring everything together you test it you build it you deploy devops says we can do that more often than that we don't have to wait every week two weeks three weeks whatever we don't have to wait till the end of a sprint we can do daily builds so we can have a an insight into how this is all going to flush out at the end of the sprint sooner very much like how it can improve waterfall and give us more visibility into what we're doing and what we're producing devops does that in the agile world it may make things like deployments at the end of a sprint almost like that's a no-brainer because if if you've got ci cd already built into it you've got daily builds daily deployments and the only difference is at the end of the sprint maybe you tell maybe you open it up to some different people to see that that was deployed other than that you basically have been deploying daily all along the way and so it doesn't in that sense doesn't cost you more time or resources to do a build at the end of the sprint because that stuff's already been absorbed and is automated and ready to go you may have heard of site reliability or sre this is it's really it's more about reliability and stability within systems uh it's very much a google concept something that came out of the world of google and it is while it started back in the 2000s before devops was really coined there are a lot of similarities uh and a lot of areas where sre and devops worked are basically the same the difference is devops is focused on the entire life cycle sre is really more about us being able to have a an environment like it doesn't have to be production it could be a test environment but having an environment that is reliable that is reproducible that is scalable so we have some of these things we will have infrastructures code that way if we have a server that goes down in our environment we can have a monitoring remember that's another one of the pieces there's something monitoring it sees that that server is going down or maybe is about to go down and can spin up another server in its place and get us closer to the you know five or six nines of reliability or maybe maybe 100 availability because we can always see what's going on and spin up another server and we're off and running so devops works very well in the uh the sre world sysops now sysops is really more where like site reliability is about keeping an environment up reliable scalable stable sysops is system operations is this is like the op side really of the devops side so it's more about monitoring and responding to issues with an environment typically production and again while sysops does a lot of typically has sort of a manual kind of stuff you know there may be some automated monitoring but it's much more human intervention is involved to spin up a system to bring one down to redirect things to note that there's errors occurring things like that devops makes sysops work better it takes a lot of the human interaction and possibility for human error out of the equation so now we've got things that are much more automated that are um communicating in code as opposed to people having to communicate with each other so you have all these processes you have this really this infrastructure around your platform that allows you to be confident that it's up that it's not when it goes down usually to put something you know replace that piece sooner rather than later and then regardless of the methodology you use devops can be an add-on when you think particularly about some of the back up a little bit here when you think particularly about a couple of these things build automation ci cd infrastructures code even configuration management but particularly those first three even if you have your own little standalone development environment there is value in being able to rebuild that quickly to know what it is to be able to share that with somebody else you know infrastructures or code um that you can whatever your approach is whatever methodology you're working in dev ops is something that is is worth considering it is something that can make you better at doing that thing whatever your methodology happens to be so particularly when you're thinking about waterfall and agile rapid application development if you do like a rad approach that is again a perfect way uh a perfect fit for devops for that ci cd so that we can put something in front of users we can make some changes and we can turn that around quickly and say okay this is you know does this work or given this now what changes are needed so there's a a lot of ways that devops can fit into our world so let's look at some of the pros and cons the benefits and the concerns that we may have because they're not they're not necessarily pros and cons because it's not really whether you can use it or not it's more about this is what it provides us and here's some things we need to watch out for you
Transcript Segments
[Music]
so we want to automate our builds
because more or less because we can but
also because we need to
because we're talking about just a large
number of environments it's
manual is too
error prone
devops is going to give us this
continuous integration appointment
it is very much a
uh goes hand in glove with
infrastructure as code
it's like i said earlier you don't build
you don't have you can't build a
physical server with code but when you
get into the cloud when you talk about
virtual machines and virtual resources
you very much can
and if you've ever spent much time
getting going a little bit into
the azure or amazon web services or
google you'll see that that's a lot of
what is there is how to script out
creating all of those different services
which is perfect when you want to be
able to
do so and replicate an environment you
see this in and we've it's been around
for a while even without the cloud when
you've had
containers uh docker is another you know
classic
script the whole thing out you can
script out a vm all the different
software you want to put on it and then
you're you're off and running so instead
of saying
to a new developer
here's all these different things i need
you to install and you got to try to
make sure they all work instead you just
give them a docker script and say here
you go run this
it's going to spin up a vm and you can
go do what you need to with it
with this with the infrastructures of
code and build automation there's also a
configuration management piece to this
because we've you know touched on the
idea of development and staging and
testing and production environments
those are going to be configured
differently maybe for a number of users
maybe for security purposes maybe the
different
data sets or resource
sources and targets
and so each of these there is a
configuration of those that goes on as
opposed to
building something like the whole
infrastructure's code
we're not having to build that whole
script but we do have to send certain
parameters with
into that code when that environment is
built
that is your configuration management
side
and this again falls under the
the dev ops
auspices
orchestration
is
in the same vein as um
really the infrastructure code and that
and this is
making sure that all of these things
work together properly
that we are
spinning up and and turning down turning
off situations and resources as needed
that we are
integrating them as needed that we are
making sure that the steps that need to
be automated are automated properly so
it's things like you know on a code
commit
do i kick off a bill or do i kick off a
test or do i kick off a
a code review alert or something like
that
and then of course operations
like the
grandfather of operations was just
monitoring stuff
are the systems up are they not are they
working completely are they sort of
working are there issues with them
um performance it you know is it
responding in the time it needs to is it
a little slow today
things like that
that still falls into the world of of
devops
because once we get all this stuff out
we want to make sure that
we're keeping an eye on whether or not
it
it works whether it's up and functional
or not because that's sometimes what we
run into is that you've got a
because now
devops is supporting everybody so it's
not just production where you've got a
production server down and people are
you know crying and screaming and saying
hey i can't get to the server
you may now also have it with your qa
people or your developers or anybody
like that
so you want to add you want to have some
monitoring
tools or scripts or
processes out there to make sure that
you're keeping an eye on what
you know what is it that
is up what is this functional what is
it's not
and hopefully you're ahead of the game
so if something goes down you can notify
that
the group or groups that are impacted by
it
so
getting better oh i don't know why i
have
okay i had a couple of slides that i
need to yank back out
um
[Music]
sometimes
you do such things
so let's go back to
so let's talk about the
usage of devops
in various methodologies
how does this fit in because
we've touched on a little bit but it
it's worth it to spend a little time
thinking through them
so i'm going to take this a little out
of order so let's look at waterfall
first in the world of waterfall
methodology
if you don't remember you you have these
steps that are taken in order and you
don't take a next step until the prior
steps completed so you
you gather requirements and then when
you're done gathering requirements and
documenting those you put together
design and when you're done with the
design and have that documented you go
into implementation when your
implementation is done and you go over
to testing when testing is done you go
to deployment
the dev ops
world is not
it it pushes against
waterfall methodology
because devops wants all of those things
to be much more fluid and not such hard
steps along the way
if you think of with waterfall they sort
of think the reverse would be like a
stairway you take a step and you you
know where you can't go back you step up
okay now you got to step up to the next
one you can't step back down
and that's you know sort of the hard and
fast rule of waterfall
and with that it doesn't necessarily
make sense to have the continuous
integration and appointment because
you're not
you don't really have the
the visibility from the later steps like
when you're in implementation you can
code and you can deploy but it doesn't
really help the testers because they're
not even involved yet because
the coding's not done
so devops does push
well it can work with waterfall
because you still have
more or less
in most cases you're going to have
development environments that you could
orchestrate and make sure that those are
kept in sync particularly when you get
large development teams so that all the
developers have access to what they need
to see the system as it's being built
even if they're not testing it
officially there's some level of that
that goes on
plus
uh integration type
steps and work that needs to be done
that is much more
it's much more feasible to do that when
you've got environments
that are
similar or ideally the same
and you can compare those and you can
have access to all the different pieces
of the system
that sometimes you don't have as a
developer in particular waterfall you
may be working on one section of code
and you never really have an opportunity
to see how that integrates with others
because there is no
platform where those things can be built
together and actually the integration
tested
so it can
well devops can be
it can great against some of the
waterfall methodology it can also
improve waterfall within each of those
steps with each of those silos
and make things a little
a little more stable but also just i
guess get ahead of the game a little bit
so that you're more confident coming out
of your step particularly implementation
side you're much more confident that
what you built and what you did
is correct and
will pass testing as opposed to i don't
know wrote a bunch of code think it
works we'll see what happens when you
start integrating it
so devops
although it may feel very different or
not
it may feel completely foreign actually
i guess with waterfall but it's not it
can work with that
agile
is
again it's going to push agile to be
more agile
when you think about the idea of scrum
and sprints within agile you have these
you know one two three week four week
whatever it is sprints and at the end of
those you do a bill you bring everything
together you test it you build it you
deploy
devops says we can do that more often
than that we don't have to wait every
week two weeks three weeks whatever we
don't have to wait till the end of a
sprint we can do daily builds so we can
have
a
an insight into how this is all going to
flush out at the end of the sprint
sooner
very much like
how it
can improve waterfall and give us more
visibility into what we're doing and
what we're producing
devops does that in the agile world it
may make things like
deployments at the end of a sprint
almost like that's a no-brainer because
if if you've got ci cd already built
into it you've got daily builds daily
deployments
and the only difference is at the end of
the sprint maybe you tell maybe you open
it up to some different people
to see that that was
deployed other than that you basically
have been deploying daily all along the
way and so it doesn't
in that sense doesn't cost you more time
or resources to do a build at the end of
the sprint because that stuff's already
been absorbed and is automated and ready
to go
you may have heard of site reliability
or sre
this is
it's really
it's more about reliability and
stability within systems uh it's very
much a google
concept something that came out of the
world of google
and
it is
while it started back in the 2000s
before devops was
really coined
there are a lot of similarities uh and a
lot of areas where sre and
devops worked are basically the same the
difference is
devops is focused on
the entire life cycle
sre is really more about us being able
to have a an environment like it doesn't
have to be production it could be a test
environment but having an environment
that is reliable that is reproducible
that is scalable
so we have
some of these things we will have
infrastructures code that way if we have
a server that goes down in our
environment we can have a monitoring
remember that's another one of the
pieces there's something monitoring it
sees that that server is going down or
maybe is about to go down
and can spin up another server in its
place
and get us closer to the you know five
or six nines of reliability or maybe
maybe 100 availability because
we can always see what's going on and
spin up another server and we're off and
running
so devops works very well
in the uh the sre world
sysops
now sysops is
really
more where like site reliability is
about keeping an environment
up reliable scalable stable
sysops is
system operations is this is like the op
side really of the devops side so it's
more about monitoring
and
responding to
issues with
an environment typically production
and again
while sysops
does a lot of typically has sort of a
manual kind of stuff you know there may
be some automated
monitoring but it's
much more
human intervention is involved to spin
up a system to bring one down to
redirect things
to note that there's errors occurring
things like that
devops makes sysops work better
it takes a lot of the human interaction
and possibility for
human error out of the equation so now
we've got things that are much more
automated that are
um communicating
in code as opposed to people having to
communicate with each other so you have
all these processes you have this really
this infrastructure around your platform
that allows you to be confident that
it's up that it's not
when it goes down usually to put
something you know
replace that piece sooner
rather than later
and then
regardless of the methodology you use
devops can be
an add-on
when you think particularly about some
of the
back up a little bit here when you think
particularly about a couple of these
things build automation
ci cd infrastructures code
even configuration management but
particularly those first three
even if you have your own little
standalone development environment
there is value in being able to rebuild
that quickly to know what it is to be
able to share that with somebody else
you know infrastructures or code um that
you can whatever your
approach is whatever methodology you're
working in
dev ops is something that is
is worth considering it is something
that can make you better
at doing
that thing whatever your methodology
happens to be so particularly when
you're thinking about waterfall and
agile
rapid application development if you do
like a rad approach that is
again a perfect way
uh a perfect fit for devops for that ci
cd so that we can
put something in front of users we can
make some changes and we can turn that
around quickly and say okay this is you
know does this work or
given this now what changes are needed
so there's a
a lot of ways that devops can fit into
our world
so let's look at some of the pros and
cons the benefits and the concerns that
we may have because they're not
they're not necessarily pros and cons
because it's not
really whether you can use it or not
it's more about this is what it provides
us and here's some things we need to
watch out for
you