# Cloud Architecture Cloud architecture is the methods, technologies, and frameworks developers use to design cloud applications, including microservices, APIs, containers, and resources for deploying, maintaining, and scaling cloud services. 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. ## 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. ## 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. ## 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. ## 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... ## Building durable cloud control systems with Temporal DevFeed: [Building durable cloud control systems with Temporal]() Original publisher: [Read original article]() Author: Sergey Bykov Published: 2025-01-16T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Cloud](), [Architecture & Design](), [Cloud Architecture](), [Multi-tenancy](), [control-plane](), [Scalability](), [Managed Services](), [reliability](), [Resilience]() Tags: [architecture](), [cell-based-architecture](), [cloud](), [cloud-services](), [database](), [high-availability](), [how-to](), [low-latency](), [managed-services](), [multi-tenancy](), [reliability](), [resilience](), [scalability]() ### AI overview Temporal describes how it built Temporal Cloud as a managed service, emphasizing multi-tenancy, durable execution, and a separation between data-plane and control-plane responsibilities. It also explains using cell-based architecture to isolate resources and limit the impact of failures. ### Source excerpt Explore how Temporal leverages durable execution, multi-tenancy, and cell-based architecture to build scalable, reliable cloud control systems. Learn key lessons and insights for managed cloud services. ## Failover in Amazon RDS Multi-AZ Architectures DevFeed: [Failover in Amazon RDS Multi-AZ Architectures]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2024-12-18T23:22:08Z Content type: tutorial Language: en Sources: [Guille Ojeda]() Topics: [Amazon RDS](), [Amazon Web Services](), [Cloud Architecture](), [distributed-systems](), [Amazon EC2](), [Database](), [Replication](), [Availability](), [VPC]() Tags: [amazon-rds](), [amazon-web-services](), [architecture](), [aws](), [cloud](), [databases](), [distributed-systems](), [ec2](), [failover](), [replication](), [vpc]() ### AI overview This tutorial explains how Amazon RDS Multi-AZ deployments handle database failures and failover. It examines RDS architecture, including EC2 compute, EBS storage, VPC connectivity, the control plane, storage-level replication, and Availability Zone isolation. ### Source excerpt Database failures are inevitable. Even with the most reliable hardware and software, something will eventually break. AWS RDS Multi-AZ deployments promise to handle these failures gracefully, automatically failing over to a standby database when prob... ## 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... ## 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