You need to consider the type of environment you need to have when you want to develop an application. First, you can develop your application on your client's machine. Once you have completed the task, it needs to be tested. For that, you should have a Testing Environment. If your application works fine in Testing Environment and you have got the confidence to go live, you need to promote your Application in the Production Environment. If you would like to have continuity of business, you may need Disaster Recovery as a backup plan in case your Production Environment has encountered some problems. This is the most general scenario to develop an application.

Production Environment

Type of your Application - Is it a real-time application? Is it integrated with other systems? How much data is to be processed? Does it operate 24 hours per day? Type of your Business - How critical is your business? Who will be affected if this application is down? A number of the user (Active user and Name user) Number of Transactions - Number of transactions within a period of time such as the number of transactions in a month. Accepted downtime - Number of downtimes in a year and how long is the accepted downtime per each occurrence?

Disaster Recovery Environment

The Disaster Recovery Environment is the backup environment for your Production Environment and cannot be operated for a long duration. To design the Disaster Recovery Environment, you need to consider the following points.

• RPO (Recovery Point Objective) - How much of your data can be lost when you decide to turn on the Disaster Recovery Environment?

• RTO (Recovery Time Objective) - How long can it take when you decide to turn on the Disaster Recovery Environment?

• How much percent of your Production Environment Capacity do you expect to use in the Disaster Recovery Environment?

Testing Environment

Testing Environment is used for testing your application. To design the Testing Environment, you need to consider the following points.

• How many testers or people involved do you plan to use the testing environment?

• How many systems do you have to integrate with?

• How much data do you plan to be used in the testing process?

ONEWEB is an Application Development Platform that is built on Java EE technology and supports a 3-Tiers Architecture consisting of Web Tier, Application Tier, and Database Tier. This technology is developed as an Enterprise-Grade Application that will enable you to scale capacity up to serve your business growth.

ONEWEB also supports containerized architecture for deployment on the cloud. There are many options for the users to choose the ONEWEB Architecture depending on your business demands. The standard architecture of ONEWEB as preferred are as follows:

• Standalone Architecture

• High Availability Architecture

• Cloud Architecture

Cloud Architecture is an alternate way for you to host your Application on a Cloud Provider. This type of architecture has many benefits such as lower cost of server maintenance, lower cost of hardware investment, etc. If you are looking for Cloud there are many choices for Cloud solutions such as PaaS (Platform as a Service), IaaS (Infrastructure as a Service), and SaaS (Software as a Service). ONEWEB can be hosted on the cloud as PaaS or SaaS solution based on your customer preferences.

High Availability Architecture is to be considered for serious critical systems, which can tolerate a certain amount of failure and errors before they no longer work properly. The design of this architecture comes from a key criterion for the capability of your service to meet your expected service level agreement (SLA).

The key aspects to design High Availability Architecture are as follows.

Avoid single points of failure - To avoid single points of failure and to maximize system availability, it needs to have some degree of redundancy. The solution typically involves horizontal scaling across multiple machines.

1. Hardware redundancy - Eliminate single points of failure in the system by including hardware redundancy. There are many techniques to design hardware redundancy. - Use horizontal scaling to distribute application servers across multiple physical machines (Active-Active) - User backup server (Active-Standby)

2. Process redundancy - Provide process redundancy and isolation so that a failing server does not impact the remaining healthy servers.

Load balancing (Active-Active) - Use Load balancing techniques to make sure that the individual servers are not overwhelmed with client requests while other servers are idle.

Fail-over support (Active-Standby) - The environment must be able to continue processing client requests, even if one or more components are offline.

Standalone Architecture is simple, easy to maintain, and most budgetary to cost. This architecture is suitable for less critical systems that can accept some downtime to recover or upgrade the system. This architecture has 3 tier components which consist of the Web tier, Application tier, and Database tier as shown in the following diagram.

Web tier - This tier is used to receive a request from the client or load balancer, then process the static content request and forward a business logic request to the Application Server in the Application tier.

Application tier - This tier is used to process the request from the client using Application Server Middleware.

Database tier - This tier is used to persist data into storage.

The Standalone Architecture diagram above is shown as three instances of servers, which is the best virtue for Architecture. You can also separate each component using a firewall or network infrastructure to secure your system and improve performance. But it is not necessary to separate each component (Web, Application, and Database), as these components can also run on the same server but in that case, the server should have enough capacity for all components. You may also choose to separate these into two servers, one for the Web, whereas the Application, and the database on the second server. This decision certainly depends on your resources and your security policy.

ONEWEB can be installed as distributed containers using simple docker engine or as an orchestrated container architecture using Kubernetes. The ONEWEB containerized installation include the following containers.

• oneweb-iam2 - Authentication & Authorization

• oneweb-uxp - User Experience Runtime

• oneweb-bpp - Business Process Runtime

• oneweb-mfr - Microflow Runtime

• oneweb-mfd - Microflow Designer

• oneweb-pgd - Page Designer

• oneweb-pgb - Page Builder

• oneweb-designersuite - AppSpace, App Designer, Process Designer and other Utilities

• apache conatiner - Web Server

• database container - Database

The sample Kubernetes architecture followed by ONEWEB is depicted in the image below.

ONEWEB uses ELK stack for monitoring cloud infrastructure as well as the platform services.

ONEWEB can be setup in different configurations depending on the customer requirements. Customers can pick and choose the products to be included in their subscription.