ArchitectingForScale Tag

Articles, tagged with ArchitectingForScale, providing techniques, guidance, and best practices for how to build web applications that scale to significant traffic volumes.


How Service Tiers Can Help to Avoid Microservices Disasters

Mar 22, 2019

Bringing down an entire application is easy. All it takes is the failure of a single service and the entire set of services that make up the application can come crashing down like a house of cards. Just one minor error from a non-critical service can be disastrous to the entire application. There are, of course, many ways to prevent dependent services from failing. However, adding extra resiliency in non-critical services also adds complexity and cost, and sometimes it is not needed. Read the entire article today in The New Stack.


Managing Risk in Modern Enterprise Applications

Feb 6, 2019

By: Ken Gavranovic and Lee Atchison Want to reduce MTTR, reduce incidents and have a data driven discussion on investment allocation? Try what many modern software development and operations companies have implemented, an Enterprise Risk Matrix. We have seen implementing this process on a quarterly, bi-annual or annual basic can reduce MTTR by as much as 70%, incident count by 90% within 6-12 months.  Most importantly, the risk matrix can introduce a data driven discussion about investment in products (hopefully you have already migrated away from funding projects).


DevOps Reading List: Top 30 Best DevOps Books You Should Read In 2018

Apr 3, 2018

The #1 book on their list is “Architecting for Scale” book by Lee Atchison. As the article says:

"The first one on our DevOps reading list is Architecting for Scale. It is an excellent book to understand real-world paradigms for scaling and managing critical applications. This book covers 5 different elements: availability, risk management, services and microservices, scaling applications and cloud services. This book can be called a practical guide as well, it shows how to prevent an application from becoming slow, inconsistent, or downright unavailable as it grows. Also, in this book the word “Scaling” is explained very well as it is not just about handling more users; it’s also about managing risk and ensuring availability."


Why I Wrote the Book on ‘Architecting for Scale’

Jul 25, 2016

As applications grow, two things begin to happen: they become significantly more complicated (and hence brittle), and they handle significantly larger traffic volume (which more novel and complex mechanisms manage). This can lead to a death spiral for an application, with users experiencing brownouts, blackouts, and other quality-of-service and availability problems. “But your customers don’t care. They just want to use your application to do the job they expect it to do. If your application is down, slow, or inconsistent, customers will simply abandon it and seek out competitors that can handle their business. That’s how my new book, Architecting for Scale: High Availability for Your Growing Applications, begins.


Architecting for Scale - Updated Early Release Available

Jan 28, 2016

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.


Scaling with Availability

Jan 14, 2016

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.


Why Use Microservices?

Jan 6, 2016

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.


Welcome!

Dec 29, 2015

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.