Building Stateful Applications – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Building Stateful Applications – InApps in today’s post !
Read more about Building Stateful Applications – InApps at Wikipedia
You can find content about Building Stateful Applications – InApps from the Wikipedia website
Lightbend sponsored this post.
Andy Thurai is a technology influencer and thought leader who focuses on emerging technologies such as Cloud, AIOps, AI, ML, DL, Edge, and IoT. He is a trusted advisor to many startups and enterprise executives, and specializes in selling complex technologies to CxOs. His website is TheFieldCTO.com.
Cloud native applications allow enterprises to design, build, deploy and manage monolithic applications in more agile, nimble ways. These applications accelerate business value while driving greater operational efficiencies and cost savings through containers, a pay-as-you-go model, and a distributed runtime.
However, current serverless implementations (namely, Function-as-a-Service, or FaaS for short) are unable to fully manage business logic and state in a distributed cloud native solution, which creates inefficiencies in hyperscale applications. What is required is a “stateful” approach to serverless application design.
At its core, serverless computing holds enormous promise as it helps enterprises:
- Concentrate on application development instead of worrying about infrastructure. With serverless, cloud runtime will automatically scale as needed.
- Write once and run it anywhere, without worrying about manipulating the full stack. Full-stack engineers are very expensive to hire and retain.
- Scale the infrastructure for high-intensity cloud workloads with near-zero latency and pay for only the time it was used.
With that said, the most widely-used serverless model — FaaS — has limitations. When serverless functions execute, they generally lose computational context that then needs to be restored. Distributing this context across millions of short-lived, serverless hyperscale instances is extremely hard and might require durable external data storages or message queues. As a result, mimicking the hyperscale at the application-layer level is a hard problem to solve. And if this can’t be solved, the app scaling can’t be automated – which limits the true elasticity of the application.
Unfortunately, a lot of enterprise use cases need to be stateful — such as long-running workflows, human approved processes, and e-commerce shopping cart applications. Workflows, in general, require some sort of state associated with them. Pure serverless functions can’t provide that, since they exist for short durations. Obtaining the application state is most commonly solved by either frequenting database access or saving the state at the client. But both are bad ideas from a security perspective, as well as from the perspective of scaling the database instances.
What Is Stateful Serverless?
Imagine this scenario: Your organization builds an e-commerce platform where developers can focus on inventory management, competitive pricing, delivery management, and customer experience; instead of writing a lot of infrastructure code to manage seasonal, regional, and situational usage spikes.
Sounds incredible, right? What makes this possible is a stateful serverless model that scales the application layer and preserves the state of a cloud native application — instead of just scaling the infrastructure layer, as offered by FaaS. A smart way to distribute state is to replicate and persist data (that is, co-location of state and behavior). And not just the current state, but the full history of all states and events that led up to the current state.
So, in case of failure, a service can self-heal by replaying the events to reach the current state from any previous state. In particular, the Cloudstate version of the stateful serverless model — which is a combination of stateful serverless, event sourcing, and Akka — is not only stateful at any given moment, but it is self-healing and recovers from any disaster to the current state quickly without any external simulation.
Scaling a database or replicating a cache system can hit huge data volumes fairly quickly. By event sourcing, functions can hydrate — or catch up — to the current state while starting up. This means there is no need for a round trip to an external, durable data store for every event processing — it can be self-sufficient. These distributed functions become the true extension of an application with ZeroOps. Depending on the demand, the application can now be truly elastic and expand in the cloud with limitless bounds.
Managing State: A Silver Bullet for Enterprises in the Cloud
A stateful serverless approach allows enterprises to build complex workflows without a need for a roundtrip to the database. If you are using a patchwork series of function chains in your serverless design, have functions triggering other functions, have lots of queues in the workflow, or frequent database connections, then you need to rethink your design using stateful serverless. As of this writing, there are a few popular frameworks to consider including Cloudstate, Azure Durable Functions (based on Dapr), and RIFF.
Even though these functions are designed to stay alive for longer periods — days or even months — you will get charged only for the time the function executes and not while it is waiting for something to happen. These functions also execute quickly, as there is no on-demand provisioning overhead. They will run in “sleep mode,” wake up when an orchestration function invokes it, perform its job in the workflow cycle, preserve the state, and transition back to sleep. The billing is based on the time it executed, and the memory used, not while it was in sleep mode — a true consumption-based pricing model.
Stateful serverless can enable enterprises to rapidly scale their application layer effortlessly in a cloud native environment (both in public and private cloud variations), much the same way current serverless models scale the infrastructure layer. And while a cloud-specific implementation by the cloud provider can help with that specific cloud, you need to select tools — such as those mentioned above — that can help in a hybrid situation.
It is time to take your cloud native enterprise applications to the next level. Distributed enterprise applications need to maintain state, self-heal, recover from disasters quickly, and scale both at the infrastructure and application layers with minimal dependency on a centralized database. This will eliminate bottlenecks in the application flow and allow your applications to hyperscale.
If you would like to explore this architecture in greater detail, download a copy of Build Stateful Applications by Jonas Bonér, creator of Akka and CTO at Lightbend, and get started building stateful enterprise applications.
Feature image via Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.