Application and Web Cluster Services
Deployments that happen on a Tuesday afternoon because the application tier holds no state — which is the actual prerequisite, not the deployment tool.
What this usually looks like
The application runs on several nodes, but a deployment still needs a maintenance window because the nodes are not interchangeable.
- Uploads live on one node’s local disk, and that node is somehow load-bearing.
- Sessions are sticky, so the load balancer is choosing which users get logged out during a restart.
- Deployments are all-at-once because nobody trusts a mixed-version window.
- Nobody can say what the tier saturates at, only that it "seemed fine at launch".
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- State audit: what lives on the application nodes that should not
- Session handling and load-balancing policy review
- Capacity measurement against realistic traffic, not peak marketing numbers
- Deployment and rollback procedure review, including the abandon criteria
Build
One-off delivery: design, code, hardening, handover
- State extraction: uploads to object storage, sessions to Redis or a shared store
- Rolling deployment with health-checked drain and atomic release switching
- Load balancer configured for the traffic shape, not just round-robin
- Database tier reviewed against the application access pattern
- Rollback rehearsed, with a measured time to previous release
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Deployment support during change windows, for the releases that matter
- Capacity and saturation review each quarter against real traffic
- Runtime and dependency patching on an agreed cadence
- Error-rate and latency budgets monitored per tier
- Quarterly rollback drill so the procedure stays real
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Web tier
- nginx
- Apache httpd
- PHP-FPM
- Varnish (if caching is warranted)
Application runtimes
- PHP
- Java (Tomcat · WildFly · JBoss EAP)
- Node.js
- Python (Gunicorn/uWSGI)
- JVM tuning + GC analysis
Java clustering
- mod_cluster
- JGroups
- Infinispan / JDG
- session replication vs. external store
Session & state
- Redis-backed sessions
- sticky routing where justified
- JWT with revocation
- shared object storage for uploads
Delivery
- release directories + symlink switch
- rolling deploy with connection draining
- health-check endpoints
- Blue/green where the app permits
Platforms
- cPanel / WHM (HA)
- Plesk
- DirectAdmin
- containerised app tiers on Kubernetes
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Deployments happen in business hours with zero user-visible errors and no maintenance window.
- Rollback to the previous release is measured and takes under five minutes.
- Losing one application node removes capacity without removing sessions.
- The tier’s saturation point is a measured number, reported to you.
- No application node holds unique data — verified by taking one out of service at random.
What we would build, and where the weak point is
The session store is now the single point of failure the application tier used to be — a trade that is worth making, because it is one component with a clear ownership boundary instead of six nodes carrying hidden state. It still needs its own failover test.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Out of scope
Application code changes and feature development
We make the platform deployable and observable. What the application does is your product team’s work, and we stay out of it.
- Requires partner
Front-end build tooling and asset pipelines
We will host and serve the output. We do not take ownership of your front-end toolchain.
- Requires partner
WAF rule content and application-layer security testing
We run the WAF and can tune rules against observed traffic. Application penetration testing is a separate specialist engagement.
- Out of scope
Legacy proprietary application servers without vendor support
If your vendor has stopped supporting it, we would be guessing at documented behaviour. We will tell you that before quoting.
What it looked like last time
A publishing platform whose six-node PHP tier required a monthly maintenance window: state extracted to shared object storage and Redis, rolling deployments with health-checked draining, and a measured rollback under five minutes — moving releases from monthly weekend windows to weekly business-hours changes.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the platform engineer about your application & web clusters
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a platform engineer: botonwa@gmail.com · +86 130 5181 3099