OVERVIEW
Running twenty services well depends on people paying attention. Running five hundred well depends on not needing them to. The difference is not discipline. Some controls cost effort on every change, and some cost nothing once they are in place, and only the second kind survives multiplication.
A change record is the first kind. It is accurate when written and describes one change at one moment. Across five hundred services that effort multiplies while nothing checks the aggregate, so a repository can be complete on Monday and wrong by Friday without anyone being careless. A reconciliation loop is the second kind. It compares desired and actual state continuously, and costs the same whether it covers five applications or five hundred.
This session works through the controls that keep their shape as you grow. Generating applications from repository structure, so onboarding a service is a directory rather than one more hand-written manifest. Continuous coverage checking, so resources nobody declared surface on their own instead of during an incident. Declarative sync windows, so a change freeze is enforced by the system rather than announced to forty teams. And recovery as a reviewed revert, which costs the same at any size.
We will also cover where a human belongs on purpose. Many regulated teams keep the sync decision manual, and that is a design choice rather than a shortfall.
Designed for platform, operations, and infrastructure teams, this session covers the honest limits. A reconciliation loop enforces whatever it is given, so a wrong value reaches five hundred services as reliably as a right one. Enforcement scales. Judgment does not, which is why review stays the place where correctness is decided.
In this webinar, we'll cover:
- Which controls keep their shape as service count grows, and which quietly stop covering everything
- Onboarding a service as a directory rather than another hand-written manifest
- Coverage checking that runs continuously instead of during an audit
- Change freezes enforced by the system rather than announced to teams
- Recovery as a reviewed revert, at any size
Any questions? Please contact Sylvia A
Taufik Harahap
Senior Technical Account Manager, Red Hat
With over 15 years of experience in the IT sector, Taufik possesses a robust background in various technical capacities, including assessment, planning, design, deployment, support, and consulting within the Banking, Financial industries, Retail and Telco. Recently, Taufik has concentrated on initiatives to become a trusted advisor that facilitate customer infrastructure and application transformation and adoption, utilizing technologies such as RHEL, Openshift and Ansible Automation Platform.
Muhammad Taufik Rahman
Technical Account Manager, Red Hat
With eight years of experience in banking and government technology, Maman has worked across backend engineering, DevSecOps, and site reliability. He previously led a team in the banking sector covering delivery pipelines, release controls, and production reliability across on-premise and cloud environments. Recently, Maman has focused on advising financial services and public sector organizations on OpenShift adoption, platform automation, and running AI workloads within the operational controls that regulated environments require.
