API based architecture for web applications in the Oracle Cloud

When it comes down to developing websites and web applications a lot has changed since the time I developed my first web based applications. Changes ways of developing, changing platforms and frameworks, changing programming languages and changing architectures. Almost every company today is considering, having a website, as a given. Where websites used to be a relative static brochure showing what a company was about we are already well on the track of making websites a customer portal and application. Websites and web based applications are becoming more and more a part of the overall customer experience and customers expect that they can do everything and find everything they might want on a corporate website.

This makes that a website or web based application is becoming more and more critical to the success. A failing website, a slow website or a website unable to deliver the experience expected by the customer will have a direct negative effect on the customer satisfaction and as a result of this a decreasing willingness to do business with a company.

To cope with the growing importance of web based applications and to cope with the requirement to be scalable architectural principles used to develop web based applications are changing rapidly. One of the examples currently seen is the change to API centric development.

Traditional architecture
The traditional, as shown in figure 1, is based upon a direct connection between the web application and the Oracle database instance (or any other database for that matter). A customer would interact with the web application using HTTP or HTTPS (A) and the web application would interact with the database (B) using SQL.NET whenever needed.

figure 1 - traditional architecture 

Simple API based architecture
When looking at applications that are currently build a number of web based applications are still being developed using the more traditional architecture as shown above. Companies who do require their applications to be more fault tolerant, scalable and secure are adopting new architecture principles. Commonly a more API based architecture is being used where the web application is not directly communicating with the database. In those cases the customer facing application is communicating with an API and the API service will communicate with the database on behalf of the web application.

Another observation that can be made is that the trend is that more and more open source frameworks and solutions are used. In the below example you will for example see NGINX and Flask being deployed on Oracle Linux for serving the API’s to the web applications.

In the below model the web application is not directly communicating with the Oracle Database. In this model a customer would interact with the web application using HTTP or HTTPS (A) and the web application would interact with the API’s (B) using HTTPS whenever needed. The API server running NGINX and Flask will interact with the database server (C) using SQL.NET whenever needed.

figure 2 - API based architecture

As shown the above diagram in figure 2 shows an additional layer is introduced in the form of NGINX and flask deployed on Oracle Linux. The use of NGINX and flask is only an example which is chosen in this post as both as it is becoming more and more a popular deployment used in this type of scenarios. Other solutions can be used also in this place and play this role.
Added value

Companies who do require their applications to be more fault tolerant, scalable and secure are adopting new architecture principles.

The added options for scalability and fault tolerance are provided in the “layer” by having the option to create a cluster of servers providing the API functions to  the web application layer. As shown in figure 3, you can create a cluster of NGINX and Flask nodes running on Oracle Linux to your overall deployment architecture. When running a deployment as shown in this example on a public or private cloud you can quickly scale up and down your API layer when needed.

What you have to take into account when deploying a automatic or semi-automatic scaling of your API layer is the way you will distribute the load over the different nodes and how your routing / load balancing solution will be made aware of nodes that are added or removed.

By having a clustered API layer you will at the same time add on resilience against the failure of a node. In the deployment model shown in figure 3 the loss of a single node will not stop your web application to function. This provides an additional insurance that your application will be available to end users.

Figure 3 - API cluster

The added security by using this deployment model, regardless of the use of a clustered layer or not, comes from the fact that your customer facing web application is no longer directly connected to your database. In a traditional web configuration a malicious user could try to exploit for example SQL injection and regardless of the fact if that succeeded he would directly interact with the database. In the API based model injection would result in sending injected code to the API and not to the database directly. 

In this model you can add security measures in the web application itself, the API layer and the database opposed to having only security measures in the web application and the database. By adding this additional layer you can have build the API to function as an additional security tollgate. 

Enabling the next step

An added benefit of this model is that it enables enterprise to prepare, or adopt the next step in architecting applications. The model described above is ideally fitted to develop microservices oriented architecture applications. In a microservices oriented architecture you can use the API layer to develop and run your microservices. 

Applications build upon microservices are currently seen as the way forward and the next step to build robust, flexible and scalable applications. 

Moving it all to the cloud

The above example is drawn in a way that hints at a traditional deployment model. As stated, when deployed in a private or public cloud you will have the added benefits of options to quickly scale up and scale down the number of nodes in your API layer.

When selecting a public cloud solution the option for Oracle Public Cloud might be quite obvious. As Oracle provides both Oracle Database and Java a Oracle database and Java oriented application might find its best public cloud partner with Oracle. 

Figure 4 - cloud deployment

Database cloud deployment

The deployment of your database in the Oracle public cloud can be done by making use of the Oracle Public Cloud database service.

Java application deployment

For your java application you can make a selection out of a couple of products. The Oracle Java Cloud Service might make the most sense. However, you might also be able to make use of the Oracle Application Container Cloud or you can deploy everything yourself by making use of the Oracle Compute service which provides you raw computing power in the form of a Oracle Linux VM.

API layer deployment

Depending on the language you want to develop your application in and the level of “outside of the box” development you might want to do you can select the Oracle Integration cloud, you can also make use of the Oracle Application Container Cloud which enables you to deploy docker containers and deploy your API custom code in the container. When using the combination of NGINX and Flask and you focus on developing Python code (which is a very good choice for the API layer in my personal opinion) you might want to make use of the Oracle Compute service and the Oracle Linux VM’s provided by this public cloud service.