Welcome to This is My Architecture.
My name is Claudia,
solutions architect at AWS in Brazil,
and we're going to talk with Thiago,
from Globo TV.
-Welcome, Thiago.
-Thank you, Claudia.
Thiago, can you introduce a little bit
about Globo TV?
Sure. Globo TV is a leading company
in telecommunications here in Brazil.
We have five local TV networks,
also a set of affiliates
that helps us to cover
almost the entire country.
Our content is watched in 190 countries,
we also have an international channel
and a strong presence either online
as in our over-the-top app,
which is Globo Play.
Cool. Could you talk about
the business challenges
that this solution addressed to?
Basically, we had two challenges, Claudia.
The first one was related to provide
a more efficient infrastructure
for our rendering services in the cloud.
In the past, we used to do a provisioning
by the average peak of the demand curve.
We realized that, most of the time,
our resources were idle.
So, the first point is efficiency,
the second point
is a matter of business positioning,
we see there's a growing demand
for content
having visual effects
increasingly complex and bulkier.
And having this ability, this elasticity
of going to infinity and beyond,
only the cloud can really provide that.
Nice. Now, can you explain to us
how this solution works,
the Think Box's deadline?
Sure. This one is the most
up-to-date architecture
that we've got, after a year and a half
of evolution in our partnership.
Globo TV and AWS.
So, the most successful point
of this architecture
is to have the creation design in its core.
Why? Because we have a flow
and our biggest challenge
was to make the user experience
to be exactly the same he has
on the on-premises render.
So, how does it work?
Basically, there's the designer,
when he's ready to do the render,
which is the composition of various textures
to create a virtual object,
he goes to this Deadline Manager,
which is already our tool,
and he uses a resource from another application
that runs inside the Deadline Manager,
which is the AWS Deadline Portal.
It basically has some features.
The first one is provide
all this path to the cloud.
We go through here using a VPN,
through the forwarder,
it delivers here on the S3's bucket
and then delivers
to the Spot Fleet machines.
So it does all this provisioning.
We have a gigabit internet link,
so it establishes a SSH session
with the cloud
through this VPN,
and it also does this:
We basically had two problems
for this user.
The first one was that for every render
that he does in the cloud,
we could have one quick sample
right after the rendering.
In other words, when the rendering is ready,
we can see at least one frame of it.
The second point is to replicate
the entire effects library that it had
here, in the cloud,
so it didn't have to do
any kind of compilation
in another folder to have it uploaded.
This would take a lot of the user time,
because there are so many effects
and the folder structure is too big.
So, this AWS Deadline Portal,
it also replicates
the entire folder structure
in the forwarder, which delivers
the content, it works like a cache,
delivering the content in the S3 bucket,
and when the content is available here,
it's rendered on these Spot machines,
which delivers again here, in the S3,
and then deliver to the forwarder
and finally returns to the storage.
Nice. So you generate
some preview sample in order to see
if it's good, and then you render
the whole project, right?
Correct. If you have, for instance,
a 180 frames project,
the first frame, as it gets ready here,
it automatically downloads the frame
to the local storage,
so they can preview this material.
Cool. So tell us a little bit
about how was the definition process
of this group of machines
that renders the rendering?
This was also a nice job in this partnership,
because we tested
a big number of instances
in this render service
until we finally found the one that has
the best value for the money
that we were looking for.
Not only from the delivery standpoint,
render capacity
and speed of delivery for the user,
but also, obviously,
from the cost standpoint.
Cool. So you ended up using Spot
because of these tests
and also that it could provide
better prices for a larger capacity.
I like your observation,
because initially we started
with on-demand machines, but...
The architecture, as a whole,
and also especially
the number of machines in use,
we came from a series
of feedback and working along
with the product team of AWS
that now provisioned us
with these Spot machines
with a value closer to what we planned
in our business case.
Nice. So it's a great example
of a hybrid scenario,
in a way that you provide interaction
with no impact to the costumer.
And tell us what your predictions are
for the future,
for the evolution of this architecture?
Alright. We're addressing
a number of goals
in our architecture, evolution goals.
But the one I can highlight is the one
regarding the forwarder.
Today, basically,
we have one machine per sector.
So, there's one for entertainment,
one for advertising and communication
and one for journalism and sports.
The perfect scenario is to have
a cluster of machines
where, if we had a failure in one of them,
the service would not be interrupted.
It would simply migrate all workload
to another machine,
in an active-active system,
and I would know
that this machine is down,
we're having a downtime and such,
this would give us more resilience,
availability, visibility
and that's something we're looking for
with the product team.
-Thank you very much, Thiago.
-You're welcome.
Thank you for watching our video.
See you next time.
