 Terima kasih banyak untuk menghubungi talian saya. Jadi, sebenarnya saya mencoba untuk menghubungi... Nama saya adalah di Google Translate. Saya harap ini benar. Saya harap ini tidak menghubungi sesiapa-siapa di sini. Jadi nama saya adalah Gio. Ya, ini cukup jauh. Jauh dari Giovanni. Ini sebenarnya nama italian, tapi saya tidak mempunyai nama italian. Jadi, saya sebenarnya datang dari Jakarta. Ia berada di sekitar 3 jam dari Jakarta. Ia tidak terlalu jauh. Saya tahu bahwa beberapa orang dari jauh sangat jauh. Seperti 20 jam atau sesuatu. Maaf untuk itu. Jadi... Pada latihan saya, saya sedikit tentang latihan saya dulu. Sebenarnya saya bekerja di rumah software, sebagai developer software. Mereka kadang-kadang menghubungi konsultan IT. Dan saya bekerja di perusahaan. Saya bekerja di perusahaan. Kita membuat aplikasi B2B. Dan saya tidak ingat ketika saya menggunakan Ruby. Tapi saya ingat versi pertama dari Ruby dan Rails yang saya ada. Saya menggunakan. Saya rasa itu adalah 187, 1.8.7. Dan saya menggunakan Rails 2.3.4. Jadi, jika saya melihat release di sini. Saya rasa saya berada di sekitar 2009. Seperti April untuk Ruby. Dan Rails itu di sekitar September untuk Rails. Jadi, itu bermaksud... Ini sebenarnya merupakan 10 tahun saya di universitas yang menggunakan Ruby. Jadi, sekarang saya bekerja di Gojek. Mereka akan mendengar jika... Jika aktivitas kamu di Surat Asia. Gojek seperti... Ia hanya sebuah perusahaan yang benar. Kita hanya memiliki perusahaan transportasi seperti Uber. Tapi itu berubah banyak. Kita juga memiliki perusahaan makanan. Kita juga memiliki perusahaan logistik dan sebagainya. Dan juga di Thailand, kita memiliki Get. Jadi, itu sebenarnya di perusahaan yang berbeda. Tapi kita dari perusahaan yang sama. Ini disebut Get. Jadi, ini sebenarnya screenshot untuk Gojek. Jika kamu di Jakarta. Karena di Jakarta, kita memiliki... Banyak-banyak lebih banyak perusahaan. Sementara menggunakan mesej. Mereka memiliki perusahaan. Jadi, kamu bisa memilih medan dari aplikasi. Jadi, itu sebenarnya... Banyak aplikasi di satu aplikasi. Jadi, saya bekerja di Gojek sebagai perusahaan sistem. Ini adalah tim saya. Jadi, satu yang berada di kanan saya adalah... Ajay Goree, CTO. Mereka tidak dapat membuatnya pada konferensi ini. Ini adalah gambar dari tahun lalu. Apabila kita berbicara di Depth of the India pada masa itu. Saya rasa banyak orang di Gojek menyukai Ruby. Kita menggunakan Ruby di... Banyak-banyak... Banyak-banyak... Ruby adalah salah satu perusahaan yang menggunakan 5 atau 6 perusahaan. Saya ingat bahwa GoFood... Banyak-banyak perusahaan ini dibuat di Ruby. Saya ingat bahwa GoFood adalah salah satu perusahaan yang menggunakan di Jakarta. Ruby mungkin adalah sebuah pelajar yang membuatkan... Mereka sangat berjaya. Saya juga menggunakan perusahaan Ruby di Jakarta. Dan konferensi. Ini adalah gambar. Jadi, kita sebenarnya memiliki... Perusahaan Ruby di 2017. Dan kita akan melakukannya lagi di tahun ini. Sebenarnya pada akhir ini. Mereka adalah sebuah pelajar. Kita juga meminta Akira Matsuda untuk datang. Jadi, ini akhirnya. Maksud saya, sebenarnya tidak banyak tentang Ruby. Tapi saya berharap bisa tetap mendapatkan bahwa ini. Karena... Kubernetes. Mereka telah mendapatkan bahwa ini. Tapi, beberapa orang tahu bahwa ini. Jadi, saya akan berbicara tentangnya. Ini adalah gambar saya. Saya akan berbicara bahwa ini. Bagaimana untuk menggunakan ini. Dan bagaimana untuk menggunakan perusahaan kamu dari menggunakan ini. Biar saya beritahu kenapa. Pertama, saya akan berbicara tentang disclaimer. Saya tidak ingin menggunakan teknologi. Jadi, saya pasti bahwa Kubernetes adalah teknologi fantastik. Dan kita menggunakan Kubernetes dalam perusahaan. Dan... belajar sesuatu yang baru adalah selalu sesuatu yang baik. Jadi, itu tidak terlalu teruk. Jadi, jika Anda memiliki teknologi baru yang akan datang, itu tidak terlalu teruk untuk belajar tentangnya. Dan saya berbicara bahwa ini sebenarnya bagus. Dia sebenarnya, setelah beritahu saya untuk menggunakan Kubernetes, dia tanya saya untuk menggunakan perusahaan saya. Dan saya berbicara tentangnya di RubyKaigi. Pada tahun ini. Tapi, ini sebuah kisah untuk sebuah pertanya. Dengan cara itu, mari kita berbicara tentangnya. Apa adalah perusahaan terakhir dari perusahaan? Kamu tahu? Kamu tahu bahwa ini sangat terutamanya bahwa kamu berkata kepada bosmu. Tapi itu berhasil pada masin saya. Saya tidak tahu mengapa itu tidak berhasil pada masin klien kami. Jadi, perusahaan tidak seperti ini. Apabila mereka membuat sesuatu di box mereka, mereka ingin lebih mudah dibuat dengan semua orang. Mereka ingin hal ini. Apabila mereka membuat sesuatu, mereka ingin lebih mudah dibuat dengan semua orang. Kemudian, jika kita jauh satu hal lagi, kamu ingin melakukan web scale ini. Saya tidak tahu jika ini terma atau tidak, tapi saya ingat bahwa untuk tidak menjadi web scale. Saya tidak tahu mengapa itu berarti. Jadi, saya menyebutnya di sini. Web scale. Kemudian, apa yang kita ingin juga adalah dynamic scaling. Maksudnya, perusahaan terhadap hari dan malam itu berbeda. Kadang-kadang, kadang-kadang, itu berhasil. Apabila itu berhasil, kamu tidak ingin memberi banyak duit untuk infrastrukturmu. Apabila perusahaan berhasil, kamu ingin lebih senang memperkenalkan kapasitasmu untuk mengandalkan perusahaan itu. Jika kamu bercakap tentang kubinitis, kubinitis mencoba memasukkan itu. Tapi itu adalah projek yang sangat besar sekarang. Itu memasukkan banyak perkara lain. Tapi saya akan fokus pada ini sekarang. Jadi, apa yang kubinitis itu? Saya menemukan terserah-terserah ini online. Sangat mudah, tapi itu sangat bagus. Apabila kamu ingin mengatakan konsep yang susah untuk orang lain. Jadi, itu sebenarnya seperti sebuah box teks yang akan diketahui. Jadi, kamu harus mengatakan idea, idea yang susah hanya menggunakan kekuatan yang paling common. Jadi, saya mencoba, saya mencoba ini untuk mengatakan atau mengatakan tentang kubinitis. Dan saya... ini yang terbaik yang saya bisa lakukan. Saya tidak tahu kenapa, tapi software sebenarnya tidak... satu... 10.000 kekuatan yang paling common di Inggeris. Jadi, itu sebabnya, software yang diketahui. Tapi lainnya, itu okey, kan? Jadi, itu sebenarnya ini. Kubinitis ini software yang membantu kami untuk mengajar banyak komputer. Jadi, kamu ada banyak komputer. Dan dari perspektif developer, kamu ingin hanya... kamu ingin hanya memikirkan seperti komputer yang sehingga. Untuk memikirkan pekerjaan. Jadi, itu... itu definisi yang saya dapat mengalami tentang kubinitis. Sebenarnya, ini merupakan seperti kubinitis yang penting. Ini bukan... bukan perkara baru. Kita memiliki ini seperti 30-40 tahun lalu. Tapi, apa kubinitis yang penting untuk kubinitis? Pertama, elasticity. Sudah tentu. Saya berbicara tentangnya, seperti seketika. Request bisa bergerak atau bergerak. Jika kita... jika itu bergerak, kita ingin dapat mengandalkan. Jika itu bergerak, kita ingin menghilangkan kemampuan. Kemudian, kita berbicara tentang kemampuan resursi. Kamu tidak ingin memikirkan hardware fisikal di belakang. Seperti developer, kamu hanya ingin memikirkan sebuah resursi besar dan kamu ingin memikirkan workload. Kemudian, ini sebenarnya kubinitis saya. Jadi, kubinitis memiliki api. Sebenarnya, kita harus memikirkan file YAML. Kemudian, kita akan memikirkan file YAML dan memikirkan kontainer yang berdasarkan file YAML. Kemudian, ini kemampuan resursi optimal. Jadi, jika kita tidak memiliki sesuatu seperti kubinitis, kamu harus memikirkan lebih banyak VM. Kadang-kadang, kemampuan di VM tidak sangat kemampuan. Di kubinitis, kamu bisa memikirkan banyak kontainer yang mungkin menjadi satu node. Saya akan bercakap tentang kubinitis ini. Tapi sebelum itu, pertanyaan adalah, kubinitis hanya seperti solusi yang hanya menolak masalah ini. Sebenarnya tidak. Karena ada banyak solusi yang lain, seperti tadi, kamu mungkin tahu doker Swarm. Kemudian, kita memiliki mesos, nomad, frencher, dan juga, jika kamu ingin memiliki Amazon ECS, kubinitis kontainer, dan Heroku. Sudah tentu, jika kamu menggunakan Ruby atau Rails, kamu mungkin tahu tentang Heroku. Itu sesuatu yang sama, yang kamu ingin memikirkan kubinitis tanpa memikirkan kubinitis. Tapi sekarang, selama dua tahun, kenapa kubinitis lebih popular? Jadi, saya hanya mendapatkan kubinitis ini sebenarnya pagi. Ini sebenarnya kubinitis yang lebih popular sekarang. Jadi, jika kamu tahu IKEA, kamu selalu mendapatkan kesempatan kesempatan, apabila kamu memiliki sesuatu dari awal. Walaupun, jika tidak terlalu bagus, kamu tetap akan memiliki kecil-kecil. Jadi, saya rasa itu sesuatu seperti itu. Karena kubinitis, itu bukan sesuatu yang kamu bisa menggunakan segera. Kamu harus belajar banyak perkara sebelum kamu bisa sebenarnya menggunakan kecil-kecil di produk. Jadi, itu sebabnya, ada kesempatan saat kamu berhasil menggunakan kecil-kecil dan menggunakan kecil-kecil. Tapi jawapan seriusnya itu, mungkin karena kubinitis itu dibuat oleh Google. Jadi, Google memiliki produk kecil-kecil ini sebelum mereka memiliki kubinitis tanpa memikirkan. Dan setelah itu, seperti beberapa prinsip, sebuah pembentangan, seperti Red Hat, seperti VMware, dan Microsoft, mereka menggunakan kecil-kecil dan menggunakan kecil-kecil. Dan mereka membuat komunitas di sekitar itu. Jadi, setelah prinsipnya datang dan komunitas membeli idea itu. Jadi, tapi itu sangat lucu, karena jika kita memiliki solusi yang berhasil sebelumnya, kubinitis itu sebenarnya hanya seorang yang memiliki memiliki pembentangan yang sangat kompleks. Sebelumnya, kamu bisa menggunakan produknya. Jadi, tentu saja jika kamu tahu doker, kamu mungkin tahu kubinitis doker atau mungkin rancor. Sebenarnya lebih mudah untuk menggunakan solusi yang lain daripada kubinitis. Jadi, saya pikir saya memiliki sebuah hal. Saya pikir pembentangan seperti Challenge. Jadi, mereka tidak sebenarnya memiliki sebuah hal. Mereka hanya memiliki pembentangan. Tapi, sebenarnya, kubinitis itu sangat lucu. Sejauh jika kamu tidak memiliki produknya. Karena, bahkan di Gojek, kita melihat beberapa masalah sebelumnya. Sebenarnya, itu sangat menarik, bermaksud pembentangan kubinitis. Jadi, mari kita berbicara bagaimana kubinitis sebenarnya berhasil. Jadi, kubinitis itu sebenarnya sebuah sistem budaya. Jadi, itu berhasil dari beberapa komponen. Itu tidak seperti sebuah software yang bisa kamu install dan membuat sesuatu dengannya. Ini adalah beberapa komponen. Jadi, jika kamu memiliki komputer, kamu harus install sekurang-kurangnya komponen ini. Pertama, kamu harus install pembentangan kubinitis di CD. Itu seperti database. Kemudian, kamu memiliki pembentangan kubinitis. Kemudian, kamu akan berkongsi oleh manajer kontroller. Ini adalah komponen dalam kubinitis yang berhasil untuk memastikan apa-apa yang kamu ingin kubinitis untuk dilakukan, itu akan mengisi. Seperti misalnya, dalam manajer kontroller, mereka memiliki kontroller yang dipanggil perbalikantin. Jadi, misalnya, jika kamu ingin mengasuki pengluar, dan kemudian kamu ingin membuat replika dari 1 ke 3. Seperti, kamu memiliki keadaan besar, keadaan besar, kamu ingin memiliki replika. kembali ke 3, yang sebenarnya yang akan digunakan adalah kontroller manager. Jadi itu seperti berbeda dari kubernetes. Dan setelah mengubah state dengan langsung, kontroller manager akan menghubungi APSR. Jadi itu micro-service sebenarnya. Dan mereka juga ada scheduler. Jadi apabila Anda memiliki kontainer, kontainer itu harus dikejul pada satu dari komputer lain. Karena kita harus menghubungi kompleksiti dari hardware fisikal dari developer. Jadi itu sebabnya, instead of the developer doing it manually, it has to be the scheduler who do it for the developer. So the scheduler will put the container into appropriate computer. So this is what we call the controller plane. And then this node, this computer, we call it the master node. So we don't usually put any production container inside this master. So we have another computer. In this other computer, oh sorry, before that the master, we can increase number of master, like more than one. The reason is that if something happens to the first master, the other master can easily take over the first master. So that's for achieving reliability and resilience. And the other computer that you have, the one in color in blue, you install something different. It's called the kube lab. So kube lab actually contact API server and it ask for any container that it has to schedule on that particular computer. It keeps asking, like, do you have container that I have to run on this computer? If there is a container which needs to be run on this particular computer, it will contact the runtime. So the runtime is docker basically. You can change it into anything, something else. Like you can use CRIO, there are several actually. But maybe most of people familiar with docker. So it will contact docker and then it will run container in the worker node. So it is called the worker node. So we also have other component, it's called the kube proxy. So it will actually handle the communication and the networking. It will actually modify the IP tables in real time to ensure that the pods, the containers, the nodes and everything can connect with each other, can communicate with. We can also have several worker nodes. Like if you have like 100 computers, you have 1000, you can do it. You can increase as many as you want. As long as, I mean like, we are doing this so that the developer does not need to know how many hardware that we have. So they can just assign, keep assigning, like creating containers into the Kubernetes. And we control Kubernetes via CLIM. So it's like a remote control. There was a joke actually on how to pronounce the CLIM. So it's actually, we usually call it the kubectl because it's called the kubectl. So it's like a remote control. So it's like this. You can run kubectl from your own personal computer from your own laptop. And then you have to configure the access appropriately and it will contact the API server. Let's go through each scenario to understand more about this. I talked before about the Uniform Declarative API. So what is this about? Basically, if you're talking about Uniform Declarative API, we as a developer create a YAML files. This is an actual YAML file that probably can work if we run it. We send it from the kubectl. It will send it to the API server. And then the API server will, and the control manager and scheduler will work to ensure that this job, this workload is running on one of the worker. So that's the concept. And then if you're talking about resource abstraction, I've already talked about this several times. So actually, whenever we do something by this remote control, we have to understand what actually happens in the worker. So as long as our workload is scheduled or put somewhere, then we're good. So that's the abstraction of resource. And we're talking about elasticity. This is my favorite part. So with this, you can do actually this. So when the traffic increase, you create more containers. If the traffic decrease, you reduce the container. So you can do cool automation like this to handle your load. And obviously, the most very important benefit, optimal resource utilization, you can see that the containers are quite dense. You can create as many containers as you want, as long as it doesn't reach the limit of each node. The reason for doing this is that usually if we have microservice architecture, the workload will vary. Some services will get higher load than the other. So that's why it is very optimal if we can just spawn containers as many as we can into one particular node. So from what we've seen so far, it seems wonderful. So the question is, why should I discourage my boss from using one? So why should I? So let's see. So if you're talking about technology, choosing tech, choosing tech is hard. So because we're an engineer, if we are under-engineered, it means that we will lose opportunity. So there are a lot of traffic coming in and because our solution is under-engineered, we cannot handle all that traffic. But if we do over-engineering, it means waste. We spend a lot of time or money or resources to do something that is not very useful for the customer. So actually, today I'm going to talk about that we need to have principles. So what are principles that I'm talking about? So what I believe now, currently, there are things that needs to be avoided for as long as we can when scaling. This is actually quite interesting. Let's see, for example, the first one that I want to avoid is using code. If you don't know before, but Gojek was actually a call center for four years before they create their first app. So they don't actually have any app. They want to gain traction first and after that, they decided to create an app. So it's very interesting. So there's actually a website called makerpad.co. It is like a community which creates something without writing any code at all. This is not the only one. There are several communities which do something like this. Very interesting. And then next, we're talking about managing state. Managing state is very hard. Managing our own database is very hard. For as long as we can, my belief is we should avoid it. If it's necessary, then we should do it. And then going one level above is casing. It's a problem of computer science, casing validation. So it's hard. And then sharding. It's a different level of complexity altogether. You want to separate your load from each different type of request. It's even harder. And obviously, what I think should be avoided for as long as we can is building or operating a distributed system. For example, migrating or operating and maintaining Kubernetes. Because Kubernetes, as you can see from the previous description, it's actually a distributed system. Like a lot of moving components, a lot of things that can break. And distributed system is subject to the eight fallacies of distributed system. So these are the eight fallacies. So what does it mean? What does it mean that a system is subject to this? You don't actually have to think about this before when you have a monolithic architecture. But now that you are subject to these fallacies, you need to account for this stuff. You have to become basically a network engineer. Because most of the thing that you see here is related to network. And it's true. When I operate Kubernetes in my company, I have to learn a lot about network. And also about security. Because we need to discuss about the communication between each component. And the other thing is if you're talking about Kubernetes, it's not enough to just use only Kubernetes. You have to account for all of these landscapes that Cloud Native Computing Foundation has. Kubernetes is only a small part in their life. Then you start to think about say, for example, the surface discovery. You have to think about the surface mesh. You have to think about, let's see logging. Logging is different now if you're talking about Kubernetes. You're talking about monitoring lots of components that needs to be monitored. The complexity starts getting really high. So I would recommend to you if you want to decide if you want to use something like Kubernetes or not, to ask this question. First is what is your app usage characteristic? How is the traffic? How is the distribution of the traffic? Is it like dynamically distributed? Is it like have very high traffic during the day and then very low traffic during the night? You need to scale very quickly up or down. Do you have lots of services to deploy? Like, are you using microservice architecture? And then this is also very important. How many people do you have? Do you have a dedicated systems or ops team? Because if you want to maintain Kubernetes in your team, you need to have this. If not, are you willing to build that team? And then do you absolutely have to avoid vendor lock-in? Because other Kubernetes, there's actually a very good solution out there, like HeroCube, for example. You can just use it and forget about it. You don't have to think about the deployment stuff. And then you absolutely have to squeeze that last drop of performance. For example, you need to maintain your own data center and you need to account for your expense. So if the answer is mostly no, then probably adopting Kubernetes is not really necessary. So I have a LDR version of this presentation. If you don't know this person, this person is actually quite famous in the Kubernetes community. He's one of the advocate for Kubernetes. So he actually said this. So he's one of the advocate from Google but he actually said this. And he actually also said this. You can get Kubernetes faster easily. But there's nothing easy about what's required after that. So wrap up. If you really need it, if you understand what you need, Kubernetes is great. But if we're talking about building a solution for your customers, don't under or overengineer. Instead, I will propose that we need to always have a migration plan. So what does it mean? For me personally, optimizing for change, it yields the best returns. So overengineer or underengineer is not good, but if you invest all your effort optimizing for change in your code base. For example, if you have a code base do a modular, write your code in modular fashion, do the domain driven design, do separate by bounded context, things like that, optimize for change, make it modular so that it can easily be refactored later. It yields the best return. And then please, before doing any kind of major migration or change, always ask the important questions first, to you or to your boss. For example, previously when we were talking about Kubernetes these are my heuristic wherever we need to adopt Kubernetes or not. You need to have this kind of heuristic before you decide to adopt a new technology or not. You need to also account the technological team. I really like this. I get it from the ThoughtWorks. It's a wonderful company. You might know some of the person who works in ThoughtWorks. They create a lot of books. This is called the Technology Rather. So they categorize technology that they want to adopt into four. Adopt, trial, assess, or hold. It's really wonderful. And then maintain architectural decision records. So, whenever you make a major change you can Google this, whenever you make major change you need to keep it as a record and then people can benefit from it. I think that's all folks. Thank you very much for...