Fabrice Triboix

MyDocSafe needed expert help to design a monitoring system suited to their application. They experienced a lot of instability, server crashes, and performance problems. Once this immediate solution was in place, they required an expert to design and implement a highly available and scalable architecture to run their workload reliably on AWS, complete with automated deployment.

Work done:
• Wrote Ansible roles and playbook to install CloudWatch Agent on EC2 instances and configure Amazon SNS and CloudWatch to notify key people of alarms on EC2 instances.
• Tweaked Apache configuration to stop it from crashing under heavy load.
• Wrote Ansible roles and playbook to create Let's Encrypt SSL certificates using DNS challenge, including creating the subdomain on Amazon Route53.
• Installed and configured ELK stack to monitor Apache logs.
• Designed a highly available and scalable architecture to run a complex workload reliably.
• Progressively migrated the existing system to the new architecture.
• Employed the new architecture in production.

I worked as part of the system team who released set-top-box software to a major EU broadcaster.

Work Done:
· Set up and maintained a variety of software tools to enable the smooth running of the continuous integration process.
· Set up the Coverity static analysis and enabled nightly automation using Jenkins
· Set up BlackDuck open-source code matching.
· Configured Nagios and set up an NRPE with custom Git checks.
· Set up various Cron/Jenkins jobs with Bash/Python to automate tasks.
· Worked in a Scrum process with three-week iterations with a team spread over three countries.
· Worked with a codebase of 20 million+ lines of code.
· Detected and responded to the system problems.

Technologies: Linux, CentOS, Coverity, Jenkins, Black Duck, Continuous Integration, Scrum, Bash, Python, iptables/Netfilter, Nmap, Git, Rally

Armedia needed an AWS specialist and DevOps expert to help them modernize the architecture of ArkCase, a case management system. They needed to move from running everything on one server to a modern architecture based on Kubernetes, microservices, and infrastructure as code (IaC). Additionally, they required an AWS expert to help them build an AWS marketplace offering for ArkCase.

Tasks:
- Move from a monolithic architecture to a microservice-based architecture
- Dockerize various services
- Write Helm charts
- Secure the Kubernetes cluster using network policies and RBAC
- Install and configure Istio to encrypt internal traffic and facilitate distributed tracing
- Install and configure observability tools: Loki for log aggregation, Prometheus and Grafana
- Write CloudFormation templates to set up the infrastructure on AWS
- Write Lambda functions in Python as CloudFormation custom resources or for admin tasks such as rotating secrets with the SecretsManager
- Modify existing Ansible roles and playbooks
- Build an internal PKI using IaC on AWS using only serverless services; certificates are renewed automatically when they expire and when CA certificates are renewed themselves.

• Client: HM Revenue & Customs (UK)
• Sector: Government
• When: June 2023 to March 2024
• Role: Platform engineer, HAWK platform team, remote
• Stack: AWS, EKS, RDS, Terraform, HashiCorp Vault, Keycloak, GitLab CI, Helm, Prometheus, Grafana

HAWK is HMRC's shared runtime for other HMRC projects (EKS, RDS, Vault, Keycloak, Prometheus, Grafana, CI/CD). I split my time between the platform itself and being the point of contact for one tenant.

That gap is where onboarding slows down: the platform team wants people to use the design; tenants want to ship. I fixed platform issues driven by real tenant pain, wrote their GitLab pipelines, ran their environments, and explained the platform to engineers whose job was the application, not HAWK. Feedback on the work and the communication was excellent.

What I still look for on reviews: docs written for tenants, a working first pipeline on day one, errors that name the fix, and a named owner on the platform team for each tenant.

• Client: NatWest Group (London, UK)
• Sector: Banking
• When: December 2024 to September 2025
• Role: Platform engineer, core platform team
• Stack: AWS, EKS, Terraform, OpenTelemetry, Amazon Managed Prometheus, Amazon Managed Grafana, CloudWatch

On NatWest's multi-tenant EKS platform for business-critical services, Grafana was a hand-built proof of concept. There was no systematic alerting on AWS managed services, signals were not attributable to a tenant, and nobody was checking that the telemetry pipeline itself worked.

I took Amazon Managed Grafana into production using Terraform, including dashboards and data sources. I added a generic way to declare CloudWatch alarms in code, wrote an ADR on alerting from logs, and labeled metrics and traces with Kubernetes metadata so tenants can find their own workloads. Small OpenTelemetry jobs continuously test the path to Prometheus and alert if data does not arrive.

Those checks caught an intermittent pipeline failure, which the dashboards did not show. I would centralize metrics and build the pipeline checks on day one.

• Client: NatWest Group (London, UK)
• Sector: Banking
• When: December 2024 to September 2025
• Role: Platform engineer, core platform team
• Stack: AWS, EKS, Istio, Terraform, OpenTelemetry, Amazon Managed Prometheus, Amazon Managed Grafana, CloudWatch

NatWest was building a multi-tenant EKS platform for Important Business Services. Shared egress meant noisy neighbors and no proof of which tenant could access which on-premises service.

I designed Istio egress gateways per tenant, all in code. Tenants declare allowed destinations in their own config; the platform team still approves the change. Health checks test that traffic actually gets through and alert SRE. Plain TCP is wrapped in Istio mTLS, so non-HTTP traffic gets the same encryption and isolation.

It went into production, and tenants used it as intended. Next time, I would write the health checks first and bring self-service into the first conversation with tenants.

• Client: Pfizer (US)
• Sector: Pharmaceuticals
• When: September 2025 to September 2026
• Role: Platform consultant, remote
• Stack: AWS, EKS, Aurora, RDS IAM authentication, Terraform, FluxCD, Grafana Loki, OpenTelemetry, Python

Pfizer's data and BI apps on EKS still used database passwords. Rotation and distribution are where things go wrong, and many teams would never all change their connection code.

I moved the platform to RDS IAM authentication and hid the token handling in a sidecar, so the apps needed very few changes. A small reference app showed teams how to use it. I also standardized structured logging, deployed Grafana Loki in HA, and shipped container logs with OpenTelemetry, all as infrastructure-as-code. A new AI team on Snowflake was onboarded in a couple of weeks.

Apps now connect without passwords. Logs live in one place. Day-to-day requests got faster answers. On a mixed-language estate, the sidecar was the right call; a single-language platform might use a library instead.