Stateless statefull update noah (#2685)

Signed-off-by: Noah Ispas (iamNoah1) <Noahispas@gmail.com>
Signed-off-by: Noah Ispas <Noahispas@gmail.com>
Co-authored-by: Hilliary Lipsig <hlipsig@redhat.com>

content/en/stateful-apps.md

@@ -1,29 +1,16 @@
 ---
 title: Stateful Apps
 status: Completed
-category: concept
-tags: ["fundamental", "application", ""]
+category: Property
+tags: ["fundamental", "application", "property"]
 ---
 
-When we speak of stateful (and stateless) apps, 
+When we speak of stateful (and [stateless](/stateless-apps/)) apps, 
 state refers to any data the app needs to store to function as designed. 
 Any kind of online shop that remembers your cart is a stateful app for example. 
 
-## Problem it addresses
+Today, most applications we use are at least partly stateful. In cloud native environments though, 
+stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic. 
+They can be scaled up and down, restarted, and moved around but still need to be able to access their state.
 
-Using an app generally requires multiple requests. 
-For example, when online banking, you'll authenticate yourself by 
-entering your password (request #1), 
-then you may transfer money to a friend (request #2), 
-and finally, you'll want to view transfer details (request #3). 
-To function correctly, each step has to remember the previous ones, 
-and the bank needs to remember the state of everyone’s accounts. 
-Today, most applications we use are at least partly stateful, 
-as they store things like preferences and settings to improve the user experience.
-
-## How it helps
-
-There are several ways to store state for a stateful application. 
-The simplest is to hold the state in memory and not persist it anywhere. 
-The problem with that is, whenever the application has to be restarted, all state is lost. 
-In order to prevent that, state is persisted either locally (on disk) or in database systems. 
+Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases.

content/en/stateless-apps.md

@@ -1,34 +1,15 @@
 ---
-title: Stateless Apps
-status: Feedback Appreciated
-category: technology
-tags: ["fundamental", "application", ""]
+ title: Stateless Apps
+ status: Completed
+ category: Property
+ tags: ["fundamental", "application", "property"]
 ---
 
-A stateless application doesn’t save any client session (state) data on the server where the application lives. 
-Each session is carried out as if it was the first time and responses are not dependent upon data from a previous session and 
-provides functionality to use print services, CDN (Content Delivery Network) or the Web Servers 
-in order to process every short-term request. 
-For example, someone is searching a question in the search engine and pressed the Enter button. 
-In case if the searching operation gets interrupted or closed due to some reason, 
-you have to start a new one as there is no saved data for your previous request.
+Stateless applications process requests as if each request were the first it's ever been sent. 
+The app doesn't "remember" previous interactions or user session data. 
+Data from previous interactions is referred to as state, and since that data isn't stored anywhere, these apps are state*less*. 
+Here's an example: 
+When you use a search engine, and that search is interrupted (e.g., the window is closed), those search results are lost. 
+You'll need to start all over.
 
-## Problem it addresses
-
-Stateless applications tackle the problem of resiliency, 
-because different pods across a [cluster](/cluster/) can work independently, 
-with multiple requests coming to them at the same time. 
-If there’s a problem, you can easily restart the application, 
-and it will return to its initial state with little or no downtime. 
-As such, the benefits of stateless applications include resiliency, elasticity, and high availability. 
-However, most applications we use today are at least partly [stateful](/stateful-apps/), 
-as they store things like preferences and settings to improve the user experience.
-
-## How it helps
-
-Boiling everything down, in a Stateless Application the only thing your cluster is responsible for is 
-the code, and other static content, being hosted on it. 
-That’s it, no changing databases, no writes and no left over files when the pod is deleted. 
-Stateless [containers](/container/) are easier to deploy, 
-and you don’t need to worry about saving container data on persistent storage volumes. 
-You also don't have to worry about backing up the data.
+On the other hand, applications that process requests while considering previous interactions are called [stateful applications](/stateful-apps/).