Articles providing techniques, guidance, and best practices for how to build web applications that scale to significant traffic volumes.
Are you a CEO, CTO, COO, VP, or Director of a company that utilizes or wants to utilize the cloud? Come to the COUP: Embrace Change, Recognize New Opportunities & Capitalize in Miami, FL, and see me speak on Monitoring the Cloud.
Join me at Cloud Expo 2016 at the Javits Center in New York, NY on June 7-9, 2016, where I will be speaking on keeping high availability in the Cloud.
Take a look at the article Microservice Architectures: What They Are and Why You Should Use Them>, written by me and published by New Relic.
It’s an increasingly common scenario: As a company grows, it finds that it needs to move away from the monolithic software architecture that powered its initial success. The alternative? A microservices approach that provides more speed and flexibility. That’s the story told by both our guests on the latest episode of The New Stack @ Scale Podcast: Tung Nguyen, vice-president of engineering at Bleacher Report, and our own Lee Atchison, principal cloud architect & advocate at New Relic. Listen to it on New Relic’s Blog.
An updated copy of my book, Architecting for Scale, published by O’Reilly Media, is available for download. This is the second version under the early release program. The full book is scheduled to be released in May.
One of the most important topics in architecting for scalable systems is availability. While there are some companies and some services where a certain amount of downtime is reasonable and expected, most businesses cannot have any downtime at all without it impacting their customer’s satisfaction, and ultimately their company’s bottom line. How do you keep your customers happily using your service and keep your company’s revenue coming in? You keep your service operational as much as possible. There is a direct and meaningful correlation between system availability, and customer satisfaction.
Traditionally, software companies created large, monolithic applications. The single monolith encompasses all business activities for a single application. As the company grew, so did the monolith. In this model, implementing an improved piece of business functionality requires developers to make changes within the single application, often with many other developers attempting to make changes to the same single application. Developers can easily step on each other’s toes and make conflicting changes that result in problems and outages. Development organizations get stuck in the muck, and applications slow down and become unreliable. The companies, as a result, end up losing customers and money. The muck is not inevitable, you can build and rearchitect your application to scale with your company, not against it.
Scaling web applications isn’t easy. As web applications grow, two things begin to happen. First, they become significantly more complicated and hence brittle. Second, they handle significantly larger traffic volume requiring more novel and complicated mechanisms to handle this traffic. This can lead to a death spiral for an application that can lead to brownouts, blackouts, and other quality of service and availability problems. My purpose for this blog is to provide techniques, guidance, and best practices for how to build web applications that scale to significant traffic volumes.