In November 2018, I had the privilege to attend the Australian Oracle User Group national conference “#AUSOUG Connect” in Melbourne. My role was to have video interviews with as many of the speakers and exhibitors at the conference. Overall, 10 interviews over the course of the day, 90 mins of real footage, 34 short clips to share and plenty of hours reviewing and post-editing to capture the best parts.
In a previous blog, I explained how to provision a Kubernetes cluster locally on your laptop (either as a single node with minikube or a multi-node using VirtualBox), as well as remotely in the Oracle Public Cloud IaaS. In this blog, I am going to show you how to get started with Oracle Container Engine for Kubernetes (OKE). OKE is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud on Kubernetes.Continue reading “Teaching How to Get Started with Oracle Container Engine for Kubernetes (OKE)”
I am thrilled with the Oracle’s Gen2 Cloud Infrastructure architecture, where Oracle completely separates the Cloud Control Computers from the User Code, so that no threats can enter from outside the cloud and no threats can spread from within tenants.
Obviously with more security, there comes more coordination, especially at the moment of invoking OCI resources APIs. Luckily, Oracle did a good job at providing a simple to use CLI and SDK (see here for more information).
For the purpose of this blog, I built a simple NodeJS application that helps demystify the security aspect of invoking OCI APIs. Check this link for examples of running similar code across other Programming Languages.
My NodeJS application manages OCI resources in order to:
- List ADW instances
- Stop an ADW instance
- Start an ADW instance
I started this NodeJS application to list, start and stop ADW resources. However, I designed this application to easily extend it to invoke any other type of OCI resources.
I containerised this application with Docker, to make it easier to ship and run.
This is a picture of the moving parts:
So following on from my earlier article, Policies let your teams play safe, I have been given another challenge: Can we give our users single sign on now that each team can play safely in their own Oracle Cloud Infrastructure compartments?
Single sign on delivers a number of really important benefits. Firstly, the user experience is much smoother and seamless as users don’t get prompted for multiple passwords and don’t have to remember even more passwords. More importantly, single sign on eliminates the need to manage multiple stores of identities. This can be a big overhead for administrators and sometimes open up additional risks. Finally, an enterprise wide identity solution can often provide additional capabilities can be leveraged by your Oracle Cloud Infrastructure.
Earlier today I was given a challenge by my colleagues. Recently Oracle released the Autonomous Data Warehouse and we have a lot of excitement from customers, partners and internal folk alike. This excitement is driving a lot of innovation right now, but that also brings some challenges. The last thing we want is the Marketing team to mess with Finance resources. How do we make sure different teams don’t step on each other’s toes?