<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.8" -->
<?xml-stylesheet href="https://wiki.bzz.ch/lib/exe/css.php?s=feed" type="text/css"?>
<rdf:RDF
    xmlns="http://purl.org/rss/1.0/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel rdf:about="https://wiki.bzz.ch/feed.php">
        <title>BZZ - Modulwiki - en:modul:m321_aws:topics</title>
        <description></description>
        <link>https://wiki.bzz.ch/</link>
        <image rdf:resource="https://wiki.bzz.ch/_media/wiki/logo.png" />
       <dc:date>2026-05-19T07:03:29+00:00</dc:date>
        <items>
            <rdf:Seq>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/01?rev=1755099352&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/02?rev=1755101804&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/03?rev=1755102110&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/04?rev=1755354625&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/05?rev=1755113614&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/06?rev=1761656691&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/07?rev=1755114309&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/08?rev=1761143525&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.bzz.ch/en/modul/m321_aws/topics/09?rev=1761554533&amp;do=diff"/>
            </rdf:Seq>
        </items>
    </channel>
    <image rdf:about="https://wiki.bzz.ch/_media/wiki/logo.png">
        <title>BZZ - Modulwiki</title>
        <link>https://wiki.bzz.ch/</link>
        <url>https://wiki.bzz.ch/_media/wiki/logo.png</url>
    </image>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/01?rev=1755099352&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-08-13T15:35:52+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Centralized vs Distributed System Architecture</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/01?rev=1755099352&amp;do=diff</link>
        <description>Centralized vs Distributed System Architecture



[Fig-01: Centralized vs Distributed System Architecture]





Centralized System Architecture

A centralized system architecture refers to a computing architecture where all or most of the processing, data storage, and management are performed by a single central server or a mainframe. This central entity is responsible for handling all requests and serving all client devices connected to it. Here are the main characteristics and components of a …</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/02?rev=1755101804&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-08-13T16:16:44+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Peer-To-Peer (P2P) Architecture</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/02?rev=1755101804&amp;do=diff</link>
        <description>Peer-To-Peer (P2P) Architecture

The peer-to-peer (P2P) architecture is a unique type of distributed system that operates without centralized control. In this architecture, any node, also referred to as a peer, can function as either a client or a server. When a node requests a service, it acts as a client and when it offers a service, it&#039;s considered a server.</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/03?rev=1755102110&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-08-13T16:21:50+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Monolithic vs Microservice</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/03?rev=1755102110&amp;do=diff</link>
        <description>Monolithic vs Microservice

The choice between monolithic and microservice architecture significantly impacts the design, development, and maintenance of software applications. Here’s a detailed comparison:





Monolithic Architecture

A monolithic architecture is a single, unified software application where all the components and functionalities are tightly coupled and run as a single service.</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/04?rev=1755354625&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-08-16T14:30:25+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Basics of Kubernetes (K8s)</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/04?rev=1755354625&amp;do=diff</link>
        <description>Basics of Kubernetes (K8s)




What is Kubernetes (K8s)?

Kubernetes is a platform to orchestrate the deployment, scaling, and management of container-based applications. The core functionality is scheduling workloads in containers across your infrastructure. Some other capabilities of Kubernetes are:</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/05?rev=1755113614&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-08-13T19:33:34+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Expose an App in Kubernetes (K8s)</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/05?rev=1755113614&amp;do=diff</link>
        <description>Expose an App in Kubernetes (K8s)




Kubernetes cluster

A Kubernetes cluster should have a minimum of three nodes because if one node goes down, 
both an etcd member and a control plane instance are lost, and redundancy is compromised. 
You can mitigate this risk by adding more control plane nodes.</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/06?rev=1761656691&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-10-28T13:04:51+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Scaling an App in Kubernetes (K8s)</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/06?rev=1761656691&amp;do=diff</link>
        <description>Scaling an App in Kubernetes (K8s)




Scaling

When scaling your app then you are running multiple instances of your app.
A K8s Deployment creates only one Pod for running the application. 
When traffic increases, we will need to scale the application to keep up with
user demand.</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/07?rev=1755114309&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-08-13T19:45:09+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Updating an App in Kubernetes (K8s)</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/07?rev=1755114309&amp;do=diff</link>
        <description>Updating an App in Kubernetes (K8s)

Users expect applications to be available all the time, and developers are expected to deploy 
new versions of them several times a day. In Kubernetes this is done with rolling updates. 
A rolling update allows a Deployment update to take place with zero downtime. It does this 
by incrementally replacing the current Pods with new ones. The new Pods are scheduled on 
Nodes with available resources, and Kubernetes waits for those new Pods to start before removi…</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/08?rev=1761143525&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-10-22T14:32:05+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>Imperative versus declarative commands</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/08?rev=1761143525&amp;do=diff</link>
        <description>Imperative versus declarative commands

Until now, our examples were focused on quick and imperative commands by using kubectl &lt;command&gt; i.e. to create deployments and services running on a one-node cluster with minikube. This is convenient for something quick, but does not easily expose the full flexibility of the</description>
    </item>
    <item rdf:about="https://wiki.bzz.ch/en/modul/m321_aws/topics/09?rev=1761554533&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2025-10-27T08:42:13+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>How Kubernetes &quot;self-heals&quot;</title>
        <link>https://wiki.bzz.ch/en/modul/m321_aws/topics/09?rev=1761554533&amp;do=diff</link>
        <description>How Kubernetes &quot;self-heals&quot;

Let&#039;s first have an overview over the pieces of &#039;self-healing&#039; mechanism by K8s. 

	*  Controllers (Deployment → ReplicaSet → Pods): A Deployment declares the desired number of pod replicas. The ReplicaSet owned by that Deployment ensures that number is kept. If a pod is deleted or a pod’s container exits, the</description>
    </item>
</rdf:RDF>
