How observability impacts your developer velocity?
For a long time, developers cared about the logs in their application only. Anything downstream would be "other teams' problems". With the adoption of Cloud and Serverless technologies, developers have access to a whole set of new tools to play with and they need to understand what is happening in this complex system.
In this new world, logs are just one part of the pie. Back in 2013, Twitter Engineering sparked a conversation about a concept called Observability. Since then, the conversation around this topic has been broad and sometimes mangled between too many buzzwords. Observability can be defined as a superset of Monitoring, providing benefits and insights that monitoring tools lack. With 4 core pillars, Twitter defined the "Observability Engineering" in that post, which includes:
- Distributed Systems Tracing Infrastructure
- Log aggregation/Analytics
As we can see, Observability is a cultural trait, not a specific tool. We could consider other parts of the system that would be helpful to understand how it is working:
When developing serverless applications, these parts work together to help you move forward with confidence and quality. With that in mind, which tools would help us achieve these Observability features since day one?
On AWS, we have some good options out of the box:
- Amazon CloudWatch: Alerting, Monitoring, and Visualization
- Amazon CloudWatch Logs: Network, Machine and Application logs
- AWS X-Ray: Distributed Tracing System
- Amazon Elasticsearch Service: Log Aggregation and Analytics
Effects, Benefits, and Outcomes
Using the default tools from AWS, you can have a good level of Observability by instrumenting these tools to do what you need:
You can create CloudWatch alarms, monitor metrics and visualize your environment:
AWS X-Ray helps you understand and trace your requests inside your system, helping you to debug it across services in AWS:
In Amazon Elasticsearch Service you can aggregate requests from any service and also generate dashboards about your AWS environment:
Now that we paved the way to what Observability means, we don't need to instrument all of that ourselves. With the rise of the cloud-native approach, Thundra was built to address the lack of visibility and management across distributed systems and infrastructure.
On its core, Thundra defines 3 pillars of Observability:
Providing to developers rapidly applications debug and troubleshoot, understanding of workflows and systems, alerts and actions, automate verification of security controls and many other great points.
By far, my favorite is the reduction of context switching across multiple tools. Instead of using multiple tools to apply characteristics of Observability Engineering, I can use a true end-to-end management platform for distributed applications across serverless architectures.
Including 17 metrics by default (some runtime specific, e.g. Java or Go), Thundra can provide coverage for:
- Invocation Counts
- Invocation Durations
- Memory Usages
- CPU Percentages
- Disk IO Bytes
- Process Memory Usages
- Thread Count
- GC Counts
You can check the complete list in this link.
With compatibility for Open Tracing, Thundra provides full tracing capability, including local and distributed tracing, where you can check your Lambda interactions with other resources.
In the same dashboard, you can quickly debug your logs, making easy to connect your invocations and traces.
And with CloudWatch integration, within minutes, you can retrieve all of your functions in your AWS account.
Going serverless doesn't mean you can't understand what is happening in your workload. Problematic interactions will happen, and quoting Werner Vogels:
Everything fails all the time -- Werner Vogels
With the concepts of Observability Engineering, you can have all the benefits of rapidly troubleshooting, debugging and end-to-end systems tracing. Your cloud environment will look more familiar, and the confidence in your product will grow, helping you deliver better features and innovations.
Thundra is available on AWS Marketplace, you can also sign up through our console. Looking forward to your comments and feedback about offline debugging! You can reach out to us via firstname.lastname@example.org or on Twitter regarding your comments and feedback.