diff --git a/content/en/stateful-apps.md b/content/en/stateful-apps.md index d4065b79c0..a59499c64e 100644 --- a/content/en/stateful-apps.md +++ b/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. diff --git a/content/en/stateless-apps.md b/content/en/stateless-apps.md index ea364457a2..6cf8647441 100644 --- a/content/en/stateless-apps.md +++ b/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/). \ No newline at end of file