[MUSIC] In this video, we'll touch on some of the main ways of Interacting with OCI. Including The Console, CLI, SDK, and REST API. Starting from the top our goal is to connect to OCI from our Local Machine and manage infrastructure. The tool we're likely familiar with for that is the console, but it's important that we dig a little deeper. Under the hood every interaction with OCI is through a REST API Endpoint. So for example, whenever we want to create a VCN, we have to hit the endpoint with a request that looks something like this. Obviously working with the API directly is rather unwieldy. Writing these comes up in specific use cases like an application integration. More often than not, it's easier to work with high level tools that generate these calls for you. The important thing is to be loosely familiar with the API for two main reasons. First permissions are granted at approximately the API level. So to implement the principle of least privilege, we need to understand which API calls we grant to each actor. Second, when things go wrong, figuring out exactly which API call failed is often a great first step in debugging. But for the most part, will generate these calls through other tools. The first and most familiar way is with the Cloud Console. This is the web application where you can click around to manage your environments. It's the easiest tool to use and it's great for prototyping or for small environments. But when it comes to more complicated actions like, say, provisioning 100 compute instances it becomes labor intensive and error prone. The appropriate tool for automating repetitive tasks is the Command Line Interface (CLI). This is a simple text based utility that can be installed on most operating systems, terminals including Mac OS, Windows and Linux and Unix systems. This way we can leverage shell scripts to manage infrastructure. If we want to provision 100 compute instances, we could write a quick bash script that loops 100 times. Or for example, if we wanted to change the shape of every compute instances in the compartment, we could write a script that queries for all of the compute instances and then iterates over them, changing their shape. But just like the Console, when use cases get even more complex, the CLI can also become unwieldy. Suppose we want to automatically provision a new server and decommission an old one if certain health checks fail. Or suppose we want a pilot DR environment that automatically replicates prod but scale down. For these, the appropriate tool would be the SDK. The Software Development Kit (SDK) consists of libraries for various programming languages that will generate API calls for you. This way we can leverage the full generality of languages like Python, Ruby or Go just to name a few. As opposed to the CLI, the SDK becomes the most natural tool when complex logic is involved. Additionally, the SDK can be used for serverless functions that are executed based on custom API calls or infrastructure omitted events. Just to show a quick example, here's a Python script that creates VCN. Load settings, establishes a connection to OCI, packages up details for the VCN and sends the request to OCI. Summing up, we have that OCI is fundamentally REST API based, but we generally use higher level tools to generate those calls. The Console is best for simple use-cases, experimenting and prototyping. The CLI is best for simple but repetitive tasks and automation. And the SDK is best for complex automation. Throughout this course, we'll stick mostly with the Console and the CLI and two other methods we haven't mentioned yet. But it'll be helpful to keep the API in the back of your mind as a way of unifying the different methods. In the next few videos, we'll go into a little more detail on the CLI, starting with the authentication methods. See you there.
