In our previous blog post, Cloudstate (Part 5): How to work with it?, we learned how to work with Cloudstate. But in this blog, we are going to learn that Cloudstate has reversed the traditional architecture of multi-layered application.
What is the Tradition?
In a traditional multi-layered application, each layer (of the application) will invoke another layer to retrieve and manipulate its state. This approach has been a favorite of many architects for many years because:
- It’s secure as we can secure each layer separately using different methods.
- It allows easy management of the application: Since we can manage each layer separately, adding or modifying each layer without affecting the other layer(s).
- Makes the application scalable. As we can add more resources for each layer, without affecting the other layer(s).
- And at last, it is flexible as we can expand each layer as per the requirement.
However, it has some challenges that grate with the serverless philosophy, like:
- The application must be aware of the location of the database, i.e., what database is being used, how to talk to it , etc.
- The application is responsible for handling errors like the errors related to managing state, infrastructure level failures, and domain level errors (such as concurrent updates & transactions).
Cloudstate Reverses the Tradition
How?
- It removes the necessity for the application/user code to call the state management system instead, the state management calls the user code.
- This means that the responsibility of handling the data, taking care of the technology used, etc., goes to the state management system, and not to the user code.
- Moreover, the data access error(s) & transactional error(s) (like managing concurrent updates, caching, sharding, routing, etc.) all become a concern of the state management system, not the user code.
What are its benefits?
- We can simplify the code that users need to write.
- Allows more automation.
- Allows more in-depth monitoring to be achieved out of the box.
All because state management concerns have been moved out of the user code and put into the infrastructure itself.
Hence, Cloudstate reverses the traditional multi-layered architecture in its own way. In the next blog, we will see the fitting of a Cloudstate service. Till then stay tuned 🙂
