PaaS – Page 2 – RedThunder.Blog

Teaching How to Get started with Kubernetes deploying a Hello World App

In a previous blog, I explained how to provision a new Kubernetes environment locally on physical or virtual machines, as well as remotely in the Oracle Public Cloud. In this workshop, I am going to show how to get started by deploying and running a Hello World NodeJS application into it.

There are a few moving parts involved in this exercise:

Using an Ubuntu Vagrant box, I’ll ask you to git clone a “Hello World NodeJS App”. It will come with its Dockerfile to be easily imaged/containerised.
Then, you will Docker build your app and push the image into Docker Hub.
Finally, I’ll ask you to go into your Kubernetes cluster, git clone a repo with a sample Pod definition and run it on your Kubernetes cluster.

Continue reading “Teaching How to Get started with Kubernetes deploying a Hello World App”

Teaching How to use Terraform to automate Provisioning of Oracle API Platform

Previously, I showed how to use Terraform and PSM CLI to spin up a “Build Server” and use it to provision Oracle Integration Cloud (OIC) environments. You can find this blog here.

In this blog I am going to show you how to do the same, but to provision Oracle API Platform environments.

The approach that I will be following is the same:

Continue reading “Teaching How to use Terraform to automate Provisioning of Oracle API Platform”

Teaching How to use Terraform to automate Provisioning of Oracle Integration Cloud (OIC)

In a previous blog, I explained how to treat your Infrastructure as Code by using technologies such as Vagrant and Terraform in order to help automate provisioning and decommissioning of environments in the cloud. Then, I evolved those concepts with this other blog, where I explained how to use Oracle PaaS Service Manager (PSM) CLI in order to provision Oracle PaaS Services into the Cloud.

In this blog, I am going to put together both concepts and show how simply you can automate the provisioning of Oracle Integration Cloud with Terraform and PSM CLI together.

To provision a new PaaS environment, I first create a “Build Server” in the cloud or as my boss calls it a “cockpit” that brings all the required bells and whistles (e.g. Terraform, PSM CLI, GIT, etc) to provision PaaS environments. I will add all the tooling it requires as part of its bootstrap process. To create the “Build Server” in the first place, I am using Vagrant + Terraform as well, just because I need a common place to start and these tools highly simplify my life. Also, this way, I can also treat my “Build Server” as “infrastructure as code” and I can easily get rid of it after I built my target PaaS environments and save with that some bucks in the cloud consumption model.

Once I build my “Build Server”, I will then simply git clone a repository that contains my scripts to provision other PaaS environments, setup my environment variables and type “terraform apply”. Yes, as simple as that!

This is a graphical view of what I will be doing:

Continue reading “Teaching How to use Terraform to automate Provisioning of Oracle Integration Cloud (OIC)”

Teaching How to use Oracle PaaS Service Manager (PSM) CLI to Provision Oracle PaaS environments

In this blog, I am going to get you started with Oracle PaaS Service Manager (PSM) CLI – A great tool to manage anything API-enabled on any Oracle PaaS Service or Stack. For example, provisioning, scaling, patching, backup, restore, start, stop, etc.

It has the concept of Stack (multiple PaaS services), what means that you can very easily provision and manage full Stacks, such as Oracle Integration Cloud (OIC), that combines multiple PaaS solutions underneath, e.g. ICS, PCS, VBCS, DBCS, etc.

For this, we are going to use a pre-cooked Vagrant Box/VM that I prepared for you, so that you don’t have to worry about installing software, but moving as quickly as possible to the meat and potatoes.

This is a graphical view of what we are going to do:

Continue reading “Teaching How to use Oracle PaaS Service Manager (PSM) CLI to Provision Oracle PaaS environments”

Teaching how Oracle Integration Cloud (OIC) simplifies Application Integration, Process Automation and API Management

In this blog I am going to show you three new capabilities introduced in Oracle Integration Cloud (OIC) that massively simplify the enablement of Application integration with extensions to Business Process Automation workflows and finally how to expose all of that as secured APIs via the Oracle API Gateway.

These three new capabilities are:

Call your Process Cloud Service (PCS) workflows from an Integration Cloud Service (ICS) orchestration.
Call your ICS integrations from a PCS business process.
Expose your ICS integrations as APIs into the Oracle API Gateway

Our scenario is simple, it is an incident management extension, that requires some human intervention to manage service requests.

To be specific, let’s assume the following components:

We need to extend Oracle Service Cloud out-of-the box incident Management functionality with a custom business process automation. For this, Oracle Integration Cloud Service (ICS) will seamlessly listen/subscribe to events in Oracle Service Cloud and when a new Service Requests gets created, it will pass it on into Oracle Process Cloud Service (PCS) to manage the Human interventions.
PCS starts a new workflow and it redirects the various tasks to the appropriate task owners for approvals/rejections.
As the PCS workflow runs across the various human interventions, PCS keeps updating the Service Request status into Service Cloud (via ICS) to determine whether it is invalid and needs to be rectified or it is in progress until completion.
Finally, if we determine that this Incident Management extension workflow could become a reusable asset among other use cases, we can simply go to the ICS integration that triggers the PCS workflow and expose it as an API to be deployed and run into the Oracle API Gateway.

This is a high-level view:

Continue reading “Teaching how Oracle Integration Cloud (OIC) simplifies Application Integration, Process Automation and API Management”

Teaching How to Recover Errored Instances with Oracle Integration Cloud

