In the era of SaaS services<\/strong>, building stateless microservices<\/strong> seems to be the only way to achieve success. But is that true? And is it always possible to design a stateless service?<\/p>\n In this article, we will cover the fundamental differences between stateful and stateless microservices.<\/strong><\/p>\n The key difference between stateful and stateless microservices is that stateless<\/strong> microservices don\u2019t store data on the host<\/strong>, whereas stateful<\/strong> microservices require some kind of storage<\/strong> on the host who serves the requests.<\/p>\n Keeping the state is critical for a stateful service. On the other hand, a stateless service can work using only pieces of information available in the request payload, or can acquire the required pieces of information from a dedicated stateful service, like a database.<\/p>\n Here a rapid overview of the main differences between a stateless and stateful service.<\/p>\n There are multiple challenges related to running a stateful workload:<\/p>\n These challenges are in part because many stateful microservices were built for a legacy environment<\/strong>, and are probably monolithic. Organizations may begin by attempting to containerize their stateful services, but then they need to develop highly specific tooling to coordinate numerous related instances for high availability or employ other sophisticated strategies to deploy, manage or operate these services. This can lead to manual overhead requirements, which can become time-consuming and costly and\/or the need for the development of customized operation for every single service, which can bring with it considerable operational risk.<\/p>\n SaaS is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as “on-demand software”. SaaS microservices are also known as Web-based software, on-demand software and hosted software.<\/p>\n The term “Software as a Service” (SaaS) is considered to be part of the nomenclature of cloud computing.<\/p>\n Not all processes can be made stateless,<\/strong> therefore, you can build a successful SaaS service either stateless or stateful.<\/p>\n Remember that a monolithic stateful service will probably be more expensive and difficult to maintain, and will make scaling much more difficult. Also, it will need special handling for backups and high availability.<\/p>\n Sometimes you have to build a stateful service, this will not automatically harm your SaaS readiness. However, you will need to ensure some kind of scaling for your stateful services, and also plan for backups and rapid disaster recovery. While this is almost always possible, the effort may be much more than what is required to obtain better results on a stateless microservice.<\/p>\n Therefore, design your microservices stateless has a lot of advantages, especially when you need to scale automatically and when your usebase is big and geographically distributed across the globe.<\/p>\n","protected":false},"excerpt":{"rendered":" Stateful vs. Stateless: the good, the bad and the ugly In the era of SaaS services, building stateless microservices seems […]<\/p>\n","protected":false},"author":8,"featured_media":1113,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[482],"tags":[306,312,314],"class_list":["post-1111","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecting-en","tag-software-as-a-service-saas-en","tag-statefull-en","tag-stateless-en"],"yoast_head":"\nStateless<\/b><\/h2>\n
\n
Stateful<\/b><\/h2>\n
\n
The Challenges of running stateful workloads<\/b><\/h2>\n
\n
What about SaaS?<\/b><\/h2>\n
Conclusion<\/b><\/h2>\n