Microservice architecture analysis using large language models

Abstract

Methods and systems for analyzing the architecture of microservice systems using large language models (LLMs) are described. An example method for analyzing an architecture of a microservice system includes generating an intermediate representation that includes a representation of dependencies between a plurality of microservices of the microservice system, and generating, based on the intermediate representation and a general LLM, at least one answer to at least one question associated with the architecture of the microservice system. The method further includes performing, based on the at least one answer, one or more operations that reconfigure at least one microservice of the plurality of microservices. An example system includes one or more processors configured to implement the above-described method.

Description

MICROSERVICE ARCHITECTURE ANALYSIS USING LARGE LANGUAGE MODELSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This patent document claims priority to and benefits of U.S. Provisional Patent 63 / 620,503 filed on January 12, 2024. The entire content of the beforementioned patent application is incorporated by reference as part of the disclosure of this patent document.TECHNICAL FIELD

[0002] This patent document is generally related to microservice systems, and more particularly, to methods and systems for analyzing the architecture of microservice systems using large language models.BACKGROUND

[0003] Microservice architecture has become increasingly prevalent in the software domain due to its inherent flexibility, scalability, and enhanced deployment capabilities. Analyzing the architecture of microservice systems involves evaluating the modularity, scalability, and resilience of the services, and the key aspects considered include inter-service communication, data management, deployment strategies, and fault tolerance. However, challenges remain in providing an effective analysis that ensures optimized performance, maintainability, and continuous integration and delivery in dynamic environments.SUMMARY

[0004] Embodiments of the disclosed technology are related to analyzing the architecture of microservice systems using large language models (LLMs), e.g., the ChatGPT model by OpenAI. The described embodiments provide methods and systems that enable a general LLM (e.g., not trained on domain-specific datasets) to provide answers to questions focused on the service and interaction perspectives of microservice systems. Some of the described embodiments integrate intermediate representations and source code of the microservices, thereby making understanding software easier in dynamic, microservice-heavy settings.

[0005] In an example aspect, a method for microservice architecture analysis includes generating an intermediate representation comprising a representation of dependencies between a plurality of microservices of the microservice system, and generating, based on the intermediate representation and a general large language model (LLM), at least one answer to at least one question associated with the architecture of the microservice system. In this example method, the plurality of microservices interact with each other to perform an overall application function, each of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function, and generating the intermediate representation is based on the one or more source code components for each the plurality of microservices. The method further includes performing, based on the at least one answer, one or more operations that reconfigure at least one microservice of the plurality of microservices. Herein, a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, a context length of an input to the general LLM is constrained, and the at least one answer is based on a trade-off between a complexity of the intermediate representation and the context length of the input to the general LLM.

[0006] In another example aspect, a method for microservice architecture analysis includes generating an intermediate representation comprising a call graph that is aware of persistent operations, converting the intermediate representation to a natural language representation, and providing, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation. In this example method, the call graph is a representation of dependencies between microservices of a plurality of microservices of the microservice system that interact to perform an overall application function, each of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function, generating the intermediate representation is based on the one or more source code components for each the plurality of microservices, making the call graph aware of the persistent operations comprises identifying the persistent operations associated with each of the plurality of microservices, the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservicesystem, a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, and a context length of an input to the general LLM is constrained. The method further includes retrieving, from the general LLM, at least one answer to the at least one question, and implementing, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system.

[0007] In yet another example aspect, a system for microservice architecture analysis includes a microservice system comprising a plurality of microservices that interact to perform an overall application function, and one or more processors coupled to the microservice system. In this example system, each microservice of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function. Furthermore, the one or more processors is configured to generate, based on the one or more source code components, an intermediate representation comprising a call graph that is aware of persistent operations, convert the intermediate representation to a natural language representation, and provide, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation, wherein the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservice system. Herein, the call graph is a representation of dependencies between microservices of the plurality of microservices, and making the call graph aware of the persistent operations aware comprises identifying the persistent operations associated with each of the plurality of microservices. In this system, the one or more processors is further configured to retrieve, from the general LLM, at least one answer to the at least one question, and implement, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system. Herein, a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, and a context length of an input to the general LLM is constrained.

[0008] In yet another example aspect, an apparatus comprising a memory and a processor that implements the above-described methods is disclosed.

[0009] In yet another example aspect, the above-described methods may be embodied as processor-executable code and may be stored on a non-transitory computer-readable program medium.

[0010] The above and other aspects and features of the disclosed technology are described in greater detail in the drawings, the description and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 illustrates an example workflow or methodology for analyzing microservice architecture using large language models (LLMs).

[0012] FIG. 2A illustrates an example of a persistence operation aware component call graph (PO-CCG).

[0013] FIG. 2B illustrates an example code snippet that corresponds, when executed, to the PO-CCG shown in FIG. 2A.

[0014] FIG. 3 is a block diagram illustrating the cloud-native architecture of the TrainTicket system, which is used to evaluate the efficacy of the disclosed technology.

[0015] FIG. 4 includes boxplot graphs that illustrate a score indicative of the accuracy of the answer provided by a LLM for different evaluation scenarios.

[0016] FIGS. 5 and 6 are flowcharts illustrating example methods for analyzing the architecture of a microservice system using an LLM.

[0017] FIG. 7 is a block diagram illustrating an example system configured to implement embodiments of the disclosed technology.DETAILED DESCRIPTION

[0018] The software development landscape has significantly shifted in recent years by adopting the microservice architecture pattern. Microservices architecture represents a distinct form of service-oriented architecture. It comprises relatively small, self-contained services, known as microservices, that operate loosely coupled. These services function in their own environments and interact using streamlined communication methods. Over the past ten years, many top software development and consultancy firms have turned to this software architecture.

[0019] There is general agreement across organizations that enterprise system documentation has become increasingly complex due to the transformation of the IT landscape towards microservices. Moreover, understanding software systems written by others is often challenging. What drives the complexity of microservices is thedecentralization with the existence of cross-service dependencies. When one aims to assess such systems, one needs to include multiple codebases or development teams, which is challenging on a regular basis. Practitioners indicate that one of the greatest barriers to the evolution of such systems is the missing system -centric perspective, which would allow them to reason about the system evolution and see change implications or understand design trade-offs. The evolution challenges are also apparent in systems that lack documentation. It takes a long time to write in-detail documentation and fulfill all the aspects and perspectives in the all-in-one format. Proper detail of documentation is especially challenging for microservices involving separation of duties, with many moving parts where distinct teams evolve distinct microservices.

