DevOps for Developers (OR Maybe Against Them ?!) @ Manchester Java Community – 2021

okay um so yeah welcome everyone to the
manchester java community
um first of all just like to um thank
our
sponsors so just over the last week we
managed to
um strike a nice little sponsorship deal
with um
barry cranford and rec works and they’re
the people who founded the london java
community and now they’re going to be
supporting us by cooking our meal please
so that’s really cool
so we appreciate that and thanks to yeah
barry and his team
who we’ve been working quite closely
with over the past few months
um i mean other than that there’s kind
of not really a lot for me to say i just
like to really introduce pro
and um and i’ll hand over to you to
introduce yourself properly
yeah i will i will it’s somewhere in my
slides
thank you very much nick i’m very
excited to be here well
i would be very excited to actually be
there uh
as i mentioned to nick manchester is on
my bucket list and i miss
i i miss the in-person event so much
but um it is what it is we are where we
are
and we’ll make the best out of it
uh by speaking about
what devops has to do with with
developers
or should i say has nothing to do with
developers we’ll talk about that
so usually when we do this talk in
person
i love to ask the question
of do people know what devops is
and you know what i asked it so many
times that i can
be pretty sure that some people just
straight up give up that they don’t
others have opinions
um and they’re all very different and
that’s astonishing
because the option has been around for
more than 10 years
and still people talk about devops
engineers
which is not even a thing and i’m going
to talk about that today a lot
and how um you know how devops is
actually
ops which is obviously not true
and there are some ridiculous things
like
this that people actually get job as
devops engineers and then start asking
questions
what devops is and obviously we will
start with
talking about what devops is and then we
will talk about
why we as developers care or
don’t care about devops at all so yeah
my name is baruch ogurski i’m the chief
sticker officer in jfrog
that’s my business card real thing and
the part on the on on the right
is actually sticker so again if you get
my business card you can use it as a
sticker that’s kind of the idea
no stickers in virtual unfortunately
maybe on whatsapp or
wherever the stickers are but nothing
more than that
um my twitter handle though is very real
and working
at j barrow so let’s connect there
continue the conversation
feel free to follow me my dms are open
as well if you need
uh something this is the most important
slide
of this a talk if you go to jeffree
homes
show notes you will find a page there
dedicated to this talk
in this page the slides are already
there the video
as we are recording nick is going to
publish it on youtube and
i’m going to link it there as well so
you will have everything in one place
uh all the links to everything that i’m
going to mention
are there the place to comment rate
and a very nice raffle for thanking you
for being here
it’s an amazon echo 5 um
amazon echo show 5 which is a very nice
smart
uh smart morning tour uh definitely um
recommend you to participate in the
raffle so you go to general
show notes and it’s on the bottom of
every page
um as my twitter handle and the twitter
handle of this meetup group
and hashtag devops if you men mention it
on twitter
go ahead it will bring some attention to
you as well
so um why am i talking to you
about demobs for developers so you
obviously
noticed jfrog you might heard about us
we are doing
we are doing tooling for
helping making devops happen
but me myself if you looked at my
linkedin
um i’m a developer i’m a java developer
with um
almost 20 years i think like april next
week
next year will be my 20 years
anniversary
as a java developer and
this is how i kind of have both
perspectives
like as a developer myself but working
in company
which is a really devops company and
i will take you through the journey that
will
be built in two parts the first
i will talk about where devops came from
how it came to be why this
um movement has started and then
we’re going to talk about what’s in it
for you
so let’s start in the beginning most of
the people
learn about devops from this marvelous
book
the phoenix project is definitely very
very
important book to promote devops
just because it’s an entertaining
non-fiction
um literature that
gives you a very good overview
as a story of why devops is important
and conveniently enough on the cover of
the phoenix project
you can see the main characters of the
story and
i would like us to look at them now and
try to see
what devops is about through the people
who
are participating in this devops journey
that described in the phoenix project so
here we go um patty and i’m just going
from left to right
not by any order of importance she’s
director of it service support
you can see she’s an ops person she
actually manages
service support which is like you know
escalations of it equipment and this
kind of stuff
this davis is her colleague is a
director of distributed technology ops
he has ops in the name he’s an ops guy
there are some people
who are not technical like sarah vp of
retail ops and steve ceo
and then dick the cfo this is all fine
and now we get to the main protagonist
of the book
the main character bill palmer he’s the
vp
of i.t ops he is an ops guy
and he is like the main character he
goes through this transformation
and discovers devops for the entire
organization he’s an ops guy
um a board member and then the main
technical person of the book
is brent and he’s a lead sis admin she’s
admin he’s ops
and then there is there is john who is
the cso
so you see something that should bother
you a lot
no developers in the story well there
are some developers in the story but
first of all they are kind of
playing secondary flute and they’re also
not
they pictured not really in advance in
in
like a good light throughout the book
and this kind of
raises all kind of flags is devops
an ops idea an ops
story someone something that ops came
with and for what let’s look at another
evidence
the devil’s handbook that’s kind of the
second
book that you will read after the
phoenix project if you want to learn
about devops
and here let’s look at the authors so
jin kim
he’s the author of the phoenix project
and we just kind of digested
what what the phoenix project is about
and what are the thoughts
of jin kim of where devops came
from and and and and why let’s look at
the others
patrick dubois the person who came up
with the term devops
10 years ago patrick used to be a system
architect system architect is like the
architecture
of whatever six admins are doing of the
pipelines and everything else
that’s that’s an ops position oops sorry
g
s humble the author of an amazing book
continuous delivery the co-founder
and co-author of the accelerated book of
the and the
state of devops report a very important
person
in the devops ecosystem deputy
director of delivery architecture
delivering is an ops concept
and then john willis the the father of
devsecops if you wish
he was a vp of services in a company
literally called
ops code automation of ops
all the founders of devops are
ops people in the background now let’s
see
who teaches us about devops
you can see here you go you google it
and you see immediately
new relic new relic it’s a monitoring
platform for ops
and then amazon web services cloud
infrastructure
as a service ops clubnet
they’re like a mixed bag but then again
the agile admin
system administration right there
wikipedia and then again atlassian
devops company and then azure another
infrastructure is a service cloud
platform
and then in the bottom logs io obviously
monitoring and ops concept
it looks like everywhere you look
this devops thing was
invented by and promoted by
ops people and then
you ask yourself why what’s going on
why this devops thing is
pushed so hard by ops people
let’s try and understand what this dev
thing is about
if we google what devops
job is you find some interesting stuff
for example here is an answer on quora
so what you need to do is basically you
have all
your bingo linux administration will
help you go
easily get started with devops because
it all starts with linux fundamentals
fine so you go all this linux
fundamental and then the only thing that
is
devops here according to disha is the
devops tools
something that is called gitz and chef
and maven and everything so basically
you learn gitz
you are a system administrator you learn
gits and now your devops
and how it’s great to be devops well
look at that
linux system administrator get this
match much damage engineers
get 50 more isn’t it nice
and then it’s a super hot job
you can see that only in the united
states there are 15 000
open positions for devops engineers
and all those platforms that we spoke
about promote
they think it’s devops engineer through
certifications
and books and everything else so then
you say aha
i got it this devops is a plot
of system administrators to rebrand
themselves
and start earning more money is it true
it’s not it’s not true because
this is confusion because a cause
and an effect ten years ago when patrick
dubois
and uh jin kim and um jazz humble
and john willis came up with this idea
no one knew that it will create
such a huge hype that you will be able
to earn 50
more by just learning gifts and calling
yourself devops engineer no one knew
that it would happen
so it cannot be the reason so what is
the reason
what is the reason devops came up
sorry ops came up with devops to
understand that
we need to look at the true definition
and the true definition of devops
is this it’s the infinity loop of
planning coding building testing
releasing deploying
operating and monitoring
now you look at this infinite infinite
loop and say
hey this looks familiar
this looks very familiar it almost looks
like the agile infinity
loop which is plan design develop test
release feedback
and we all know that agile is good for
us at least i hope so and if not
that’s a topic for an entirely different
talk agile for developers or against
them
but let’s assume we all know that agile
is the way to go
because it allows us to postpone
it allows us in the environment of
uncertainty
to postpone decision making to the
latest point
possible so we will be able to make
more knowledgeable decisions when we
actually don’t know anything and that’s
that’s our life and you say well agile
is good i understand it
but devops is like they took our part of
the job
the developers and then added to it tons
of stuff
which has nothing to do with us with the
developers i mean seriously
deploy operate monitor this is not us
we do our site we do design develop
tests
and and that’s what we do so it looks
like
the ops people went ahead and took what
we did
and then added to it what they used to
do so we do it as well
is it so let’s check another proof
let’s look at the state of devops report
state-of-the-report is the most
important
the most significant research that
the devops industry has it is done by
used to them by
what is called dora devops research and
assessment group
led by dr nicole forsgreen and just
humble
and um i think jin kin is with them so
it’s kind of the same the same people
all over
and they assess organizations
30 000 organizations they assessed
based on those metrics the metrics are
deployment frequency something about
deploying code
lead time to changes after we’re done
coding
what’s happening there time to restore
service
after outages and change favorable
rate stuff like degraded service
and you look at that and you go like
what
everything that is here has nothing to
do with development
there are no metrics which speak to me
the developer
this is all ops story and they call it
devops what the hell is going on
you look at the results and you see how
new work is highlighted here so heavily
a new work should be highlighted heavily
because new work
any type of work this is where the money
is
those are the new features that
obviously the customers pay
now the question is what is defined
as work in what work
the report refers to let’s look
planned work for them business projects
or new features
okay that makes sense we do new features
that’s great
but then internal project server
migrations you go like what what’s the
remediation so i’m writing code
and then changes okay and then again
unplanned work
support escalations and emergency
outages
what i have as a developer i have to do
with outages
this is all very fascinating obviously
and probably important
but it has nothing to do with me as a
developer
what the heck for the developer for us
types of work are very simple new work
are
new features this is what we do and
the not new work are either bug fixes
or refactoring right either defects
or a technical debt fine
this is what we understand this is not
what
uh dora reports talks about this is not
what the phoenix project talks about
this is not what
the devops handbook talks about so i
hope
i got you into the mood of my
um conspiracy theory
that devops is a conspiracy of ops
to make us the developers
do more work i hope you are
all all agree with me all on board on
this conspiracy theory
and with that let’s put the
ridiculous and funny part of the talk to
rest
now let’s get serious and let’s really
talk about
what devops really is and why we the
developers
should care about it so just to segue
from the conspiracy
theory let me ask you okay so let’s say
let’s assume as a part of the theory
that devops has nothing to do with us
the developers
and whatever work they refer to is not
our work what is
our work what is the
proper developer work
there are obviously different
definitions and the one i like
regardless of what you feel about the
software craftsmanship as an
organization
and the personalities behind it i think
the
core values of the manifesto should
resonate with most of the developers
what are the core values
we want to write better software yes we
are
we want to this software to be useful
by adding value yes we want
to be a community of professionals and
learn from each other
yes and we want productive partnership
with
other organizations like the ops the
product and everybody else
yes sure this i hope
everyone can get behind now let’s look
more closer
and try to see what other people
say about this manifesto and how can we
bring it down
so um i have a close friend of mine
um anton cax he works in estonia
in a startup that are pro proudly
software craftsmanship startup and this
is how
he kind of breaks those values
into details he speaks about
how important it is to know a broad set
of technologies
being a polyglot developer how a
a a true developer knows the essence and
then can apply it to any possible
technology
and tons of very very
interesting and and on point stuff and
then
he man he mentions deployment
as an afterthought like also deployment
and the reason why he kind of speaks
about deployment
is so you don’t want to be called
by the admin during the night
so again we see here how
developers now segregate themselves
from the deployment part and saying this
is not our job
the only thing why we should care about
deployment
is so we can sleep at night while those
ops people
are battling their deployment which is
not our job anymore
right so looking at this
list we can come up with a definition of
done
for software it will be the standards
need to be done
yes our code is readable simple
understandable
our code is easy to deploy that’s
important that’s on us
we have collaborate a collaboration with
the ops team
we want to make their life easy we want
our code to be easy to deploy it’s still
not our job to deploy it
but we care about that will be easy and
then
non-financial requirements are met
security performance
we didn’t incur any technical depth and
even reduce some
this is great the tester pass generally
the qa took a look and they’re happy
with the quality of our software
and the team lead is happy with the
architecture or whatever whatever the
design
and the product owner who is the proxy
for the customer
took a look and they are happy which for
us means
the customer or the client is happy as
well now
again this is all i hope most of you
can relate to now i want to talk
about why this list
might not be conclusive and i want to
start this
with an old misconception that i hope
the majority of us already put behind
you probably remember this silly
tug of war between developers and
testers
how they are you know in war with each
other
and the developers is getting distracted
by those testers that find those
bugs which are not really bugs but
features and the testers are upset with
the developers
because they do all those stupid bugs
and they don’t know how to quad
well i hope you will agree with me that
it’s all
in the end of the day the testers and
the qa
help us the developers write
code with better quality and i hope
for all of us better quality
is important is a big deal
and we all want better quality to our
software
and that means that this conflict does
not exist
it means that testers are helping us
doing our job
and if we all agree that the quality is
part of our job
then it means that we really need to
care about it
now i obviously write code until now
but the last time i really co like coded
full-time job for like production
services
was a way ago and
the definition of quality back then was
different
this is my bank chase 10 years ago this
is their website
most of it doesn’t work by now but
even then back then it wasn’t very
useful it was nice i could probably
maybe see the balances
and check where the closest branch is
but in the end of the day
if i wanted to do any serious banking i
would
grab myself and go to the branch
so even if i saw something here in the
news and announcement stream
about well we have a maintenance window
it will be 20 12 hours because we need
to upgrade our systems to ensure quality
i would probably
go like oh whatever i i would just go to
the branch if i need anything
obviously today that’s not the case
i don’t remember the last time i visited
the bank branch
it was probably like last year or
something and
i don’t need anything from the branch
because
today’s quality assumes that i have
everything
on the website and in my mobile app and
today
something like 12 hours maintenance for
update
it’s completely unacceptable in terms of
quality
i would say well it’s a crappy website
it’s a crapping up
if it takes 12 hours of downtime to
update
so our definition of quality
changed what else has changed the
software itself
we now have much more complicated
software
with much more data in it
and that makes testing much more
complicated
to a point that it doesn’t make sense
anymore to have a staging survey
server in the classical terms on it
and the classical term would be we have
a copy
of production environment that we can
test the out of it
and then we are 100 sure that we can go
to production and we’ll have no bugs
there is no such thing anymore in more
and more organizations
give up on this idea just because
it’s not feasible or not worth it
from a from a economy perspective
to invest in a copy of production
environment so
how can we still guarantee quality
which is to remind you is a part of our
job
as a developers well we start
testing in production there is an entire
industry that is called everything
around progressive delivery
that this is what it does canary
deployments
feature plans reducing blast radios
observability all those are
new terms that emerged from this need
of guaranteeing quality and this
limitation of we can only guarantee the
quality in production
now if we as developers care about the
quality of
our code it turns out that we cannot go
to the pub
and start drinking while the ops are
battling with the deployment
because our quality is not yet
guaranteed
we have to be there in production
when our code is deployed because
this is the only place we can see the
quality of our code
and decide whether we are done
as developers or not and that’s by
definition means
we need to be there we need to be on
call
so suddenly we have another new entry
in our definition of done which is
sre took a look and they are happy
who are those sre and what it has to do
with us
according to google who came up with the
term sre
which stands for software reliability uh
sorry service reliability engineer
or site reliability engineer sres
are sre implements devops
this is the engineering um
part the engineering aspect
of devops and sre
are in charge of making sure
that what you wrote will be deployed in
production
and that’s different from sre are in
charge on deploying to production
because you deploy to production as a
developer
sre are making it possible
through building pipelines through to
making around the releases etc etc
they are in charge of making sure you
can deploy to production
and why now you care about what
they are thinking because as we just
spoke
you care about the production quality
you need to see your application through
all the way to production and the way it
gets to production
now is suddenly something that you as a
developer care about
so what does it mean sre took a look and
they are happy
so first of all we understand how our
code is going to be deployed
that’s kind of the basics if we want to
deploy it successfully
rapidly we need to understand what’s
going on the build is reliable
repeatable and fast
very important if now we need we care
about quality
we discover the bug it’s our bug we
fixed it
we need to get it to production as fast
as possible
because our software is already in
production and people are suffering
the code has to be built successfully
reliably repeatably and fast our code is
stateless
another bug which is also our bug is
that our system is too slow
and it’s too slow because there is too
much load we need to scale
for that we need software that can be
scalable
scalable our code starts fast and dies
fast
starts fast again because we need to fix
stuff that we broke
as fast as possible but also we need to
take down misbehaving code
as fast as possible and it should die
fast as well
our code is observable we need to know
if there is a problem
and that’s again on us part of it is the
login
that we add or don’t add there are other
aspects of observability
and that’s yet again another talk um our
code supports feature plans
we want to be able to turn off something
that doesn’t work as it should
immediately without rebuilding and
redeploying
we can do it programmatically we can
embed feature flags and say
hey i want to turn off this feature
because it doesn’t work well
i will fix it and then we will redeploy
and turn it back on
our code backwards and forwards
compatible backwards compatible
obviously but also if we’re talking
about rollbacks
we’re going to roll back now new clients
is going to use
old code it should work how can we
guarantee that
our code means event streams again that
goes to observability
and this is also looks very familiar as
well
there is another manifesto and i’m into
manifestos today
and that’s the 12 factor up the 12
factor up
is a little bit dated now but still very
relevant description
of how do you write an application that
runs successfully in the cloud what it’s
called the cloud native app
the cloud native app it’s an app that
was born
to run in the cloud how do you write it
what are the aspects
you can see here that the aspects are
exactly the same
what we spoke about is pretty much
described here
just in a different terminology it’s not
conclusive
since there we discovered other factors
which are summarized in the other
books like beyond it will factor up and
again if you go to jefferson’s show
notes it’s right here in the bottom of
the slide
you can find the link there to the 12
hour app and the beyond the 12 factor
app
both of them are free resources for you
to take a look
right so going back here this is the
list
of what sre cares about and that means
that you care about as well
but there is one more and this one is
our code is
lean and by lean i mean
saving money to the organization
what is the biggest expense of the
organization in terms of runtime well
their cloud bill
and you know you heard how all those aws
bills
are very um confusing
and and uh not intuitive
and costs a lot of money and you go and
ask yourself again
what the hell i have to do with with
that
that’s an ops concern you have
engineers in the um that
take care of it and those are the sre
that i mentioned
let them figure out how to minimize this
bill
well not exactly we as developers
have a very big impact of how much
it costs to the organization to run
our code and here’s one example this is
kafka summit last year
and you can see here how would i
from signalfx give a talk about how they
achieved
50 reduction in cross availability zones
network costs by just implementing kafka
correctly
i don’t think we anyone will argue that
implementing kafka
is something that we as developers are
in charge of
and then you see how important it is
for reducing the operational costs of an
organization
and i have to say that signalfx they had
billions of transactions
um every day because they do
observability for huge organizations
and this is tons of money that’s like a
lot
so suddenly not only we care about
production
from quality perspective we also care
about production from business
perspective
from costs and revenue and all this kind
of stuff
and suddenly it’s a good thing because
now
we are empowered to help
the business do the right thing so next
time
we have to cut costs instead of
laying off the developers or starting
charging
for coffee we can
switch to serverless and move to the
cloud and this is how we save money
so instead of worrying about layoffs and
paying for coffee
we should start learning
cloud native and google how to pronounce
cube cuddle correctly so suddenly we
are a very big part of business
that ask questions that we can answer as
developers
we need more happy customers what the
customers want
they want new features when the
customers want the new features
they want them yesterday how we can help
we can implement devops looking at the
state of devops report
elite organizations those who ship
faster actually those who implement
devops
ship 208 times faster
more frequently than those who don’t
suddenly implementing devops has a very
big
business implications and as i hope you
so by now
it’s in our hands to do that the same
for security
we need to improve our security well one
way
is to hire um cso
and uh blame them for the outages
the other way is to make sure that we
can
react to security incidents the fastest
possible
as we react when we drive and we
want to make sure that we see the
problem and then
apply the brakes as fast as possible the
same
with security we want to identify a
bridge
fix a bridge and then deploy update our
software
as fast as possible again and the
update part is about devops
is about deploying the fix 208
times a 200 times faster
so you see how devops
is an evolutionary process
it’s not that someone just decided hey
let’s do devs for the fun of it
there are very serious reasons
very serious reasons in quality
in money in business for
devops because devops is a mean to an
end it’s a mean to achieve better
quality
cost savings faster and better new
features to the customers
and and security and what that
means is that devops is here to stay
and the only question is how do we do it
correctly now let’s look at how do we do
it correctly
now once we made peace with the infinity
loop
and embraced it and realized that yes
we’re all in it together
and we are all going to participate in
it let’s
ask what it actually takes when you look
at
the definition of term dev ops
it’s dev and the ops kind of merging
together
into this wonderful mythical devops
thing you might say well now
what is required for me as a developer
is start learning all the ops concepts
and becoming not only dev the dev
engineer
but only but also ops engineer and qa
engineer
well good news those
engineers that know everything do not
exist
they are as rare as unicorns farting
rainbows
devops engineer does not exist
because devops is not about
knowing everything it’s about
collaborating
between everybody so devops engineer
makes
as much sense as collaboration engineer
which is obviously
do not exist and this is
a complete misunderstanding of what
delves is about
what devops is about is t-shaped people
aligned in empowered teams
what do i mean by t-shaped people i mean
is that you
as a software developer you still being
very good software development and
that’s kind of the lag of the tea
when you know your stuff very very well
but
also you have now this broad
top part of the tea that goes into
different directions
and you understand the world of other
people you understand
how the pipelines work kind of the off
ops
aspect you understand how this the the
quality checks in the pipelines work the
qa part
of the puzzle you understand how the
security checks are now embedded
in your code in the ci in the pipelines
that the security you understand the
bigger picture
it makes you a t-shaped person a
t-shaped engineer
and teams of those engineers with
different legs of the t there are people
who come
who who are developers the people who
are sres the people who are security
engineers
all working together this is
what devops is about now you remember
how we started
with this thing the ops
devops doesn’t care about developers
this while it was true 10 years ago
is very very different today and if we
look at the last
state of devops report that we have from
last year
you can see how things change suddenly
you can see that among
those 30 000 people that they asked
actually the majority are development or
engineering
so they really start asking
developers and only the second
is the ops unnecessary you can see how
the
metrics include very clearly
the part of software development it is a
part of devops it’s important
and now the lead time is defined not
where the coding is done but actually
all the process including development
itself
and more so you remember the phoenix
project
they didn’t have a single developer in
sight
jin kim the same jean kinder author of
the phoenix project
wrote another book it’s called the
unicorn project
and this is the alternative reality it’s
the same company
facing the same problems and coming to
the same solution which is devops
but the person the main protagonist
who came up with the idea of devops
and managed to transform the
organization and
to win through devops is
developer maxine she’s a lead developer
now
so even those people who kind of always
looked at devops through the eyes of ops
now experience the change and understand
that
devops that dev is a really huge part of
devops
and what about those sres they are much
closer to us the developers than the
traditional system administrators
look what sre is sre is what you get
when you treat operations if if it is a
software problem
not only that system administrators
disconnect to us it’s the opposite they
become
a little bit of developers themselves
when we talk about devops
because now they see their problems as
software problems
and that means that you know what we’re
almost there we’re all dealing with
software problems
we are very close to each other we can
all almost
almost be both so good news everyone
yes devops is an ops idea and
there is no arguing with that but the
business liked it
and that means that it’s here to stay
because it provides quality
savings competitive advantage and
security
and for us it’s not as
bad as we might thought it was because
in the end of the day
everything is code and this is what we
the developers do
we love cod and all we need is to follow
principles and practices
and we definitely know how to do so
so yes devops is more than okay
devops is great for us and we definitely
shouldn’t be afraid of it or consider it
against us
devops is great with that i’m edgy
baruch on twitter
this is mcr java on twitter as well when
you
tweet about this talk whether you liked
it or not don’t forget the devops
hashtag
and go to jfrog.com show notes
the slides are there the video will be
there all the links are already there
and uh thanks to ari um amazon echo show
five
is for you to grab thank you very much
questions awesome thank you very much
that was really interesting um yeah if
we got any questions from anybody
on the call okay nick one thing i wanted
to uh
add is uh that you know we got a small
intimate crowd today which is awesome
um what i’m gonna do is anyone that
enters the contest
at jfrog.com backslash show notes
there’s no one that leaves the loser
today because what’ll happen is
they will everyone will get a t-shirt uh
so
if you go ahead and put it enter the
contest i’ll contact you via email so i
can
mail you one of our really cool jfrog
t-shirts uh well we’ll wait
while we wait to the questions let me
see if i can find the t-shirt that ari
is talking about
yes please do yeah and you will see how
awesome it is
so is that on by the show notes link
we’ll get to the
the android page for them you’ll see
baroque’s talk on the top
right cool oh yeah so
you want organizers to enter too by the
way yeah
definitely that’d be cool
oh yeah that’s that’s the t-shirt
awesome that’s good all right yeah
so as has anybody got any questions
i don’t know if anyone’s putting it in
chat
uh can i ask a question yes
thanks very much very very entertaining
interesting talk i was a bit
uh what’s the word initially i was a bit
worried
in the first few slides but then
afterwards i got the footage
um that’s a good idea that’s nice cool
this is something i haven’t really been
clear about enough and i’ve looked into
it a bit and i’ve had people talk about
it and even your talk you
kind of referred to it this whole idea
of the sre
as well in in the mix
i still can’t grasp the
the difference isn’t this just devops
with a different
name yeah yeah yeah or that’s that’s a
great question
so first of all another reminder
devops engineers do not exist okay let’s
start with that
because devops is a set of collaborative
practices
there is nothing engineering about it
it’s not an
engineering discipline there is nothing
technical about it
devops is about collaboration between
dev
and ops now developers didn’t change
much in the process
we’re still java developers we write our
code we do pay attention to the
cloud native nature of the code that we
write
all the aspects of the 12 factor up fine
but the
ops cannot stay the same
the good old system administration as
an engineering practice is dying it’s
dying because
it’s by definition very manual
very bottleneck very wait for it i’m
going to log into this server
and set up stuff here and then it will
be different a little bit from the other
server
because i don’t remember exactly how i
did it
the problem in implementing
the rapid releases that devops inclines
the real battlenecks are the old-school
system administrators
they need to evolve and they indeed
evolved they evolve into software
engineers
it’s an engineering discipline the site
or the service reliability engineers
who are now helping us the developers
to deliver the software that we are
writing by providing the infrastructure
who is in charge of building
configuring and working on the pipelines
who are in charge and making sure that
we can spin up environments
any environment including production and
then tear it down
when needed who are in charge in make
sure that
the testers and the security are
embedding their checks into the
pipelines
the sres are the people who are
working to make the infrastructure
available for the entire organization to
be able to release the software
208 times faster than before
brilliant that’s quite cool so um so i
work for uh
government department and um
so what you just described is our devops
and uh
what we call yeah i i get what you’re
saying but within my like within my team
for instance all the
stuff you just described the people we
don’t have old school ops we have a
bunch of guys
who know uh well about systems and who
know how to use terraform
and and all that jenkins and all that
stuff
and work with the devs to
as you said feel pipeline make sure that
we can deploy quickly
blah blah blah so that’s what we call
devops as a role but it seems to be
based on what you’re saying is more of
an sre
should be no if you call them devops so
you have
you have dev yes and then you have
devops
as is them and then the collaborative
practice between them
should probably called dev devops right
yeah i guess yeah
so the next the follow-up question is is
this so what my
my project is trying to do and i’ve
actually seen this work
in the previous place that i worked in
is they’re trying to merge the two rows
so they’re staying they’re saying it’s
not
efficient for devs to be on the dev side
just
cutting java doing maven publish
and going home and maybe yeah we do
interact with
and work with devops to make sure
pipelines are working and
make sure that we are deploying the
right way but they’re not
saying devs should jump in
you know get involved in doing terraform
get involved in puppet the whole
devops two to two sets and to some
extent
because it’s easier for devs to do all
those things now for the people who are
traditionally ops
to actually write clean efficient
like java node code but the whole the
the the whole
uh drive is to have what they’re calling
platform engineers
which is uh holy glut you can do
everything type setting
and the dream is you just have people
you just hire people
and they can do anything in that whole
pipe
the whole process end to end is that a
feasible and encouraging direction
so i’ll i’ll tell you what
uh to be frank as i mentioned it’s it’s
very very hard to be exporting
everything
i guess there are not a lot of people
out there who can
actually do that and and those people
are very
rare to find and very expensive but the
good news are you
don’t really need it as long as you have
the collaborative practices
well set up as long as you speak with
each other as long as you work towards
the
common goal it’s completely fine
to be expert in development or to be
expert
in site reliability engineering you
don’t really need to be expert in both
as long as you understand what they are
doing in the general terms
you are willing to work together towards
the common goal
and you have good collaborative
practices i don’t believe
in this devops is about you become
expert in everything
just because humans are limited
in what we can possibly grasp to a level
of an expert
does that make sense yeah yeah yeah i
mean i i’d kind of um
i love my i work as an sre and i think
yeah the term devops engineer i almost
see that as a bit like a market in terms
to get people interested in the job
uh but actually knowing reality what
they’re doing is they’re enablers for
the organization that people are
building platforms and tools that enable
devs to be productive essentially
and do things well so i think yeah i
totally agree with what
i was just saying there it’s um
it is it’s it’s devops engineer is just
kind of
a bit mythical i think you mentioned
there about the dream of everybody being
able to know
how to you know understand all the ops
tools i think there is there’s just too
much there’s too much complexity
there’s too many new things happening
and changing all the time and do you
want
everyone in the organization to relearn
and get new
these new kind of low-level skills every
three or four years or do you want to
abstract some of that kind of complexity
from them
yeah i think it’s finding that finding
that balance is the key
give them enough information so they
kind of know what’s happening
um but yeah will they ever need to know
how everything works inside out i’d say
definitely not
and that’s probably not it’s not even
possible i don’t think
yeah but yeah that’s cool
it’s interesting topic that’s for sure
and i imagine it gets some kind of good
debate going
yeah yeah it’s it’s always fun and i i
feel a little bit like
don quijote fighting the you know the
windmills on my
quest against the term devops engineer
but but i think it is important because
uh
this kind of terminology incentivize
behavior
and once you have devops engineers and
you start to organize them
in the devops teams then this is the end
of it
you’re back to square one which is just
instead of ops or
or system administrators now you have a
completely isolated and solid team that
called
the devops team that have a bunch of
devops engineers and
the only thing you can do now is come up
with dev devops and start all over again
yeah yeah we started from there when i
joined there was a special
devops team and they had the devs teams
and it was always basically was the old
pattern just an ops team and then what
we then did
was merge it all together so we’re all
the same team now as a much smaller unit
and there’s a lot of collaboration they
still do
what we call devops engineers still
focus on the
building pipelines getting deployments
through learning those
building tools for us to get deployments
through and stuff like that but we’re
all in the same teams the same stand-ups
the same boards the same tickets go
through this
better communication and collaboration
which helps
i think what you often kind of see in a
probably in like
larger organizations particularly is
that sometimes
there might be new ideas and having that
small group of people who have got that
motivation or interest to kind of
explore some of these things and prove
our
ideas and try and get that buy-in from
the wider organizing maybe that’s where
these kind of devops teams originate
and but the idea yeah that they then
become you know
they then disperse and they become it’s
just part of the organization
it’s probably the the right path to go
rather be a persistent thing that lives
forever
and everybody depends on because then
like you say it’s just ops
essentially that happens
yeah yep
awesome um
is there a particular size team that you
would recommend
that devops practices starts to make
more sense so we’ve only got a small
team of devs
um and they’re pretty much stretched at
the moment so
to add something like that onto their
plate as well
it seems like a lot to ask for for
smaller teams
i i understand and the the issue is like
everybody
are our stretching over overwhelm we
have no time to
implement those practices it’s something
that obviously we hear a lot
but you know what it’s almost like you
remember this caricature
when uh prehistoric people on square
wheels
are are struggling uh to uh
to move the cartwheel and then someone
comes with them with the round wheel
and they’re like no no no we have no
time for that it’s it’s it’s more or
less
that in the end of the day implementing
devops will
allow the teams to have less stress or
to deliver more
depends on what your priorities are
obviously and sometimes you really need
to stop
and kind of get your head out of the
above the water and
and look on the big picture obviously
bringing someone with the existing
expertise
from outside who will help
to uh with the burden and also will make
sure that you
don’t step on don’t repeat other
people’s mistakes
is a very good idea and if you were
talking about devops as
as a profession there will be some cons
that
consultants are those who actually make
sense who can take a look in your
organization
and and see how the processes can be
improved
to actually make it easier for everybody
and not just adding more
work
okay thank you
yeah cool nice um good question
well we yeah we we tend to be more
project driven
um so the only time new things are
implemented is when there’s a larger
project
but the problem is we’ll we’ll bring in
a contractor
which maybe has these skills and then
they’ll implement it and then they’ll
disappear
in the year’s yeah yeah but but those
techniques
of how you deliver how you build the
pipeline
how you roll out the pipeline those are
completely portable
right once you learn them once and one
you
have them and you obviously need to
update them to to reflect
the current uh technological
state-of-the-art thing but in the end of
the day once you
switched to deployment pipelines as
opposed to manual deployment processes
it’s going to be the same over and over
again and each and every project
those skills are completely portable
yeah i think one of the challenges that
i’ve seen
at least is as a developer which is my
background
it’s kind of being able to articulate
and get your
your point across about about why it’s
important to somebody who’s just trying
to sell new
products or something or wants new
features building
and i mean i suppose that’s a challenge
and a skill in its own right to be able
to have those kind of sensible
conversations with
the people who want the new features to
say actually we need to slow down a bit
so we can go faster in the longer term
and that’s difficult that’s not there’s
no easy answer to that um
it takes a bit of kind of i suppose
yep a bit of effort a bit of kind of
motivation to really make that
difference
but start having those conversations
would be the starting point
trying to talk about these things quite
openly with business
yep yeah
awesome so cool if that’s
all the questions i think it is um just
like i said thank you very much
to ari and burj for kind of nick there
was there was one more i have a question
i was just kidding actually uh two
things one is uh for those who entered
the uh raffle uh
i um will select the winner within two
business days and then contact the
winner via email
i’ll contact everyone that entered
regarding their t-shirt but i just
realized something else too
um next week with all this devops talk
we actually have
a workshop in um that’s good for
european time it’s a hands-on workshop
and i just wanted to see are you okay if
i drop the link in the chat for people
that would be interested in it’s
actually specifically for
java developers uh so basically it’s uh
devsecops for java developers and sven
rupert is actually going to be uh doing
that hands down it’s a great workshop
and it is i believe 10 am central
european time
so i went ahead and i dropped that in
there for anyone that would want to join
it we give you all the tools that you
need
for for the workshop they’re free um and
it’s a good way
for those who aren’t as uh who haven’t
who have not been immersed in that
culture yet to really get their
feet wet yeah i mean if you if you like
you can also share that on the meetup
event feel free to kind of add the link
in i don’t know how kind of
why you want to share it but if you’d
like to go for it um
you’re on mute sorry what did you say
i’m sorry
so on the on the meetup page for this
event if you wanted to share it on there
as well feel free
i’m happy absolutely we’ll be happy to
thanks for having us
yeah brilliant okay thank you very much
and um hopefully
i see you in person next time who knows
really really hope so thank you for much
for
for so much for hosting us and yep see
you in person next time
brilliant cheers yes thank you hey and
and by the way nick uh
melissa texted me back and she says
she’s excited she should be very very
excited to hear from you all right yeah
i’ll drop her a message
all right good deal take care thank you