Infrastructure & Reliability · Middleware — Web · Chapter 22 of 33
Web and application server products, and the infrastructure under them
Who makes what, which of them a bank actually runs, and how to size an estate from a request rate rather than from a vendor’s reference architecture.
This chapter names products, so a reminder of the rule behind it: the products follow from the jobs described in the last two chapters. A web server terminates TLS, proxies and filters; an application server hosts code and lends it pools, transactions and messaging. Every product below is a particular answer to those jobs.
Web servers and proxies
| Product | Who owns it | Licence | What it is best at |
|---|---|---|---|
| Apache HTTP Server (“httpd”) | Apache Software Foundation | Open source (Apache License 2.0) | The long-time default; a module for almost everything |
| IBM HTTP Server | IBM | Supplied with WebSphere | Apache httpd, built and supported by IBM as the front end of WebSphere estates |
| Nginx | F5, which acquired Nginx in 2019 | Open source; NGINX Plus is the commercial edition, sold per instance | Reverse proxying and very many concurrent connections |
| Microsoft IIS (Internet Information Services) | Microsoft | Included with Windows Server | Hosting .NET applications on Windows |
| HAProxy | HAProxy Technologies | Open source; enterprise edition | Load balancing, for both HTTP and raw network connections |
| Envoy | Cloud Native Computing Foundation | Open source | The proxy inside service meshes and Kubernetes ingress |
On the public internet, W3Techs’ survey for 26 September 2026 finds Cloudflare’s servers in front of 31.0% of websites whose server it can identify, Nginx 30.8%, Apache 22.0% and Microsoft IIS 3.0%. Do not carry those numbers into a bank. They count public websites; inside a bank’s estate, IIS fronts a large share of internal .NET applications and IBM HTTP Server fronts every WebSphere estate, and neither shows up much in a survey of the public web.
Application servers
| Product | Who owns it | What it implements | Status, September 2026 |
|---|---|---|---|
| Apache Tomcat | Apache Software Foundation | The web profile only — a servlet container | 11.0 (Jakarta EE 11), 10.1, and 9.0 — the last javax line, supported to at least 31 March 2027 |
| Eclipse Jetty | Eclipse Foundation | A servlet container, often embedded inside applications | Active |
| IBM WebSphere Application Server (“traditional”) | IBM | The full Java EE platform; the Network Deployment edition manages clusters | 8.5.5 and 9.0.5; no planned end of support |
| IBM WebSphere Liberty / Open Liberty | IBM | Modular: switch on only the features an application uses, javax or jakarta | Single-stream continuous delivery; no end-of-support date. Open Liberty is the open-source core |
| Oracle WebLogic Server | Oracle | The full platform | 15.1.1 (November 2025, Jakarta EE 9.1); 14.1.2 still javax |
| Red Hat JBoss EAP (Enterprise Application Platform) | Red Hat, owned by IBM since 2019 | The full platform, as a supported build of the open-source WildFly | 8.0 (February 2024, Jakarta EE 10); 7.4 is javax |
| WildFly | Community project | The open-source upstream of JBoss EAP | Frequent releases, community support only |
| Payara | Payara Services | A continuation of the GlassFish reference server | Open-source and commercial editions |
One ownership fact is worth knowing going into an interview: IBM owns WebSphere and, through Red Hat, JBoss — and, as the messaging chapters show, IBM MQ and, since March 2026, Confluent, the main commercial Kafka company. The largest vendor on both sides of a typical bank middleware estate is now the same company.
The other half of many bank estates is not Java at all. .NET applications run on IIS or on Microsoft’s own cross-platform web server, Kestrel, and are licensed through Windows Server rather than through an application-server product — which matters when the licence chapter compares costs.
What a production estate is made of
- Traffic management — a global traffic manager that answers DNS lookups with the address of a healthy site, and hardware or virtual load balancers in each site (F5 BIG-IP and NetScaler are common in banks).
- A web tier in the demilitarised zone (DMZ) — two or more web servers per site, holding certificates and nothing else of value.
- An application tier — nodes each running several Java Virtual Machines (JVMs), or containers on a platform.
- An administration layer — WebSphere’s Deployment Manager, WebLogic’s Administration Server or a JBoss domain controller, which pushes configuration and deployments to every node. If it is down, the estate keeps serving but cannot be changed, a distinction worth stating in an interview.
- Session storage, if sessions are not held in the servers themselves.
- Observability — application performance monitoring agents inside each JVM, log shipping, and metrics; covered in observability tools.
- Key and certificate stores on every tier — the inventory from the previous chapter.
Two terms from resilience planning belong here. The recovery time objective (RTO) is how long the service may be down after a site fails; the recovery point objective (RPO) is how much data, measured in time, may be lost. Active-active application tiers bring the first close to zero; only synchronous data replication brings the second there, and it costs latency. The regulatory side is in operational resilience.
Sizing an estate from a request rate
Vendor reference architectures are a starting point, not an answer. The defensible method starts from the load you must carry and works down, and it uses Little’s law from the first web chapter.
| Step | Worked example | Why |
|---|---|---|
| Peak request rate | 1,200 requests a second at the busiest minute of the busiest day | Size for the peak you have seen, plus the growth you expect before the next review |
| Time in system | 180 milliseconds average at the application tier | Measured in production or in a load test, not guessed |
| Requests in flight | 1,200 × 0.18 = 216 | Little’s law |
| Comfortable concurrency per JVM | 40 (a pool of about 60, run at two-thirds) | Leaves room for latency spikes without queueing |
| JVMs to carry peak | 216 ÷ 40 = 5.4, so 6 | Round up, always |
| Per site | 6 JVMs, because either site may carry everything alone | The rule in the diagram |
| Nodes | 3 JVMs per node: 2 nodes carry the peak, plus 1 spare for patching or failure | So a node can be drained for patching at peak without falling short |
| Memory per node | 3 × (4 GB heap + about 1.5 GB outside the heap) + operating system, about 24–32 GB | Heap from measurement; the JVM uses memory beyond its heap too |
| CPU | From a load test: if one core sustains 60 requests a second at target latency, the peak needs 20 cores per site | CPU is the one input arithmetic cannot supply — only a load test can |
The spare node is the line that gets cut in budget reviews, and the one whose absence turns the next patching window into an incident.
On a container platform
The same estate increasingly runs as containers. The web tier becomes an ingress controller, each application ships its own Liberty, JBoss or Tomcat inside its image, and scaling becomes a replica count. Vendors provide operators — software that runs their servers on Kubernetes — for Liberty and JBoss EAP. The sizing arithmetic above does not change; only the unit changes from a JVM on a node to a container on a cluster.
The inventory an auditor asks for first
Every question in the last two chapters — which servers are out of support, which Java runs where, which certificate expires next — is answered from one list. A middleware team should be able to produce it on demand, per node:
- Product, version and fix-pack level, and the vendor’s end-of-support date for it.
- The Java runtime: its version and its vendor, because the vendor decides the licence.
- Every certificate on the node, its expiry date and who renews it.
- The applications deployed, and the business owner of each.
- The licence entitlement it consumes — cores, PVUs or a subscription — and whether the measurement tool covers it.
An estate that cannot produce this list in a day is carrying three risks it cannot size: unsupported software, unexpected licence bills and certificate outages.
Check yourself