Operations | Monitoring | ITSM | DevOps | Cloud

‍In this final part, the Scout team continues our talk with Freedom Dumalo, former CTO at Flexcar and current CTO at Vestmark. We discuss some essential questions about architecture, touch on Rails, Turbo, and Stimulus, and the key considerations for those starting off before they lock in an architecture or tech decision. ‍ By the way, before we jump in, Scout Error Monitoring is coming!

It’s been a while since we’ve shared what’s been bubbling up behind these scenes are Scout. In this post, here’s an update on where we’ve been and where we’re going!

In 2025, many companies are reckoning with the true cost of microservices, especially as cloud bills grow and engineering teams face coordination fatigue. The move back to monoliths is gaining traction, particularly for startups and mid-sized businesses who need: ‍ At Scout APM, we’ve been thinking about these shifts not just from a monitoring perspective, but from a broader architectural one.

The Internet Engineering Task Force (IETF) is the premier Internet standards body, developing open standards through open processes. The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of Internet architecture and the smooth operation of the Internet. The IETF standards-setting process is open to any individual interested in providing technical contributions.

In 2025, many companies are reckoning with the true cost of microservices, especially as cloud bills grow and engineering teams face coordination fatigue. The move back to monoliths is gaining traction, particularly for startups and mid-sized businesses who need: ‍

Congratulations! Your Rails app has finally started seeing consistent traffic and things are on the upswing. But with growth comes the potential for the sluggish sort of SQL queries that can really slow things down. In this post, we’ll go over what your database (whether it’s MySQL or PostgreSQL) can tell you about the problem, and we’ll also talk about what it can’t tell you. Spoiler alert: this is where Scout comes galloping over the hillside to the rescue!

‍ Let’s talk about something we’ve all experienced: a customer reports that their checkout process is “sometimes slow,” – or maybe you noticed an unexpected spike in response times. So, you dive into the logs, grep through thousands of lines, and try to match timestamps with your APM traces. Sound familiar? At Scout, we’ve seen countless engineering teams struggle with this disconnect between their logging and APM tools.

‍ While Scout provides powerful monitoring tools (try it now!) mastering logging is an awesome complement to these skills. In this post, we’ll see how to create readable, actionable logs for both humans and machines. You’ll improve your logging strategy, drastically reduce troubleshooting time, and put yourself in the best possible position for maximum observability. As a starting example, let’s take this error log.

Proponents of microservices claim more development velocity and reliability; more comprehensive test and vertical or horizontal scale with a container orchestrator; tons of flexibility around tool choice. They’re not wrong: When you build with a microservices architecture, you’re likely going to see cost improvements early in your software development life cycle (SDLC), driven mostly by the decoupling of services.

Slow code is everywhere—or maybe "anywhere. "Slowness" is a spectrum. Sometimes, you triumphantly move performance bottlenecks so that the bar for "slow" always gets lower. In our experience, though, things often trend in the other direction.