Build your web application as a set of microservices that can be independently tested, deployed, and owned by different application teams. Expose services as REST APIs and communicate with other microservices using APIs.
Web applications typically contain a front end, which is what users see, and a backend that has the business logic. In response to a user or API request, a web application interacts with the API or with data stored in a file system, object storage, block storage, or a database. The application must support different clients, such as browsers and mobile devices, and interact with other systems and apps by using APIs. Web apps also need to be scalable to handle spikes in demand and operate well under stress with low latency. They must be available 24/7, they must be resilient enough to produce data when requested, and they must not lose stored information. The apps should be modular, and it must be easy to make updates or modifications with zero downtime.
Security is of paramount importance for web apps exposed to the internet. Data encryption, TLS, DDoS protection, firewalls, and granular access management are a must. The application must guard against attacks on the front end that use cross-site scripting (XSS) and cross-site request forgery (CSRF), and attacks to the backend.
Oracle Cloud Infrastructure (OCI) provides scalable, secure, reliable, and highly performing infrastructure required for the most demanding web apps. This document describes the design principles to architect a web or mobile application.
Use lightweight open-source frameworks and mature programming languages
Build your web application by using Helidon or Micronaut, which provide ready-to-use support for common features like logging, telemetry, security, configuration, and common patterns (such as building REST APIs) that web apps need. Use Java, which is platform-independent, portable, has a rich set of libraries, and has been used by millions of developers to build scalable, resilient, and secure web apps.
Build apps as services that communicate over APIs
A web application needs to interface with other business systems and services that are outside the organization. Services that are part of a web application should expose their interfaces through well-defined APIs for interaction and collaboration. Use OCI API Gateway as the single point of entry for all clients, and route API requests to the appropriate service.
Automate the build, testing, and deployment
The teams that develop web apps need to deliver code rapidly and frequently, and deploy the apps in a way that minimizes downtime. Use OCI DevOps to establish a consistent and automated way to build, package, and test apps. Use OCI Resource Manager to automate the provisioning of your infrastructure which could include API Gateway, load balancers, databases, Kubernetes clusters, and other services.
Use fully managed services to eliminate complexity in application development, runtimes, and data management
Maintaining a web application isn't an easy task. Use managed services such as OKE, Oracle Cloud Storage, and Autonomous Database, which maximize availability and scalability to respond to the changing demands for your web apps. Managed services ensure that the web application is available 24/7/365 and protect it if a failure occurs in the data center where the infrastructure is hosted.
Keep application tier stateless
Keep middle-tier components of application stateless. If the application state is to be stored use Oracle Autonomous database to store application data and state for consistency, durability, and fast recoverability from the root of the application state.
Use converged databases with full featured support across all data
Web applications use data in different formats, and they need to store and search for the data in a data store. The data might be tabular (relational), unstructured, formatted as XML and JSON, spatial, or graph. Traditionally, this disparity meant using a relational database for relational data, a document store for unstructured data, and graph databases for hierarchical linked data. But the use of multiple databases leads to operational complexity and data inconsistency. To solve this problem, use a single multi-model Autonomous Database to store multiple types of data, index them, and provide ways to search the data.
Instrument end-to-end monitoring and tracing
A web or mobile application can contain hundreds of services, owned by different application and business teams. Observability tools are important for gaining visibility into the behavior of these inherently distributed systems. Instead of each team building their own solution, centralize the observability solution by using the Oracle Cloud Observability and Management services. These services monitor the entire stack, from front end to backend, to quickly find and fix issues in the application.
Eliminate single point of failure through automated data replication and failure recovery
Web applications must be resilient, recover from failures, and minimize downtime and data loss. You can eliminate a single point of failure by implementing redundancy in the following ways: In OKE, set up node pools with a minimum of three nodes with each node in a separate availability domain in a multi-availability domain region. In a single availability domain region, setup node pools in OKE with a minimum of three nodes with each node in a separate fault domain. Use a single public load balancer and multiple private load balancers with multiple ingress controllers for redundancy in OKE.
Design a pilot light disaster recovery topology to restart apps and restore workloads quickly in a standby region if a disaster strikes the primary region where the web application is hosted. Configure your CI/CD pipeline to deploy your application to a standby region to recover from region failures. Replicate your block storage volumes across regions by using block storage volume replication and object storage replication. Provision required infrastructure in the standby region using Oracle Resource Manager if the primary region fails. Setup the autonomous database for maximum availability using Autonomous Data Guard to minimize operational downtime and data loss.
Additionally, test for resiliency to see how the application behaves under abnormal conditions that occur intermittently. For example, you can adopt the Chaos Monkey framework for chaos testing. Also, use throttling, circuit breakers, and retry mechanisms to implement a resilient web app.
Implement a defense-in-depth approach to secure the application lifecycle
A web application on the internet should be designed with sufficient security to guard against attacks by malicious entities. Review all your apps, client-side code, and third-party code to check for suspicious behavior. Use filtering rules and set up DDoS protection by using OCI Web Application Firewall (WAF) to protect the application from unwanted internet traffic.
Store sensitive information such as passwords and auth tokens in OCI Vault. Set up encryption of Kubernetes secrets in etcd. Rotate and set short lifetimes on the certificates that your web application uses to make it harder for an attacker to impersonate a trusted entity.
Follow the principle of least privilege to ensure that users and service accounts have only the minimal privilege necessary to perform their tasks. Control who has access to the web application components by using OCI Identity and Access Management (IAM). Use multifactor authentication in IAM to enforce strong authentication for administrators to restrict access to the application components.
The following diagram illustrates this reference architecture.
Description of the illustration architecture-maf-web-mobile.png
The architecture has the following components:
- Web Application Firewall (WAF)
WAF is a PCI compliant global security service that protects applications from malicious and unwanted internet traffic. It can protect any internet-facing endpoint, providing consistent rule enforcement across all customer's applications
- OCI API Gateway
OCI API Gateway is a fully managed regional API gateway service that is used to provide protected RESTful API endpoints for Oracle Kubernetes Engine (OKE) and any other service or endpoint running on Oracle Cloud Infrastructure. In this example architecture, the requests are routed to a private load balancer which passes on the requests to a service running in OKE.
- Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)
OCI IAM provides robust authentication, MFA, social login, self-registration for end-users, identity management, single sign-on (SSO), and identity governance for applications.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.
- Autonomous database
Oracle Autonomous Transaction Processing is a self-driving, self-securing, self-repairing database service that is optimized for transaction processing workloads. You don't need to configure or manage any hardware or install any software. OCI creates the database and manages backups, patching, upgrades, and tuning.
- Object storage
Object Storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. Use standard storage for hot storage that you need to access quickly, immediately, and frequently. Use archive storage for cold storage that you retain for long periods of time and seldom or rarely access.
In this architecture, the media assets of the application are stored in Object Storage in a bucket of the standard storage class.
- Container Engine for Kubernetes (OKE)
OKE is a fully managed, scalable, and highly available service that you can use to deploy your containerized apps to the cloud. You specify the compute resources that your apps require, and Container Engine provisions them on OCI in an existing tenancy. Container Engine uses Kubernetes to automate the deployment, scaling, and management of containerized apps across clusters of hosts.
All the resources are deployed in a single availability domain in an OCI region. The tiers are isolated in separate subnets in a single virtual cloud network (VCN). Network security groups (NSG) serve as firewalls to regulate the network traffic to and from the resources in each tier. A route table attached to each subnet contains rules to direct traffic to destinations outside the VCN.
Other alternative architectures such as Single-page Architecture, Progressive Web Applications (PWA), or JAMStack can be considered but are not shown here.
The following diagram illustrates this alternate architecture.
Description of the illustration architecture-maf-web-mobile-alternative.png
The architecture has the following components:
- Load balancer
The OCI Load Balancing service provides automated traffic distribution from one entry point to multiple servers in the backend.
- Web servers
OCI Compute lets you provision and manage compute hosts. You can create compute instances with shapes that meet your resource requirements (CPU, memory, network bandwidth, and storage). After creating a compute instance, you can access it securely, restart it, attach and detach volumes, and delete it when you don't need it.
The web servers in this architecture run on compute virtual machines.
- Autonomous database
Oracle Autonomous Transaction Processing is a self-driving, self-securing, self-repairing database service that’s optimized for transaction processing workloads. You don’t need to configure or manage any hardware or install any software. OCI creates the database and manages backups, patching, upgrades, and tuning.
- Network security group (NSG)
NSGs act as virtual firewalls for your compute instances. With the zero-trust security model of Oracle Cloud Infrastructure, all traffic is denied, and you can control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of VNICs in a single VCN.
In this architecture, separate NSGs are used for the load balancer, web servers, and the database.
- Route tables
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
Example Use Case
This use case describes a customer ordering system for a store that sells GPUs online.
The following diagram shows the architecture for this use case.
Description of the illustration architecture-maf-web-mobile-example.png
Traffic from the public internet is routed by the DNS service through a web application firewall (WAF) to API Gateway, which forwards the incoming requests to an Ingress (Nginx) microservice via the load balancer. The application is made up of a front-end service, an orders service, a messaging service, and an inventory service. All of these services are containerized and are in the OKE cluster. Each of these services exposes its interfaces by using REST APIs. Data is stored in Autonomous databases.
The customer places an Order for GPUs using the Front-end Service from either a web application or an app on a mobile device. The Orders service and the Inventory Service communicate with each other using the messaging service (NATS). The orders service reads and writes order data in the orders pluggable database (PDB). The Inventory service reads and writes inventory data in the inventory pluggable database. The orders service sends a notification using the Notification service so that the customer can be informed of the order status via email or Slack. The customer can get the order status from the front-end, which looks up the order using the REST API for the orders service.