Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stateless statefull update noah #2685

Merged
merged 8 commits into from
Dec 11, 2023
Merged

Stateless statefull update noah #2685

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
380a16c
follow up on stateless and statefull apps
iamNoah1 Dec 6, 2023
e0a833d
update wordlist
iamNoah1 Dec 6, 2023
ed5bfd8
Update content/en/stateless-apps.md
iamNoah1 Dec 7, 2023
2d79f15
Update content/en/stateless-apps.md
iamNoah1 Dec 7, 2023
bd92e3e
remove words again
iamNoah1 Dec 9, 2023
7192973
Merge branch 'main' into stateless-statefull-update-noah
iamNoah1 Dec 9, 2023
a2639b7
Update content/en/stateful-apps.md
iamNoah1 Dec 9, 2023
8256b0d
Update content/en/stateless-apps.md
iamNoah1 Dec 9, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 7 additions & 20 deletions content/en/stateful-apps.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
41 changes: 11 additions & 30 deletions content/en/stateless-apps.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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/).