Operations | Monitoring | ITSM | DevOps | Cloud

We know speed to market matters—now more than ever. Bill Gates said in the nineties that “if you don’t meet customer demand quickly enough, without sacrificing quality, someone else will.” But software quality also matters, affecting everything from customer loyalty to developer experience. Poor quality causes immediate issues like bugs and crashes, as well as building technical debt and making updates needlessly hard.

Software quality isn't just about defect density; it embodies the reliability, performance, and security that underpin digital trust and user satisfaction. But measuring software quality can be as challenging as defining it. In this post, we'll demystify the complexities around assessing software quality and provide actionable insights for you and your software development team.

On December 31, 2008, all the Microsoft Zunes around the world stopped working. The development team hadn’t properly accounted for the Leap Year, and when the year changed over, everything broke. On February 29, 2024, card payments in a Swedish grocery chain went down, payment terminals in New Zealand gas stations crashed, and an EA Sports racing game was rendered unplayable for the day.

After decades as a software engineer, I’ve seen firsthand how complexity can grow exponentially with scale. Thankfully, over that time, quite a few tools have come along to help manage some of that complexity. One great example is the Internal Developer Portals (IDPs), which were built to connect an engineering organization’s architecture, processes, documentation, and definitions and alignment to standards of health.

When speed to market can make or break a business, the move from monoliths to microservices has become an obvious choice for many engineering teams. This transformation promises agility, scalability, and the ability to more closely align with business functions. It is why we see organizations moving from the rigidity and restrictions of monoliths to the flexibility and control associated with microservices architectures.

Already a quarter of the way into 2024, we’re seeing a lot of shake-up in on-call best practices. We’re excited to see AI in the mix, but we’re also seeing a renewed focus on existing and neglected best practices. Some current topics in on-call best practices include: In this article, we’ll review some best practices and explore the 2024 trends.

It's been a decade since Marc Andreessen declared that software is eating the world, and it is still hungry. Customers expect software solutions for every need, driving digital transformation in every analogue industry. Software quality is now fundamental to company reputation, directly affecting customer satisfaction, brand and overall business success.

Earlier, applications were mostly monolithic, meaning that several programs were written in the same language and placed in the same web stack. However, it is no longer the case today. Today, every software is comprised of several small application programs coming together each providing a service of its own. These applications are what we call microservices.

Containerized microservices have been the gold standard for cloud computing since they replaced the monolith architecture over a decade ago. The flexibility, scalability, and velocity they enable for teams make them an obvious choice. Yet, a strict interpretation of one service for one function doesn’t quite serve everyone, especially when architectures get large. We’ll discuss how flexibility in service architecture might be the way to go.

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.