How Tackle.io Monitors Performance in Serverless
Sentry sponsored this post.
Serverless technology is increasingly being adopted by organizations. According to The New Stack’s analysis of a community survey on GitHub, 75% of users plan to build a greenfield serverless application over the next year. Tackle.io, which has built a platform that helps independent software vendors (ISVs) get their software listed in the cloud marketplaces quickly, is one company that has adopted a serverless architecture. While serverless helps developers to quickly create and scale new applications and services, the inherent lack of visibility into the underlying architecture and how the performance of that architecture impacts users is a significant challenge.
In this Q&A interview with Tackle.io founder and Chief Technology Officer Dillon Woods, we talk about how they have overcome the challenge of monitoring a 100% serverless stack. We also discuss what it’s like building software for other software engineers and how this impacts their expectations, as well as why he believes code monitoring will in a few years become just as important as infrastructure monitoring in the DevOps pipeline.
We know that Tackle helps customers turn cloud marketplaces into repeatable, sustainable sources of revenue, which means your customers are essentially other software developers, right? What is it like to build software for other software engineers? How does this impact their expectations, and as a result, how you and your team measure success?
Software engineers are often Tackle’s biggest advocate within an organization because we help them focus on core product development rather than worrying about developing and maintaining cloud marketplace integrations. However, software engineers can be our toughest customers as well, because they have high expectations! All customers look for a great user experience, but software engineers also highly value security, architecture, and API best practices. We know we are on the right track any time we see engineers smiling when they get done evaluating Tackle’s product.
Slow iterations with a lot of testing, or move fast and (potentially) break things — where do you fall on the spectrum of speed vs stability? What drives this?
The Tackle engineering team moves fast! We’re lucky to have amazing customers who are excited by new ideas and rapid releases, but that doesn’t mean we can sacrifice quality. A key to our success is having the right tools in place to actively monitor customer experience, so we can start working on fixes before our customers even report the problems.
Describe the tech stack and your approach to development. What languages/frameworks do you use to build Tackle? What are your biggest engineering opportunities/challenges?
In one word, our tech stack is serverless. Developing with a completely serverless stack has been a major competitive advantage for us, both in terms of how fast we can develop new services and how little time we spend securing and maintaining our infrastructure. We use a combination of AWS Lambda and Fargate to power our APIs and services. Our backend is written primarily in Python, with JavaScript on the frontend. One challenge we’ve encountered with serverless is that it has been difficult to ensure a consistent and responsive end-user experience because the API infrastructure is outside of our control. For example, we were experiencing numerous “cold start” issues with our Lambda functions that caused users to intermittently see long response times from API calls. We’ve since integrated Sentry’s Performance Monitoring toolkit into our backend Python code, to quickly identify and solve these types of issues.
As frontend development becomes more operational, many people are talking about a gap that exists between the systems/infrastructure, code and customer experience. Is this something you’ve seen? What actions have you taken to bridge this gap and why?
As an industry, SaaS companies spend a lot of time thinking about providing a great user experience during the design phase of software development, but that thinking doesn’t always lead to a great user experience in production. Issues such as data inconsistency, client misconfiguration, or connectivity problems may only manifest themselves under a real customer workload. To bridge this gap, we continuously use Sentry to monitor run time errors and API performance so that we can give our developers visibility into real customer experiences.
What results have you and your team experienced?
There is something magical about proactively reaching out to customers about their issues before they have a chance to report them. This direct customer engagement has allowed us to build a more meaningful relationship between our developers and the users of our product. We have also found that we spend far less time debugging issues that show up in our production environment. Our developers used to spend hours recreating a chain of Lambda function calls to troubleshoot a slow page load, but now we can find a complete stack trace at the push of a button using the Sentry dashboard.
How do you see software development and delivery changing over the next several years? What role do you think code monitoring will play in this evolution?
Over the past four years, most forward-thinking companies have adopted automated infrastructure monitoring as a core part of their DevOps pipeline. I believe that in the next several years, code monitoring will become just as important. Like many trends in SaaS, widespread adoption of code monitoring will be driven by user expectations. Once users become accustomed to their favorite SaaS vendors reacting to issues in real-time, they will start to expect the same from every product they interact with.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
