 The title of the presentation is NotCloud. So NotCloud is a Node.js package for the OpenCloud. So when we progress through the presentation, we will see what is OpenCloud and why it matters that we know about OpenCloud and, yeah. So who am I? We will start in the presentation. So I'm Rajigar and I'm currently working as a software engineer at 99x Technology. So 99x Technology is a company based in Sri Lanka. So I'm also from Sri Lanka. And also I'm a co-contributor at Skollab. So we are also representing GSOC and GCI. And you can find me in any platform using this handy, Rajapimal, GitHub, Medium, Twitter. All right. So before starting, before diving into all the details of NotCloud and how we manage the APIs, I need to go through what OpenCloud is all about. So imagine that we have a situation like this. So we have an application and we need to use different services of different clouds. So in this case, we have Cloud A and Cloud B. So this particular application is trying to use a particular set of services from Cloud A and also a particular set of services from Cloud B as well. So this application is interacting with different clouds. So, yep, so the OpenCloud, the basic definition would be consuming different services of different cloud providers. So why would we need OpenCloud? So one such use case is to make use of different strengths of different services. So you might have seen that different cloud providers such as AWS, GCP, they have different services and they have a similar set of services. So we can make use of these strengths of each of those services using this OpenCloud paradigm. And another thing is using the redundancy and disaster recovery. So we can make use of the OpenCloud paradigm to get rid of disasters and to avoid vendor locking. So if you are an organization, so you might be particularly interested to avoid vendor locking. So you might not be interested in getting into one particular cloud provider. So you need to be flexible to shift from one provider to another. And another thing is compliance. So as an organization, you are very interested and you are very concerned about compliance. So various services from different cloud providers might not be compliant with your organization standard. So that's a very important point. And scalability, so different providers have different levels of scalabilities with different services. So we need to be thorough about scalability as well when we are building enterprise applications. And cost optimization, again, this is a very big concern for organizations. The cost is a very important thing that we need to think about. All right. So solutions are leveraging OpenCloud. So there are different, there should be different characteristics of services which should have using the OpenCloud paradigm. So one such thing is transparency. We need to have a good transparency when we are called for OpenCloud paradigm. So we need to see what's actually happening with the APIs that we are using. And the versatility. And we need to be able to easily manage the applications which are running on different clouds. So if they are using different providers and they are different services, they should be actually easily managed. So we need to be thorough about how we, about the maintenance aspects as well. And the configuration options, again, this is one such important point that we need to think about. So when we have different providers, we need to think about how we are actually going to configure our cloud-based applications. So when we are interacting with different APIs, we need to be thorough about how we are going to configure our different services using the APIs of different cloud providers. All right, so let's move into a use case. So in this scenario, I'm referring to a backing up of AWS S3 Pocket in a GCP storage. So these are similar services from different cloud providers, AWS and GCP. So why would we need something like this? So this is a sample use case. So there might be account hacking and against data loss. So you might be concerned about your data. So there might be use cases like this from backing up AWS S3 to your GCP storage. So this is a very, very simplified architecture. So you have AWS cloud provider and GCP. So this is our application layer. What we are trying to do is we have a cron job in this case. And we are trying to back up this S3 data from our application to our GCP. So how we are going to do is here we have the AWS SDK and here we have the GCP SDK. So we need to code this application layer and we need to be thorough about the maintenance and the design aspects of this particular layer. So this is how we can do with the respective SDKs. So what we see here is that we have this application of APIs because different providers have their different API implementation. So AWS might be following a different set of specifications and they might expose different set of interfaces for you. And if you think about GCP, they will do their own specifications. And also the constructs are different from each other. So as I mentioned, they have different ways of exposing their interfaces from different services. So what are the disadvantages of a designated API? So if you are a large organization and if you have applications using open cloud paradigm, you need to move faster if you are a large organization. So it is very hard to move faster if you have these desegregated APIs. And you will spend more time on integration rather than your business logic. And there's a really high learning curve when it comes to learning the different interfaces of different SDKs from different cloud providers. And it's really hard to focus on the business processes because you might be focusing about your integration aspects rather than your business process. So that your ROI will be much lower. So we see that the clear current structs are a necessity. And we came up with a solution called Node Cloud. So this is for Node.js only. This is a Node.js package. And it's a unified API layer in Node.js. So you will be using only Node Cloud if you are going to interact with different cloud providers and if you're using the open cloud paradigm. So currently we support three providers, Amazon Web Services, Google Cloud, and Microsoft Azure. So the design philosophy, so we have chosen a plugin architecture for this because we need to build a community around this project so that the community also can contribute to our Node Cloud project. And so this is the previous, the same architecture diagram that we saw. We have the different cloud providers and we have our application layer. So with Node Cloud, we can replace those two SDKs and we will be using only Node Cloud so that it will be more easier and you will be always interacting with Node Cloud APIs. So you don't need to learn any more extra APIs from different cloud providers. So how do you get started? So we have different plugins. So there's a configuration file called nc.config.js. And what we need to do is just, so in this nc.config.js we need to import our plugins. So one such plugin is Node Cloud AWS plugin and the other one is a Node Cloud GCP plugin. So how we give the providers are like this. We specify our providers and yeah, so here we have AWS and Google providers. So yeah, so I will show you a quick demonstration of Node Cloud and how we can interact with the different APIs. So this simulates the same use case that I mentioned in the presentation. So we are going to upload to S3 bucket and also with the same API, we can do that to GCP as well. So here I'm trying to create, here I'm trying to create a S3 bucket. So you can see that the parameters, these parameters might be different for different cloud providers and their respective services and that's something that we can't actually, that we don't actually have control on. So these parameters should be based on the SDKs. So what I'm trying to do here is create a S3 bucket. So you can see that this S3 bucket was created from the create API from the Node Cloud SDK. And again, I'm trying to upload from Node Cloud. So I'm giving a key value pair. You can see that it was uploaded from the SDK Node Cloud SDK itself. And we will see again how we can use the same API interface to create a GCP storage and also how to upload it using the same API. So here I am using the Google provider from Node Cloud and I'm trying to create a bucket. So you can see that this is the same API. So earlier you had also bucket, but if you use different SDKs, you will see that AWS SDK has different terminology and if you use Google GCP SDK, they have a different terminology. So with Node Cloud, you need to only learn one API and with that API only, you can make use of the different services. So here I'm creating. So this is the create API, the same API that I used for AWS history. So we will go to our GCP platform and we can see that the bucket was created in GCP. And again, I'm trying to upload using the same API that I used earlier to upload to AWS bucket. Again, we have different parameters. So this is not under our control as I mentioned earlier. So I'm uploading a key value here. Yep, so I've uploaded a JSON apparently and it was there with the same API that I used to upload to AWS history. So that was a quick demonstration of how we can use Node Cloud APIs to interact with different providers with the same API. So you don't need to learn about different APIs when you are building enterprise applications. All right, so we have an organization called Cloudlips. So Node Cloud is under Cloudlips organization. So if you go to github slash cloudlips slash Node Cloud, you will see the core repository. So as I mentioned earlier, we have a plugin architecture. So this is the core repository that we have and this repository has the ability to inject different plugins. So as I showed earlier, we had the AWS plugin and also a GCP plugin. So this is the core repository. And these are the plugins that we have. This is one of the earliest plugins that we have created Node Cloud AWS hash plugin. So when we were developing this Node Cloud project, we thought of how we can provide the configuration. So in software, we have different ways of configuring. So we thought of going ahead with configuration with code. So as I mentioned, we have a file called nz.config.js. So with that file, we can actually configure our Node Cloud providers. And so we prefer configuration with code. So this is the same file that I mentioned earlier. So we have our configuration in our JS file. So let's say there's a new provider, upcoming provider and is a really good provider and they have similar services that we have in our different providers that are in the market currently. So let's say this is a provider called x. So we need to create a plugin. So as a community member, you see that you need a plugin to interact with Node Cloud. So how we can do it is just at the plugin name to the list of providers, so just create a pull request and we have a file called providers.js. So it's really easy to find that in the Node Cloud core repository. And then what you need to do is create a repository using the following naming convention. So you might have seen the webpack naming convention for plugins and loaders. So these small have the same condition that we are following here. We have Node Cloud, the provider name. So our priority is x, Node Cloud dash x dash plugin. And you have to code your APIs in the repository itself. And next what you need to do is communicate with the core team. So you can see the core team if you go to our Node Cloud core repository and just communicate with us, tell us what you're going to do and we will communicate with you and we will see what we can do with the plugin. And as the last step, just publish it to MPM, share it with everyone. So the aspects of Node Cloud, where can we use this? There are three different aspects. So the first one is application layer. So this is something that I demonstrated in the presentation and provisioning infrastructure. So let's say if you need to spin up a VM from AWS or GCP, you can use the same APIs to provision your infrastructure using the API layer itself. And the consuming infrastructure, consuming different infrastructure levels that you can interact with the Node.js SDK and get familiar with the APIs itself. Yep, so that's all I have for, from me. If you want to contact me, use this handle. I'm on GitHub, Twitter and media. Yeah, so thank you very much. If you have any questions, yep, sure. So, questions? No, complete silence. I do feel indeed to find out what you guys are interested in. All right, definitely no questions, last call. All right, thank you, okay, it's round of applause. Thank you. Thank you. And one note before finishing up, we are also having this project, if you're a student, we are also having this project in GSOC and GCI. So if you're interested, just check this out. Thank you very much. You are just asking generally about Scolab, right? Okay, so to get started with Scolab, you can go to our Gita channel. And if you're interested in a particular project, you can go to that particular project's Gita channel and just say hi, and Mendes will be there and they will respond within a day or two. And we will see what you can do if you are a beginner or if you are an intermediate level. So we will see what is your level and we will inspect that. And you can just get started with this. So in our repositories, mostly we have labels in the issues, so you can inspect that and just get started for GSOC or GCI. Thank you.