 So just to give you a quick brief overview of who 9 Seconds is and what we do. So we are a global video creation platform, we basically work with brands to help them create videos. This video production is a complex thing and so we allow brands to use our platform to simplify the video creation process. So mainly we work with about 12,000 creators since our inception in 2010 and then over 13,000 brands. We produce about 30,000 videos across 160 countries and 150 cities. And so basically I want to start off with how the DL team works in 9 Seconds. So the DL team works in various stakeholders across the organization. So that might include marketing, engineering, product, etc. But mainly if you see the error, we mainly work with the engineering team especially when we release some data products. So a quick overview of our DL team at 9 Seconds. So we split the roles in the broadly tree categories, sorry the data analysts, the engineer and the machine learning engineer. So I want you to go into the detail as to what these roles are because I think these roles are quite common in most organizations but I think what you might find surprising is that all these three roles actually do play a part in maintaining data pipelines. This is also because we believe that each individual in the DL team should have some responsibility over maintaining a good data quality. And so here's a very big picture view of how we use GCP Go Club platform for data and DevOps in 9 Seconds. Our main data sources can be split into two main groups, internal platform at 90 Seconds and also the external API. So that might include stuff like Google Analytics, video intelligence, API, etc. So we use Airflow of Google Kubernetes Engine to extract, transform and load the data into BigQuery as our data warehouse. And from there we apply, we use data in BigQuery to apply them to marketing automation, machine learning, and business intelligence. And so now I'll let Tommy go through a view of how the infrastructure that we have at 90 Seconds. Thanks, Aaron, for the introduction and the insights on how the data team at NetDiscounts work. OK, so the next part is a bit more focused on the infrastructure size of the data team. So that we all know that the data work plot is always, the requirement of the data work plot is always different from the others. But then thanks to the wide variety of the host services and the well-written documentation of Google Cloud Platform that allow us to desire system with optimal performance and affordable cost as well. So I want to go through some of the main points that throughout the time, so that we can, yeah, throughout the time that we have concluded on the journey with the Google Cloud Platform so far. The first one I want to mention is the deployment flexibility. At 90 Seconds, we use GK. And the first thing I know is about GK, Google Cloud Platform, and start cluster creation. It's very stressful. We have many ways to create a cluster, and if we want to think fast, then we can just go for a cluster to the same things. If we want to just like, can just do a common line to run G Cloud, create a cluster or something, and we can actually write like symbol script and we can get back with there, but at 90 Seconds, then we embrace, what we embrace the infrastructure is called. So we use the telephone for like creating resources. And right now, this is the approach that we use to create cluster and at 90 Seconds. We write on telephone modules and then we can use it across multiple teams. So each team can just like take their telephone modules and they can create the cluster for themselves and test various Google. And the next part is we also use HEM to deploy the application in Kubernetes cluster, including their services from the data team. So for who doesn't heard about HEM, HEM is a package manager for Kubernetes, so that HEM is just a way to conventionalize the deployment. So you can imagine something like in HEM, we have a set of templates and we have a set of values. So for each of their environment, I mean, like for example, for staging environment and for production environment, we have a set of value. We have a set of different secrets. And at the deployment time, we just apply a set of value into the set of like to create a Kubernetes manifest and we deploy. So, and also it provides us the ability to like rollback the deployment in case something went wrong, for example. And for the secret management and at first we use the Kubernetes secret for secret management, but then there's something that they show that not all of us have the knowledge about Kubernetes. So not everyone prefer to use like keep secret to create a secret as well. So that we choose Vault as a replacement. So in Vault, then we can use the UI to update the secret so that it's ready for the UI to everything, even though they are not from the technical background, they can still even use the UI to update a secret that they want to. And next one, I want to talk about like RPG airflow. Like airflow right now is really important service at 90 seconds. So airflow with us is like the new ground is a game changer as well. Since introduced, then airflow has become a crucial part of our system so that with airflow we can create a really effective workflow to solve a lot of business requirements, which before that we need to have some guys need to manually do it. But right now with the airflow, we can finally fully automate those. This is one of the features of the airflow that we just successfully rolled out recently with the airflow version 1.10.1.10.3. So this is a Kubernetes executor. So with this feature, then we don't need to reallocate or recreate the worker for airflow anymore. So every time we have a new task, then the airflow scheduler, we just call the Kubernetes 8.0 server to create a port that runs that task. And then it will be terminated after the job finished. So the setup is really clean and simple right now, only the scheduler and the web. And one more feature that I want to mention about airflow is the Kubernetes operator, as we know that airflow is written in Byfun. And then after us, then we somehow expect that all of the developer will know about Byfun, they need to write a DHE with Byfun. But with the Kubernetes operator, then the developer can choose their own language, choose the language they prefer. They can write on anything like Go, Ruby, Byfun. As long as the service they write is packed into a local image. And then we can just use that local image and run as a DHE task. The second point I want to talk about is the high availability in Google Cloud Platform. So in the GKE, then the master node, the SLA of the master node is like 99.95%, so it's quite high. So we personally haven't made any big outage with the GKE at all. So our work is like really safe when running on GKE compared to like running our in-house Kubernetes cluster. And also the version upgrade is quite easy as well. Just like click a button on the Google Cloud UI, that's all. And this is one of the advantages of GKE over the self-built Kubernetes cluster. I personally faced an issue with my previous committee, then it's really hard to upgrade a Kubernetes cluster. But now things is quite easy and I have a lot of more time to focus on other workloads. And since the application is deployed on Kubernetes, then it's like it's sometimes quite high because you don't need to worry about when it's dead and how to restart it because Kubernetes already takes care of it. The third one is the cost. We use the preemptive instances for our staging clusters. Maybe in the future we can use the preemptive for production as well, but not now. So the initial idea of the preemptive instances is that you can have the same amount of compute resources with the cost of five highlights than the all-demand instances. So it's quite cheap if you use the preemptive instances for the test cluster because our staging cluster should not be available, it doesn't be necessary to be available for 100% of the time. And GKE also allows us to make the most out of the resources we have, like right now I can run the FLO cluster among the other ones as well, like for example the cluster that we run FLO, we have like five more services. So yeah, the utilization is quite okay, like around 70 to 85 cents, which is quite good. So we don't waste the idle resources. This is maybe a bit out of scope, but I'm not sure what to mention about the default setup. Right now, the FLO is also one of the important services for us, like it keeps every kind of secrets that we have right now, so that we need to ensure that the VOL setup is high at reliability. So we deploy VOL in three different ACs so that in case one AC gets down and everything is still working as normal. And this is the overview of the deployment of FLO on Kubernetes. As you can see, the Kubernetes executor will create a job on demand and depend on how many resources we have then we can entirely scale to infinity. And the next part I want to introduce now is to go a bit inside the video intelligent and some of more use cases in the data team. Thanks, Tsoi. I'm Nasser and I'm a machine learning engineer in 90 seconds. So thanks to Tommy and Aaron B, who built the infrastructure and foundations we were able to leverage AI and machine learning to give impact to their business. Yeah, so we have a lot of video data, eight years, 160 countries, 3,000 videos, 40 terabytes of video. The structure data that we have is the video brief, it creates this involved industry. And unstructured data is a video. So we use the video intelligence API to extract structured data from the unstructured videos. So the first application we built is a video search engine. So it was with that much data, it's crucial for producers to be able to find relevant videos that they want to make. So what we did was we combined the structure data that we received from video intelligence and now users can search videos by supplying an object. So once you have the object, it also returns, there are videos that have these objects and what you also have is the time that these objects appear in that video. So for example, you could search for smartphones or sunsets and then you'll get a video that contains those items as well as whatever filters that, such as industry. So this is the architecture of how we made it happen. So we use the video intelligence API that goes to BigQuery, then we work with Elasticsearch and then that goes into our 90 seconds platform. So another application that we use is video performance. So what the problem was that once the video goes into production, the brands need to know how well the video is performing. So that includes like whether there's a viewer should drop off or which scenes or which shots are unpopular and which could cause the viewers to stop watching. So now with the data that we received from video intelligence as well as our Google AdSense, we could identify certain entities or certain shots that could be traded to improve the video performance. So we could recommend actionable insights with this tool. Sorry. So this is the architecture of how we build it. So similar to the video search engine, so we just combine with the AdSense and the YouTube API and then that goes to BigQuery, then that works with Elasticsearch and that goes to our platform. So we also build a recommendation engine. So why it was important was that we need to give the right jobs to the right people and also vice versa, the right people to the right jobs. And then we also need to make sure that when we do have new creators joining in the platform that jobs were also given to them so there was no bias involved. So previously the process of how we gave jobs was manual. So we had a producer manually finding creators to fill a job. So now with this recommendation engine, we take a certain metric so we could figure out how relevant a certain creator was to the project, so whether he has done it before or whether he has done similar projects before, so then the recommendation engine would recommend that creator. So it has become almost automated. So that's it from us. It actually kept it short, so maybe you have any questions, feel free to ask. Do you run any transcoding? Sorry? Do you run any transcoding? Yeah, so the question was whether we ran any transcoding. That's right. We currently run transcoding service only for the premium customers. I'm sorry, they request for it. Is transcoding going to use this? The transcoding, do you use graphic changing like GPUs or is it just pure or is it pure? So currently we call it some API to do transcoding, but I'm not sure what their infrastructure is. Any other questions? Thanks. Thank you so much, Adam, Raju, then I'm coming. So we just have two talks left for the evening. We already have our speaker for the next talk here. So this is Daniel Poole. He's going to be talking about transforming pets to cattle with infrastructure as code, very interesting title, I guess. And Daniel is the lead engineer for DevOps and architecture at Vigo. He's done a lot of talks. You, if you're a part of some of the other meetup groups as well, you might have come across Daniel's talks. And Daniel, so we asked, we basically asked Daniel to write a little bit about himself and he kind of wrote this up and it's a little bit of a tongue twister, so I'm just going to read it out for you all. Daniel likes building stuff for people that builds stuff to empower them to build stuff better. So what would you do for this talk? All right, thank you guys. Give me a second. Let me just set this up. My name is Daniel. I'm from Vigo and I've recently taken a position of lead engineer of DevOps and infrastructure. So what I want to talk about today is about transforming pets to cattle using infrastructure as code. So a couple of speakers that have just spoken have been talking about infrastructure as code and then the importance of it. So I would like to dive a bit deeper into that as well as do a live demo. So this is just an overview of what it's going to be. A lot of it is going to be quite visual when we run through the code as well to see the effects of the demonstration. So just...