Speedscale was built primarily to provide engineering teams with better insight into their applications over time, replaying single transactions for root cause analysis that give developers and SREs confidence that tomorrow’s application code will work just as well in production as it did yesterday.
Testing in production simply means testing new code changes in production, with live traffic, in order to test the system’s reliability, resiliency, and stability. It helps teams solve bugs and other issues faster, as well as effectively analyze the performance of newly released changes. Its overall purpose is to expose problems that can’t be identified in non-production environments for reasons that may include not being able to mimic the concurrency, load, or user behavior.
At Speedscale, we’re always trying to find ways to iterate faster and reduce developer toil. In line with that mission, we slant our engineering decisions towards using cutting edge tech because we usually move faster and it also allows us to help our customers later on when they upgrade their own tech stack. Recently, we had the opportunity to upgrade the communication channel between our api-gateway and react front end. This journey provided some unexpected benefits.
Large portions of software development budgets are dedicated for testing code. A new component may take weeks to thoroughly test, and even then mistakes happen. If you consider software defects as security issues then the concern goes well beyond an application temporarily crashing. Although even minor bugs can cost companies a lot of time to locate the bug, resolve it, retest it in lower environments, then deploy it back to production.
Massive tomes have been written on engineering management, but I thought it might be helpful to take a brief minute to discuss setting up your Founding Engineers (FE) for success. For this post I define FEs as the first wave of engineers hired after the founding team. This round of hiring usually takes place after seed funding has been secured and some semblance of initial product/market fit has been achieved.
Speedscale ‘SpeedChat’ Episode 2: Shift-Left vs. Shift-Right Throwdown featuring Nate Lee (Founder, Speedscale), Ken Ahrens (Founder, Speedscale) and Jason English (Principal Analyst, Intellyx).
Speedscale ‘SpeedChat’ Episode 1: Discussing software product management, ‘dogfooding’ and scaling quickly for product/market fit without breaking things.
As a team we have spent many years troubleshooting performance problems in production systems. Applications have gotten so complex you need a standard methodology to understand performance. Fortunately right now there are a couple of common frameworks we can borrow from: Despite using different acronyms and terms, they fortunately are all different ways of describing the same thing.
One of the reasons we selected Sierra Ventures as one of our seed investors is because of their CXO Advisory Board. They have dozens of knowledgeable advisors across a wide variety of verticals: Healthcare, Consumer, Retail, Finance, Technology, Media and Telecom. Each year they conduct a broad survey of major trends. This kind of survey data is gold for Enterprise-focused startups.
When making changes to applications these days, it’s hard to understand and predict the impact of those changes before you deploy. API connections are multiplying, and with new cloud platforms such as containers/serverless, it only add to the complexity. Some people have trouble remembering whether they closed the garage door or turned off the coffee maker. Can you remember all the details of your latest API contract change? Let alone who would be impacted and needed to be notified?