[0020] Section headings are used in the present document to improve readability of the description and do not in any way limit the discussion or the embodiments (and / or implementations) to the respective sections only.

[0021] 1 Overview of Microservices and Large Language Models

[0022] An approach with great popularity taken by the research community in the last years to address the problem of missing or outdated documentation has been automatic code summarization. The automatic generation of code summarization makes understanding a code easier since the summaries explain the logic and functions of source code in natural language. However, for enterprise systems such as these, which use microservice architecture, the generated summarization remains too complex, unaware of decentralized dependencies, and scoped into the all-in-one format. An alternative form to summarization and documentation could be question answering. This trend is apparent in Natural Language Processing domains. It reduces the heavy workload of developers with the use of high-performance Large Language Models (LLM). For instance, MetaGPT uses LLMs-based agents to generate diverse, high-quality, structured intermediary designs and documentation. However, using an LLM agent on top of system documentation or summarization could be challenging, especially when considering system evolution and outdated documentation where delays in changes could generate wrong answers. Fine-tuning the LLM would be necessary each time the documentation changes, and still, a noise from the past could be introduced. To guarantee no noise from the past, such fine-tuning from scratchbecomes computationally expensive. Alternatives, such as in-context learning, include the limitation of the context length that can be injected into an LLM.

[0023] Embodiments of the disclosed technology enable models like ChatGPT to effectively answer intricate queries about a cloud-native system based solely on source code in an in-context learning fashion by using the source code as a knowledge base. However, these decentralized systems might have self-contained and disjoint codebases with large source code volumes (i.e., cloud-native practices recommend distinct codebases). Thus, the researched perspective further considers augmenting the source code with a system’s intermediate representation that includes inter-service dependencies for these systems. An intermediate representation candidate for cloudnative systems, which was proposed in the context of software architecture reconstruction using static analysis for the purpose of system documentation and reasoning (and which is overviewed in Section 2.8), can be used in the described embodiments. Since these systems are built with component-based development frameworks, components can be recognized and interconnected across and within microservices, forming Component Call Graphs (CCG) (i.e., connected via calls, remote calls, or data dependencies). Herein, these graphs were augmented to make them Persistence Operation aware (PO-CCG). Furthermore, the impact of the ChatGPT efficiency when using PO-CCG as a knowledge base was analyzed.

[0024] Although the examples and embodiments herein have been described in the context of using ChatGPT, the disclosed methods and systems are not limited thereto, and any other general large language models (LLMs) can be used herein.

[0025] Using such an approach, a list of realistic system design-related questions were generated to assess the service and interaction view perspectives, and a study to measure the performance of ChatGPT using different knowledge bases (source code, PO-CCG) was designed. Results indicate that the ChatGPT -like approach can indeed address design-related queries about the evaluated cloud-native system, and shows promise in leveraging both source code and PO-CCG as knowledge bases.

[0026] 1.1 Example Metrics for Evaluation

[0027] In this patent document, an extensive analysis of ChatGPT’s efficiency in responding to questions about microservice systems is conducted. This analysis includes the evaluation of both service view and service interaction aspects, along with an exploration of the impact of different knowledge sources (source code and PO-CCG)used by the model for question answering. More specifically, the following three metrics are used to evaluate the efficacy of using LLMs to analyze microservice system architecture:

[0028] (1) Can ChatGPT utilize source code to address questions regarding microservice service and interaction views, and in doing so, what efficacy levels are attained and what challenges are encountered? This metric focuses on evaluating ChatGPT’s ability to answer designed questions about microservice system views. It aims to determine the model’s efficiency and identify any limitations in addressing such questions.

[0029] (2) Does ChatGPT demonstrate enhanced efficiency in answering questions related to microservice systems when utilizing source code compared to PO- CCG? Given that source code can include irrelevant information for addressing questions related to microservice service and interaction views, and it often involves a larger number of tokens and data to be processed by ChatGPT, the PO-CCG representation was constructed to offer a more focused flow of information and persistent operations. The objective of this metric is to ascertain whether ChatGPT can achieve greater efficiency in answering questions by using source code as compared to the PO-CCG approach.

[0030] (3) Does combining source code and PO-CCG improve ChatGPT’s efficiency in responding to questions concerning microservice systems? After individually measuring the efficacy of source code and PO-CCG knowledge bases, this metric evaluates whether their combination can enhance ChatGPT’s effectiveness in answering questions about microservice views.

[0031] 1.2 Examples of Microservice Architecture Documentation

[0032] The transformational impact of the Microservice Architecture (MSA) comes with its own set of challenges, primarily the increased architectural complexity, more integration points, and, consequently, increased potential for failure scenarios. This complexity is further compounded by the agile development approach, which, while expediting time to market and decreasing the need for inter-developer communication, often poses challenges in understanding the implications of new or modified microservices on the overall system, particularly when documentation is lacking or incomplete.

[0033] A significant research effort has been devoted to developing methods that can cope with the complexities of MSA documentation. One approach leveraged the Ontology of Microservices Architecture Concepts (OMSAC), to comprehensively describe MSAs. Another approach conducted a study on the documentation of architectural decisions in the MSA domain using decision models. Security is another concern that needs to be taken care of, and a method to collect MSA information to secure applications has been developed. Yet other approaches have proposed a technique for automatically generating structured API documentation.

[0034] Another important viewpoint is that of Software Architecture Reconstruction (SAR), which is a process that automatically derives various software architecture views from artifacts like documentation, source code, and run- time traces. SAR artifacts then contribute to the system’s documentation and enable further analyses. SAR on MSA fundamentally considers four views that capture different aspects of a system: (i) Domain view, (ii) Technology view, (iii) Service view, and (iv) Operation view.

[0035] The agile methodology also highlights the transient nature of code documentation in fast-paced development environments. Code summaries, although they enhance comprehension, can quickly become misaligned or obsolete due to rapid software changes. While automatic code summarization attempts to bridge this gap, its static nature struggles to keep up with the ever-evolving codebase. Consequently, visualization techniques for microservice architectures have emerged, but have still left developers with the heavy lifting — correlating visualizations, summaries, documentation, and code to answer their queries.

[0036] But is this the correct answer for agile development in a microservice architecture environment? Embodiments of the disclosed technology are directed to an agent capable of asking questions about a system and getting answers from it as soon as possible, and which is configured to use high- performance Large Language Models in its operations.

[0037] 1 .3 Examples of LLMs for Documentation

