 Baiklah. Selamat pagi. Saya rasa ia sedikit terlalu awal bagi kami. Okey, nama saya Kenneth. Saya dari Jungle Element. Saya CEO dan co-founder dari Jungle Element. Jadi, apa yang Jungle Element lakukannya adalah, kami membangun kelebihan artifisian untuk syarikat. Kami berdua berdua bersama dengan Microsoft. Selain itu, sebelum saya bermula, saya suka berkongsi cerita saya. Saya rasa untuk orang yang pernah dengar sebelum ini, saya akan berdua bersama dengan saya. Saya datang sekejap. Saya pernah bekerja di Microsoft. Sebelum itu, saya sebenarnya melakukan penjelasan kelebihan di Indonesia. Jadi, hal yang saya lakukan adalah, saya sebenarnya melihat kelebihan di Indonesia untuk sistem ekosistem partner di Singapura. Saya menjadikan kepada kelebihan, SME, startup dan sebagainya. Untuk menggabungi kelebihan di Indonesia, kemudian dari portas klasik kemudian ke dalam portas baru. Kemudian, saya pergi ke KSAT, saya mengubah degree komputer saya dan saya mengubah beberapa penjelasan dengan Hitachi. Jadi, salah satu fokus saya adalah tidak hanya komputer klasik. Komputer klasik adalah pengalaman saya, tetapi saya juga mempunyai kelebihan kelebihan. Ia sebenarnya melakukannya ke janggaran janggaran, menjadi penjelasan AI untuk apa yang kita lakukan. Untuk penjelasan chat. Jadi, banyak kelebihan yang kita lakukan di atas KSAT dan saya rasa itu adalah salah satu perkara yang saya ada di sini juga. Okey, untuk serverless, saya biasanya tanya ini pertanyaan. Berapa banyak orang yang pernah melakukan serverless di pejabat kerja? Olim Peter. Okey, jadi sesiapa pun ada idea apa serverless ini? Okey, jadi saya rasa ini adalah salah satu perkara yang orang bercakap tentang serverless dan bagaimana yang kita lakukan. Untuk sesiapa yang anda tak dapat melihat. Sebenarnya, apa yang dia katakan di sini adalah... Kalaulah, orang ini di luar, dia seperti... Tidak mengalami dan kata, ayah, biarkan saya masuk. Kemudian, orang ini adalah penjelasan server. Kemudian, orang ini... Dia nampak seperti pelanggan atau pelanggan. Dia kata, oh, saya tahu yang ada server. Kemudian dia kata, oh, ada pelanggan dan pelanggan. Kemudian dia kata, saya fikir kamu beritahu saya dengan serverless. Jadi, saya bermakna serverless sendiri tidak bermakna kita tidak mempunyai server, tidak mempunyai apa-apa yang menghargai. Sebenarnya, idea serverless adalah hanya penjelasan pelanggan kamu. Jadi, apa yang saya akan melihat dalam beberapa minit lagi adalah menunjukkan idea apa serverless itu sebenarnya. Jadi, dalam kes ini, seperti yang anda lihat di sini, ilustrasi sebenarnya bercakap dengan diri sendiri, apa yang orang ada dalam fikiran mereka apabila kita bercakap tentang serverless. Apabila anda balik ke pejabat dan beritahu boss, oh, boss, saya mahu bergerak ke serverless. Kemudian boss akan berkata, oh, tapi kita ada server, apa yang kita perlukan dengan serverless? Kemudian, kamu boleh beritahu boss sebenarnya, oh, itu bukan kes itu. Kami mencari pembunyian kaka-kaka tetapi di level yang berbeza. Jadi, bagi yang anda tahu dengan pembunyian kaka-kaka, saya rasa anda pernah melihat gaf ini sebelum ini. Jika anda tidak melihat, saya akan menjelaskannya. Sebenarnya, idea pembunyian kaka-kaka, kami datang dari jalan yang lama, kita bercakap tentang on-premise. On-premise tersebut adalah sesuatu yang dipanggil tradisional, sesuatu yang digunakan untuk membeli servis-servis setelah servis-servis. Dan sebabnya, anda sebagai perusahaan servis, anda sebagai perusahaan, anda mempunyai semua pembunyian. Anda dapat mengawal semuanya. On-premise virtualisasi adalah bagaimana kita bercakap tentang, mempunyai SCVMM, Windows Server 2016, menggunakan Hyper-V, dan menggunakan Spinnig-off. Sebenarnya, anda menjadi pembunyian kaka-kaka dengan menggunakan Spinnig-off di depan SCVMM. Jika anda bermain dengan SCVMM dan semua pembunyian kaka-kaka, anda merasa anda dapat membangun pembunyian kaka-kaka sendiri dengan pembunyian kaka-kaka sendiri. Di mana pembunyian kaka-kaka datang, kita bercakap tentang pembunyian kaka-kaka servis, pembunyian kaka-kaka servis, dan pembunyian kaka-kaka servis. IAS adalah di mana orang seperti Microsoft, Azure, AWS, IBM, mereka menolak pembunyian pembunyian untuk anda inventa pembunyian alsa-sasalah anda boleh membangun pembunyian, bagaimana yang saya mahu dengan pembunyi, cara saya mahu membangun pembunyi. Di pembunyi servis, saya menulis pembunyi Dulu, kemangu notification, pembunyi pembunyi, jika ia beri svara untuk lajkan pembunyi bahkan-bahan saya austrihatkan pembunyi saya untuk melanjutkan. Sekiranya, jika anda menikmati, Kita sebenarnya bergerak kemudian sekarang, software as a service where, Oh, hey, your job box, your one drive, You can actually use just the software, I don't have to be worried about like the backend system, the application control. And then I will say we are at the end user stage. Now where serverless comes in, serverless is again out of, it's technically out of these three tiers. Basically serverless is now the Azure Function where we call it a function as a service. Some people call it backend as a service. So that means right now, we are extracting the whole cloud computing, the idea, the paradigm shift into actually building up functions as a service by triggers. So actually like this, how they actually represent serverless way. You have a lightning and this bracket coding thing. So earlier we mentioned about on-premise for cloud computing, how you actually build. So if I think some traditional companies you're still moving into this way, traditional architecture where you have to build not just your system architecture, you have to start building up all these serverless and put information there. The very traditional way of architecting this is kind of like very tightly coupled together. If anything breaks, you know, you technically break up the whole system. We move on to microservice architecture where we're looking just at service itself. So microservice means that everything in an office service is one service on its own. So for example, if we're talking about paywall system, we're talking about like some management system, you definitely have common tools, common things that's running together. So user services could be like, I want you to do a login, I want you to do like retrieving my users, deleting a user. All these function be classified as one service itself. And that itself is your microservice architecture. And why are we so concerned about microservice architecture? Because if we move on to the new age of computing, if you think about it, everything is going to be big pieces here and there and you have so many moving parts. Microservice architecture allows you to build your system such a way that right now everything is in its own services. So if you want to update a particular service, let's say I want update user service, my developers can just focus on one set of codes and they deploy it whichever they need without affecting my other services. However, if we look at the traditional architecture where you know, you're building everything tightly coupled together, the monolithic structure, your applications are so tightly coupled together where if one development team had some bugs within, it can affect your entire system. So there's one thing that most solution architects are actually looking for to do is actually building up a microservice architecture to ensure that my services are loosely coupled, but yet at the same time, I'm able to control the dev ops between your services. Now what we're looking towards is server architecture. Now server architecture is slightly interesting because here we see microservice where everything is classified as a service. User service is one container on its own. Serverless architecture is where we break it up again. So it's like Lego blocks. One, I give you the whole Lego block and say, okay, this is your traditional architecture. Now I say, okay, let's break it up into the head component, your body component and the tail component. This is now microservice. Then we break it up even smaller. We say now the head component, let's break it up even smaller. This becomes your serverless architecture. What we're looking at is now APIs are now tied to functions. So earlier we saw that if I want to create a user, I need to call this user service architecture. Now for functions, what we need to do is actually write a certain function and do a trigger. So in this case, if let's say I want to do login or creating a user, but your functions actually handle that for you, meaning your entire application, you don't have to handle all the heavy load for your certain cause. Although this seems like a very simple idea, but if we go into the deeper technical architecture of let's say, I want to do storing, I want to do processing of information, you want to lift that heavy load and say, hey functions, do that for me. So this is what exactly serverless architecture does. Your API is actually pointing a trigger to a function which is on the cloud and your function will do that task for you, link it up to the database, do whatever it needs to and then return you a response. So in that sense, and your application, if you think about it, the API will be your Covenant Service Architecture. Functions will be the one that's sitting on the cloud. Heavy lifting is actually done on functions level. Your application will just do the processing, manipulation of data. Whatever that comes to you, you just handle. So in this case, if you think about it in the biggest scale, oh, serverless now becomes easier for you to code, easier for you to do things. So serverless computing is the next level of abstraction in cloud computing. So why do I say so? One is abstraction of servers, yes. Okay, we've talked about it, like how we abstract the servers into various small parts into functions. Two is event-driven skill. So event-driven, everything is driven by an event triggered by a function. So for example, let's say I want to trigger something 15 minutes, one a certain task. That is event-driven. It's driven by an event, event happening, I do this. Sub-second billing, this is a bit different from how Azure or AWS bills you. Usually when you spin off a VM, you're built by the minute, the seconds. Sub-second billing does is every execution you keep built at that level, seconds instead of like, I built this one whole chunk, everything's like page you go also. Now what we are looking at for serverless and how is it different is because monolithic applications are now loosely coupled applications. So we're actually looking at how we can actually break down these applications into various small parts and this becomes our moving parts within the cloud. Putting them all together, we're actually looking at events happening asynchronously outside your application. So usually what we do is build everything inside application. Right now we can talk about building things outside the application, everything is triggered by events asynchronously on the cloud, send back to my mobile phone, send back to my IoT devices and handles the information there. We're also looking at how we can actually build and use micro-functionalities to react to a single event. Complex framework, your huge complex framework, you're actually now breaking things down into a micro-functionality event itself. So what are the key benefits? One, you shift faster, definitely. Because if you think about it, now I have to handle less things, I have to think about lesser things and I can break things down into smaller items. If let's say you have to build an invoice management system, you have to start building all your logic all the way to the end goal that you're looking for, database and stuff like that. Service shipping faster means now with serverless, now with Azure Functions, what you can do is actually to build your business logic on different layers, whether it's on your codes or you want to put it on Azure Functions, it's up to you to decide what you're going to do. You actually reduce your DevOps in the process as well. And yeah, of course, last you can actually focus on the business logic. So in that sense, whether your business logic sits in your code or whether your business logic sits on the cloud on Azure Functions itself, it technically helps you to build codes faster, ship faster as well. So there's the pinnacle of your platform as a service compute where you're not just managing servers right now, you're actually focusing on the main thing. You're focusing on the building up the application, focusing on building up your business logic. So one way with this, you get lower effort to get started much faster to spin off as well. So Azure Functions, we're talking about four points, one, your development. So many developers you're wondering, oh, Azure Functions is on Azure, means is this C-Shop? Well, C-Shop is definitely there, but you have the freedom to actually code in other languages, node.js, PHP, Python if you want, batch.fowl if you want, F-Shop. So there are various languages that you can code on top of Azure Functions. Integrations is pretty much similar. Basically, everything is by event driven. So that becomes easily accessible, easily to develop and easy to put together. Your accessibility is where we are talking about how can Azure Functions allow and expose APIs for us to use. So it's not just sitting on the clock, you actually have APIs for you to actually connect to and to reach to your service. Scalability is where we scale the functions based on the demand. So in this case it's not just on the load we're talking about the demand of the functions and the events that's happening. So what does it look like? Azure Function is sitting like like this where you come from two points, input and output. Every input that comes in it triggers Azure Function and say that hey, there's a function that I need you to call. There's something I need you to do. Now possess the information, put it into output. In the other sense if you look at the other graph, it means that your application, your service will call or trigger Azure Functions whether it's on a webhook or whether it's on a HTTP trigger. You can actually do the following task whether it's to Office 365, you know, your office graph, Azure Storage, etc, etc. Today as we're looking into IoT devices, what we're actually looking at is you know, think about it. If IoT devices allows me to collect information from various places, sensory data, weather data, you know, I can collect even the IoT devices and even, you know, Microsoft build we're talking about IoT age where it's sitting right at your machine level. There's a lot of information that we can actually transmit out. Now, if I can transmit this information to Azure Function, which goes through like IoT Hub or IoT Hub to Azure Functions, what can I actually do with this whole integration together or together as one? So, one of things is Azure Function allows you to say that hey, you know, whatever information that's coming from IoT devices whether it's on my IoT or whether it's on my IoT device right now, I want you to send a periodic data every 15 minutes ping me whether it's my device alike or not. Or two, you know, every time when you collect a sensory information real time, you send it to me. I want to see on my dashboard, for example. Instead of going through, you know, all your web service and whatnot, you can actually tell your IoT devices hey, now I want you to send this information to a service bus trigger. Let the service bus handles the information on Azure Function. When Azure Function is done with that trigger, pass the information to IoT Hub, pass the information to notification Hub and then get the information back to me. So in that what we're looking at now is actually abstracting our design of building an IoT device or application at different levels, architecting it in such a way that hey, right now I'm focusing on a couple of things. One, I'm building my IoT. Two, I'm actually allowing my web service to actually handle that for me on Azure Function. And three, the integration itself is kind of similar because we're running everything on Azure. The integration is just by is vessel APIs. So when we talk about event driven model earlier, this is what it means. It means that server's implementation is actually an API function where your application is calling the Azure Function with HTTP trigger. It can be a web pool trigger like we've mentioned earlier. So your application could also be your IoT device, for example. And once the function executes behind the scenes, it's then responded if it turns a response and a response goes back to your device or your application. So in that sense if you think about device, now if you're building a huge application, a huge moving design platform, for example, you want to reduce the load that is running on your application. Why do you do that? Because I don't want my application to be running all the load all the time because in that sense I'm not being productive. If you're releasing an application, for example, you're doing a huge data processing. You don't want to be processing data or training your machine learning everything on your application itself. You want to send the information and say hey, Azure Function has this very huge data I need to be processed. I need to probably convert an image or convert a video into an image frame, for example. Send the information to Azure Function and say hey, do that for me. So in that sense you're actually handing the workload to the cloud to do it for you. When it comes back to you and say that hey, I got this response it's now stored at a blob storage. It's now stored at your SQL pick up from there. I give you the link. And which means now your application is very lightweight because maintenance whether it's it for deaf ops purposes, you're actually streamlining and pipeline everything into it's blocks. Block A I do this, block B I do this, block C I do this and it's scalable. If you think about it if I'm if I'm a developer it's scalable. Anybody comes in I can say hey, look at this Azure Function. Hey, you look at this quotes. Business logic wise clear whereas traditionally your developers come in look at whoa, there's so many things and you learn so many documentation I need to read. So this is one way that Azure Function can help you to reduce your deaf of time your videos a lot of things and how we should faster. Now, this likes a bit more of the overview of what Azure provides. As we're looking into IoT devices, there are a lot of things, you know that that comes into play where you can integrate to build a more holistic application. So for those of you looking at enterprise level, there's like logic apps, there's app service, there's there's lots more. You can go and check it out. Okay, I'll skip this. So okay, for quick overview basically what Azure Function architecture is built on top, it's actually your web jobs SDK. So web jobs is like it's like a job that's always running. You can actually take the SDK, code it on a C-Sharp, code it on Node.js, code it on Python. You can build the same thing on your local development level. So the idea is actually you know the web web job scripts we actually call a trigger, receiving input and output and handles your codes from there. Okay. Serverless or Azure Functions actually dual abstraction. One, your serverless compute actually abstracts away the compute. So in this case right now we're not talking about computation cycles in terms of VM, but we're talking about how we can actually put the compute cycles on Azure Function as an event itself. Two, your bindings will abstract away the services that you interact with. So bindings are really interesting on Azure Functions or at least on serverless itself. Bindings are things that you can actually bind to whether it is it in to your third party services like Twilo, third party services to drop box. You can also bind that to Azure Functions or Azure services like block storage, queue storage, service bus, etc, etc. So in this case what we're looking at is now my serverless platform as a service my business logic comes in at Azure Functions and my other services can bind and sit on top of whatever that I need to build. Very simple. This is an overview of what we're talking about when we build Azure Functions functions programming concept. The idea is one if in node.js I have my trigger. So the trigger actually receives that trigger from HTTP or where is it from webhook saying that hey there's something that's coming in process this information. Input receives that input and say that hey this is the data that you have. I need you to process this information on functions. Do the output return the output. So what we're looking at is is an overview of this but we're looking at different services. So bindings when we talk about how we can keep bind to different services. This is something that that you know gives us a a better idea of what what's happening. So we have HTTP you know whether it's a vessel API or whether it's webhook you can actually bind to like Bob storage events queues storage table et cetera et cetera and then we have like SQL table SQL so again you can bind to external services toilo SMS sanggwit so if you think about it right now if you want to be productive in your workplace for example and and you as developer you want to do something cool right so every email that comes in sometimes you know you're so busy you miss out certain email and you want the email to be pushed to your SMS for example so you can say okay I'll I'll do Azure Functions for that probably you know when an email comes in I put it into a Microsoft flow Microsoft flow triggers an event send it to Azure Functions Azure Functions send me an SMS you could design in such a way that every time an email comes in you'll receive an SMS of course I mean now there's there's so many platform and tools to do that but I mean if you want to hack it on your own that's something that you can do okay platform and scaling this is a bit more on the Azure pricing site like what are the things that Azure Functions provide so app service is dedicated there's there's two tiers one is dedicated and one is the dynamic tier the dynamic allows you to pay per the number of executions so how they calculate the executions basically by executing your functions or on on the Azure function and that platform itself is responsible for the scale whereas for app service you are responsible for the scale yourself so usually people if you want to start very small scale you don't need to run like a million over triggers or million over executions you know dynamic will be more than sufficient so this is the dynamic tier tier pricing basically the number of execution we're talking about the duration of the execution how long it takes to execute and stuff like that and usually you know if you are not doing anything too computational intensive these you take in a couple of seconds but if you're doing something computationally intensive you might want to look at like okay what are the things that you're doing are you doing data analytics are you doing something that's so heavy that you need to use power BI or you need to use some of other tools then that's where you need to start looking at your architectural okay so the best practices for Azure functions or any functions in the sense whether it's AWS Lambda or Azure functions this is something that you need to think of one the main thing has to be main thing so you have to one one thing at the time so Azure functions you know if you receive a webhook to do one particular task you don't make that task to do multiple things focus on the one thing so they can build multiple functions to do different things at at the same time of course you know as developers you build things you want to be fast as possible so you don't want to be you know writing a function that there's hangs there you know for 20 minutes 30 minutes and realize that hey it's not running okay so these are kind of science that you kind of know whether is it useful for you to use it Azure functions or not one stateless meaning if you design an architect your your whole application are you actually carrying states around moving states around your application so if your application is stateless and you want to scale it at the same time then Azure functions is one for you why? because if you design your application to be stateless right stateless application means that I don't contain states within my application I can actually tell somebody to do the job for me send that response but I can do it the same the same so stateless architecture is also very important as you design whether you're not I think this is one good practice to do so yeah sure go ahead okay since you talk about the state plus yeah I mean yeah and I have a function B yes function B should start after the function A computer yes so this kind of scenarios can be added in service yeah definitely definitely so I I will show you a couple of use cases in the wall basically what you mention it's basically you can type many functions one after another basically doing different tasks and in that sense if you're stateless already you're not handling any stake on your application side basically you tell a zero function say hey I want you to process this information when I receive the output from you I will then send the output as an input to a function B and let function B handle and then once I receive the function B's output I can say okay function I can process again on my end and say okay now I got my process output put it as input to function C function C handles so you can always bind as many functions as you want whether it is it function A to do block storage function B to SQL function C you can do it to IoT devices IoT Hub sesuatu seperti itu jadi dalam perasaan itu ia ia ia ia sangat fleksibel ia menolakkan anda memperkenalkan juga jadi dalam perasaan anda aplikasi mempunyai sangat minima logik perniagaan kerana semua logik perniagaan menghubungkan ke fungsi kelebihan untuk melakukan itu untuk anda adakah anda menjawab pertanyaan anda? betul jadi saya akan menunjukkan beberapa kesannya yang yang menjawab pertanyaan anda juga jadi apa yang kita mencari adalah beberapa kesannya yang anda boleh sebenarnya mencari untuk fungsi kelebihan satu kita bercakap setiap 15 minit perniagaan jadi jika anda ingin melakukan sesuatu task yang anda tidak ingin membuat servis web untuk mencari dan mencari dan mencari setiap 15 minit biar fungsi kelebihan membuat itu untuk anda bagaimana? secarabasarnya ada peluang yang anda boleh beritahu fungsi kelebihan yang anda kata setiap 15 minit melakukan ini memperkenalkan bahan saya setelah anda memperkenalkan bahan saya ingin anda memperkenalkan kelebihan untuk SQL jadi sekarang kita mencari dua perkara satu adalah fungsi kelebihan dua adalah bindings yang kita bercakap tentang sebelumnya bindings akan mengambil kelebihan SQL sekarang kita ada database kosmos anda boleh membuat ini kelebihan Mongol anda boleh membuat ini kelebihan Gremlin anda boleh membuat ini kelebihan apa-apa yang anda mahu anda boleh bahawa anda boleh mengambil itu kelebihan Table Storage untuk menunjukkan beberapa kelebihan yang mungkin sangat berkenal seperti IoT devices kita mencari untuk mencari IoT devices mencari komputer vision kelebihan untuk mencari setiap kelebihan mencari kelebihan kita saya boleh katakan Hey saya ingin mengucapkan kelebihan bagi prima sekarang saya mengucapkan kelebihan mengbuang boleh begini bagi media sebagai Greg lanjutkan merumpA dan memasukkannya sebagai satu. Anda dapat menghantar, okey? Saya akan menghantar kepada fungsi Azure. Jadi, ada cara yang berbeda yang anda dapat menghantar fungsi Azure bersama-sama. Satu-satunya ini adalah sebuah event prosesi. Ini adalah sebuah event prosesi. Biasanya, jika anda tahu bagaimana Facebook advertisement berfungsi, saya rasa beberapa ini adalah sangat menarik. Mereka berfungsi perusahaan perusahaan perusahaan perusahaan untuk anda. Dan dalam perusahaan, jika anda ingin memperusahaan perusahaan perusahaan perusahaan untuk pengguna anda, anda boleh berkata, hei, ada seorang pengguna yang memasukkan page saya, Microsoft.com, For example, Azure.com. Saya dapat menghantar bagaimana jika saya mempunyai perusahaan perusahaan perusahaan, saya dapat melakukan fungsi perusahaan perusahaan, berkata, bagaimana pengguna ini, bagaimana penggunaan perusahaan perusahaan, menyebabkan saya sesuatu, menggabungkan informasi itu bersama, menghantar itu sebagai pilihan kompleta untuk dia. Jadi, apa yang kami lihat di sini adalah, sekarang pilihan perusahaan perusahaan anda adalah membuat staf minimum. Jadi, bagaimana anda sebenarnya membangkakan segalanya, logik perusahaan perusahaan di pilihan perusahaan anda sangat berat, anda sebenarnya menghantar informasi itu untuk seseorang yang membuat itu untuk anda. Jadi, anda fikir tentang itu, ia sebenarnya membuat perusahaan berat untuk anda di pilihan perusahaan perusahaan. Pilihan anda dan melihat pelanggan lain membuat beberapa perkara lain. Jadi, ini adalah seorang yang anda minta, boleh saya melakukan fungsi A untuk fungsi B, fungsi B untuk fungsi C? Ini adalah apa yang berlaku. Jadi, kami mencari beberapa perusahaan perusahaan perusahaan, betul? Hei, buat ini. Seteruskan itu untuk saya. Jadi, di dalam perusahaan anda, perlu tidak mempunyai perusahaan web untuk membuat semua perusahaan untuk anda, tetapi anda boleh melakukan perusahaan dan berkata bahawa fungsi A untuk membuat itu untuk saya. Jadi, anda dapat idea yang sebenarnya sekarang, perusahaan berat anda tidak telah dibuat pada perusahaan perusahaan anda, tetapi perusahaan berat anda telah dibuat pada perusahaan di komputer yang seluruh. Sudah tentu, ada perusahaan berat saya rasa, perusahaan berat jika anda mencari perusahaan media, untuk contoh, perusahaan hidup. Jadi, ini adalah aplikasi yang dapat menghubungkan dengan jauh dengan cara anda dapat menggunakan fungsi A. Perusahaan perusahaan, bagi contoh, sekarang anda melakukan perusahaan web. Mari kita berkata, mereka melakukan perusahaan web untuk berkata-kata masa depan, dan jika mereka melakukan video hidup sekarang, mereka dapat menghubungkan perusahaan perusahaan di perusahaan tersebut, menghubungkan perusahaan tersebut. Jadi, anda dapat menghubungkan fungsi A dan berkata, saya mendapatkan informasi hidup ini. Boleh anda melakukan perusahaan dengan perusahaan perusahaan perusahaan? Dan dari sana, saya dapat menghubungkan itu dengan langsung ke output saya, apabila ia berada di Facebook Live, di YouTube, atau saya dapat menghubungkan bahawa saya tidak mahu melakukan apa-apa, tetapi menghubungkan. Jadi, ini adalah cara yang berbeza yang dapat kita bermain dengan fungsi A. Menghubungkan fungsi A. di dalam perusahaan anda, dan kemudian membiarkan mereka melakukan perusahaan tersebut untuk anda. Jadi, apa yang kita fokuskan adalah, bagaimana perusahaan mereka dapat menghubungkan itu pada perusahaan tersebut, atau perusahaan tersebut. Kemudian, anda menghubungkan semuanya dalam aplikasi monolitik. Sudah tentu, perusahaan terakhir adalah sesuatu yang terdekat dengan apa yang kita lakukan di sini, perusahaan saya. Ia sebenarnya sebuah perusahaan yang telah dihubungkan. Jadi, jika saya menghubungkan sebuah perusahaan daripada pengguna, bagi contohnya, dan saya dapat berkata, hey, fungsi A, buat itu untuk saya, masukkan ke kotana di analitik, kotana kami menghubungkan itu, menghubungkan informasi, dan kemudian menghubungkan informasi kembali kepada pengguna saya. Jadi, apabila platform yang berlaku, apabila di Facebook, apabila di Telegram, Microsoft Teams, Skype, itu menghubungkan pengguna yang penting untuk mencapai NLP, dan apa-apa analisi yang saya perlu lakukan untuk menjawab pengguna saya. Jadi, itu pretty much untuk konten yang saya ada hari ini untuk servis fungsi Azure. Jika ada sebuah pertanyaan, anda boleh beritahu saya sekarang. Ya. Terima kasih. Mereka ada pengguna? Ya. Ya. Jadi, pertanyaan saya kepada anda, kerana satu, kita bercakap tentang sebuah pembentangan, jadi pertanyaan saya kepada anda adalah, apa yang anda inginkan dari sistem seluruh anda? Kerana, kami tidak hanya cuba mencapai fungsi Azure menjadi aplikasi, dan berkata, hei, kita boleh melakukan fungsi Azure. Saya rasa itu bagus, tapi satu perkara yang perlu dikenal adalah, okey, jika anda mempunyai banyak perkara yang berlaku di luar sana, apa yang anda inginkan yang anda inginkan pada pembentangan anda? Jadi, bagi contoh, jika anda inginkan saya mempunyai log-in, saya perlu log-in penggunaan saya ke luar sana, ke pembentangan saya, atau WPF untuk kata-kata. Apa yang anda boleh lakukan adalah berkata, hei, sekarang, saya hanya membina saya hanya membina pembentangan api saya atau saya boleh menggunakan pembentangan api untuk melakukan itu, dan kemudian, saya menghubungi informasi itu ke pembentangan fungsi. Jadi, saya menghubungi fungsi Azure dan berkata, hei, sekarang anda akan melakukan log-in, anda akan melakukan registrasi untuk saya. Baga, saya akan menghubungi berkata-kata ke pembentangan fungsi Azure, saya perlu melakukan pembentangan untuk mengubungi data atau informasi user dengan keputusan saya. Jadi, saya boleh mempunyai informasi user untuk anda, fungsi Azure dan fungsi Azure untuk menghubungi informasi untuk saya, kemudian, menghubungi informasi untuk saya. Bagaimana anda? Bagaimana anda berjaya atau tidak berjaya log-in? Untuk contoh, sangat mudah. Kenapa kita melakukan itu? Kerana, satu perkara di website atau satu perkara dalam aplikasi online, anda ingin mengguna keputusan yang anda sebenarnya mengguna. Anda ingin mengguna berapa banyak yang anda menghubungi kerana, setiap perkara yang anda lakukan di website atau di sistem architektur. Ada sebenarnya keputusan, keputusan sistem yang ditutupi juga. Jadi, apa yang kita cuba lakukan adalah mengatakan bahawa, apa-apa saja yang saya perlu lakukan, saya tidak perlu menghubungi saya, seperti berkata-kata, berkata-kata pembentangan web itu. Kerana sekarang, saya percaya apa yang anda lakukan adalah sebenarnya, anda menghubungi pembentangan web yang sebab pembentangan user cuba log-in, saya perlu menghubungi database saya, saya menghubungi itu, betul? Jadi, apa yang kita cuba lakukan adalah mengucapkan, betul, pembentangan whole pipeline, jadi, jika kita mengucapkan pembentangan pertama dan katakan, mari kita melakukan log-in atau mengguna. Apa yang kita boleh lakukan adalah mengucapkan dan katakan kita mengucapkan kepada fungsi Azure. Jadi, sebab anda tidak menggunakan code anda sebenarnya hanya menghubungi fungsi Azure web URL dan mengatakan bahawa, setiap kali pembentangan user datang ke log-in, setiap kali pembentangan user cuba mengguna atau contohnya, saya melakukan API. Jadi, biar saya menunjukkan yang kita bincangkan sebelumnya. Jadi, apa yang kita cari sebenarnya adalah ini. Setiap kali aplikasi anda datang berkata, saya ingin membuat pengguna untuk contoh registrasi, ia berkata kepada api anda. Sekarang api anda akan menghubungi fungsi trigger untuk fungsi Azure dan berkata, membuat fungsi ini untuk membuat pengguna untuk saya. Membuat pengguna untuk memakai database. Dan database berkata, apabila ada permainan atau apabila ada di log-in, anda boleh menghubungi itu. Ya. Ya dan tidak. Jadi, jika anda mempunyai MVC atau MVP. Ya. Baiklah. Jadi, apapun yang anda mempunyai, anda hanya mempunyai layar itu dan tidak mempunyai model MVC atau MVP. Kenapa? Kerana apa yang anda lakukan adalah mempunyai pilihan utama dan berkata, apabila pilihan utama ini berkata, ia mempunyai fungsi Azure untuk membuat pengguna untuk membuat pengguna. Jadi, apabila anda membuat pengguna untuk membuat pengguna? Ya, betul. Sebenarnya. Apabila anda membuat pengguna untuk membuat pengguna, Ya. Sebab kita membuat pengguna untuk membuat pengguna. Ya. Apabila anda mempunyai kesä-sasea yang contohnya A melepaskan pengetahuan dan kemudian anda mempunyai peraturan untuk membuat pengguna. Baiklah. Apa yang mereka mempunyai? Pertanyaan 2. Pertanyaan 2. Ia akan mengambil kesa ini. Kita mempunyai perangkatan dan mengubah. Sebenarnya. So, you said you're right, in typical scenario, the new user will be the eye-offs. I mean, most of the traffic will be going to the new users. Correct. And the update and delete will be, I mean, not more than 10% to 15%. Correct. So in this case, what model I can choose? Either I can go for a dynamic or a standard pricing model. Can I split by the functions? Say for example, function A, I go for a dynamic pricing. Maybe function B, I go for an unusage. Sorry, answer. You have two pricing models. App service. App service. So which model is... Okay, so his first question was, you know, are there any use cases out there that people are using Azure functions and actually helps to reduce the company's cost or even successful use cases? I don't have any use case at this point in time. Not that I know of any company is doing that as well. Because I think serverless is really new. So a lot of companies are still not adopting this serverless compute as of now. So there I can't give an answer. To your second question, we are asking whether, you know, now that most of my traffic is going to create user, I could have lesser traffic going to update and delete. So how do we go about that? So for me, it really depends on how much traffic you have actually monitored so far. If most of your traffic is going to create user and that is the main bulk of bottleneck that's happening on your site, then I would say abstract that, put it into Azure function. Why? Because your app itself, whatever application that you're doing or even if you're doing a simple, you know, payroll management, you know, a login website actually at the end of the day you're running on the cloud, you're running on some services. System resources is going to be eating up. Every 10,000, every 1,000 users that come in concurrently simultaneously, you're eating up a system resources. So why are you actually, you know, letting your application do the heavy lifting? Rather than... Ya, sure. This, right? Ya. So what I'm trying to say is because you abstract that out to your create user as a function, what you can look at here is two things. One, you can actually, yes, you can create two different functions for two different tiers, whether it's to app service or this is a dynamic tier. To your course will be actually videos because now we are looking at a very small number which is 0.00016 per execution time. So if you calculate and complete everything right now your create user will actually be on a dynamic tier pricing, which if as and when I have users coming in, I direct my traffic here, I don't have the skill because if you look at the previous slide what we're actually looking at is platform is responsible for skill. So when the platform is responsible for skill, every time once it hits a certain threshold, my functions will automatically scale on its own. Unless you want to do control where you are responsible for skill, this app service you're actually responsible for the VMs as well because they are actually giving you base on the number of visa VMs. So it depends on which use case you're looking for. I think for your case if it's just going to be like, for example create user, something very like, dynamic pricing is more ideal for you. The next question say for example, Black Friday have a heavy traffic. Correct. Even though I choose dynamic pricing model, how do you ensure the resources are allocated? How do you ensure that your resources allocated? So basically how this dynamic pricing does is every time the number of executions comes in, it's actually calculated based on the duration of execution times the reserve memory. So whatever the Azure functions allocated to you, you're actually running based on that allocation that's provided. If they need to scale it, let's say you have a Southern Spark search of load. It will actually scale accordingly because the backend infrastructure that they built, the ops code, is actually very lint. So in the sense right now if you have a lot of users coming in, you're sending traffic, they'll actually scale that for you without you worrying on the load balancing in that case because Azure functions by functions and by triggers. Every trigger is coming in. They have a certain threshold to detect whether how they want to scale that function or that model for you. So that in the case, again I don't have an actual use case. I don't have an actual scenario for that. That you have to try to see how it scales. But as far as the product team has mentioned is that they're actually scaling based on the number of functions and event cost is happening. Correct? So as of now we don't have an actual use case to say that hey, we have tested on 10,000 load but there are people in the cop level they actually tested by heavy load and Azure functions able to handle the scaling based on I think about 10,000-100,000 they spin off a couple of loads to test it. Yeah. Thank you. Any other questions? Okay. Yes and no. So the question is again but it's architecture question. Are you actually requiring your functions to do the database call? So if let's say you're doing for example some of the use cases where I'm actually doing for example processing images. I don't have to call my database, correct? So in that sense if I'm doing Azure function in this case my bindings will not be SQL. My bindings will actually be block storage or my bindings could be hey, process this information only then send me the information back whether it's successful or not. So not necessarily that every time you call an Azure function we have to go through an SQL database. Yes. Okay. So in that case your question will be more if right now I'm calling the database once again depend on what use case you're talking about and Azure functions have to call again and again. You can always do your architecture such that I maintain a certain state on a table storage every time that I need that information I can just pull from that state and then let the state handle the information. Yes. Ya. Ya. So at the architecture level you have to design in such a way that you have your own caching or Azure function handles the heavy lifting so it depends on how you design it or you can always put on a table storage or you can put in some other various for example. Ya. Nothing else? I will add a little bit did you finish your presentation so this is general questions? Ya, these general questions Okay. It's quite short today. So websites I was looking having a function that something changes in my website have a function click in to do something so I know that you can have a trigger that something changed in block storage. Ya. But I don't actually know where my website's block storage is so how do I actually find that out and how do I set up the triggers? Your Azure website is block storage? Well I just had an Azure website they store files on this virtual D home directory whatever it is. Right. But for I want to find out how my function can access those files and put it into the network. Your functions can't access your virtual website's files because how functionable is actually you sending the input to the function and saying that I need to send the information I've seen a demo of the numbers triggered by something some file being added to some or it wasn't unusual but the file was added to block storage and something happens. File in the website? Yes, it's different. So what what this block storage is is actually a binding to your Azure functions. So in this case Azure functions receiving a block storage binding as an input whereas there isn't a Azure website's binding that you can actually call form. So if you want to do that means that Azure websites has to have a block storage that is tied to it in your account and saying that okay now this is since it's tied to my account I can put all my files onto the block storage. You know what I'm saying? Then from there I use Azure function to say that input form that block storage that's within my Azure websites to do the transfer to another block storage on another website. So end to end basically what you need what you need to do is actually to tie the block storage onto your Azure websites because Azure website is actually running on a VM that is container-wise within the system itself. So all the files are actually within the VM level. So what you could do is actually to tie that block storage as a resource to the Azure websites okay I want you to transfer their files into block storage write a code transfer that let Azure functions pull that from your block storage end to end send that information to another block storage let your Azure websites to do the transfer. Okay but do you think I think that you could do a migration you could do a migration that is much easier like data migration for one end to another and like a simple file transfer yeah or you could clone or Azure websites in that matter but does it need to be real-time like you need to synchronize both at the same time or how does that work or you're just trying to migrate one to another I think yes Azure function could be one unless you're actually requiring to access some of the system files that sits inside Azure websites otherwise I think you could either put or Azure functions or web service that sits in between your Azure websites actually one website is a CMS that writes files out that the other one uses it doesn't use those files it writes out because I don't think I can access the other website directly from the first one but I have to get them over there okay so I mean on premise they don't live on the same server and they can write wherever they want but of course there are separate websites in Azure sure so that was the question I had yesterday I mean yes you could do that on Azure functions but that but that means you have to go through a block storage because Azure web services independently on its own in the VM so what you need to do is to tie resource to Azure block storage let Azure block storage do the binding to your functions and let the functions do the transfer output to your I have in my CMS I have providers and the providers is right to the local file system yes so if I can change it the providers say store these files somewhere else yes, correct then where would I store them directly you store it directly to a block storage but can I kind of go all the way directly to the second website I mean if if you if you could store it to one block storage you could technically put a block storage as a centralized block storage okay so once you put to the centralized block storage in fact you don't even need an Azure function your website could just pull from their block storage yeah so again it's a how do you design there's always all these things yes but you don't understand everything correct and moves to Azure right yeah sure thank you any other questions okay terima kasih