Navigating Traditional, Cloud‑Native, and Serverless Risks
Key Points
- The technology landscape can be divided into three buckets—traditional monolithic deployments, cloud‑native container‑based systems, and the newer serverless platforms—each carrying its own risk profile.
- Traditional deployments relied on large WAR/EAR files, required weeks or months to release, and were fraught with manual effort and frustration.
- Cloud‑native containers break applications into smaller, portable units, allowing code to be packaged once and run anywhere, with deployments now possible in minutes.
- Serverless builds on containers but abstracts them into single‑function microservices, minimizing the code changes you manage while introducing a distinct set of operational and security risks.
- To mitigate risks in cloud‑native adoption, organizations foster trust in engineers, enforce the “4‑I” (four‑eye) rule for incremental changes, and automate releases with bots, shifting control from manual gatekeepers to automated pipelines while adding new complexity.
Full Transcript
# Navigating Traditional, Cloud‑Native, and Serverless Risks **Source:** [https://www.youtube.com/watch?v=BYTgP6GmwcQ](https://www.youtube.com/watch?v=BYTgP6GmwcQ) **Duration:** 00:04:57 ## Summary - The technology landscape can be divided into three buckets—traditional monolithic deployments, cloud‑native container‑based systems, and the newer serverless platforms—each carrying its own risk profile. - Traditional deployments relied on large WAR/EAR files, required weeks or months to release, and were fraught with manual effort and frustration. - Cloud‑native containers break applications into smaller, portable units, allowing code to be packaged once and run anywhere, with deployments now possible in minutes. - Serverless builds on containers but abstracts them into single‑function microservices, minimizing the code changes you manage while introducing a distinct set of operational and security risks. - To mitigate risks in cloud‑native adoption, organizations foster trust in engineers, enforce the “4‑I” (four‑eye) rule for incremental changes, and automate releases with bots, shifting control from manual gatekeepers to automated pipelines while adding new complexity. ## Sections - [00:00:00](https://www.youtube.com/watch?v=BYTgP6GmwcQ&t=0s) **Three Modern Deployment Paradigms** - The speaker outlines the three main technology buckets—legacy WAR/EAR deployments, container‑based cloud‑native approaches, and the newer serverless platforms—explaining their characteristics, speed benefits, and associated risks. ## Full Transcript
so let's talk about the three different
buckets that exist with technology
nowadays in the cloud native space or
technology in general you have the
traditional way of doing it now you have
this new wave or Cloud native coming
down the line and then also you have the
serverless platform that is pretty new
and still has a level of risk that you
need to think about so let's dig into
each one of these a little bit deeper we
have our traditional ways of doing
things we used to have this little war
file or ear file or something like that
to deploy our code to our servers
then we'd have
something that would sometimes take
months or if not weeks to deploy and it
costs so many frustrations what can we
were moving past this and now we're
moving to our new wave Frankly Speaking
I'm calling it New Wave because I don't
want to say cloud native over and over
again but what is it it's our next step
it's what we're moving past our
traditional way of doing things
we have these great things called
containers now which allows us to be
able to package up our code in smaller
bits and be able to push things out
in a fast efficient way and share code
where it works on my laptop no longer
means it just works on your laptop it
works anywhere anywhere a container can
run
and another great thing about the new
wave or the cloud native space
is that it only takes minutes to deploy
now you're probably wondering why am I
talking about all this and I should be
talking about risk we need to have some
level set of understanding of all these
different Technologies before we dig
into the risk profiles of each of these
and hopefully it'll open up some spaces
for this
serverless is still built off of
containers just like our new wave or
cognative space
but the beauty of it is is it's so small
it's just the changes you need to worry
about it leverages true microservices
where functions do all the work
but that brings in an interesting risk
profile when you start talking about
these Technologies
so let's actually take this next step
and talk about what happens when you
start worrying about these different
systems for your risks
so how are the companies actually
mitigate risk when it comes to moving
the cloud native
first thing they do is they start to
learn to trust their engineers
but with that trust takes a little bit
of time
they'll cover something called the 4i
rule and make small iterative changes
with that comes at least four eyes
looking at every Small Change
to be able to be merged into the main
main branch
but when that gets merged what happens
next
they Leverage The Bots to do the work
for you no longer do you have someone
releasing some code at three in the
morning
instead when you merge it into the main
branch the Bots take over and release
the code for you
this means you no longer have a Council
of Elders of senior engineers and
Executives discussing every single
change
now you let the Bots do the work for you
but with that comes complexity we're
going to talk about
how to take care of some of that
complexity
however something called get UPS
which believe it or not is pretty dang
cool
so what is get UPS
simply said
it's leveraging a git repository as your
source of Truth for the deployment of
your applications it can be production
it can be development could be even Dev
so how does get Ops actually make your
life easier when it comes from from the
angle of risk
first thing first you can actually audit
what any change you've ever made can you
actually answer when the last time you
deployed your application and who made
what change
the majority of people out there they
can't whoever's in get UPS you actually
have an audible system through the git
history
with that too that means you can also
verify what the change has been made
because it's cryptographically signed
using the git hash algorithm this is
important especially in regulated
environments
taking it a step farther if something
horrible goes wrong you actually take
that git Repository
and recreate whatever you're trying to
do in another environment
this gives you the ability to
make sure that it comes out exactly how
you want every single time
you have to leverage different
Technologies though
to enforce these get UPS principles like
Argo CD or flux CD
but that means you need to start
trusting the Bots to do the work for you
this is going to be a big problem for a
lot of companies because no longer
you're going to have humans do these
changes
you're now having the machines do the
changes
so you're going to have to spend some
time with the operations team your SRE
team your devops team
to really be able to embrace this new
mentality
but you will reduce your risk in the
long term because you'll be able to
enforce things leveraging the get-offs
principles
thank you if you like this video and
want to see more like it please like And
subscribe if you have any questions
please drop them in the comments below