[0038] The advent of Large Language Models (LLMs) has opened a pathway of new applications and the possibility of drastically revolutionizing several areas within science, technology, and society. Particularly, ChatGPT, an LLM based on the GPT-3 architecture, has ample capabilities, including but not limited to debugging and bugfixing, code generation and completion, refactoring and code quality, and general Q&A and assistance for software development.

[0039] Recent studies, in the context of MSA, have explored the ability of ChatGPT to identify microservices based on systems’ requirements descriptions, as well as the possibility of a collaborative architecting of microservice-based software between specialists and ChatGPT. These studies highlight ChatGPT’s capabilities in analyzing, designing, and evaluating the system’s architecture.

[0040] Correctly prompting the system is core to effectively using chatbots like ChatGPT. A catalog of prompt engineering techniques has been developed in the form of patterns, with the aim of reusability of descriptions. Therefore, prompt patterns admittedly imitate the description style of software patterns and include information such as (i) name, (ii) classification, (iii) intent, (iv) context, (v) motivation, (vi) structure, (vii) implementation, and (viii) consequences. This work paved the way for structured and reproducible usage of conversational agents like ChatGPT. Another work proposed MetaGPT, a multi-agents collaborative framework that employs Standardized Operating Procedures to support effective task coordination between LLMs instances. Each LLM assumes a role in their system, and collectively, it can produce complete software engineering projects, including source code and other relevant artifacts like sequence diagrams and class diagrams (referred to as interface designs in the patent document).

[0041] Different from the recent studies and approaches, the described embodiments use LLMs (e.g., ChatGPT) with in-context learning to analyze microservice architecture. This way, every question is being answered using the latest changes in the code rather than potentially using outdated documentation or code summaries. Additionally, the disclosed technology uses both the source code of specific microservices and Persistence Operation-aware Control Call Graphs (PO-CCG) as context. The strength of PO-CCG is that it gives a concise view of important architectural details, using fewer context tokens when communicating with ChatGPT. This is crucial because of the known context limits in current LLMs. Thus, the described embodiments are directed to evaluating the trade-off between detailed context and token efficiency.

[0042] 2 Example Embodiment of the Disclosed Technology

[0043] In some embodiments, the workflow or methodology for analyzing microservice architecture using LLMs is shown in FIG. 1. The pipeline in FIG. 1illustrates how the different phases interconnect to provide the ChatGPT model with the essential information and context required to effectively respond to queries regarding microservice systems. Examples of the following phases are detailed separately:

[0044] - Source code extraction: Extract source code components from microservice projects.

[0045] - PO-CCG Construction: Extract PO-CCG representation from the microservice source code.

[0046] - NL Transformation: Transform the PO-CCG to natural language.

[0047] - Questions Generation: Generate questions for study evaluation.

[0048] - Prompt Engineering: Perform prompt engineering to construct a complete prompt for each question.

[0049] - ChatGPT Question Answering Process: Provide the information and context required to perform the study.

[0050] 2.1 Source Code Extraction

[0051] In some embodiments, the enterprise architecture standards of the layers of communications are followed. Each project has a separation of component types in Controller, Service, and Data Repository. The codebases of the microservices are inspected to extract their source code files. Upon identifying these files, they are parsed to pinpoint method declarations and their corresponding bodies. The content representing both the method declaration and its body is then extracted and denoted as the method’s source code. Along with the text of the source code for each method, the other information specified in Table 1 in also extracted. Additionally, for each method, its class is identified and key details about that class collected. This class information and extra information is also present in Table 1.Table 1: Information extracted during source code extraction phase

[0052] 2.2 PO-CCG Construction

[0053] In some embodiments, the PO-CCG construction is a two-phase process. First, the CCGs are constructed, and then they are augmented to make them aware of persistent operations. In some embodiments, the CCG is constructed as described in existing approaches. Through static analysis, low-level constructs in the application source code are identified. The code is scanned to detect methods and classes, either within the entire application or specific modules. A method call graph, highlighting method relationships, is established by detecting method calls within each method’s body.

[0054] Entry points, methods that are not invoked by other components but are accessible from client frontends, are vital for understanding an application. These are identified using a depth-first search technique. The call graphs are subsequently enhanced to create the Component Call Graphs (CCG), incorporating details such as component types and their properties. As depicted in FIG. 2A, the component type is presented within brackets ([]), and properties are illustrated in rectangles connected to the respective component.

[0055] As an example, Listing 1 (shown in FIG. 2B) provides a code snippet, which is a source code example for a Java application. Here, the getAIIFood endpoint method in FoodController invokes the getAIIFood method in the Foodservice component. Subsequently, RecordService initiates two procedure calls: first, it reaches out to a third- party API using restTemplate, and then, it calls the findAII method in FoodOrderRepository. The ensuing call graph can be seen in FIG. 2A. This graph originates from the endpoint interface within the FoodController component andtraverses, following the directional arrows, representing each method invocation, ultimately constructing the full graph. Among the properties linked to the findAII method in FoodOrderRepository is “CRUD Op” with a value of “READ”. This particular property signifies that the component is aware of persistence operations, as it represents the persistent actions initiated by that method.

[0056] The second and last step is to augment the constructed COG, making them aware of persistent operations. In some examples, persistent operations are those that cause data to be created, read, updated, and / or deleted (e.g., termed CRUD operations) from a database or other permanent medium in the microservice system. The procedure begins by extracting endpoints from the entire system. Subsequently, the source code of these endpoints is analyzed, transformed into a call graph, and examined to discern various accesses to data entities, pinpointing the CRUD operations for every graph element. By this stage, the persistent operations associated with each microservice are determined. However, to gain a comprehensive perspective, a subsequent phase examines inter-service interactions. This phase extends the specific persistent accesses of an endpoint with the persistent operations employed in its dependent endpoints, which belong to other microservices. These persistent operations are included in the constructed CCG, making it persistent operation aware.

[0057] 2.3 Natural Language (NL) Transformation

[0058] In some embodiments, the PO-CCG components are converted to natural language using a heuristics approach. Concretely, the Control Flow Graph is processed using a Visitor pattern to traverse the graph structure. In some examples, only flow paths are parsed; therefore, the structure to be visited is simply a list. Nevertheless, the Visitor implementation is made independent of the traversal. A visit to a node may store some information in the context of the Visitor, e.g., visiting a node that represents a controller stores such node’s information in the context for future reference by deeper nodes. Additionally, visiting a node may generate a message that is appended on the spot to a sequence of messages kept in the context of the visitor class. The final description produced is the concatenation of all messages generated. Table 2 lists the nodes in the graph that produce a message. Other nodes simply contribute to adding information to the context.Table 2: Nodes in the Control Flow Graph that produce a message in NL.NodeMessage