Building Enterprise integrations in the Cloud with iPaaS brings many benefits, including among others: simplicity, agility and scalability. However, these benefits should not be taxed by having a weak core, not able to properly manage common enterprise requirements, such as error management. I’ve been a bit disappointed with how most iPaaS vendors handle runtime exceptions of integration flows. A typical example of this, is not being able to support dehydration for asynchronous flows (i.e. dehydration is crucial to supporting long-running instances by saving their memory state into a database, until a correlation invocation, a.k.a call-back, wakes it up to continue with the flow). This causes that when an error occurs, recovery has to start from the beginning of the integration flow that failed.

In these situations, we would have to either design an integration to be fully idempotent and stateless across all its partner links (service invocations), which is not always possible. Another way to do it is by manually handling the recovery of errored scenarios, this is to avoid state inconsistency across the previous service invocations in the orchestration, prior to the error… But then if we have to manually handle compensation, what about iPaaS being easier?

Luckily, Oracle Integration Cloud maintains simplicity at the front end and a mature and strong integration core at the backend. It acknowledges when an orchestration is asynchronous, so that dehydration points (a.k.a. break points) are enforced along the way across service invocations or long-term actions (e.g. waits), enabling with this long-term running instances avoiding to timeout, but to stay in memory (and DB back store) until all activities and external call-backs in the orchestration flow complete.

In this blog, I am going to show you how to recover errored instanced with Oracle Integration Cloud. For this, I am going to build a flow that demonstrates how errored instances recovery occurs from the latest dehydration point, allowing you to simplify complex orchestrations without having to compensate manually.

Continue reading “Teaching How to Recover Errored Instances with Oracle Integration Cloud”

Teaching How to Design and Secure an API with Oracle API Platform

This blog is the second part of an end-to-end exercise that starts explaining the steps to clone a GitHub repository that contains an agnostic Medical Records application, built by us in NodeJS and which exposes REST API endpoints via a Swagger API-descriptor running locally on Swagger UI (all included as part of the repository). The previous part of this 2-blogs series also explains the steps required to run the MedRec NodeJS application on Docker containers either locally or in the Oracle Public Cloud. For more information about this first part, go here.

Moving to this second part, we are going to cover the following steps:

Create an Apiary account used to Design APIs (API First approach) and create a new API Project using the existing MedRec Swagger API-definition.
We are going to spend a little bit of time playing with Apiary to feel comfortable in areas such as:
1. Validating API definitions
2. Testing API endpoints
3. Switching across out-of-the-box Mock Servers and real Production MedRec service end-points.
Login to Oracle API Platform and configure an API, this includes:
1. Enforcing Security and other policies.
2. Deploy API and securing access level to on-premise and Cloud-based API Gateways.
3. Publishing APIs into the API Developers Portal.
4. Linking API to Apiary Swagger API-definition living document.
Login to API Developers Portal (API Catalog)
1. Register a New Application
2. Understanding the role of API Keys
3. Reviewing MedRec API Documentation
4. Registering to consume MedRec APIs
5. Testing APIs.
Understand API Analytics, consumption, metrics and monitoring dashboards.

Continue reading “Teaching How to Design and Secure an API with Oracle API Platform”

Teaching best practices to Design, Build, Secure and Monitor APIs

In this blog, I want to share my experience after having created many APIs using different approaches and technologies. I am going to encapsulate a simple process that will help you construct APIs, starting from scratch with an idea or requirement and move it all along to a happy consumption.

The best part of APIs is that they are microservices enablers, which implies that they are not technology prescriptive, so in this blog you will see that your APIs can be implemented using any technology or programming language.

I decided to use “Jokes” as the vehicle to explain the APIs construction best practices, mainly because jokes are a simple concept that anyone can relate to, but also because I want you to feel compelled to consume these APIs and by doing so, get a laugh or two.

My original idea with jokes is to:

Get a random joke.
Translate the joke to any language.
Share the original or the translated joke with a friend via SMS.

This is the high-level view of how our end solution will look like:

Continue reading “Teaching best practices to Design, Build, Secure and Monitor APIs”

Apiary designed APIs tested using Dredd

APIs are becoming the window to the digital assets of the modern business. Well documented, well governed and easy to use APIs are key to their successful uptake, longevity and associated business success. Yes, I did say well documented. In this instance I am talking about the documentation required to describe the APIs capabilities in a manner that is meaningful for your ultimate audience, the “API Consumers”, however it will also provide the template for the API Developer to develop their code from. In the modern business climate, we probably don’t want to produce War and Peace, we simply want to take a minimum viable approach to our API documentation. But where would I find a capability that will simplify our task as API Designers, capture the design documentation for our APIs, allow us to do some initialise testing to validate the usefulness of our design before any code is cut, and also have the documentation ready for consumption by team members and interested parties using a standards based approach. Where indeed ! Look no further than Apiary.io. Continue reading “Apiary designed APIs tested using Dredd”

Teaching How to simplify building NodeJS APIs with Loopback Framework

In this blog, I am going to show you how to get started with the Loopback framework to easily auto-build REST APIs in NodeJS and persistence layer in a variety of options, including relational and non-relational databases e.g. In-memory DB, MongoDB, MySQL, Cassandra, Oracle, etc.

In terms of API design and development, Loopback allows you to work “top-down” or “bottom-up”. I am going to cover both approaches in this blog.

First, we are going to create an API model definition in place, as we are building the REST APIs, this exercise will give us a Swagger-based API definition. Alternatively, we are going to start from an existing Swagger definition and use it to implement NodeJS REST APIs pointing to a persistence layer of choice (in-memory DB, MongoDB, MySQL, DB2, Oracle, etc.). I personally prefer the “API First/Top Down” approach, as it gives me the option to properly design and test my APIs first and then, simply move to implementation phase, but this ultimately depends on situations, preferences and requirements.

Continue reading “Teaching How to simplify building NodeJS APIs with Loopback Framework”