►
From YouTube: Lightning Talk: Don’t Let a Bot In! Protect Fortune 500 Compani... Sudhamsh Bachu & Remington Breeze
Description
Lightning Talk: Don’t Let a Bot In! Protect Fortune 500 Companies & Users - Sudhamsh Bachu, ArkoseLabs & Remington Breeze, Akuity
Context: ArkoseLabs is in the security space. Focused on Fraud Detection space. It protects its customers from Bots and human bad actors. Most of its customers are Fortune 500 companies like PayPal, Microsoft, Amazon, etc. Serving Fortune 500 customers is a double-edged sword for a start-up. Enterprise customers can detect start-up service issues quickly. How would I know? - I built some of the monitoring and detection tools for one of our largest customers. Arkose Labs improved Developer Experience, Increased Product Releases, Improved quality, and reduced outages with ArgoCD & Rollouts implementation. Application availability & stability are paramount as we provide warranty on Credential Stuffing use cases. ArgoCD’sGitOps approach & Argo Rollouts deployment Strategies like blue/green & Canary were loved by the application teams. We were plagued with multi-day releases, rollback, toil, outages, etc. So we implemented ArgoCD with our existing GitHub actions for CI to automate manual tasks, metric analysis, and blue/green deployment strategy to address our pain points.
A
Oh,
you
might
be
curious.
What
is
don't
let
a
bot
in
I
want
to
get
creative
so
that
I
could
get
picked
for
the
lightning
talk.
So
that's
the
whole
reason
cool
so
about
our
course
Labs.
It's
it's
a
security
cyber
security
company.
Why
I'm
sharing
about
Arcos
Labs
is
like
why
religious
are
more
important
to
us.
What
would
happen
if
releases
don't
work
as
expected,
or
if
there
is
downtime
so
Argos
Labs
has
protects
its
customers
like
PayPal,
Microsoft,
Adobe,
roadblock,
snap
and
bunch
of
other
customers.
A
It
has
multiple
use
cases.
It
it
deters
Bots
from
creating
accounts
or
hijacking
accounts,
protects
payment.
Fraud
on
the
financial
space
account
takeovers.
Pretty
much
every
site
that
has
a
login
could
use
our
application
new
account
fraud
like,
for
example,
if
PayPal
has
a
promotion
for
ten
dollars,
somebody
could
create
use,
Bots
and
then
create
accounts
and
then
exploit
that
marketing.
So
that's
where
our
product
stops
users
by
with
captcha
challenges
and
later
spots.
A
If
a
manual
user
is
creating
multiple
accounts,
we
have
different
rules
and
strategies
to
block
those
users
with
complex
puzzles
and
at
a
particular
point
we
deny
them.
So,
as
you
see,
we
have
like
very
large
customers
like
Microsoft,
PayPal,
Adobe
and
others.
They
have
very
strong
observability
Platforms
in
their
environment.
So
if
our
service
goes
down
they'll
detect
in
no
time
so,
whenever
we
do
a
release,
we
need
to
be
confident
that
the
release
will
go
smoothly
and
it
will
not
have
any
regressions.
So
that's
where
so.
A
A
So
some
of
the
challenges,
what
we
had
multi-day
releases
I'm,
not
making
it
up
as
being
a
SAS
company.
We
had
to
make
sure
release
your
region
test
it
thoroughly
then
go
to
next
region,
then
test
it
thoroughly
that
that
took
multiple
days,
because
for
a
couple
of
reasons,
because
we
were
in
ECR
and
something
like
blue
green
was
not
supported
out
of
box.
So
the
the
end
result
was
like
50
different
manual
steps
to
be
done
to
make
sure
that
the
release
goes
smoothly
and
customers
are
not
impacted.
A
Obviously,
if
you
have
a
multi-day
release
with
like
six
or
seven
people,
you
can
imagine
the
toil
on
the
developers
like
dude
release
is
kind
of
a
dreaded
day
in
for
everyone.
Whoever
was
involved
in
that.
So
when
you
have
a
long
release,
it
has
an
other
side
effect.
The
release
velocity
would
be
low
because
nobody
wants
to
spend
multi-day
release
and
then
you
release
once
a
month
or
once
in
three
weeks.
What
would
that
result
to?
You
will
have
more
rollbacks,
because
a
lot
of
changes
are
going
at
once.
A
A
And
other
problem,
what
we
had
was
building,
always
irrespective
whether
it's
a
config
change
or
whether
it
is
a
chord
change
kind
of
goes
to
like
different
folders
and
don't
build.
If
your
code
hasn't
changed,
it's
a
config
change.
You
can
release
without
building
your
image
as
the
the
code
hasn't.
The
code
hasn't
really
changed
for
your
to
deploy
a
new
image
into
your
environment.
A
So
when
we
evaluated
multiple,
multiple
products
that
are
in
the
space,
what
we
liked
was
Argo
CD,
along
with
the
rollouts,
so
one
of
the
reason
some
multiple
reasons,
as
we
have
heard
throughout
the
day
very
fast
releases.
As
soon
as
we
make
a
change
in
GitHub,
then
the
event
is
triggered
and
then
you
can
deploy
to
all
your
environments.
You
increase
the
velocity,
as
things
are
faster.
It
has
a
positive
effect
on
the
developers.
A
Experience,
hey
I
made
the
feature
chain,
so
let
me
release
it
and
the
sooner
we
release
we
are
getting
a
better
return
on
the
investment.
The
time
we
have
spent
it's
already
it's
released
to
our
customers,
and
they
are
delighted
that
makes
everybody
happy
products
is
Happy.
Injuring
is
happy
and
developers
are
happy
and
also
github's
principles
in
some
of
the
companies
that
have
worked
before
this
is
a
separate
change
ticket
process.
You
have
one
level
approval
two
level
approvals
based
on
the
complexity
of
the
release.
We
don't
have
to
do
that.
A
Githubs
already
has
protected
branches.
We
already
have
things
for
coaching,
so
if
you
are
doing
a
code
release,
why
not
use
the
existing
process?
That's
already
there
and
also
increasing
the
increasing
the
release
confidence.
We
can
do
blue
green
deployment
test
on
the
inactive
stack
which
is
not
like
taking
live
traffic
and
then
promote
your
next
version,
n
plus
one
to
take
live
traffic.
This
increases
release,
confidence
and
reduces
roll
backs,
and
with
blue
green
we
don't
send
any
live
traffic
to
it.
A
One
other
aspect
that
we
we
looked
at
Argo
CD
before
choosing
that
was,
can
it
scale
as
our
micro
scale
microservices
scale
and
as
the
company
grows,
so
that
kind
of
checkbox
on
the
Argo
CD?
It
can
scale
horizontally
just
as
long
as
the
infrastructure
in
which
it's
running
scales,
so
it
can
scale
and
also
the
observability.
A
Yes,
I,
think
some
of
the
talks
we
had
like
from
the
Prometheus
metrics
and
other
that
that
are
exposed
out
of
box
with
Argo
CD
like
how
do
I
monitor
my
I
mean
the
Argo
CD
service
itself.
Is
it
deploying
or
are
there
any
bottlenecks?
How
do
I
get
visibility?
If
something
is
not,
something
is
not
working,
as
expected,
so
being
part
of
the
release
team.
A
If
something
goes
wrong,
I
had
to
work
throughout
the
night
until
that's
get
fixed,
but
I
need
a
starting
point
where
the
problem
is
so
that's
where
Argo
CD
helps
by
exposing
its
internal
metrics
and
that
you
can
look
at
so
all
the
features
so
before
even
looking
at
Argos
cdb
went
through
the
requirements.
Argument
hey.
These
are
the
things
that
we
want.
You
more
scalable
observability
and
then
blue
green
deployment,
Canary
notifications,
Etc
out
of
the
box,
so
that's
the
value
proposition.
That's
what
I
saw
with
Argo
City.
A
As
pratik
said
in
the
keynote
today,
and
yesterday,
Argo
CD
was
looked
at
as
a
product.
It's
not
somebody
put
it
together.
Hey
this
feature
looks
good.
This
feature
looks
good.
Okay,
let's
make
it
an
application
out
of
it.
It
was
thought
like
a
product.
There's
a
single
sign-on
integration
to
it.
It
integrates
with
active
Microsoft
active
directory.
That's
what
we
use
I
was
surprised.
Really
we
use
that
and
then
you
already
have
an
integration
for
it,
so
it
can't
get
better
than
that
drift
management.
A
So
githubs
as
things
change,
that's
our
source
of
truth.
Then
our
environment
would
be
in
sync
when
we
do
an
auto
sync
enabled
for
applications
metric
analysis
as
part
of
rollout
and
integrates
with
data
dog,
where
we
can
do
the
metric
analysis
and
release
it
I
think
two
more
minutes:
okay,
so
blue,
green
Canary
out
of
box
slack
notifications.
So,
as
I
said,
we
had
a
checklist
where
a
developer
would
say:
hey
I'm,
starting
on
us
region.
A
One
do
the
deployment
and
then
one
more
sense,
one
more
slack
message
saying:
hey:
we
finished
on
us
East
one,
that's
not
good
use
of
time,
and
that
would
not
be
accurate
because
the
deployment
Could
Happen
anytime.
So
when
that
is
integrated
with
as
part
of
the
Argo
CD
deployment,
then
you
know
that
the
action
happened,
pretty
close
to
the
message
that
that
was
sent
out.
A
Multi-Cluster
support,
one
Argos
CD
can
deploy
to
any
number
of
clusters.
So
you
don't
have
to
log
into
multiple
uis
command
and
control
for
sres.
If
a
part
is
misbehaving,
SRS
can
just
restart
or
I
mean
delete
the
part
in
production.
That's
that's
a
lot
better
than
getting
the
credentials
from
AWS
console,
updating
your
credentials
file
and
then
connecting
to
Cluster
connect
to
the
namespace
and
deleting,
and
somebody
could
delete
it
from
a
wrong
namespace
and
it's
open
source.
So
it's
an
easy
sell
to
finance
team.
B
All
right,
thank
you,
so
I'm
going
to
speak
a
little
bit
about
acuities
partnership
with
Arcos
Labs.
So,
as
sudama
mentioned,
they
have
very
high
requirements
for
uptime
with
their
product
and
Argo.
Cd
helps
provide
that.
But
in
addition
to
that
comes
a
higher
standard
and
Acuity
helps
them
achieve
that
standard.
B
So
arvo
is
a
pretty
complex
product,
and
with
that
comes
a
lot
of
configuration
and
at
Acuity
we
like
to
think
that
we
help
our
customers
squeeze
all
of
the
value
out
of
Argo,
so
yeah,
some
of
what
we've
provided
when
Arcos
was
having
difficulty
configuring,
the
Rolex
extension,
for
example,
for
the
Argo
City
UI.
We
help
them
to
do
that
and
then,
on
top
of
that,
we
just
have
a
lot
of
knowledge
here
at
Acuity
about
Argo,
because
we
are
a
company
of
maintainers
and
experts.
B
So
we
bring
all
of
that
knowledge
and
and
help
our
our
friends
at
Arcos,
and
then
we
also
launched
last
week
a
platform
that
makes
it
easy
to
configure
Argo
CD
without
the
Box
benefits,
such
as
security
and
cost
reduction.
On
top
of
all
the
OSS
features
that
you
guys
know
and
love
so
yeah.
Thank
you
guys
cool.
Thank
you.