[0059] On the other hand, parsing the Partial Operations are much simpler. First, a header message is created with the language: "CRUD operations are performed over the following entities:". Then, an itemized list of CRUD operations over each entity is appended. For example, a lie may look like "Person: GET, PUT, POST", meaning that Get, Post, and Put operations are executed over the Person entity.

[0060] 2.4 Questions Generation

[0061] In some embodiments, the methodology for preparing the questions centers on evaluating the model’s precision in addressing queries related to microservice systems, considering both the service view and service interaction perspectives. These questions were formulated without bias towards any particular system, ensuring their applicability across diverse scenarios. To maintain objectivity, the questions were designed to yield uniform answers, facilitating consistent evaluation against actual responses without subjective judgment. Beyond testing the model’s knowledge, the aim is to gauge its ability to provide insightful and practical solutions that address the challenges inherent in microservice systems. These questions have been classified into three distinct categories: Endpoint Details, Remote Calls, and Dependency.

[0062] The Endpoint Details category pertains to the service view perspective, encompassing queries about various aspects such as the responsibilities of endpoints, response mechanisms, internal operations like CRUD operations, and the configured HTTP methods. On the other hand, the Remote Calls and Dependency questions focus on aspects related to service interactions. Remote Calls involve examining requests made from one microservice to another, including the sequence of calls between pairs of microservices or endpoints within the system. Conversely, the Dependency category delves into exploring the service dependency graph of a microservice and identifying the endpoints responsible for establishing dependency relationships between microservices.

[0063] Furthermore, each question necessitates a specific number of microservices to provide comprehensive answers. Specifically, Endpoint Details questions can typically be answered with information from a single microservice. In contrast, questions in the Remote Calls and Dependency categories may require data from multiple microservices to compile a complete response concerning interactions.

[0064] Additionally, the questions encompass various aspects, with some inquiries focusing on specific functions while others refer to functions using their responsibilities. The questions also employ specific terminology and keywords that carry particular implications; for example, the word ’communicate’, when it is mentioned on microservices, signifies a remote call relationship between them.

[0065] Importantly, these questions encompass a wide range of microservice variations to ensure that the results are not skewed toward any particular use case within the system. Thus, the findings are reflective of different facets of the system, avoiding bias towards any specific user case.

[0066] 2.5 Prompt Engineering

[0067] In some embodiments, and to effectively use ChatGPT for addressing questions related to microservices, specifically focusing on code and static analysis, prompts were constructed with the following three components:

[0068] Role Prompt: Leveraging research from agent-based frameworks (e.g., MetaGPT) that highlight the role the agent has to play, the described embodiments used the role of “a great developer with best practices in Microservices project”. This foundational step ensures the model aligns its responses within the specified role, offering insights relevant to microservices, and is general instead of something like“Microservices Analyst” or “Code Reviewer,” which allows testing with any type of questions. In addition, this prompt clarifies to ChatGPT that there will be a lot of upcoming messages before the actual questions come along, and to save tokens and get feedback, ChatGPT only answered with “got it”.

[0069] Context Prompts-. ChatGPT was provided with a specific context to see if it could accurately respond to a question based on that information. The whole context would conform to the class file path on the source code project, the methods’ names, the method’s source code, and also the PO-CCG in natural language form. Depending on what one wanted to test, one could exclude some information or not. In addition, not all the information was given in a single prompt, but a set of prompts, one per method. In addition, this prompt reminded ChatGPT that still more messages were coming before the actual questions and to refrain from answering anything rather than “got it”.

[0070] Task Prompt: The task prompt asks the question after ChatGPT has all the context we want to inject. However, depending on the question, a more targeted prompt engineering approach can be performed: (i) For questions that necessitated an understanding of specific definitions, the approach was sequential: ask ChatGPT to define the concept; if the answer was right, prompt ChatGPT to rephrase the original question, including at the beginning of this definition in a way that was clear to understand and give that final answer as the Task Prompt, (ii) Additionally, replace technical words with more natural language words like instead of “Microservice A calls Microservices B” we would replace with “Microservice A communicates with Microservices B”. This step-by-step for- mat aimed to facilitate deeper comprehension and more accurate responses from ChatGPT.

[0071] The exact Role Prompt was “I want you to act as a great developer with best practices in Microservices project. I will give you the information of a Microservice during the following messages. I will expect that in each of those messages, you can answer as simply as: got it. When I am finished I will let you know and start asking you questions about it.”

[0072] The exact Context Prompt was “In the path < classFilePath >. There is a method called < methodName >. With this code: < sourceCode >. Finally, this is information about Crud and the Control Flow (sequence of calls): < PO-CCG >. Remember that for this message, you must answer only got it.”

[0073] 2.6 Question Answering Process

[0074] In some embodiments, and in order to combine the outcomes of the Source Code Extraction, PO-CCG Construction, and further NL Transformation, and the Prompts Engineered to condense all the information and present it to ChatGPT to get an answer to a given question was the following:

[0075] 1 . Pass the Role Prompt to ChatGPT.

[0076] 2. Given the predefined microservices involved in getting the answer to the given question, filter the Source Code Extraction data and the PO-CCG natural language information related to only those microservices. This filtering specifically targets the methods within their controllers and services.

[0077] 3. The extracted information and PO-CCG in the natural language form corresponding to each method are used to build the Context Prompt.

[0078] 4. Each Context Prompt is passed to ChatGPT as a separate message until no Context Prompts are left. Basically, every message corresponds to a single method from the microservices involved.

[0079] 5. Ask ChatGPT the final question with the Task Prompt and get an answer.

[0080] 2.7 Case Study Results

[0081] The described embodiments were tested using TrainTicket, a publicly accessible microservice testbench that was specifically developed to emulate a real- world microservice architecture and is well-recognized in the software engineering field. An example architecture of TrainTicket testbench is illustrated in FIG. 3. The TrainTicket testbench employs a decentralized database architecture, wherein each microser- vice is paired with its dedicated database. Predominantly, MongoDB is the database of choice for these microservices, except for one instance where MySQL is utilized. In line with modern cloud-native standards, the system incorporates advanced features such as containerization and sophisticated routing mechanisms, among others. The system encompasses 41 microservices alongside a dedicated Ul project. Out of these microservices, 37 are crafted using Java, 2 are developed in Python, 1 is written in Go, and the remaining one is built with NodeJS. The Java microservices adhere to enterprise conventions, employing a layered application structure with controllers, services, and repositories. They rely on the Spring Boot framework and standard Spring annotations for development. For inter-service communication, the system relies on REST API calls. The system comprises 584 Java files containing 29,003 lines of code,accompanied by 4,445 lines of comments. The cumulative number of tokens across all the microservice Java files stands at 263,846, representing the total token count for the system’s Java source code.

