Serverless application operational recovery and manifest creation
Systems and methods for backing up and restoring serverless applications are provided. A serverless application is queried to identify the functions and services used. These functions and services are transformed into a manifest or graph that allows the relationships of the serverless application to be identified in an automated manner. The serverless application can be backed up and/or restored using the manifest.
1. A method for backing up a serverless application, the serverless application including backend services, application functions, and function mappings, the method comprising:
adding function vertices and service vertices to a manifest, wherein each function vertex corresponds to a function of the serverless application and each service vertex corresponds to a backend service;
identifying characteristics of each function;
adding the identified characteristics to the manifest as edges between the function vertices and the service vertices;
evaluating the manifest to identify components of the serverless application that impact a persistent state, wherein the function vertices and the service vertices that are not connected to other function vertices or service vertices by an edge are not included in the serverless application and do not impact the persistent state; and
backing up the identified components as a single serverless application, wherein the function vertices and the service vertices that do not impact the persistent state of the identified components are backed up as a different serverless application.
2. The method of claim 1 , wherein the characteristics include triggers, environmental variables and/or function calls.
3. The method of claim 2 , wherein the manifest comprises a graph, further comprising adding the triggers, the environmental variables and/or the function calls as edges in the graph.
4. The method of claim 1 , wherein the identifying characteristics of each function includes parsing each function to identity triggers, environmental variables, and/or function calls.
5. The method of claim 1 , wherein the evaluating the manifest to identify the components of the serverless application that impacts a persistent state includes identifying a group of vertices connected by edges as the serverless application, wherein vertices that do not have a path to other vertices in the group of vertices are not included in the serverless application and are identified as the different serverless application.
6. The method of claim 1 , further comprising querying the serverless application with one or more queries to obtain a list of functions and/or services.
7. The method of claim 6 , wherein the one or more queries include a list functions command, a get function configuration command and/or a get function command.
8. The method of claim 1 , further comprising detecting a change in the serverless application and generating a new manifest in response to the detected change.
9. The method of claim 8 , further comprising backing up the serverless application based on the new manifest.
10. A non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising:
adding function vertices and service vertices to a manifest, wherein each function vertex corresponds to a function of the serverless application and each service vertex corresponds to a backend service;
identifying characteristics of each function;
adding the identified characteristics to the manifest as edges between the function vertices and the service vertices;
evaluating the manifest to identify components of the serverless application that impact a persistent state, wherein the function vertices and the service vertices that are not connected to other function vertices or service vertices by an edge are not included in the serverless application and do not impact the persistent state; and
backing up the identified components as a single serverless application, wherein the function vertices and the service vertices that do not impact the persistent state of the identified components are backed up as a different serverless application.
11. The non-transitory storage medium of claim 10 , wherein the characteristics include triggers, environmental variables and/or function calls.
12. The non-transitory storage medium of claim 11 , wherein the manifest comprises a graph, further comprising adding the triggers, the environmental variables and/or the function calls as edges in the graph.
13. The non-transitory storage medium of claim 10 , wherein the identifying characteristics of each function includes parsing each function to identity triggers, environmental variables, and/or function calls.
14. The non-transitory storage medium of claim 10 , wherein the evaluating the manifest to identify the components of the serverless application that impacts a persistent state includes identifying a group of vertices connected by edges as the serverless application, wherein vertices that do not have a path to other vertices in the group of vertices are not included in the serverless application and are identified as the different serverless application.
15. The non-transitory storage medium of claim 10 , the operations further comprising querying the serverless application with one or more queries to obtain a list of functions and/or services.
16. The non-transitory storage medium of claim 15 , wherein the one or more queries include a list functions command, a get function configuration command and/or a get function command.
17. The non-transitory storage medium of claim 10 , the operations further comprising detecting a change in the serverless application and generating a new manifest in response to the detected change.
18. The non-transitory storage medium of claim 17 , further comprising backing up the serverless application based on the new manifest.