<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>InfoQ - DevOps - Articles</title>
    <link>https://www.infoq.com</link>
    <description>InfoQ DevOps Articles feed</description>
    <item>
      <title>Article: Implementing Chaos Engineering in Financial Payment Systems: Lessons from Enterprise ECS Deployments</title>
      <link>https://www.infoq.com/articles/chaos-engineering-ecs-payments/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=DevOps-articles</link>
      <description>&lt;img src="https://res.infoq.com/articles/chaos-engineering-ecs-payments/en/headerimage/chaos-engineering-ecs-payments-header-1788254676411.jpg"/&gt;&lt;p&gt;Standard chaos engineering assumes experiments stop cleanly, blast radius is knowable in advance, and production is fair game. Payment systems violate all three. Salim Adedeji describes ECS-specific failure modes from enterprise deployments: a 60-second DNS TTL that produced 93-second failover, retry logic amplifying database load 2.4x, and AZ rebalancing loops that generic tooling misses.&lt;/p&gt; &lt;i&gt;By Salim Adedeji&lt;/i&gt;</description>
      <category>Amazon Web Services</category>
      <category>Reliability</category>
      <category>Compliance</category>
      <category>Cloud</category>
      <category>Containers</category>
      <category>Fault Tolerance</category>
      <category>Site Reliability Engineering</category>
      <category>Financial Applications</category>
      <category>Chaos Engineering</category>
      <category>Architecture &amp; Design</category>
      <category>Development</category>
      <category>DevOps</category>
      <category>article</category>
      <pubDate>Tue, 08 Sep 2026 09:00:00 GMT</pubDate>
      <guid>https://www.infoq.com/articles/chaos-engineering-ecs-payments/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=DevOps-articles</guid>
      <dc:creator>Salim Adedeji</dc:creator>
      <dc:date>2026-09-08T09:00:00Z</dc:date>
      <dc:identifier>/articles/chaos-engineering-ecs-payments/en</dc:identifier>
    </item>
    <item>
      <title>Article: Eliminating Long-Lived Credentials in GCP with Workload Identity Federation</title>
      <link>https://www.infoq.com/articles/gcp-wif-scale/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=DevOps-articles</link>
      <description>&lt;img src="https://res.infoq.com/articles/gcp-wif-scale/en/headerimage/gcp-wif-scale-header-1787838950646.jpg"/&gt;&lt;p&gt;Long-lived GCP service account keys are secrets that must be managed forever, are hard to rotate, and are easy to leak. Scaling Workload Identity Federation to 120+ production projects shows why it changes how machine identity is approached entirely: keys are secrets to manage, federated identities are trust relationships configured once, gated by attribute conditions.&lt;/p&gt; &lt;i&gt;By Shijin Nair&lt;/i&gt;</description>
      <category>DevSecOps</category>
      <category>Cloud</category>
      <category>Google Cloud</category>
      <category>Authentication</category>
      <category>Cloud Security</category>
      <category>Architecture &amp; Design</category>
      <category>DevOps</category>
      <category>article</category>
      <pubDate>Mon, 31 Aug 2026 11:00:00 GMT</pubDate>
      <guid>https://www.infoq.com/articles/gcp-wif-scale/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=DevOps-articles</guid>
      <dc:creator>Shijin Nair</dc:creator>
      <dc:date>2026-08-31T11:00:00Z</dc:date>
      <dc:identifier>/articles/gcp-wif-scale/en</dc:identifier>
    </item>
  </channel>
</rss>