[0082] In order to tailor our evaluation to the TrainTicket system, the testing began with a set of questions that were initially not tied to any specific system. These were adapted to the characteristics and components of the TrainTicket microservice architecture, producing a set of customized questions for the study on this testbench. The comprehensive dataset with these questions, along with their categories and answers, has been made publicly available at httgs.^nodo^rg / reCT^®358519.

[0083] In total, the study includes 33 questions that were categorized as follows: 8 questions pertain to endpoint details, 13 questions focus on remote calls, and 12 questions center around dependencies. This diverse set of questions explores various usage scenarios within the TrainTicket system, addressing specific aspects of 15 distinct microservices. The questions vary in complexity, with answers requiring anywhere from 1 to 4 microservices.

[0084] In some embodiments, the Context Prompt was modified depending on the experiment, and an example of how an initial question was transformed into the final Task Prompt is provided. Furthermore, in the case of the Context Prompt, if only the source code was to be used, all the sections related to the PO-CCG were removed (and vice versa). However, in both cases, the class file path and method name were always the same.

[0085] For the Task prompt, an example of a question that was believed was going to turn out confusing to the model based on the ambiguity of the term dependency and the adaptation by our Prompt Engineering strategy described above is as follows:

[0086] Original Question’. Identify the microservice endpoints that directly rely on the “ts-food-service” microservice?

[0087] Then, ChatGPT was asked to define the term “service dependency graph” and, with that definition and the original question, a prompt was created that it could understand, but always including the definition at the beginning.

[0088] Adapted Question’. A service dependency graph is a representation that shows the interdependencies between various services in a system, especially in the context of microservices architecture. Each node in the graph represents a microservice, and the directed edges between nodes represent one service’sdependency on another. In other words, if Microservice A calls Microservice B, there would be an edge from A to B. Given that context answer, I want you to identify the microservice endpoints that the “ts-food-service” microservice has a direct dependency on them.

[0089] After some analysis, it was decided the word call is too technical, counterintuitive and potentially ambiguous for ChatGPT. Therefore, we replaced call with communicate and the final task prompt was:

[0090] Task Prompt. A service dependency graph is a representation that shows the interdependencies between various services in a system, especially in the context of microservices architecture. Each node in the graph represents a microservice, and the directed edges between nodes represent one service’s dependency on another. In other words, if Microservice A communicates with Microservice B, there would be an edge from A to B. Given that context, answer the following I want you to identify the microservice endpoints that the “ts-food-service” microservice has a direct or indirect dependency on.

[0091] 2.7.1 Implementation Details

[0092] For source code extraction, the prototype for the example embodiment was tailored for Java microservices designed around a layered application structure — comprising controllers, services, and repositories — built atop the Spring Boot framework. To begin the analysis, the tool requires the path to the source code. Java source files are pinpointed using Apache Commons IO, filtering files based on the “.java” extension. Each identified file undergoes static code analysis leveraging the javaparser library. This analysis distinguishes various coding components such as packages, classes, interfaces, and select methods, excluding rudimentary methods like getters, setters, and constructors.

[0093] The described embodiments include tools that generate a CSV file as output, cataloging the methods detected and the classes to which they’re associated, as referenced in Section 2.1. While most data points are extracted directly via the javaparser library, the categorization of a class is discerned based on specific Spring annotations: classes with ©Controller are labeled as controllers, ©Service as services, ©Repository as repositories, and “other” for classes without these annotations. Be aware that the source code extraction primarily focuses on methods. Therefore, thenumber of rows in the CSV corresponds to the total count of methods present throughout the system.

[0094] For PO-CCG construction, a prototype for CCG extraction (using the methodology described above) was employed to generate the CCG in a JavaScript Object Notation (JSON) format, and a persistence-operation extension prototype was used to pinpoint persistent operations, which were also outputted in a JSON format. A newly developed prototype tool took these two JSON files as input, and then associated each previously extracted method with its corresponding CCG and persistent operation, provided they exist in the inputted JSON files.

[0095] For NL transformation, the procedure described in Section 2.3 was conducted in the Python programming language. Therein, the script takes as input a Comma-Separated-Values (CSV) file that contains columns for the Persistent Operations and the Control Flow Graph and produces a new CSV file with an added column of the description.

[0096] For the ChatGPT question answering process, a Jupyter Notebook was employed using the Python programming language. The main libraries used were the Pandas libraries to handle the dataset of information condensed in the CSV file and the OpenAI library as the primary tool for interfacing with the ChatGPT model. This library facilitated real-time communication and data processing with the model, enabling us to pose questions and receive responses systematically.

[0097] For some experiments, ChatGPT gpt-3.5-turbo-16k, which is a variant of OpenAI’s Generative Pre-trained Transformer (GPT) model, was used. This particular version has been optimized for efficiency and performance, making it suitable for various applications, from casual conversations to more specific tasks requiring nuanced understanding. A standout feature of the “gpt-3.5-turbo-16k” variant is its ability to consider up to 16,000 context tokens in a single interaction. This expansive context window allows it to handle longer conversations or detailed content more effectively, capturing intricate details and providing more coherent and context-aware responses over extended interactions.

[0098] However, in these experiments, it is important to notice that there are context limitations in ChatGPT, where the longest available context open access for API is 16k tokens with gpt-3.5-based versions. This resulted in deciding to employ the Services and Controllers of every microservice involved; the scope was deliberatelyreduced to only Services and Controllers, which mainly address the inherent constraints associated with ChatGPT.

[0099] 2.7.2 Performance Evaluation

[0100] The evaluation process was initiated by thoroughly analyzing the source code to extract actual answers for the questions directly from the system. Subsequently, these actual answers were compared with those provided by the ChatGPT experiment. This evaluation included responses obtained from the different knowledge bases as follows: source code, the PO-CCG approach, and the combination of both source code and PO-CCG.

