How Glide Reduces Costs and Identifies Optimization Opportunities With Honeycomb
15 minute read
We consider Honeycomb an investment rather than expenditure.
Company Stage: Startup
Tech stack/integrations: Typescript, Google Cloud Platform, Firestore, Honeycomb
Industry: Information Technology
Location: Headquarters in San Francisco Bay Area
Founded in 2018, Glide lets anyone easily create mobile apps without writing a single line of code—their mission is to create a billion new software developers by 2030. The company offers many free and paid templates that enable their customers to create and distribute mobile apps generated from spreadsheets, with custom actions and workflows. Those apps are also automatically updated when creators update spreadsheet data.
With more and more people relying on mobile device apps daily, Glide’s top priority is ensuring that the apps their customers create are working as intended to provide the best user experience by keeping spreadsheets and apps synced, all while keeping a close eye on their backend spend.
Understanding individual customer experiences
Shortly after launching, the Glide team quickly realized that understanding their backend performance was a mission-critical need in order for their services to meet demanding customer expectations. The only problem was their platform provided very limited options when it came to achieving that.
Glide uses Google Cloud Platform’s Firebase, a platform developed by Google for creating mobile and web applications. They heavily rely on Cloud Firestore, a scalable database for mobile and web development integrated with Firebase. According to Mark Probst, CTO and Co-founder at Glide, Firebase had very limited tools to help them identify where problems might be occurring.
After evaluating alternate solutions, including Grafana, the team ultimately decided to go with Honeycomb because it allowed them to understand what individual customers were experiencing. “We looked at many different options, and the one thing that stuck out to me was Honeycomb’s ability to handle any cardinality we wanted to see,” explained Mark. “A lot of the data we care about most, like app IDs, have very high cardinality. We needed to drill down and group by data that helped us understand what individual customers are seeing happen with specific apps. That capability turned out to be huge and incredibly useful for our future.”
We needed to drill down and group by data that helped us understand what individual customers are seeing happen with specific apps. That capability turned out to be huge and incredibly useful for our future.
“Our use of Honeycomb is extremely exploratory based on whatever we need to figure out at the time,” added Daniel Sweet, Senior Software Engineer at Glide. “We largely use it to debug issues by getting a feel for how our apps behave and what sort of usage patterns we have going on. For example, our customer support requests keyed against app IDs to drive support investigations, and we simply would not have been able to do that without Honeycomb.”
The team then started sending their frontend events to Honeycomb in order to understand how users were seeing errors. “At first, we didn’t know how often users were seeing errors because there was no way of reporting on them,” explained Mark. “We needed to find out things like how often users saw errors and how long they appear on the screen. Once we started sending frontend events to Honeycomb, we didn’t need to use any other analytics tools to see that.”
Experimenting to identify the right optimization investments
Honeycomb also helps the Glide team understand fine-grained performance details in ways that allow them to identify the right optimizations to make. That ability has led the team to set up experiments that validate proposed changes, make better architecture decisions, and ship new changes to production faster.
“For the longest time, we had issues where cold-starting our cloud functions took forever,” shared Daniel. “Once we started using Honeycomb, we could see how long it took to import various functions we needed. We discovered it took up to eight seconds to load some functions from Google’s API package. We had to be very careful about what we decided to import, and with Honeycomb, we were able to start shuffling around our code to reduce initial start execution times for anything in our critical path.”
Those optimizations led the team toward being able to release changes to production faster. “We were able to deploy faster, and more importantly, after we deployed, our users would not experience periods of unavailability because everything was able to initialize very quickly.”
The team now regularly sets up experiments that quickly measure the impact of proposed changes. “We wouldn’t be open to experimentation if we didn’t have a way to measure it,” shared Daniel. “We would’ve had to set up this entire measurement infrastructure ourselves and that’s an additional thing we would’ve had to maintain.”
We wouldn’t be open to experimentation if we didn’t have a way to measure it. We would’ve had to set up this entire measurement infrastructure ourselves and that’s an additional thing we would’ve had to maintain.
“Before, what we would have to do is stand up a local development environment that effectively connected to some of our production environments,” he continued. “We had to impersonate specific users and apps inside of our development environment to try and piece together how frontend and backend interactions came together. With Honeycomb, we no longer have to do that because it can just give us the raw data and status codes we need.”
Now the Glide team uses feature flags in tandem with Honeycomb to measure impact in production. “We’ll set context fields for experiments we actively run on our backend. A feature flag we’ve enabled results in that context being added to our traces. What we do then is compare execution times or error results between requests where that feature flag is true or false,” explained Daniel.
“That ‘turn it on, turn it off’ style of experimentation has been huge for us in terms of being able to try out new things and validating the results. For example, Honeycomb is helping us figure out where we need to make the right infrastructure investments as we look into moving toward a more persistent containerized environment.”
Managing backend spend
Beyond customer behavior, Glide also uses Honeycomb to monitor their own usage patterns as well. Keeping customer spreadsheet data synced with mobile app data is critical to providing a great customer experience, but also incurs incremental costs with Cloud Firestore. Those costs can quickly spiral, and the team takes steps to ensure they don’t get any unpleasant surprises in their bill.
“We use a Honeycomb derived column to calculate the cost of various functions,” explained Mark. “We also put in app IDs to figure out which ones eat up the majority of our spend. Often, we find there’s either a bug we can fix or a cost-saving measure we can implement to keep our costs down.”
In one instance, the team discovered some apps weren’t frequently used, yet their data kept being reloaded even if it hadn’t changed. Changing their backend to only reload data when an app is actively used resulted in big cost savings. “By seeing that with Honeycomb, we reduced our costs by half and saved at least $10,000 with that one change,” shared Mark.
Honeycomb has enabled the Glide team to better understand a once-opaque cloud architecture. Their ability to zoom in on individual customer and app behavior has given them a better way to support customers, reduce costs, and introduce a culture of experimentation to identify optimization opportunities. Currently, the team is experimenting with non-serverless application architectures, an initiative that was prioritized by seeing the performance and cost benefits through Honeycomb.
“Overall, Honeycomb saves us time because of its fine-grained querying capabilities—it’s very substantial,” said Mark.
“We consider Honeycomb an investment rather than expenditure,” added Daniel. “It’s been absolutely worth what we’ve put in—it has absolutely been a worthwhile investment, both financially and time-wise.”
Calculating Costs for Observability
Debugging in production is a requirement for modern teams, especially for teams who ship frequently. DevOps teams need the best tools to debug issues when they come up, not just hope they can catch everything in staging. You need to make the move to next-gen APM--but how much will it cost? How much should it cost?
Progressive Delivery: Using Feature Flags & Observability to Ship Confidently
Progressive delivery lets you see whether or not new changes will benefit users before they’re really released. This webinar explores how to use progressive delivery, feature flags, and observability together.