You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@flink.apache.org by tz...@apache.org on 2020/03/12 02:45:47 UTC
[flink-statefun] 02/08: [FLINK-16515][docs] Drop overview
This is an automated email from the ASF dual-hosted git repository.
tzulitai pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/flink-statefun.git
commit 4fdf79cb37e393088d166116cc2b74a0dca4dc53
Author: Seth Wiesman <sj...@gmail.com>
AuthorDate: Wed Mar 4 18:10:50 2020 -0600
[FLINK-16515][docs] Drop overview
---
statefun-docs/docs/overview/benefits_grid.html | 79 --------------------
statefun-docs/docs/overview/consistency_model.rst | 54 --------------
statefun-docs/docs/overview/execution_model.rst | 59 ---------------
statefun-docs/docs/overview/index.rst | 70 ------------------
statefun-docs/docs/overview/stateful_functions.rst | 83 ----------------------
statefun-docs/docs/overview/tech_space.rst | 57 ---------------
6 files changed, 402 deletions(-)
diff --git a/statefun-docs/docs/overview/benefits_grid.html b/statefun-docs/docs/overview/benefits_grid.html
deleted file mode 100644
index 0e62d81..0000000
--- a/statefun-docs/docs/overview/benefits_grid.html
+++ /dev/null
@@ -1,79 +0,0 @@
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-<!DOCTYPE html>
-<html>
-
- <style>
-
- div.gallery {
- margin: 10px;
- border: 1px solid #ccc;
- float: left;
- width: 130px;
- text-align: center;
- display: table-cell;
- }
-
- div.gallery:hover {
- border: 2px solid #446D6F;
- }
-
- div.gallery img {
- width: 100%;
- height: auto;
- }
-
- div.desc {
- padding: 15px;
- text-align: center;
- }
-
- div.container {
- display: flex;
- width: 100%;
- justify-content: center;
- padding-bottom: 20px;
- }
-
- </style>
-
- <div class="container">
-
- <div class="gallery">
- <img src="../_static/images/state_first.png" alt="State-Centric" width="100" height="100">
- <div class="desc">State-Centric</div>
- </div>
-
- <div class="gallery">
- <img src="../_static/images/fault_tolerant.png" alt="Fault Tolerance" width="100" height="100">
- <div class="desc">Fault Tolerance</div>
- </div>
-
- <div class="gallery">
- <img src="../_static/images/async_exec.png" alt="Asynchronous" width="100" height="100">
- <div class="desc">Async Execution</div>
- </div>
-
- <div class="gallery">
- <img src="../_static/images/resource_footprint.png" alt="Resource Footprint" width="100" height="100">
- <div class="desc">Minimal Footprint</div>
- </div>
-
- </div>
-
-</html>
\ No newline at end of file
diff --git a/statefun-docs/docs/overview/consistency_model.rst b/statefun-docs/docs/overview/consistency_model.rst
deleted file mode 100644
index 7327c38..0000000
--- a/statefun-docs/docs/overview/consistency_model.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-.. _consistency_model:
-
-#################
-Consistency Model
-#################
-
-.. contents:: :local:
-
-**Stateful Functions** provides a high-level of consistency by following the pattern of function/state co-location and single reader/write access — a `well known <https://cs.brown.edu/courses/cs227/archives/2012/papers/weaker/cidr07p15.pdf>`_ approach that underlies many modern stream processors, databases and other systems. In combination with exactly-once state/messaging semantics, it forms the foundation for a strong consistency model:
-
-.. topic:: Up-to-date function state
-
- Each function state always reflects previous updates. The function is the single reader/writer to its state, and both are (logically) co-located. Function state seems instantaneously persistent, not relying on the completion of a remote operation.
-
-.. topic:: No loss and no duplication of messages
-
- Functions message each other with exactly-once semantics. Exactly-once messaging here means that functions perceive messages as being delivered exactly one time.
-
-.. topic:: Failover safety
-
- If any state update or messaging delivery actually fails (in case of a failure/recovery), the state and messages are rolled back consistently across multiple functions to a state from prior to that failed operation. The logic is then re-attempted. That way functions get the impression of failure-free execution without message loss and keep the state of all functions consistent with each other.
-
-Application developers still need to “think message-based” and deal with multiple intermediate states — for example, when requiring multiple input messages for an action or round-trip messaging with other functions. But they can drop a lot of the complex “defensive logic” against lost messages, broken connections, timeouts, concurrent modifications of shared state and other common setbacks.
-
-.. warning::
- Some care needs to be taken when to communicate the effects to components outside a **Stateful Functions** application. Similar to the topic of “manifesting side-effects” in stream processing, there exist solutions, like transactional egresses. These may however impact the latency of propagating that informing.
-
-Consistency vs. Availability Trade-off
-======================================
-
-There is an inherent trade-off between the level of availability and consistency that an application can provide. The `CAP theorem <https://en.wikipedia.org/wiki/CAP_theorem>`_ famously states that trade-off (though in a simplified manner without all the `nuances <https://jepsen.io/consistency>`_). There is no right or wrong in the trade-off you choose: systems that pick different trade-offs target different use cases.
-
-We picked a high consistency level for **Stateful Functions** and, while it `cannot be totally available <http://www.bailis.org/papers/hat-vldb2014.pdf>`_, we believe it is the right choice, because:
-
-* It makes application development much easier and much more accessible. In practice, many development teams struggle heavily in the presence of lower consistency guarantees.
-
-* It is still possible to provide very high levels of availability with this consistency model. For example, Google Spanner solves an arguable harder consistency/isolation problem and still managed to give such high availability that it was by all practical considerations `as good as totally available <https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem>`_. And while not all software can assume atomic clocks and or rely on well-behaved networks `a lot can [...]
-
-* High consistency is the necessary foundation for even more powerful building blocks, like offering protocols/behaviors with transactional isolation between modifications of multiple function states. This can be implemented on top of streaming messaging, as `illustrated in this example <https://www.ververica.com/hubfs/Ververica/Docs/%5B2018-08%5D-dA-Streaming-Ledger-whitepaper.pdf>`_. Without high consistency, stronger isolation levels between concurrent transactions have much less usef [...]
diff --git a/statefun-docs/docs/overview/execution_model.rst b/statefun-docs/docs/overview/execution_model.rst
deleted file mode 100644
index ffecde0..0000000
--- a/statefun-docs/docs/overview/execution_model.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-
-.. _execution_model:
-
-###########################
-Distributed Execution Model
-###########################
-
-.. contents:: :local:
-
-The Apache Flink Dataflow
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-All ``Functions``, ``Ingresses``, ``Egresses`` and ``Routers`` get assembled into a single Flink application, backed by a single dataflow. This is a different approach from regular Apache Flink applications, where each transformation function is an individual operator in the dataflow. In those applications, each operator has dedicated resources in the TaskManagers (i.e. slots, threads, memory) and can only send events to operators downstream. Assembling all functions into a single, fixed [...]
-
-.. image:: ../_static/images/flink_dataflow_graph.png
- :width: 50%
- :align: center
-
-The Apache Flink dataflow executes the **Stateful Functions** application as follows:
-
-* Ingresses and Routers run in `Flink Source Functions <https://ci.apache.org/projects/flink/flink-docs-release-1.9/api/java/org/apache/flink/streaming/api/functions/source/SourceFunction.html>`_, Egresses in `Flink Sink Functions <https://ci.apache.org/projects/flink/flink-docs-release-1.9/api/java/org/apache/flink/streaming/api/functions/sink/SinkFunction.html>`_.
-
-* All functions are executed by the ``FunctionGroupOperator``. The logical ID of each function acts as the key by which the operator is parallelized. Functions and their state are hence sharded by their logical ID.
-
-* All messages from Routers to functions and from function to function are sent through ``keyBy()`` streams that route the message according to the key (i.e. the logical ID).
-
-* Arbitrary function-to-function messaging is implemented by a feedback loop:
-
- * Functions send messages downstream, routed by key to the ``Feedback Operator``.
- * The Feedback Operator is co-located shard-per-shard with the Function Dispatcher and places the messages into an in-memory feedback channel.
- * The Function Dispatcher pulls messages out of the feedback channel and dispatches them to the functions.
- * When a function emits a message to an Egress, it “side outputs” that message to the respective sink function.
-
-Logical Function Instances
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-All functions types and instances run within the ``FunctionGroupOperator``. Each parallel operator maintains a single instance for each function type and the state for all functions is stored in Flink’s state backend — typically backed by RocksDB or some other map implementation. When receiving a message for a function, the State Dispatcher looks up the function instance from the function type, and the state from the function type and logical ID. The operator then maps the state into the [...]
-
-.. image:: ../_static/images/flink_function_multiplexing.png
- :width: 75%
- :align: center
-
-Parallel Execution & Fault Tolerance
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Apache Flink executes the dataflow in parallel by distributing the operator instances across different parallel processes (i.e. TaskManagers) and streaming events between them. State storage and failure recovery are backed by Flink's state and fault tolerance mechanisms. However, Flink does not support fault tolerant loops out-of-the-box — the **Stateful Functions** implementation extends Flink's native snapshot-based fault tolerance mechanism to support cyclic data flow graphs, followin [...]
diff --git a/statefun-docs/docs/overview/index.rst b/statefun-docs/docs/overview/index.rst
deleted file mode 100644
index 6fbeebe..0000000
--- a/statefun-docs/docs/overview/index.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-
-########
-Overview
-########
-
-**Stateful Functions** is a framework for building and orchestrating distributed stateful applications at scale that aims to solve some of the most significant operational challenges for developers: consistent state management, reliable interaction between distributed services and resource management.
-
-Key Benefits
-############
-
-.. raw:: html
- :file: benefits_grid.html
-
-.. toctree::
- :hidden:
-
- stateful_functions
- consistency_model
- execution_model
- tech_space
-
-Architecture Overview
-#####################
-
-The framework is based on :ref:`functions with persistent state <stateful_functions>` that can share a pool of resources and interact arbitrarily with strong consistency guarantees. **Stateful Functions** uses a state-of-the-art runtime built on `Apache Flink <https://flink.apache.org/>`_ for distributed coordination, communication and state management.
-
-.. topic:: Stateful Functions API
-
- The API is based on, well, stateful functions: small snippets of functionality that encapsulate business logic, somewhat similar to `actors <https://www.brianstorti.com/the-actor-model/>`_. These functions exist as virtual instances — typically, one per entity in the application (for example, per user or stock item) — and are distributed across shards, making applications **scalable out-of-the-box**. Each function has persistent user-defined state in local variables and can message othe [...]
-
-.. topic:: Stream Processing Runtime
-
- The runtime that powers **Stateful Functions** is based on stream processing with Apache Flink. State is kept in the stream processing engine, co-located with the computation, giving you fast and consistent state access. **State durability and fault tolerance** build on Flink’s robust `distributed snapshots model <https://ci.apache.org/projects/flink/flink-docs-stable/internals/stream_checkpointing.html>`_.
-
-.. topic:: Messaging Model
-
- In **Stateful Functions** applications, everything is inherently strongly consistent: state modifications and messaging are integrated to create the effect of **consistent state and reliable messaging** within all interacting functions. Care about consistency needs to be taken only when interacting with the "outside world”. Event Ingresses and Egresses — optionally with transactional semantics — support interaction with the “outside world” via event streams.
-
-.. topic:: Consistency Model
-
- Interactions flow between functions as event streams, in the style of message passing. Apache Flink’s snapshot-based fault tolerance model was extended to support cyclic data flow graphs while ensuring **exactly-once messaging guarantees** (yay!). As a result, you can have functions messaging each other arbitrarily, efficiently and reliably.
-
-**Stateful Functions** splits compute and storage differently to the classical two-tier architecture: one ephemeral state/compute tier and a simple persistent blob storage tier. This approach **eliminates the need to provision additional databases, key-value stores or message brokers** and effectively offloads application state management from the shoulders of developers.
-
-Technology Space
-################
-
-**Stateful Functions** is heavily inspired by multiple existing technologies for stateless application development and orchestration. Other than Apache Flink, also Function-as-a-Service (FaaS) systems such as AWS Lambda and the `virtual stateful actor model <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/Orleans-MSR-TR-2014-41.pdf>`_ from Microsoft Orleans served as inspiration for this project.
-
-The framework is mostly implemented in Java and runs on the JVM. Extending the API to be cross-language compatible and support languages like Python, Go or NodeJS is part of the Roadmap.
-
-Get Involved!
-#############
-
-If you find these ideas interesting, give **Stateful Functions** a try and get involved! Check out the :ref:`Getting Started <getting_started_example>` section for introduction walkthroughs. File an issue if you have an idea how to improve things.
diff --git a/statefun-docs/docs/overview/stateful_functions.rst b/statefun-docs/docs/overview/stateful_functions.rst
deleted file mode 100644
index 69a6860..0000000
--- a/statefun-docs/docs/overview/stateful_functions.rst
+++ /dev/null
@@ -1,83 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-
-.. _stateful_functions:
-
-##############################
-Stateful Functions Abstraction
-##############################
-
-.. contents:: :local:
-
-Stateful functions are the building blocks (and namesake) of the **Stateful Functions** framework. A function is a small piece of logic — currently, simple Java functions — that is invoked through a message. Applications are built from many functions that interact by sending each other messages.
-
-.. image:: ../_static/images/example_ride_sharing.png
- :width: 85%
- :align: center
-
-In many ways, stateful functions are comparable to actors or message-driven beans, but distinguish themselves through the following properties:
-
-.. topic:: Virtual
-
- Stateful functions exist in virtual instances. Each type of function (like PassengerFunction, DriverFunction, RideFunction) exists in many instances, typically one per entity (here, one per passenger or driver or pending/ongoing ride). Each instance has a logical ``ID``. The ``type`` and ``ID`` together form the ``Address`` of that function.
-
-.. image:: ../_static/images/example_ridesharing_2.png
- :width: 85%
- :align: center
-
-For example, “Driver Seth”, “Passenger Gordon, or “Ride 2924" would be addresses.
-
-.. topic:: Addressable
-
- Functions interact with each other by sending point-to-point messages to their ``Addresses``.
-
-.. topic:: Stateful
-
- Each virtual instance of a function has its own state, which can be accessed in local variables. That state is private and local to that instance. State might be the status of a ride, the account information of a passenger or similar.
-
-.. topic:: Lightweight
-
- Function instances are “virtual”, because they are not all active in memory at the same time. At any point in time, only a small set of functions and their state exists as actual objects. When a virtual instance receives a message, one of the objects is configured and loaded with the state of that virtual instance and then processes the message. Similar to virtual memory, the state of many functions might be “swapped out” at any point in time.
-
-If you know Apache Flink’s DataStream API, you can think of stateful functions a bit like a lightweight ``KeyedProcessFunction``. The function ``type`` would then be equivalent to the process function transformation and logical ``ID`` to the key. The difference is that functions are not assembled in a DAG (Directed Acyclic Graph) that defines the flow of data — or, the streaming topology —, but rather send events arbitrarily to all other functions using their ``Addresses``.
-
-Ingresses / Egresses
-====================
-
-``Ingresses`` are the way that events initially arrive in a **Stateful Functions** application. Ingresses can be message queues, logs, or HTTP servers — anything that produces an event to be handled by the application.
-
-``Routers`` are attached to ingresses to determine which function instance should handle an event initially.
-
-``Egresses`` are a way to send events out from the application in a standardized way. Egresses are optional; it is also possible that no events leave the application and functions sink events or directly make calls to other applications. Egresses are integrated with the state/messaging/consistency model and can help with sending responses in a fault-tolerant/consistent way.
-
-Scaling and Resources
-=====================
-
-Applications are inherently scalable because virtual function instances are distributed across parallel processes or shards. Sharding is based on message ``type`` and ``ID``, so messages can be efficiently routed without additional name resolution.
-
-Functions do not have dedicated resources, like threads or memory; all function types share the same resources. Each shard has a "dispatcher" that loads and invokes the target virtual instance of a message. Whenever a function is not executed, its state may reside outside memory. For example, in the implementation on top of Apache Flink, each shard keeps all function state in a local RocksDB instance, with “warm” state residing in the memory cache and “cold” state being evicted to disk.
-
-State and Consistency Guarantees
-================================
-Within a **Stateful Functions** application, everything is inherently strongly consistent. By co-locating the state with the functions, and by integrating the state modifications and messaging, the system creates the effect of consistent state and reliable messaging within all interacting functions. Upon failure, the system rewinds the affected states and messages together to a consistent point and re-executes the messages.
-
-Care about consistency needs to be taken when “interacting with the outside world” — or, any action that leaves the **Stateful Functions** application. Event Egresses support that interaction in a principled manner. Some egresses support transactional semantics, so that events are only made visible once it is certain that no rollback will occur any more.
-
-Modules of Functions
-====================
-Applications are composed of ``Modules``. A module is the entry point for adding ingresses, egresses, routers, and stateful functions to an application. Functions added in one module can message functions from another module or listen to events from an ingress registered in another module.
-
-The module system allows different parts of the application to be contributed by different developers; for example, one module may provide ingresses and egresses, while other modules may individually contribute specific parts of the business logic as stateful functions. This facilitates working in independent teams, but still deploying into the same larger application.
diff --git a/statefun-docs/docs/overview/tech_space.rst b/statefun-docs/docs/overview/tech_space.rst
deleted file mode 100644
index a3c5c3f..0000000
--- a/statefun-docs/docs/overview/tech_space.rst
+++ /dev/null
@@ -1,57 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-
-.. _tech_space:
-
-##########################
-How Does It Compare To...?
-##########################
-
-Even though **Stateful Functions** was partially inspired by FaaS offerings, the framework solves a rather different problem with a different approach.
-
-.. contents:: :local:
-
-State-centric
-=============
-
-FaaS and serverless application frameworks are **compute-centric**: they elastically scale dedicated resources (processes/containers) for computation. Interacting with state (in a database) and other functions is not their core strength and less well integrated, compared to **Stateful Functions**. A good example of fitting use cases is the classical `Image Resizing with AWS Lambda <https://aws.amazon.com/blogs/compute/resize-images-on-the-fly-with-amazon-s3-aws-lambda-and-amazon-api-gateway>`_.
-
-In comparison, **Stateful Functions** is more **state-centric**: the framework scales state and the interaction between different states and events. Computation exists mainly in the form of the logic that facilitates the interaction of events and states. The sweet spot is event-driven applications that have interacting state machines and need to remember a contextual information, such as the :ref:`Ride Sharing Application example <stateful_functions>`.
-
-These different types of problems need different approaches with different characteristics. **Stateful Functions** were designed to provide a set of properties similar to what characterizes serverless compute, but applied to state-centric problems.
-
-Resource-oblivious Development and Deployment
-=============================================
-
-When writing a **Stateful Functions** application, developers do not have to worry about how many parallel instances the application will later run on, or how many resources should be provisioned for the application: this is similar to the FaaS paradigm. Compared to regular Apache Flink applications, there is no need to think in terms of parallelism, slots, or TaskManager resource profiles, to name a few.
-
-Conscious Resource Occupation
-=============================
-
-Typical FaaS implementations keep a pool of instances (containers) for a function and scale it up and down according to the event/request rate. In addition, for stateful applications, you need to keep distributed database processes (explicit or abstracted) that scale more slowly.
-
-**Stateful Functions** has a more slow-scaling set of overall resources (Flink TaskManagers), but keeps inside those processes all virtual function instances (with state) of all function types. The resources are shared between the function types depending on the rates of messages sent to them. At any point in time, the vast majority of virtual instances are inactive and not taking any compute/memory resources.
-
-TaskManagers in Stateful Functions can be seen on a similar level as the database processes and the pool of VMs that the FaaS service uses to launch the function processes/containers.
-
-Fast Compute Scaling, Independent of State
-==========================================
-
-A stateful FaaS application with a remote database can scale the compute layer (functions) and the state layer (database) independently. **Stateful Functions** implicitly always scales compute and state together. In cases where the compute part does a lot more than only interacting with state (especially CPU intensive operations or blocking interactions with other systems), it makes sense to scale it independently from the state.
-
-Scaling compute and state together makes sense for applications where the compute part is mainly the logic that handles event and state interactions. In those applications, the required compute and state resources are typically strongly correlated, and co-locating the computation and state makes both aspects more efficient, resulting in better scalability.
-
-It is worth noting that it is not a contradiction to combine the two approaches: a “stateful tier” for the parts of the application that deal with state and messaging, and a “stateless tier” for the parts that need to be scaled independently.