[0101] As the generated questions were purposefully crafted to elicit specific lists of items, it is acknowledged that ChatGPT’s responses might occasionally contain more or fewer items than expected. The aim was to assess the accuracy of answers in terms of their ability to identify the expected responses. In cases where ChatGPT generated additional correct answers unrelated to the question specifically, they were not included in the evaluation. In summary, the evaluation was conducted based on the following criteria:

[0102] - Correct: The number of items that the system correctly identified.

[0103] - Spurious: The number of items incorrectly predicted by the system.

[0104] - Missing: The number of items that the system was expected to mention but failed to do so.

[0105] To quantify the evaluation, calculate the F1 score, which measures the answers’ accuracy. It combines the notions of correct, spurious, and missing into Precision and Recall scores, which are then aggregated into a single F1 score, as shown below:

[0106] Herein, C, M, S, P, and R represent Correct, Missing, Spurious, Precision, and Recall, respectively. The F1 score provides a balanced assessment of a model’s performance, considering both its ability to provide accurate positive predictions (precision) and its ability to capture all relevant positive instances (recall).

[0107] In order to evaluate the system, the following evaluation scenarios, e.g., based on considering a certain subset of questions, were created:

[0108] - Overall: All the questions

[0109] - Full Context: Questions where the Source Code-based scenario received the prompt for the full context of the question, namely, the relevant Controller and Service source code.

[0110] - Non-full Context: The complement of Full Context.

[0111] - Remote Calls: Questions in the Remote Calls category.

[0112] - Endpoint Details: Questions in the Endpoint Details category.

[0113] - Dependency: Questions in the Dependency category.

[0114] - One Mi era service: Question whose answer involved one microservice.

[0115] - Two Microservices: Question whose answer involved two microservices.

[0116] - More-than-two Microservices: Question whose answer involved more than two microservices.

[0117] FIG. 4 boxplot representations of the results in each evaluation scenario described above. Note that in almost all cases, the median result is the highest possible score. The hardest questions appear to be those that involve more than one microservice. Despite the 50th percentile being elevated, notice there is a high variance in the quality of the answers. Furthermore, FIG. 4 illustrates that using PO-CCG makes ChatGPT respond better than using the combined PO-CCG and source code. An explanation of this phenomenon is rooted in the inherent structure and information density of the PO-CCG. Specifically, the answers to service interaction and dependency questions are more directly obtainable from the PO-CCG, which is more concise and clear. On the other hand, when ChatGPT is presented with a more extensive context that combines PO-CCG and source code, the additional information can lead to potential confusion or misinterpretation since terms can get ambiguous depending on how they are used in different parts of the code. The vast amount of information in the merged context might mask the important parts from the PO-CCG, making the model more susceptible to mistakes or diminishing its accuracy. As support, one proved limitation in LLMs is the difficulty to answer accurately when large prompts and context are given.

[0118] 2.8 Examples of Intermediate Representation

[0119] In some embodiments, the intermediate representation is a Component Call Graph (CCG) that is created by additional properties to each component, like its type and its properties, with connections implied by calls. An example of a CCG is illustrated in FIG. 2A. The type of each component is specified at the top betweenbrackets. The properties that are extracted from each type are different, as can be seen in the cards attached to each component. The inclusion of these properties turns the call graph into a CCG. In some examples, individual CCGs can be created for every endpoint, thereby collectively representing a single microservice. As components are identified, one can also recognize external calls because they are executed via clearly defined interfaces or constructs. These REST calls can then link to other external microservice endpoints based on a matching method signature, providing a broader view of the system’s interdependencies.

[0120] Therefore, by gathering components and integrating their call sequences, types, and properties, the CCG intermediate representation of the microservice can be produced in the form of JSON.

[0121] 3 Additional Embodiments of the Disclosed Technology

[0122] As discussed in this patent document, the described embodiments are directed to using Large Language Models (LLMs), such as ChatGPT, to answer intricate queries related to cloud-native systems, leveraging both source code and a system intermediate representation obtained from static code analysis.

[0123] The described embodiments further include, as shown in the flowchart in FIG. 5, a method 500 for analyzing an architecture of a microservice system. In method 500, the multiple microservices interact to perform an overall application function, with each microservice being configured to perform a partial function of the overall application function. The method 500 includes (510) generating an intermediate representation comprising a representation of dependencies between a plurality of microservices of the microservice system, and (520) generating, based on the intermediate representation and a general large language model (LLM), at least one answer to at least one question associated with the architecture of the microservice system. In this example method, the plurality of microservices interact with each other to perform an overall application function, each of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function, and generating the intermediate representation is based on the one or more source code components for each the plurality of microservices. The method further includes (530) performing, based on the at least one answer, one or more operations that reconfigure at least one microservice of the plurality of microservices. Herein, a training dataset for the general LLM excludesdomain-specific datasets associated with application programming interface (API) documentation for the microservice system, a context length of an input to the general LLM is constrained, and the at least one answer is based on a trade-off between a complexity of the intermediate representation and the context length of the input to the general LLM.

[0124] The described embodiments further include, as shown in the flowchart in FIG. 6, a method 600 for analyzing an architecture of a microservice system. The method 600 includes (610) generating an intermediate representation comprising a call graph that is aware of persistent operations, (620) converting the intermediate representation to a natural language representation, and (630) providing, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation. In this example method, the call graph is a representation of dependencies between microservices of a plurality of microservices of the microservice system that interact to perform an overall application function, each of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function, generating the intermediate representation is based on the one or more source code components for each the plurality of microservices, making the call graph aware of the persistent operations comprises identifying the persistent operations associated with each of the plurality of microservices, the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservice system, a training dataset for the general LLM excludes domainspecific datasets associated with application programming interface (API) documentation for the microservice system, and a context length of an input to the general LLM is constrained. The method further includes (640) retrieving, from the general LLM, at least one answer to the at least one question, and (650) implementing, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system.

[0125] The described features and aspects can be implemented to further provide one or more of the following technical solutions:

[0126] A1 . A system for microservice architecture analysis comprising: a microservice system comprising a plurality of microservices that interact to perform an overall application function, each microservice of the plurality of microservices beingassociated with one or more source code components and configured to perform a partial function of the overall application function; and one or more processors configured to: generate, based on the one or more source code components, an intermediate representation comprising a call graph that is aware of persistent operations, wherein the call graph is a representation of dependencies between microservices of the plurality of microservices, and wherein making the call graph aware of the persistent operations aware comprises identifying the persistent operations associated with each of the plurality of microservices, convert the intermediate representation to a natural language representation, provide, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation, wherein the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservice system; retrieve, from the general LLM, at least one answer to the at least one question, wherein a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, and wherein a context length of an input to the general LLM is constrained, and implement, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system.

