Hello, welcome to today's This Is My Architecture
I'm Dickson, Solutions Architect of AWS.
Today we've invited the Head of Application Development of TVB, Sam
to talk about Big Big Channel and architecture
Can you briefly describe Big Big Channel, Sam?
Big Big Channel is a new attempt by TVB last year.
It is an online platform
that allows the audience to understand
the making of a TV show
or the daily life of an artist.
Artists can go live directly through this APP
and talk to their fans or audiences.
It is hard to predict the flow of data
when artists go live.
What would you do with the structure?
Correct. When the live TV show is linked
to the event,
the flow of data might increase dramatically.
The entire deployment can be classified first through the API.
Unlike Static,
When dealing with API, we would first start with the back-end.
Pre-generate JSON data on S3.
It's going to swim through when request comes over.
CloudFront serves the needs,
and finishes up on S3.
CloudFront could help with Cache,
even if there's any issue with backend or CMS.
S3 will have a copy in serve guest in place.
It is a user-driven and easy API.
We're going to release the pre-generate and get under DynamoDB,
"Recommendation", for example.
The API gets to Lamba through API Gateway.
We will arrive Lambda before DynamoDB
gets the user data up there
So you're mainly going to do it with Serveless's structure.
Why does the "container ECS" part exist?
Because app always has many features.
Some functions may be a little more complicated.
Different teams use varied codebases to process the work.
The runtime is also different.
We're going to turn individual codes into container.
Leave the ECS,
and turn it into a different task.
Then it's convenient for individual task scaling.
That's probably why different tasks have various runtime.
It could be different functions.
Can you give us an example, specifying how to use different tasks
and databases to do the scaling?
Okay, for instance, we'll register the new users.
and assign a separate task.
It even has its own cache and database.
Other services will be in response to different needs.
There will be a group of its own cache and database.
The benefit is if the flow of data increases dramatically,
or maybe lots of people register for the event,
and the scaling performance slows down, or should there be any sort of problems,
it will not largely affect the existing users,
as the piles of APIs don't need to be used.
Every function has a separate task for scaling.
Database scales separately,
and fails the same way.
I see that you're using the structure of Micoservice
to gain a better user experience.
It has high stability and provides layers of cache.
What's the impact of your development on the team?
It has huge impact.
Since we break it into small tasks to work on it,
you can focus on your own part.
So the whole working process is changed.
After the job's done, we just need to drop the code in BitBucket.
We use Jenkins to help due to a different repository.
A different branch can be deployed to an individual task
or Lambda.
The whole process is thus simplified.
Even if there's a problem after production,
the convenient monitoring feature makes it easy to supervise the system
and solve the problem immediately.
Thank you for sharing the wonderful Micoservice structure with us.
Thank you all for watching This Is My Architecture.
See you next time!
