How we're building apps as developers is changing. Fast. The breadth of our responsibility is decreasing (yeah), yet the complexity of our code is increasing (meh).
We've just launched our app monitoring service for the modern development era.
How did we get here and what problems are we solving?
The full stack/full responsibility era
Just a few years ago, if you were lauching an app, you were responsible for EVERYTHING. You and your dev team deployed and maintained the full stack:
Scaling a full stack isn't trivial. It takes valuable developer/devops time to do this. We started to look at ways to cut out pieces of our stack...
The birth of services
In 2009, Amazon introduced Elastic Load Balancing and Relational Database Service (BETA). This decreased the hardware your dev team was responsible for maintaining.
We started to like these services. What other parts of our stack could we offload?
App Services Era
It didn't stop with building services for the basic infrastructure building blocks. Today there's everything from file upload to user authentication services.
The upshot? We're responsible for less plumbing code than ever before. I'll never complain about having to write an ImageMagick or user auth system again.
As the number of app services have grown, we've been able to off-load specialized infrastructure to vendors. This means we're focused more on just our custom app code...
The acceptance of PaaS
If our infrastructure is simpler, our deploys are simpler too. It's just
If you are running on a PaaS like Heroku or Cloud Foundry, your stack has just become:
With our time freed up for writing custom app code, we're now writing more specialized apps. We're adding more awesome sauce.
This custom code is frequently slow.
Scout is intentionally NOT full-stack app monitoring
If we're not responsible for the uptime of the services beyond our app code, it makes a lot less sense to monitor those services. That's why Scout is the first app monitoring service that's intentionally not full-stack monitoring: the most time-consuming perfomance problem today is fixing bottlenecks in our own custom code.
If our ELB/RDS/File Upload/Web Socket service isn't performing, we'll submit a support ticket with those vendors. We won't debug them ourselves.
Fixing slow custom code before Scout
Before Scout, fixing slow app code looked something like this:
- Look at an overview chart of my app's performance
- Oh there's a spike - I hope my app monitoring captured the slow request then (since they just sample)
- If my APM tool happened to sample the right slow request, inspect it.
- Ok - I don't think I wrote this code. Who on my dev team might know about it?
- How long has this slow code been around?
Tracking people down is hard. I'll wait on this for now.
Fixing slow code with Scout
We've gone beyond code metrics: Scout adds critical pieces to make it easier to track down problems and find the person on your team best equipped to fix slow code.
What you used to suck up hours of dev debugging time now takes just minutes:
3 Key Features
- Don't miss a slow request - most app monitoring services just sample slow requests. It's almost 2016: we capture every one. It's the slow requests that help us learn the most about our app's performance.
- Git Integration - we
git blame your slow code so you can quickly find out who wrote it and when.
- Context - when you have a slow request, it's super helpful to know the email address of the user that triggered it, which database shard it hit, their monthly spend, etc. Easily add this with our API.
No-Haggle Pricing. No Contracts.
We're confident Scout stands on its own merits: that means no pricing tricks or contracts. Try app monitoring free for 14 days.
App Monitoring for the Modern Dev
As Scout customer Aaron Scruggs of AcademicWorks says:
"We liked New Relic, but we love Scout."
We're committed to building the first APM service that's built for you, the Heroku-deploying, AWS service-using, fast-moving developer.
Questions? Just email us at email@example.com.