[0127] Although the examples and embodiments herein have been described in the context of using ChatGPT, the disclosed methods and systems are not limited thereto. In some embodiments, the general large language model (LLM) can be selected as being one of the Claude LLM (by Anthropic), one of several LLMs by Cohere (which include Command, Rerank and Embed), Gemini (by Google), GPT-xo (i.e., any variant of GPT) by OpenAI, the Large Language Model Meta Al (Llama) by Meta, Orca by Microsoft, StableLM by Stability Al, and the like.

[0128] A2. The system of solution A1 , wherein the one or more processors are configured to: extract, prior to generating the intermediate representation, the one or more source code components from each of the plurality of microservices.

[0129] A3. The system of solution A2, wherein conversion to the natural language representation is further based on the one or more source code components.

[0130] A4. The system of solution A2, wherein extracting the one or more source code components refrains from executing the one or more source code components.

[0131] A5. The system of solution A2, wherein extracting the one or more source code components comprises performing a tracing operation.

[0132] A6. The system of any of solutions A2 to A5, wherein the one or more source code components comprise bytecode or binary code.

[0133] A7. The system of solution A1 , wherein the intermediate representation is converted to the natural language representation by processing the call graph using a visitor pattern that traverses the call graph and separates an algorithmic component of a corresponding microservice from a data structure of the corresponding microservice.

[0134] A8. The system of solution A1 , wherein the intermediate representation is based on the type of the user of the microservice system.

[0135] A9. The system of solution A1 , wherein the one or more processors are configured to: generate, based on the natural language representation and the general LLM, an interactive documentation that enables the type of the user of the microservice system to retrieve a sequence of answers from the general LLM.

[0136] A10. The system of solution A9, wherein the sequence of answers is evaluated using at least one of a completeness metric, a relevance metric, a clarity metric, or an accuracy metric. Examples of metrics used to evaluate the efficacy of the described embodiments are discussed in Section 2.7.2.

[0137] A11 . The system of any of solution A1 to A10, wherein the type of the user of the microservice system is a microservices analyst, a code reviewer, a developer, or a test engineer. In some embodiments, the prompts provided to the LLM are based on the type of user of the microservice. In some examples, the vocabulary is different based on the type of user, e.g., “endpoint” or “API endpoint”; “command” or “operation”; “component” or “software module”; and the like. In other examples, the details requested from the LLM, via the prompt, are different based on the type of user, e.g., a developer can request information related to API endpoints or unit tests; a code reviewer can request error handling details; or a test engineer can request bug reports and / or information related to load balancing.

[0138] A12. The system of any of solutions A1 to A10, wherein the persistent operations comprise a create operation, a read operation, an update operation, or adelete operation associated with a corresponding microservice of the plurality of microservices.

[0139] A13. The system of any of solutions A1 to A10, wherein the at least one question comprises a query regarding the architecture or the functionality of a particular microservice of the plurality of microservices, and wherein the at least one prompt comprises information associated with the particular microservice or an answer to a similar query for a different microservice. Herein, the latter provides an example of in-context learning, which enables ChatGPT to provide better answers by combining the newly provided information with the source code and / or PO-CCG.

[0140] A14. A method for analyzing an architecture of a microservice system, comprising: generating an intermediate representation comprising a representation of dependencies between a plurality of microservices of the microservice system, wherein the plurality of microservices interact with each other to perform an overall application function, wherein each of the plurality of microservices is associated with one or more source code components, wherein each of the plurality of microservices is configured to perform a partial function of the overall application function, and wherein generating the intermediate representation is based on the one or more source code components for each the plurality of microservices; generating, based on the intermediate representation and a general large language model (LLM), at least one answer to at least one question associated with the architecture of the microservice system; and performing, based on the at least one answer, one or more operations that reconfigure at least one microservice of the plurality of microservices, wherein: a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, a context length of an input to the general LLM is constrained, and the at least one answer is based on a trade-off between a complexity of the intermediate representation and the context length of the input to the general LLM.

[0141] A15. The method of solution A14, wherein the intermediate representation comprises a persistence operation aware component call graph (PO-CCG).

[0142] A16. The method of solution A14, comprising: filtering, prior to generating the at least one answer, the intermediate representation to generate a filtered intermediate representation, wherein the filtering is based on a type of user of the microservice system. As noted earlier, the filtering operation specifically targets themethods within their controllers and services, thereby allowing ChatGPT to provide more tailored and accurate results.

[0143] A17. The method of solution A14, wherein determining the representation of the dependencies between the plurality of microservices comprises identifying at least one endpoint associated with each of the plurality of microservices.

[0144] A18. A method for analyzing an architecture of a microservice system, comprising: generating an intermediate representation comprising a call graph that is aware of persistent operations, wherein the call graph is a representation of dependencies between microservices of a plurality of microservices of the microservice system that interact to perform an overall application function, wherein each of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function, wherein generating the intermediate representation is based on the one or more source code components for each the plurality of microservices, and wherein making the call graph aware of the persistent operations comprises identifying the persistent operations associated with each of the plurality of microservices; converting the intermediate representation to a natural language representation; providing, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation, wherein the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservice system; retrieving, from the general LLM, at least one answer to the at least one question, wherein a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, and wherein a context length of an input to the general LLM is constrained; and implementing, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system.

[0145] A19. The method of solution A18, comprising: extracting, prior to generating the intermediate representation, the one or more source code components from each of the plurality of microservices.

[0146] A20. The method of solution A19, wherein conversion to the natural language representation is further based on the one or more source code components.

[0147] A21 . The method of solution A19, wherein extracting the one or more source code components refrains from executing the one or more source code components.

[0148] A22. The method of solution A19, wherein extracting the one or more source code components comprises performing a tracing operation.

[0149] A23. A system comprising one or more processors and one or more memories comprising instructions which, when executed by the one or more processors, cause the system to perform the method recited in one or more of solutions A14 to A22.

