Cloud-native is a very popular keyword nowadays. But is it just another hype topic? My personal opinion is: No, it isn’t. Cloud-native development is essential to build sustainable, future-oriented architectures (in this context we also speak of evolutionary architectures) that can deal with the volatile, rapidly changing requirements with respect to products and business models! But what does Cloud-native mean?
According to the definition of the Cloud Native Computing Foundation (CNCF), Cloud-native apps are loosely-coupled, resilient, manageable and observable. To meet the requirements to quickly react on changed business requirements, a robust and consistent automation strategy (CI/CD). Technological Cloud-native apps massively count on containerisation. Conceptually such apps rely on modern concepts like Microservices, APIs, DevOps and 12-factor app.
To make it more concrete: Cloud-native apps are built with a Cloud-first mindset. In addition, those apps should not depend on a specific tooling or vendor so that it can be both deployed in the Cloud and on-premises as well as in the Cloud of vendor A and vendor B without changing the implementation. Technologies like Kubernetes (and of course other technologies specifically certified by CNCF) are key therefore.
From my perspective, the ideas behind Cloud-native should be the basis for any app that is developed nowadays!
Today, every Cloud vendor provides Cloud-native services; at least all of them provide a managed Kubernetes offering. With a special look to the Oracle Cloud, developers are provided with a complete Cloud-native development stack.
The figure above shows what Oracle Cloud Infrastructure offers in the area of Cloud-native Development. In the following, I’ll give a brief introduction to the services with special focus on the App development & Ops services.
As mentioned before, Oracle – as the others also do – offers Managed Kubernetes offering called OKE. Supplementary to this we have Cloud Infrastructure Registry (OCIR), which is a private Docker Registry. So developing apps to be deployed to OKE can be pushed to this registry instead of public Docker registries like Docker Hub.
With Oracle Functions there’s also a Serveless/FaaS offering. Functions are built using Fn Project, which is a quite interesting project as such. Fn allows developers to completely develop and test functions locally. This is possible due to the flexible architecture of the functions runtime. Function apps are wrapped in Docker images that can be managed in a Docker registry (e.g. OCIR) and executed within the Functions runtime. The Functions server architecture allows to have it on the local development machine, in the local datacenter or in the Cloud. A very flexible approach.
To able to access Functions provided by in the Oracle Cloud, a HTTP Endpoint needs to be securely exposed so that the function can only be called by authorized clients. To ensure that the OCI API Gateway can be used. The gateway component is completely managed by Oracle, users just have to provision it, provision the respective APIs and the corresponding policies and use it. That’s it!
Provisioning of the gateway, the APIs and policies can be fully automated by using an Infrastructure as Code approach (IaC) with Terraform (which is also the case for most of the Cloud-native Services). With respect to IaC, the Resource Manager Service is provided, which supports you with provisioning all Cloud-native Services.
In addition to the aforementioned services, Oracle is also providing a Cloud-based development runtime, the Developer Cloud Service. This service provides a complete development environment (with exception of the IDE) and amongst others contains a GIT repo, an artifact repo, Kanban boards, a Wiki and a Build server. Setting up a new project can be done within 1-2 minutes.
With Oracle Helidon (where I will give a brief introduction in an upcoming post), a Microservice development framework is available, which can be used in two flavours: a MicroProfile-based approach and in a more functional-based Microframework way. So the framework is very flexible to address different requirements.
From a Observability and Messaging perspective, the Logging and the Streaming Service are the most relevant ones from my perspective. The Logging Service (which currently is in limited availability) is a centralized Log Management with respect to the provisioned Service within a users Cloud tenant. This kind of functionality is very important, because of the distributed, loosley-coupled way Cloud-native apps are usually build.
The Streaming Service Service is basically a Cloud-native, Kafka-compatible, Event Hub implementation. It is designed for high throughput with the intention to handle large data streams that for instance may occur in IoT scenarios.
As you can see, Oracle has a solid foundation to build and run Cloud-native applications in the Cloud. More details about the aforementioned service can be found on the official landing page.
In upcoming posts, I’ll dig a little deeper into the different services. I’ll also show how the services can be combined together to build the foundation of a Cloud-native runtime and development platform.