# Cloud Architecture Published articles for Cloud Architecture. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Building cloud-native PACS on AWS DevFeed: [Building cloud-native PACS on AWS]() Original publisher: [Read original article]() Author: ManojKumar MV Published: 2026-09-17T15:21:06Z Content type: article Language: en Sources: [AWS Architecture Blog]() Topics: [Medical imaging](), [Cloud Architecture](), [Cloud](), [Amazon Web Services](), [Amazon S3](), [interoperability]() Tags: [advanced-300](), [amazon-s3](), [aws](), [capacity](), [capacity-planning](), [cloud-architecture](), [cloud-native](), [interoperability](), [medical-imaging](), [thought-leadership]() ### AI overview This article presents a hybrid cloud architecture for modernizing medical imaging infrastructure across multi-hospital networks. It describes centralizing PACS archives on AWS, supporting cross-facility interoperability, and using Amazon S3 storage tiers for cost and retention management at scale. ### Source excerpt A hybrid cloud architecture pattern for modernizing medical imaging on AWS. Learn how multi-hospital networks can centralize PACS archives, enable cross-facility interoperability, and use Amazon S3 storage tiers to manage cost and retention at scale. ## Netflix Reworks Conductor for 420 Million Monthly Workflow Executions and 10X Larger Workflows DevFeed: [Netflix Reworks Conductor for 420 Million Monthly Workflow Executions and 10X Larger Workflows]() Original publisher: [Read original article]() Author: Leela Kumili Published: 2026-09-11T14:17:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Orchestration](), [Amazon S3](), [Kafka](), [Apache Iceberg]() Tags: [amazon-s3](), [apache-iceberg](), [apache-kafka](), [architecture-design](), [asynchronous-architecture](), [cassandra](), [cloud-architecture](), [concurrency](), [development](), [devops](), [distributed-systems](), [elasticsearch](), [java-operator-sdk](), [kafka](), [latency](), [microservices](), [netflix](), [netflix-conductor-4-workflow](), [news](), [orchestration](), [s3](), [scalability](), [windows-workflow-foundation](), [workflow](), [workflow-bpm](), [workflow-foundation]() ### AI overview Netflix reworked Conductor 4.0 to scale workflow orchestration to roughly 200,000 definitions and 420 million monthly executions. The redesign raises supported workflow size to 30,000 tasks and reports a roughly 40% reduction in p99 evaluation latency by loading only task data needed for each decision. ### Source excerpt Netflix has reworked its Conductor workflow orchestration engine to handle larger workloads, increasing supported workflow size from about 2,500 to 30,000 tasks and reducing p99 workflow evaluation latency by about 40%. Conductor 4.0 separates workflow metadata from task data, moves evaluation to asynchronous processing, and introduces dynamic worker allocation and concurrency controls. By Leela Kumili ## Presentation: How To Run on Three Clouds at Once, and When Not To DevFeed: [Presentation: How To Run on Three Clouds at Once, and When Not To]() Original publisher: [Read original article]() Author: Ross McFarlane, Kevin Holditch Published: 2026-09-11T11:00:00Z Content type: article Language: en Sources: [InfoQ]() Topics: [networking](), [Databases](), [Kubernetes]() Tags: [amazon](), [architecture](), [architecture-design](), [availability](), [aws](), [cloud](), [cloud-architecture](), [cloud-computing](), [cloud-networking](), [cockroach-labs](), [cockroachdb](), [containers](), [databases](), [devops](), [disaster-recovery](), [engineering](), [europe](), [financial-applications](), [fintech](), [form3-multicloud-architecture](), [infoq](), [kubernetes](), [microservices](), [networking](), [presentation](), [qcon-london-2026](), [qcon-software-development-conference](), [resilience](), [transcripts](), [us]() ### AI overview A presentation on Form3's move from one cloud to a triple-active multi-cloud architecture, covering cross-cloud networking, distributed databases, Kubernetes operators, and regional disaster-recovery expectations. ### Source excerpt Ross McFarlane and Kevin Holditch discuss Form3's evolution from a single-cloud setup to a triple active multi-cloud architecture. They share key engineering strategies for cross-cloud networking, distributed databases with CockroachDB and NATS, custom Kubernetes operators, and navigating distinct regional disaster recovery expectations across the UK, Europe, and US financial markets. By Ross McFarlane, Kevin Holditch ## Open Sourcing ESP RainMaker Neo DevFeed: [Open Sourcing ESP RainMaker Neo]() Original publisher: [Read original article]() Author: John Lee Published: 2026-08-05T00:00:00Z Content type: article Language: en Sources: [Blog on Developer Portal]() Topics: [NEO](), [Esp Rainmaker](), [Open Source](), [Amazon Web Services](), [Internet of things](), [Cloud Architecture]() Tags: [announcement](), [aws](), [aws-iot](), [blog](), [cloud](), [cloud-architecture](), [esp-rainmaker](), [espressif](), [iot](), [matter](), [open-source](), [sdk](), [security]() ### AI overview ESP RainMaker Neo is a new implementation of ESP RainMaker with an entirely open-source device-to-cloud-to-app stack, including a cloud backend released under the Apache License 2.0. It can be deployed in an organization's own AWS account, while existing ESP RainMaker Classic deployments cannot be directly migrated to Neo. ### Source excerpt ESP RainMaker Neo is a new implementation of ESP RainMaker in which the entire device-to-cloud-to-app stack, including the cloud backend, is open source under the Apache License 2.0. This article explains what Neo is, why we rebuilt RainMaker on native AWS IoT services, what open source means in practice for your product, and how Neo relates to ESP RainMaker Classic. ## From DevOps to Platform Engineer: Navigating your career journey DevFeed: [From DevOps to Platform Engineer: Navigating your career journey]() Original publisher: [Read original article]() Author: Sarah Kruger Published: 2026-07-23T05:40:01Z Content type: article Language: en Sources: [Platform Engineering Blog]() Topics: [Platform Engineering](), [Developer experience](), [DevOps](), [internal developer portal](), [SRE](), [Infrastructure as code](), [Orchestration]() Tags: [automation](), [cloud-architecture](), [configuration](), [developer-experience](), [devops](), [infrastructure](), [infrastructure-as-code](), [kubernetes](), [platform](), [platform-engineering]() ### AI overview This career guide explains how DevOps and SRE professionals can transition into platform engineering. It emphasizes moving from direct operational execution to building internal platforms, golden paths, and self-service workflows that help developers deliver software safely and efficiently. The guide also highlights product thinking, developer research, developer portals, policy-driven configuration, and measuring developer experience and business impact. ### Source excerpt Transitioning from DevOps to Platform Engineering? This guide maps the essential technical and product skills you need, from mastering golden paths and developer portals to adopting product thinking and user research. Learn how to leverage your DevOps foundation for success in building Internal Developer Platforms (IDPs). ## What Is Multi-Cloud? DevFeed: [What Is Multi-Cloud?]() Original publisher: [Read original article]() Author: Ryan Kollist Published: 2026-06-23T16:45:27Z Content type: tutorial Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Cloud Architecture](), [cloud-infrastructure](), [Cilium](), [networking](), [Security]() Tags: [architecture](), [cilium](), [cloud](), [cloud-architecture](), [cloud-infrastructure](), [infrastructure](), [multi-cloud](), [networking](), [security](), [what-is-multicloud](), [what-is-multicloud-architecture](), [what-is-multicloud-networking](), [what-is-multicloud-security](), [what-is-the-difference-between-multicloud-and-hybrid-cloud]() ### AI overview This article explains multi-cloud architecture, its importance, and how Isovalent Cilium supports a consistent networking and security operational model across different cloud infrastructures. ### Source excerpt Learn what makes a multi-cloud architecture, why it's important and how Isovalent Cilium enables a consistent networking and security operational model across any cloud infrastructure. ## Slack AI: The Path to Multi-Cloud DevFeed: [Slack AI: The Path to Multi-Cloud]() Original publisher: [Read original article]() Author: Shaurya Kethireddy Published: 2026-05-28T14:15:20Z Content type: article Language: en Sources: [Engineering at Slack]() Topics: [AI Chat]() Tags: [ai](), [amazon-bedrock](), [anthropic](), [availability](), [aws](), [backend](), [cloud](), [cloud-architecture](), [cloud-computing](), [collaboration](), [compliance](), [containers](), [engineering](), [enterprise](), [gpu](), [iam](), [infrastructure](), [innovation](), [llms](), [machine-learning](), [performance](), [security](), [slack](), [software-development](), [uncategorized](), [vpc]() ### AI overview Slack describes evolving its enterprise LLM-serving infrastructure from AWS SageMaker toward multi-cloud, multi-vendor orchestration to improve resilience, capacity management, and access to newer models. ### Source excerpt In early 2023, Slack faced a foundational challenge: serving Large Language Models (LLMs) at enterprise scale with the security, reliability, and performance our customers expect. Over three years, we evolved from basic infrastructure to orchestrating a sophisticated multi-cloud architecture. We didn't just want shiny new models; we needed a system resilient to regional outages and... ## Announcing the Turso Startup Program DevFeed: [Announcing the Turso Startup Program]() Original publisher: [Read original article]() Author: Jeff Olson Published: 2026-05-11T00:00:00Z Content type: release Language: en Sources: [Turso Blog]() Topics: [Turso](), [AI Agent](), [Databases](), [SQLite](), [API](), [Cloud Architecture](), [Amazon Web Services]() Tags: [agents](), [ai](), [ai-agents](), [api](), [apps](), [architecture](), [autonomous](), [aws](), [building](), [cloud](), [cloud-architecture](), [data](), [database](), [databases](), [embedded](), [infrastructure](), [innovation](), [software](), [startup](), [turso]() ### AI overview Turso launches a startup program for venture-backed founders building on the many-database architecture. The article describes isolated databases for users, AI agents, and sessions, along with Turso's cloud SQLite foundation, vector search, branching, rapid database creation, and deployment options across the cloud, edge, embedded applications, isolated AWS accounts, or a company's own cloud architecture. ### Source excerpt Turso launches its startup program for venture-backed founders building on the many-database architecture, the data layer designed for AI agents, multi-tenant apps, and the next wave of software. ## Consistency Models in Azure Cosmos DB: From Strong to Eventual DevFeed: [Consistency Models in Azure Cosmos DB: From Strong to Eventual]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [consistency](), [Databases](), [Availability](), [Latency](), [Replication](), [Azure]() Tags: [availability](), [cloud-architecture](), [consistency](), [cosmosdb](), [database-design](), [databases](), [distributed-systems](), [latency](), [linearizable](), [pacelc](), [replication](), [semantics](), [system-design]() ### AI overview This article explains how Azure Cosmos DB uses five consistency levels to expose PACELC trade-offs between consistency, availability, latency, and read freshness. It describes Strong consistency, bounded staleness, and Session consistency, including their operational trade-offs and suitable use cases. ### Source excerpt Cosmos DB exposes the PACELC trade-off as five explicit levels instead of forcing a strong-or-eventual choice. Strong gives linearizable reads at the cost of write latency and availability. Session, the practical default for user-facing apps, gives read-your-writes within a session via per-partition session tokens while staying highly available. ## Scaling craft coffee: How ClickHouse powers Artly's barista bots DevFeed: [Scaling craft coffee: How ClickHouse powers Artly's barista bots]() Original publisher: [Read original article]() Author: ClickHouse Published: 2025-08-19T14:07:27Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Bots](), [telemetry](), [Data Infrastructure](), [Cloud Architecture](), [Amazon Web Services](), [Amazon S3](), [elasticsearch](), [Back end](), [Front end](), [Mobile](), [Web]() Tags: [architecture](), [aws](), [bots](), [clickhouse](), [cloud-architecture](), [data-infrastructure](), [elasticsearch](), [frontend](), [mobile](), [real-time](), [s3](), [telemetry](), [web]() ### AI overview This article explains how Artly uses ClickHouse within a hybrid AWS and GCP data infrastructure to support robotic baristas. The system processes telemetry, operational logs, and sales data in near real time, helping Artly monitor and improve consistent coffee production across multiple locations. ### Source excerpt "ClickHouse has a lot of great features. It's very flexible and great for our use cases. The pricing is also very affordable compared to other alternatives." - Tong Liu, Principal Software Architect ## The Noisy Neighbor Problem in Multitenant Architectures DevFeed: [The Noisy Neighbor Problem in Multitenant Architectures]() Original publisher: [Read original article]() Author: Carlota Soto Published: 2025-04-03T23:21:00Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Multi-tenancy](), [Cloud Architecture](), [Databases](), [Cloud](), [data]() Tags: [architecture](), [architectures](), [aws](), [cloud](), [cloud-architecture](), [databases](), [infrastructure](), [memory](), [performance](), [postgres](), [product](), [real-time](), [time]() ### AI overview This article explains the noisy neighbor problem in multitenant architectures. It describes how tenants sharing a large AWS RDS instance can compete for finite CPU, memory, and I/O resources, allowing intensive workloads from some customers to degrade performance or cause failures for others. ### Source excerpt Reddit's answer for solving noisy neighbors is simple: Have a talk with them, if you can stay calm, be as straight forward as possible. Don't bend on your position. At least find out what the other neighbors think. Good advice, but it can be difficult to talk to CPUs; they tend n... ## Monitoring and Troubleshooting on AWS: CloudWatch, X-Ray, and Beyond DevFeed: [Monitoring and Troubleshooting on AWS: CloudWatch, X-Ray, and Beyond]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2024-03-23T16:33:24Z Content type: tutorial Language: en Sources: [Guille Ojeda]() Topics: [Amazon Web Services](), [Monitoring](), [Amazon CloudWatch Logs](), [Amazon EC2](), [Cloud Architecture]() Tags: [aws](), [cloud](), [cloud-architecture](), [devops](), [ec2](), [logs](), [metrics](), [monitoring](), [troubleshooting]() ### AI overview This tutorial introduces AWS monitoring and troubleshooting, focusing on CloudWatch and X-Ray. It explains how CloudWatch collects operational data such as metrics, logs, and events, and describes using metrics and logs to understand resource performance and investigate application issues. ### Source excerpt As an AWS user, I'm sure you know that monitoring and troubleshooting are essential for keeping your applications running smoothly. After all, you can't fix what you can't see. But with the sheer number of services and tools available on AWS, it can ... ## Disaster Recovery Strategies on AWS: Ensuring Business Continuity DevFeed: [Disaster Recovery Strategies on AWS: Ensuring Business Continuity]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2024-03-15T01:07:48Z Content type: tutorial Language: en Sources: [Guille Ojeda]() Topics: [Disaster Recovery](), [Amazon Web Services](), [Availability](), [Cloud Architecture]() Tags: [amazon-web-services](), [article](), [availability](), [aws](), [cloud](), [cloud-architecture](), [devops](), [disaster-recovery](), [recovery]() ### AI overview This tutorial explains disaster recovery and business continuity on Amazon Web Services (AWS). It introduces Recovery Time Objective (RTO) and Recovery Point Objective (RPO), showing how acceptable downtime and data loss influence disaster recovery strategy choices. ### Source excerpt We're now living in the world of immediate and always-on stuff, where even a few minutes of downtime can be a disaster for businesses. Customers expect 24/7 availability, and any interruption in service can lead to lost revenue, damaged reputation, a... ## Disaster Recovery and Business Continuity on AWS DevFeed: [Disaster Recovery and Business Continuity on AWS]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2023-12-05T19:41:37Z Content type: article Language: en Sources: [Guille Ojeda]() Topics: [Disaster Recovery](), [Amazon Web Services](), [Cloud Architecture]() Tags: [architecture](), [aws](), [backup](), [backups](), [cloud-architecture](), [data](), [disaster-recovery](), [recovery](), [replication](), [servers]() ### AI overview This article explains disaster recovery and business continuity on AWS. It discusses data replication, backups, Recovery Point Objectives (RPO), and Recovery Time Objectives (RTO), including the trade-offs between recovery targets, technology, effort, and cost. ### Source excerpt Imagine this scenario: You successfully replicated your data to another region, so if your AWS region fails you can still access the data. However, all your servers are still down! You'd like to continue operating even in the event of a disaster. Dis... ## Data Loss, Replication and Disaster Recovery on AWS DevFeed: [Data Loss, Replication and Disaster Recovery on AWS]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2023-10-31T18:37:56Z Content type: tutorial Language: en Sources: [Guille Ojeda]() Topics: [Amazon Web Services](), [Disaster Recovery](), [data](), [Amazon S3](), [Databases]() Tags: [architecture](), [aws](), [cloud-architecture](), [data](), [devops](), [disaster-recovery](), [how-to](), [recovery](), [replication](), [s3](), [snapshots]() ### AI overview A tutorial on data-loss scenarios in AWS, including hardware failure and human error, and ways to reduce risk using S3, EBS or RDS snapshots, training, and defined procedures. ### Source excerpt Note: This content was originally published at the Simple AWS newsletter. Imagine this scenario: You have some data that's absolutely critical to your business. If you lose it, it's a disaster! How do you recover? Data Loss Scenarios First, we need t... ## Amazon EBS Basics and Best Practices DevFeed: [Amazon EBS Basics and Best Practices]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2023-08-30T16:15:03Z Content type: tutorial Language: en Sources: [Guille Ojeda]() Topics: [Amazon EC2](), [Amazon Web Services](), [cloud-infrastructure](), [Cloud]() Tags: [amazon](), [aws](), [beginner-developers](), [cloud-architecture](), [cloud-computing](), [cost](), [ec2](), [hdd](), [latency](), [ssd](), [storage]() ### AI overview A tutorial covering Amazon Elastic Block Store (EBS) fundamentals and best practices, including how EBS volumes provide persistent storage for Amazon EC2 instances, how volumes are managed, and the characteristics of GP3 volumes. ### Source excerpt Elastic Block Store (EBS for short) is a block-level storage service for EC2 instances. Essentially it's a virtual SSD or HDD that you attach to EC2 instances, so they can have persistent storage. Honestly, EBS is pretty boring to talk about, but if ... ## ESP RainMaker and Serverless DevFeed: [ESP RainMaker and Serverless]() Original publisher: [Read original article]() Author: John Lee Published: 2020-05-26T00:00:00Z Content type: opinion Language: en Sources: [Blog on Developer Portal]() Topics: [Esp Rainmaker](), [Serverless](), [Architecture & Design](), [Internet of things](), [Cloud Architecture](), [Scalability](), [Security](), [Deployment](), [Containers]() Tags: [architecture](), [blog](), [cloud-architecture](), [containers](), [deployment](), [esp-rainmaker](), [esp32](), [esp32-s2](), [iot](), [rainmaker](), [scalability](), [security](), [serverless]() ### AI overview The article explains how ESP RainMaker evaluated architectures for its IoT cloud service using security, time-to-market, scalability, cost, and runtime reconfiguration criteria. It reports that serverless deployment stood out in the evaluation. ### Source excerpt Recently, we launched ESP RainMaker, that provides a way for developers to build devices with readymade cloud, phone apps and voice assistant support. In this context, designing and implementing an IoT cloud service was a significant part of the efforts and we wanted to ensure that it met some of the key criteria that we had laid out. Security -- We gave utmost importance to security to ensure that device and the user data is secure, and unintentional access to the data is prevented. ## Some risks of coordinating only sometimes DevFeed: [Some risks of coordinating only sometimes]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2019-05-01T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Cloud Architecture](), [systems](), [Availability](), [Latency](), [API](), [Network]() Tags: [api](), [architecture](), [availability](), [bugs](), [cloud-architecture](), [code](), [latency](), [network](), [operator](), [outages](), [recovery]() ### AI overview The article examines risks in cloud systems that coordinate only intermittently. It explains how correlated failures can trigger sudden coordination and traffic bursts, overload controllers, increase recovery time, and cause large-scale outages. ### Source excerpt Some risks of coordinating only sometimes Sometimes-coordinating systems have dangerous emergent behaviors A classic cloud architecture is built of small clusters of nodes (typically one to nine1), with coordination used inside each cluster to provide availability, durability and integrity in the face of node failures. Coordination between clusters is avoided, making it easier to scale the system while meeting tight availability and latency requirements. In reality, however, systems sometimes do need to coordinate between clusters, or clusters need to coordinate with a central controller. Some of these circumstances are operational, such as around adding or removing capacity. Others are triggered by the application, where the need to present a client API which appears consistent requires either the system itself, or a layer above it, to coordinate across otherwise-uncoordinated clusters. The costs and risks of re-introducing coordination to handle API requests or provide strong client guarantees are well explored in the literature. Unfortunately, other aspects of sometimes-coordinated systems do not get as much attention, and many designs are not robust in cases where coordination is required for large-scale operations. Results like CAP and CALM2 provide clear tools for thinking through when coordination must occur, but offer little help in understanding the dynamic behavior of the system when it does occur. One example of this problem is reacting to correlated failures. At scale, uncorrelated node failures happen all the time. Designing to handle them is straightforward, as the code and design is continuously validated in production. Large-scale correlated failures also happen, triggered by power and network failures, offered load, software bugs, operator mistakes, and all manner of unlikely events. If systems are designed to coordinate during failure handling, either as a mesh or by falling back to a controller, these correlated failures bring sudden bursts of coo