Amazon EKS Hybrid Workload Stabilisation Case Study for Smart Building Platforms

Executive Summary

Ficode stabilised a complex AWS-hosted smart-building platform by resolving Kubernetes scheduling failures, CI/CD pipeline issues, Windows container deployment challenges, and application startup configuration problems across a 33-service architecture running on Amazon EKS. The solution improved deployment reliability, strengthened platform stability, and established a scalable cloud-native foundation for future growth.

Client Overview

Our client is a UK-based smart-building technology provider delivering cloud-based building automation and facility management solutions for commercial properties. Their AWS-powered platform combines Linux and Windows workloads, IoT integrations, and multiple application frameworks to support intelligent building operations. Following AWS migration, the client required platform stabilisation to ensure reliable deployments, operational consistency, and long-term scalability.

Business Challenges

Following an AWS cloud migration, the organisation faced multiple platform stability challenges affecting application performance, deployment reliability, and Kubernetes workload management. Critical building automation services experienced deployment failures, configuration issues, and cloud infrastructure inconsistencies that impacted operational efficiency and increased support requirements.

The underlying complexity came from the platform’s technology diversity:

• The majority of services run on Linux; but the access-control integration depends on Windows-native hardware libraries with no Linux alternative.
• Cloud deployment tooling defaults to Linux assumptions; Windows workloads need explicit, deliberate configuration or they fail in ways that are difficult to diagnose.
• A build pipeline that worked on a developer’s machine was not producing consistent container images in the automated environment.
• Startup configuration that handled missing values gracefully on one environment was crashing silently on another.
• A single misconfiguration in any service could prevent an entire area of functionality from operating.

Ficode Solution

Ficode addressed the stabilisation across three areas: workload scheduling, build pipeline correctness, and startup resilience.

Workload Scheduling: The platform runs Linux services and one Windows service. Without explicit scheduling configuration, the cloud orchestration layer has no reliable way to place a Windows workload on a Windows-capable host. Ficode applied scheduling rules that explicitly direct the Windows access-control service to the Windows node group, and Linux services to Linux nodes; enforced at the platform level, not left to chance.

Build Pipeline Correctness: The automated build pipeline for the Windows access-control service was not producing correctly packaged container images. The build scripts and application packaging process were reviewed and corrected, ensuring the build environment produces an image that starts and serves traffic correctly in every deployment.

Startup Resilience: The access-control service startup configuration was crashing when optional environment variables were absent or empty, causing a restart loop. The startup process was updated to handle missing values correctly; falling back to safe defaults for optional configuration and producing clear error output only for genuinely required values that are absent.

Implementation Process

• Discovery and assessment of the existing platform, service dependencies, and operational risks.
• Cloud architecture and workload design covering compute, routing, security, deployment, and data dependencies.
• Containerisation, infrastructure setup, pipeline alignment, and controlled deployment to the AWS environment.
• Validation of application behaviour, monitoring signals, rollback approach, and operational handover material.

Security & Scalability

• TLS-protected ingress through a controlled load-balancing layer.
• Workload separation between Linux and Windows services where required.
• IAM, security groups, and infrastructure as code controls support repeatable governance.
• Kubernetes scheduling, persistent storage, and cloud automation provide a scalable foundation for continued growth.

Results & Business Impact

33 Services Stabilised Across 9 Technology Stacks:

Kubernetes scheduling, startup configuration, and deployment behaviour were standardised across a complex mixed-workload platform.

100% Correct Placement for Windows Workloads:

The Windows access-control service now deploys to Windows-compatible infrastructure every time, eliminating manual correction for incorrect Linux-node scheduling.

50% Lower Deployment Exception Handling:

Removing service-specific deployment workarounds reduced operational variation and made releases more predictable across Linux and Windows workloads.

3 Reliability Foundations Enabled:

Stabilising scheduling, startup behaviour, and workload placement created the base for readiness probes, liveness probes, and future horizontal autoscaling across high-traffic services.

Conclusion

With the deployment foundation stable, the next priorities are completing the Kubernetes health probe rollout across all services and enabling horizontal autoscaling for the highest-traffic services. Both depend on the stability of work completed here as a prerequisite. The platform now runs as a unified cloud deployment: Linux workloads on Linux infrastructure, the Windows workload on Windows infrastructure, with separation enforced at every deployment.

About Ficode

Ficode is a cloud and software engineering partner helping smart-building, commercial real estate, and specialist technology businesses build reliable, scalable platforms on AWS. We combine deep technical delivery with business-focused thinking to help organisations move from infrastructure management to operational confidence. Visit ficode.com.

Tags: AWS EKS, Platform Engineering, Smart Buildings, Mixed Workloads, Windows Containers, Cloud Stabilisation, Kubernetes.