SAMRAT SAHA: Hello, everybody.
I'm Samrat Saha.
I am a customer engineering manager for Google Cloud,
and I'm based out of Wisconsin--
Milwaukee, Wisconsin.
Thank you for taking the time to join me today
to understand our perspective on how
to deliver a flawless UX for Black Friday to Cyber Monday.
So on our journey today, we will-- we're
going to cover a few things.
For instance, we're going to go over,
what is Black Friday/Cyber Monday?
What does success mean?
What is UX/CX?
How do you prepare for it?
How you execute on it?
And a wrap-up.
And we're going to go over quite a few concepts today,
and the goal is to give an idea as to how complex
an undertaking can be, and how partnerships
can help you solve for a business critical time period.
So we'll start off with design for failure.
All things fail.
No matter how strong you make it, it is going to fail.
It's how you recover that makes all the difference.
And this is something that people find odd coming
from an organization that's known for reliable services,
but that's precisely sort of the mind shift or the paradigm
shift that you need to get used to.
Things fail.
And how you recover define how successful you become.
So just to put things in context,
Black Friday to Cyber Monday-- it's
one of my favorite holidays.
I love Thanksgiving.
For retailers, it's a really important time period.
For instance, in 2019, Black Friday
saw sales that was over $7 billion in digital sales.
It is up 14% from 2018.
And in 2019, Cyber Monday had greater than $9 billion
in sales.
That was a 19% jump from the previous year.
So to put things in perspective, that's
a substantial amount of sales that's happening over a very
compressed time frame.
You're literally going from Thanksgiving to the Monday
after, and you see that much sales come through time period.
So BFCM-- you know, Black Friday to Cyber Monday--
execution impact-- when it goes well,
obviously your sales go up.
Revenue goes up.
It's great for business.
What happens if it goes sideways?
What happens, let's say, if you have an outage for now?
What is the impact on the brand?
What is the impact on the customer relationship?
What does a 1% impact mean?
These are really important business questions
that need to be answered, and this is where cloud can help.
UX and CX-- user experience, customer experience--
what is it?
Well, a lot of people now have mobile phones.
And a lot of people are exposed to the latest and greatest
when it comes to how applications work,
how websites work.
That's the user experience.
So for instance, if you're shopping for something,
and you decide to go and add three items to your shopping
cart, was that a smooth experience?
Did the brand make you jump through hoops
to do that action?
How smooth was the overall transaction?
A good user experience enables your users
to achieve the tasks that they want to achieve.
And customer experience is sort of the overall umbrella
around it.
It's not just the app.
It's how you communicate with your customer.
It is how you can get help if needed.
So that's the overall sort of relationship, if you will.
UX is very sort of specific.
And invariably, having a great UX
can make the difference between making a sale versus not
making a sale.
So for instance, what does a one second delay
mean to your website?
A 1% delay can mean around a 7% reduction in conversions.
It can mean a poorer user experience for your users,
and that could also mean a loss in business, a move
to a competitor.
So UX and CX are pretty critical in terms
of maintaining the relationship and making
sure your users actually enjoy using your products.
And after all, it is all about the user.
So UX/CX during Black Friday to Cyber Monday
the stakes go much higher.
So for instance, if you're delivering a great user
experience when it's not Black Friday to Cyber Monday,
that's great.
But can you give a similar experience when there's
much higher load on the system?
So for instance, let's say that a person can go in and buy,
let's say, a pair of shoes.
And that entire thing can be done with minimal disruption,
and the user loves it.
Now, during Black Friday to Cyber Monday,
let's say there are thousands of users
trying to do the same thing at the same time.
Can you deliver the same experience
that made your customer love your brand during a high stakes
period?
So that becomes really important.
Stakes go up.
The revenue potential is so much higher,
but so is the business impact.
If things go down, how do you recover from that?
What happens when, let's say, that you
have users in the east coast and you have users in the midwest?
Can you give similar user experiences
to both sets of users?
Because it wouldn't be right-- it
wouldn't be a consistent experience with your brand
if somebody, say, in Milwaukee has a three times higher load
time than somebody, say, in New York City.
So these are considerations that become really important,
but again, it amplifies so much more during Black Friday
to Cyber Monday.
To help you understand this, to help you figure out
what is important versus what is not important,
I would encourage you to think in terms of critical user
journeys.
So what is important to your user?
What is important to your business?
So for instance, a user--
it might be really important to buy, say, crayons
so they can ship it to their niece in Florida.
Now that can be super important.
That user journey is really important.
Now, for your business, it might mean
that you want to have a feedback survey filled out,
because you get information.
You can better your service.
But to a user, that may not be as important.
But there are zones of intersection
between what's important to your user
and what's important to your business.
And when you figure out where it intersects,
it can help guide you in terms of where
do you need to put more resources
to harden those systems.
So for instance, checkout is super
important to your business and your user,
because a user wants to go buy stuff, have it shipped,
and complete it with minimal disruption.
For a business, it is extremely important, too,
because that's a straight line to the money.
So you can figure out what the intersection points are
to help guide you design your systems, harden your systems,
and provide the best user experience for a business
critical time period.
So why is it so hard?
I kind of alluded to this previously.
During Black Friday to Cyber Monday,
you could see up to 3x to 4x, three times or four times
the traffic than you would normally.
And there is no--
it may not be a steady pattern.
It could be very spiky traffic.
So you might see a whole bunch of users hit your systems
within the first hour of your sale starting up,
or it could be something like you have several spikes
because you have promotions going out every other hour.
So the traffic is very spikey, and it is substantially larger
than what you'd normally find outside of Black Friday
to cyber Monday.
So with that in mind, how do you account for that?
Traditionally, what you would do is
you would have a set of compromises.
You would say, you know what?
Black Friday to Cyber Monday is critical to me.
In order to meet that demand, I'm
going to over provision my resources throughout the year.
So now you're paying for redundancy
for the rest of the year.
Or you compromise and say, you know what?
I'm willing to take the hit.
I'm going to sort of under provision knowing
that it has a slightly negative impact on my customers,
but that's a compromise.
And that's why having your resources in the cloud,
having cloud native sort of mentality towards developing
your solutions can really help.
Are your resources elastic?
Can they grow and shrink with the usage?
Are they redundant across different regions?
What happens when, say, a region goes down?
These are the kind of things that you
have to bring to the table when you're
trying to address a very distributed user base who
have high expectations on a user experience,
because that's kind of what you've
grown to build with your users.
You've built a relationship that you
want to protect and nurture.
And with all that comes in stuff like you have a distributed
system.
How does a database handle asset transactions?
How do you guarantee that consistency?
These are the sort of things that start cropping up,
which are not normally seen in traditional monolithic
application, not normally seen in traditional deployments.
So these are things that make it much harder,
and it usually takes a completely different approach
to be successful in the cloud.
But the payoffs are there.
The payoff, as well.
The payoff is, again, a great user experience.
I cannot stress this enough.
What the goal should be is provide the best user
experience so that a user can enjoy working the brand
and building the relationship up with you.
So what does it look like kind of internally?
And this is fairly sort of standard in terms
of how people approach--
how teams approach approaching peak.
You have capacity plans.
You've got to figure out how much capacity you'll need.
You have load testing.
You have tabletop exercisers.
So this is stuff like you sit down and figure out, OK,
our database has gone down.
What do you do then?
Let's say you decide you're going to simulate a network
outage to the east coast.
What do you do then?
How do you feel?
Then obviously you have Black Friday to Cyber Monday,
and sometimes it's code-- depending
the organization you are, sometimes
you institute a code freeze.
Sometimes you don't.
It depends on your approach to how you develop products.
Black Friday to Cyber Monday--
and then tapering towards December
you start scaling down.
So you understand your capacity.
You scale up.
You test, deliver, and scale down.
So all this is a very, very compressed timeline
of very sort of-- a lot of activities
going on just to deliver on that short time frame.
So breaking down, first of all, definition of success.
What does success mean?
This is a business critical objective.
What does it mean for a business in order to be successful?
Once you have that, you can start figuring out,
what do you need to do to deliver on that?
Then you have core activities-- load testing.
Do you test to three times to four times
the amount of load that you normally get?
Tabletop exercises, which I just went through,
do you assimilate sort of different failure scenarios?
And you figure out, what are the lines of communication?
How do you respond to outages?
Disaster recovery testing-- this is something
that Google is famous for.
This is where you figure out things--
again, things are going down.
How do you recover?
How quickly do you recover?
Where do you recover to?
Failover-- let's say that you have regions--
compute regions in east and west.
Sake of argument, let's say east goes down.
How do you failover so that your users on the east coast
are not significantly impacted?
There is a degradation of service.
That's for sure.
The latency went up, but how do you make sure that they still
can use your service?
And that's key.
Rollback strategies.
What happens when you decide to push an update out?
Can you roll back smoothly?
Let's say that the update caused a bug that was not caught
until it was in production.
Sometimes these things do happen.
Can you actually roll back and with confidence?
Communication-- how do you communicate failures?
How do you communicate outages?
What is that internal business process?
And most importantly, who decides?
Who's the decision maker?
So let's say that we decide that we're
going to failover from central to west
for the sake of argument.
Who's going to pull that button?
Who's gonna push that button, rather?
Who makes that final decision?
Are those chains of communication--
have they been clearly demarcated?
And are teams empowered to make those business
critical decisions?
So again, fairly complex, but for really good reasons.
Now, do you have the architecture
to deliver at peak?
Is your application-- or your application--
are they monoliths?
Was it distributed services, micro services?
What kind of cloud design patterns are you using?
Are these multi region systems?
Are these distributed systems?
High availability disaster recovery?
4-9's, 5-9's reliability.
You've got to figure out what your error budget is.
You've got to figure out how much effort
are you willing to put in to get a certain kind of reliability.
Because nothing is going to be 100% reliable.
You've got to figure out your trade off.
Implication of your systems layer.
The implication of your compute layer.
The implication of scaling.
So again, the architecture that can help you deliver for peak
becomes really, really important.
So this is a sample architecture of, let's say,
an e-commerce-ish application.
And there's certain things that are
pretty common in this kind of architecture,
but the key is you start with the user.
You have users distributed across the nation or globally,
and the fundamental part is you route a user, if you will,
to the resources that is required
to complete their user journey that's closest to be used.
In this case, what you're seeing is
you have region one on the left.
You have region two on the right.
Connecting those two is a cloud load balancer on top.
So think of it as a request coming in from the user.
Hitting the load balance, which decides,
should I send the user's request to the east,
or should I send the user request to the west?
Region one or region two.
Within those regions, you have compute resources.
In this case, you have GKE.
You have-- essentially that's more for Microsoft's kind
of approach.
Then you have a persistence layer.
You have Cloud C could have NCache or Datastore, whatever
is important to your business.
Underlying all that, you have an analytics layer.
So BigQuery.
And the architecture is a distributed architecture.
It's a highly available architecture.
If a region goes down, and you resume services,
in this architecture you can.
Is this repeatable?
What if you decide to stand up a third region?
This architecture is modular enough
that you can repeat what was successful in both regions
and stand up another region.
This allows you to also test pushing out updates.
So again, it's a very distributed architecture,
and it gives you the flexibility to scale up.
It gives you the safety to withstand regional outages.
It also gives you the template, if you will,
to expand out as your business grows.
Now, this is a fairly--
these are some of the services that you
would have in a traditional sort of e-commerce application.
As you can see, you have a whole bunch of digital services.
You have search, taxonomy, a whole bunch
of services that are required for a user to be successful.
And you have other services that are non-digital,
like shopping, delivering, stuff like that.
But again, what I'm trying to impress on you is,
to deliver a great e-commerce application,
there are a whole bunch of services
that need to be built out, and there's
a lot of cloud native design patters
that you've got to implement to be successful,
especially because, again, are your services elastic enough?
Is your infrastructure elastic enough, resilient enough
to handle high loads, and to allow for disaster recovery
to happen if things go badly, and also scaled down
once you've executed on peak?
So this is a topic all by itself.
I did want to mention it--
site reliability engineering.
This is very user impact driven.
This is more about for an infrastructure for somebody
who maintains say hardware, alright,
so let's say for an example, or somebody who's
developing an application.
Things of interest might be, what
is the CPU percentage, of utilization percentage?
Now those are interesting things and are important
pieces of information that help you solve for problems.
But what is the impact on the user?
If you don't start approaching it from user impact--
for instance, let's say that you want
a user to be able to browse for the products on your website,
and you want the search results to be returned within, say,
one second.
Now, if that is impacted, now that's a user level impact,
and that can help guide the business better in terms
of solving for a better system that is providing such results.
Now the underlying cause might be, let's say, CPU utilization.
But if you're not guided by the impact on users,
it becomes very hard to figure out what is important for users
and what is important for business.
I would encourage you to go into SRE and get a lot of resources
on-- at Google Cloud to help you understand, where does SRE
fit in?
And how do you develop and deliver reliable systems
at velocity so that your developers, your product teams
can make cool stuff, but they can also
deliver stuff reliably, and maintain reliability, as well.
Common threads of success--
so in my time at Google, I've seen some teams
be very successful in delivering a great, great Black
Friday to Cyber Monday.
And some of the things that I've noticed that my teams as
well have noticed that helps people
be successful-- there are clear objectives, communication.
Great communication.
People know-- your objectives are being communicated clearly.
The teams are empowered to make decisions.
And this trust-- they embrace cloud native thinking.
Again, it's designed for scale.
The elasticity that is important to deliver on those experiences
is really important.
And then the power of partnerships.
Leverage your partners.
They have helped solve some of these problems for others.
And more importantly, it is in their interest
to help you be successful.
So it's sort of the all-embracing approach that is
defined--
that is sort of guided by overall objectives--
business objectives, user objectives.
Success on GCP-- as you can see, we
have quite a few of our customers
who have partners with-- partner with GCP to be successful.
And hoping that we can help out you
achieve your business goals.
Thank you.