[0150] FIG. 7 shows an example of a hardware platform 700 that can be used to implement some of the techniques described in the present patent document. For example, the hardware platform 700 may implement the various modules and algorithms described herein. The hardware platform 700 may include a processor 702 that can execute code to implement a method. The hardware platform 700 may include a memory 704 that may be used to store processor-executable code and / or store data. The hardware platform 700 may further include static analyzer 706, artificial intelligence (Al) processor(s) 708, and natural language (NL) processor(s) 710, which can communicate with the processor 702. In some embodiments, the processor 702 may include one or more processors implementing at least a portion of the static analyzer 706, the Al processor 708, and / or the NL processor 708. The processor 702 may be configured to implement syntactic parsing, generating intermediate representations, NLP, and input / output operations with a large language model. In some embodiments, the memory 704 may include multiple memories, some of which are exclusively used by the processor 702 when implementing the static analyzer, the Al processor, and the NL processor.

[0151] Implementations of the subject matter and the functional operations described in this patent document can be implemented in various systems, digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.

[0152] Part of the disclosed subject matter in this specification can be implemented as one or more computer program products, i.e. , one or more modules of computer program instructions encoded on a tangible and non-transitory computerreadable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing unit” or “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g. , code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0153] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0154] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. Processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0155] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both.The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0156] While this patent document contains many specifics, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0157] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0158] Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

WHAT IS CLAIMED IS:1 . A system for microservice architecture analysis comprising: a microservice system comprising a plurality of microservices that interact to perform an overall application function, each microservice of the plurality of microservices being associated with one or more source code components and configured to perform a partial function of the overall application function; and one or more processors configured to: generate, based on the one or more source code components, an intermediate representation comprising a call graph that is aware of persistent operations, wherein the call graph is a representation of dependencies between microservices of the plurality of micro services, and wherein making the call graph aware of the persistent operations aware comprises identifying the persistent operations associated with each of the plurality of microservices, convert the intermediate representation to a natural language representation, provide, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation, wherein the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservice system; retrieve, from the general LLM, at least one answer to the at least one question, wherein a training dataset for the general LLM excludes domainspecific datasets associated with application programming interface (API) documentation for the microservice system, and wherein a context length of an input to the general LLM is constrained, and implement, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system.

2. The system of claim 1 , wherein the one or more processors are configured to: extract, prior to generating the intermediate representation, the one or more source code components from each of the plurality of microservices.

3. The system of claim 2, wherein conversion to the natural language representation is further based on the one or more source code components.

4. The system of claim 2, wherein extracting the one or more source code components refrains from executing the one or more source code components.

5. The system of claim 2, wherein extracting the one or more source code components comprises performing a tracing operation.

6. The system of any of claims 2 to 5, wherein the one or more source code components comprise bytecode or binary code.

7. The system of claim 1 , wherein the intermediate representation is converted to the natural language representation by processing the call graph using a visitor pattern that traverses the call graph and separates an algorithmic component of a corresponding microservice from a data structure of the corresponding microservice.

8. The system of claim 1 , wherein the intermediate representation is based on the type of the user of the microservice system.

9. The system of claim 1 , wherein the one or more processors are configured to: generate, based on the natural language representation and the general LLM, an interactive documentation that enables the type of the user of the microservice system to retrieve a sequence of answers from the general LLM.

10. The system of claim 9, wherein the sequence of answers is evaluated using at least one of a completeness metric, a relevance metric, a clarity metric, or an accuracy metric.

11. The system of any of claim 1 to 10, wherein the type of the user of the microservice system is a microservices analyst, a code reviewer, a developer, or a test engineer.

12. The system of any of claims 1 to 10, wherein the persistent operations comprise a create operation, a read operation, an update operation, or a delete operation associated with a corresponding microservice of the plurality of microservices.

13. The system of any of claims 1 to 10, wherein the at least one question comprises a query regarding the architecture or the functionality of a particular microservice of the plurality of microservices, and wherein the at least one prompt comprises information associated with the particular microservice or an answer to a similar query for a different microservice.

14. A method for analyzing an architecture of a microservice system, comprising: generating an intermediate representation comprising a representation of dependencies between a plurality of microservices of the microservice system, wherein the plurality of microservices interact with each other to perform an overall application function, wherein each of the plurality of microservices is associated with one or more source code components, wherein each of the plurality of microservices is configured to perform a partial function of the overall application function, and wherein generating the intermediate representation is based on the one or more source code components for each the plurality of microservices; generating, based on the intermediate representation and a general large language model (LLM), at least one answer to at least one question associated with the architecture of the microservice system; and performing, based on the at least one answer, one or more operations that reconfigure at least one microservice of the plurality of microservices, wherein: a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, a context length of an input to the general LLM is constrained, and the at least one answer is based on a trade-off between a complexity of the intermediate representation and the context length of the input to the general LLM.

15. The method of claim 14, wherein the intermediate representation comprises a persistence operation aware component call graph (PO-CCG).

16. The method of claim 14, comprising: filtering, prior to generating the at least one answer, the intermediate representation to generate a filtered intermediate representation,wherein the filtering is based on a type of user of the microservice system.

17. The method of claim 14, wherein determining the representation of the dependencies between the plurality of microservices comprises identifying at least one endpoint associated with each of the plurality of microservices.

18. A method for analyzing an architecture of a microservice system, comprising: generating an intermediate representation comprising a call graph that is aware of persistent operations, wherein the call graph is a representation of dependencies between microservices of a plurality of microservices of the microservice system that interact to perform an overall application function, wherein each of the plurality of microservices is associated with one or more source code components and configured to perform a partial function of the overall application function, wherein generating the intermediate representation is based on the one or more source code components for each the plurality of microservices, and wherein making the call graph aware of the persistent operations comprises identifying the persistent operations associated with each of the plurality of microservices; converting the intermediate representation to a natural language representation; providing, to a general large language model (LLM), at least one prompt associated with a type of user of the microservice system and the natural language representation, wherein the at least one prompt is representative of at least one question associated with an architecture or a functionality of the microservice system; retrieving, from the general LLM, at least one answer to the at least one question, wherein a training dataset for the general LLM excludes domain-specific datasets associated with application programming interface (API) documentation for the microservice system, and wherein a context length of an input to the general LLM is constrained; and implementing, based on the at least one answer, at least one remedial measure associated with the type of the user of the microservice system.

19. The method of claim 18, comprising: extracting, prior to generating the intermediate representation, the one or more source code components from each of the plurality of microservices.

20. The method of claim 19, wherein conversion to the natural language representation is further based on the one or more source code components.

21. The method of claim 19, wherein extracting the one or more source code components refrains from executing the one or more source code components.

22. The method of claim 19, wherein extracting the one or more source code components comprises performing a tracing operation.

23. A system comprising one or more processors and one or more memories comprising instructions which, when executed by the one or more processors, cause the system to perform the method recited in one or more of claims 14 to 22.

Images