Understanding Your Serverless System’s Architecture with Thundra
SUBSCRIBE TO OUR BLOG
Get our new blogs delivered straight to your inbox.
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
4 minutes read
Understanding Your Serverless System’s Architecture with Thundra
Written by Suna Tarıyan
Product Manager @Thundra
In a production setup, more often than not, there are multiple AWS services working together, connected to and interacting with each other. This is because one AWS service is usually not enough to build a complete project. For example, you would need a service such as Athena or DynamoDB to store your data, and you’d need Lambda functions and API gateways to allow your users to communicate with your data. But as the scale of your project increases, so does the number of AWS services. And soon enough, it’s hard to keep track of which service is connected to which other services and how the data or control flow works. Serverless has challenges, but you don’t want this to be another thing to worry about. To address this issue, you’ll need Thundra’s Architecture view.
Visualizing AWS Architecture
When many instances of various services work together to provide a feature in a product, it is crucial to have a bird’s-eye view of the whole infrastructure so you can spot an error and debug it before it’s too late. Even though AWS X-Ray provides a topological view of the architecture, it doesn’t consider third-party APIs and services. In fact, one of the major drawbacks of going serverless is that it is very difficult to debug your code.
There is a workaround using CloudFormation, but it’s not what CloudFormation is meant to do, so it isn’t very convenient. Also, you’ll have to go back and change the architecture manually every time you make changes to your setup.
To understand why you need a better architecture view, suppose you have a Lambda function that’s triggered every time a file is uploaded to S3. You can check the Lambda function’s configuration to see what the trigger is, as shown in the screenshot below:
Figure 1: Lambda function’s trigger configuration
As you can see from the screenshot, there is an S3 trigger for this Lambda function. What isn’t apparent, though, is the destination, which isn’t visible in the screenshot. You can add an SNS topic, an SQS queue, another Lambda function, or an EventBridge event bus as a destination. The problem, though, is that that’s a limited list of destinations. The Lambda function shown in the screenshot actually reads the name of the item uploaded to the configured S3 bucket and adds a record in a DynamoDB table. So the destination for this Lambda function is a DynamoDB table, but that isn’t shown in the designer. This is where it becomes difficult to understand the architecture of your project.
Thundra’s Architecture View to the Rescue
If you’re unable to visualize the architecture, you won’t be able to make connections and understand the relationships between different services in the project. As already mentioned, figure 1 is not telling the complete story, but let’s continue with the same example. To reiterate, there’s a Lambda function that is triggered whenever a file is uploaded to an S3 bucket. This function reads the name of the file uploaded, along with the name of the bucket, and adds this information to a DynamoDB table as a document, but that DynamoDB connection is not shown in figure 1.
Once the record is created in the DynamoDB table, another Lambda function is triggered. This second Lambda function reads the newly created record in DynamoDB and logs it to the console, and you can see the record using Amazon CloudWatch logs. But how will you know which is the second Lambda function? Unless you’ve made a note of this manually, you will have to go through each Lambda function and check the trigger manually. This isn’t feasible when you’re working on a large-scale project. But imagine having all this information mapped in one page in an easily understandable design, like the one shown in figure 2:
Figure 2: Thundra’s Architecture view
As you can see from the image above, Thundra’s Architecture view makes the project’s architecture very clear, which helps when you’re trying to debug a connection or data flow issue.
Color Coding Improves Observability
In the screenshot above you can see that the edges are all green. This means the setup is working as expected. When there’s an unexpected event that is breaking something, the nodes and edges turn red, making it easy to pinpoint the architecture error. Each node in the Architecture view also represents an AWS service. For example, from figure 2, you can tell that there are two Lambda functions, an S3 bucket, and a DynamoDB table. You can also move the nodes around to make the control flow more meaningful and understandable.
Now suppose that there’s an error between the S3-Demo Lambda function and the s3_files DynamoDB table. There could be a connection issue, or the Lambda function might not have the required permission, or the name or region of the DynamoDB table could be misconfigured. In such a case, when the Lambda function is executed and an exception is thrown, the Thundra layer catches the exception and applies the color codes to the corresponding node in the Architecture view. When this happens, you can easily tell that something is not working as expected. You can see an example of this in figure 3, where the S3-Demo Lambda function is colored red.
You can enable metrics from the filter in the Architecture view to get the invocation count for each edge. With metrics enabled, you will get an idea of how many times a Lambda function is being triggered and the time taken for each action. An example of this is shown in figure 4.
Figure 4: Example of metrics in Architecture view
If you want more granular details about an action in the architecture, you can click the corresponding edge to bring up the details. For example, if you click the edge between the S3-Demo Lambda function and the s3_files DynamoDB table from the above example, you will see charts about the number of invocations, average duration for completion of the action, and the durations for the 95th and 99th percentile of the operation. Along with this, you’ll get the time at which the invocations took place and see if there were any errors. This is shown in figures 5 and 6.
Figure 5: Charts with invocation count and duration
Figure 6: Table with details of invocations
Timeline Scrubber Helps Visualize Architecture Changes
Thundra goes one step further in helping you visualize the changes made to your architecture with a handy time scrubber at the bottom left of the page. You can move through the timeline and see the architecture change. This helps you figure out how the architecture has changed over time and see the breaking changes you’ve made to the architecture, if any.
Getting a Fuller Picture with Architecture View
As you can see, having the Architecture view auto-generated from your AWS setup is very helpful, not just for visualizing your architecture, but also for health auditing. Another very practical use is helping a new team member get onboarded. Giving them access to the Architecture view is more helpful than handing them hundreds of pages of text. And because the node edges are color coded, it’s easier than ever to figure out where an error occurred and when. This means you spend less time digging through logs on CloudWatch and more time actually fixing the issue—and you can’t deny that that’s a good thing. For more information about observability and monitoring, take a look at this whitepaper.
SHARE
×
SUBSCRIBE TO OUR BLOG
Get our new blogs delivered straight to your inbox.
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
4 minutes read
Understanding Your Serverless System’s Architecture with Thundra
Written by Suna Tarıyan
Product Manager @Thundra
In a production setup, more often than not, there are multiple AWS services working together, connected to and interacting with each other. This is because one AWS service is usually not enough to build a complete project. For example, you would need a service such as Athena or DynamoDB to store your data, and you’d need Lambda functions and API gateways to allow your users to communicate with your data. But as the scale of your project increases, so does the number of AWS services. And soon enough, it’s hard to keep track of which service is connected to which other services and how the data or control flow works. Serverless has challenges, but you don’t want this to be another thing to worry about. To address this issue, you’ll need Thundra’s Architecture view.
Visualizing AWS Architecture
When many instances of various services work together to provide a feature in a product, it is crucial to have a bird’s-eye view of the whole infrastructure so you can spot an error and debug it before it’s too late. Even though AWS X-Ray provides a topological view of the architecture, it doesn’t consider third-party APIs and services. In fact, one of the major drawbacks of going serverless is that it is very difficult to debug your code.
There is a workaround using CloudFormation, but it’s not what CloudFormation is meant to do, so it isn’t very convenient. Also, you’ll have to go back and change the architecture manually every time you make changes to your setup.
To understand why you need a better architecture view, suppose you have a Lambda function that’s triggered every time a file is uploaded to S3. You can check the Lambda function’s configuration to see what the trigger is, as shown in the screenshot below:
Figure 1: Lambda function’s trigger configuration
As you can see from the screenshot, there is an S3 trigger for this Lambda function. What isn’t apparent, though, is the destination, which isn’t visible in the screenshot. You can add an SNS topic, an SQS queue, another Lambda function, or an EventBridge event bus as a destination. The problem, though, is that that’s a limited list of destinations. The Lambda function shown in the screenshot actually reads the name of the item uploaded to the configured S3 bucket and adds a record in a DynamoDB table. So the destination for this Lambda function is a DynamoDB table, but that isn’t shown in the designer. This is where it becomes difficult to understand the architecture of your project.
Thundra’s Architecture View to the Rescue
If you’re unable to visualize the architecture, you won’t be able to make connections and understand the relationships between different services in the project. As already mentioned, figure 1 is not telling the complete story, but let’s continue with the same example. To reiterate, there’s a Lambda function that is triggered whenever a file is uploaded to an S3 bucket. This function reads the name of the file uploaded, along with the name of the bucket, and adds this information to a DynamoDB table as a document, but that DynamoDB connection is not shown in figure 1.
Once the record is created in the DynamoDB table, another Lambda function is triggered. This second Lambda function reads the newly created record in DynamoDB and logs it to the console, and you can see the record using Amazon CloudWatch logs. But how will you know which is the second Lambda function? Unless you’ve made a note of this manually, you will have to go through each Lambda function and check the trigger manually. This isn’t feasible when you’re working on a large-scale project. But imagine having all this information mapped in one page in an easily understandable design, like the one shown in figure 2:
Figure 2: Thundra’s Architecture view
As you can see from the image above, Thundra’s Architecture view makes the project’s architecture very clear, which helps when you’re trying to debug a connection or data flow issue.
Color Coding Improves Observability
In the screenshot above you can see that the edges are all green. This means the setup is working as expected. When there’s an unexpected event that is breaking something, the nodes and edges turn red, making it easy to pinpoint the architecture error. Each node in the Architecture view also represents an AWS service. For example, from figure 2, you can tell that there are two Lambda functions, an S3 bucket, and a DynamoDB table. You can also move the nodes around to make the control flow more meaningful and understandable.
Now suppose that there’s an error between the S3-Demo Lambda function and the s3_files DynamoDB table. There could be a connection issue, or the Lambda function might not have the required permission, or the name or region of the DynamoDB table could be misconfigured. In such a case, when the Lambda function is executed and an exception is thrown, the Thundra layer catches the exception and applies the color codes to the corresponding node in the Architecture view. When this happens, you can easily tell that something is not working as expected. You can see an example of this in figure 3, where the S3-Demo Lambda function is colored red.
You can enable metrics from the filter in the Architecture view to get the invocation count for each edge. With metrics enabled, you will get an idea of how many times a Lambda function is being triggered and the time taken for each action. An example of this is shown in figure 4.
Figure 4: Example of metrics in Architecture view
If you want more granular details about an action in the architecture, you can click the corresponding edge to bring up the details. For example, if you click the edge between the S3-Demo Lambda function and the s3_files DynamoDB table from the above example, you will see charts about the number of invocations, average duration for completion of the action, and the durations for the 95th and 99th percentile of the operation. Along with this, you’ll get the time at which the invocations took place and see if there were any errors. This is shown in figures 5 and 6.
Figure 5: Charts with invocation count and duration
Figure 6: Table with details of invocations
Timeline Scrubber Helps Visualize Architecture Changes
Thundra goes one step further in helping you visualize the changes made to your architecture with a handy time scrubber at the bottom left of the page. You can move through the timeline and see the architecture change. This helps you figure out how the architecture has changed over time and see the breaking changes you’ve made to the architecture, if any.
Getting a Fuller Picture with Architecture View
As you can see, having the Architecture view auto-generated from your AWS setup is very helpful, not just for visualizing your architecture, but also for health auditing. Another very practical use is helping a new team member get onboarded. Giving them access to the Architecture view is more helpful than handing them hundreds of pages of text. And because the node edges are color coded, it’s easier than ever to figure out where an error occurred and when. This means you spend less time digging through logs on CloudWatch and more time actually fixing the issue—and you can’t deny that that’s a good thing. For more information about observability and monitoring, take a look at this whitepaper.
SHARE
In a production setup, more often than not, there are multiple AWS services working together, connected to and interacting with each other. This is because one AWS service is usually not enough to build a complete project. For example, you would need a service such as Athena or DynamoDB to store your data, and you’d need Lambda functions and API gateways to allow your users to communicate with your data. But as the scale of your project increases, so does the number of AWS services. And soon enough, it’s hard to keep track of which service is connected to which other services and how the data or control flow works. Serverless has challenges, but you don’t want this to be another thing to worry about. To address this issue, you’ll need Thundra’s Architecture view.
Visualizing AWS Architecture
When many instances of various services work together to provide a feature in a product, it is crucial to have a bird’s-eye view of the whole infrastructure so you can spot an error and debug it before it’s too late. Even though AWS X-Ray provides a topological view of the architecture, it doesn’t consider third-party APIs and services. In fact, one of the major drawbacks of going serverless is that it is very difficult to debug your code.
There is a workaround using CloudFormation, but it’s not what CloudFormation is meant to do, so it isn’t very convenient. Also, you’ll have to go back and change the architecture manually every time you make changes to your setup.
To understand why you need a better architecture view, suppose you have a Lambda function that’s triggered every time a file is uploaded to S3. You can check the Lambda function’s configuration to see what the trigger is, as shown in the screenshot below:
Figure 1: Lambda function’s trigger configuration
As you can see from the screenshot, there is an S3 trigger for this Lambda function. What isn’t apparent, though, is the destination, which isn’t visible in the screenshot. You can add an SNS topic, an SQS queue, another Lambda function, or an EventBridge event bus as a destination. The problem, though, is that that’s a limited list of destinations. The Lambda function shown in the screenshot actually reads the name of the item uploaded to the configured S3 bucket and adds a record in a DynamoDB table. So the destination for this Lambda function is a DynamoDB table, but that isn’t shown in the designer. This is where it becomes difficult to understand the architecture of your project.
Thundra’s Architecture View to the Rescue
If you’re unable to visualize the architecture, you won’t be able to make connections and understand the relationships between different services in the project. As already mentioned, figure 1 is not telling the complete story, but let’s continue with the same example. To reiterate, there’s a Lambda function that is triggered whenever a file is uploaded to an S3 bucket. This function reads the name of the file uploaded, along with the name of the bucket, and adds this information to a DynamoDB table as a document, but that DynamoDB connection is not shown in figure 1.
Once the record is created in the DynamoDB table, another Lambda function is triggered. This second Lambda function reads the newly created record in DynamoDB and logs it to the console, and you can see the record using Amazon CloudWatch logs. But how will you know which is the second Lambda function? Unless you’ve made a note of this manually, you will have to go through each Lambda function and check the trigger manually. This isn’t feasible when you’re working on a large-scale project. But imagine having all this information mapped in one page in an easily understandable design, like the one shown in figure 2:
Figure 2: Thundra’s Architecture view
As you can see from the image above, Thundra’s Architecture view makes the project’s architecture very clear, which helps when you’re trying to debug a connection or data flow issue.
Color Coding Improves Observability
In the screenshot above you can see that the edges are all green. This means the setup is working as expected. When there’s an unexpected event that is breaking something, the nodes and edges turn red, making it easy to pinpoint the architecture error. Each node in the Architecture view also represents an AWS service. For example, from figure 2, you can tell that there are two Lambda functions, an S3 bucket, and a DynamoDB table. You can also move the nodes around to make the control flow more meaningful and understandable.
Now suppose that there’s an error between the S3-Demo Lambda function and the s3_files DynamoDB table. There could be a connection issue, or the Lambda function might not have the required permission, or the name or region of the DynamoDB table could be misconfigured. In such a case, when the Lambda function is executed and an exception is thrown, the Thundra layer catches the exception and applies the color codes to the corresponding node in the Architecture view. When this happens, you can easily tell that something is not working as expected. You can see an example of this in figure 3, where the S3-Demo Lambda function is colored red.
You can enable metrics from the filter in the Architecture view to get the invocation count for each edge. With metrics enabled, you will get an idea of how many times a Lambda function is being triggered and the time taken for each action. An example of this is shown in figure 4.
Figure 4: Example of metrics in Architecture view
If you want more granular details about an action in the architecture, you can click the corresponding edge to bring up the details. For example, if you click the edge between the S3-Demo Lambda function and the s3_files DynamoDB table from the above example, you will see charts about the number of invocations, average duration for completion of the action, and the durations for the 95th and 99th percentile of the operation. Along with this, you’ll get the time at which the invocations took place and see if there were any errors. This is shown in figures 5 and 6.
Figure 5: Charts with invocation count and duration
Figure 6: Table with details of invocations
Timeline Scrubber Helps Visualize Architecture Changes
Thundra goes one step further in helping you visualize the changes made to your architecture with a handy time scrubber at the bottom left of the page. You can move through the timeline and see the architecture change. This helps you figure out how the architecture has changed over time and see the breaking changes you’ve made to the architecture, if any.
Getting a Fuller Picture with Architecture View
As you can see, having the Architecture view auto-generated from your AWS setup is very helpful, not just for visualizing your architecture, but also for health auditing. Another very practical use is helping a new team member get onboarded. Giving them access to the Architecture view is more helpful than handing them hundreds of pages of text. And because the node edges are color coded, it’s easier than ever to figure out where an error occurred and when. This means you spend less time digging through logs on CloudWatch and more time actually fixing the issue—and you can’t deny that that’s a good thing. For more information about observability and monitoring, take a look at this whitepaper.
In a production setup, more often than not, there are multiple AWS services working together, connected to and interacting with each other. This is because one AWS service is usually not enough to build a complete project. For example, you would need a service such as Athena or DynamoDB to store your data, and you’d need Lambda functions and API gateways to allow your users to communicate with your data. But as the scale of your project increases, so does the number of AWS services. And soon enough, it’s hard to keep track of which service is connected to which other services and how the data or control flow works. Serverless has challenges, but you don’t want this to be another thing to worry about. To address this issue, you’ll need Thundra’s Architecture view.
Visualizing AWS Architecture
When many instances of various services work together to provide a feature in a product, it is crucial to have a bird’s-eye view of the whole infrastructure so you can spot an error and debug it before it’s too late. Even though AWS X-Ray provides a topological view of the architecture, it doesn’t consider third-party APIs and services. In fact, one of the major drawbacks of going serverless is that it is very difficult to debug your code.
There is a workaround using CloudFormation, but it’s not what CloudFormation is meant to do, so it isn’t very convenient. Also, you’ll have to go back and change the architecture manually every time you make changes to your setup.
To understand why you need a better architecture view, suppose you have a Lambda function that’s triggered every time a file is uploaded to S3. You can check the Lambda function’s configuration to see what the trigger is, as shown in the screenshot below:
Figure 1: Lambda function’s trigger configuration
As you can see from the screenshot, there is an S3 trigger for this Lambda function. What isn’t apparent, though, is the destination, which isn’t visible in the screenshot. You can add an SNS topic, an SQS queue, another Lambda function, or an EventBridge event bus as a destination. The problem, though, is that that’s a limited list of destinations. The Lambda function shown in the screenshot actually reads the name of the item uploaded to the configured S3 bucket and adds a record in a DynamoDB table. So the destination for this Lambda function is a DynamoDB table, but that isn’t shown in the designer. This is where it becomes difficult to understand the architecture of your project.
Thundra’s Architecture View to the Rescue
If you’re unable to visualize the architecture, you won’t be able to make connections and understand the relationships between different services in the project. As already mentioned, figure 1 is not telling the complete story, but let’s continue with the same example. To reiterate, there’s a Lambda function that is triggered whenever a file is uploaded to an S3 bucket. This function reads the name of the file uploaded, along with the name of the bucket, and adds this information to a DynamoDB table as a document, but that DynamoDB connection is not shown in figure 1.
Once the record is created in the DynamoDB table, another Lambda function is triggered. This second Lambda function reads the newly created record in DynamoDB and logs it to the console, and you can see the record using Amazon CloudWatch logs. But how will you know which is the second Lambda function? Unless you’ve made a note of this manually, you will have to go through each Lambda function and check the trigger manually. This isn’t feasible when you’re working on a large-scale project. But imagine having all this information mapped in one page in an easily understandable design, like the one shown in figure 2:
Figure 2: Thundra’s Architecture view
As you can see from the image above, Thundra’s Architecture view makes the project’s architecture very clear, which helps when you’re trying to debug a connection or data flow issue.
Color Coding Improves Observability
In the screenshot above you can see that the edges are all green. This means the setup is working as expected. When there’s an unexpected event that is breaking something, the nodes and edges turn red, making it easy to pinpoint the architecture error. Each node in the Architecture view also represents an AWS service. For example, from figure 2, you can tell that there are two Lambda functions, an S3 bucket, and a DynamoDB table. You can also move the nodes around to make the control flow more meaningful and understandable.
Now suppose that there’s an error between the S3-Demo Lambda function and the s3_files DynamoDB table. There could be a connection issue, or the Lambda function might not have the required permission, or the name or region of the DynamoDB table could be misconfigured. In such a case, when the Lambda function is executed and an exception is thrown, the Thundra layer catches the exception and applies the color codes to the corresponding node in the Architecture view. When this happens, you can easily tell that something is not working as expected. You can see an example of this in figure 3, where the S3-Demo Lambda function is colored red.
You can enable metrics from the filter in the Architecture view to get the invocation count for each edge. With metrics enabled, you will get an idea of how many times a Lambda function is being triggered and the time taken for each action. An example of this is shown in figure 4.
Figure 4: Example of metrics in Architecture view
If you want more granular details about an action in the architecture, you can click the corresponding edge to bring up the details. For example, if you click the edge between the S3-Demo Lambda function and the s3_files DynamoDB table from the above example, you will see charts about the number of invocations, average duration for completion of the action, and the durations for the 95th and 99th percentile of the operation. Along with this, you’ll get the time at which the invocations took place and see if there were any errors. This is shown in figures 5 and 6.
Figure 5: Charts with invocation count and duration
Figure 6: Table with details of invocations
Timeline Scrubber Helps Visualize Architecture Changes
Thundra goes one step further in helping you visualize the changes made to your architecture with a handy time scrubber at the bottom left of the page. You can move through the timeline and see the architecture change. This helps you figure out how the architecture has changed over time and see the breaking changes you’ve made to the architecture, if any.
Getting a Fuller Picture with Architecture View
As you can see, having the Architecture view auto-generated from your AWS setup is very helpful, not just for visualizing your architecture, but also for health auditing. Another very practical use is helping a new team member get onboarded. Giving them access to the Architecture view is more helpful than handing them hundreds of pages of text. And because the node edges are color coded, it’s easier than ever to figure out where an error occurred and when. This means you spend less time digging through logs on CloudWatch and more time actually fixing the issue—and you can’t deny that that’s a good thing. For more information about observability and monitoring, take a look at this whitepaper.
*** This is a Security Bloggers Network syndicated blog from Thundra blog authored by Suna Tarıyan. Read the original post at: https://blog.thundra.io/understanding-your-serverless-systems-architecture-with-thundra