Scalability Worst Practices: How Not to Design Applications

Scalability is a core requirement of modern applications. Applications need to be able to handle sudden changes in demand without losing resilience or performance. With the popularity of cloud computing and microservices, DevOps teams have a countless number of platforms and tools for deploying scalable applications. However, true scalability involves much more than just migrating an application to the cloud.Today's applications are built with scalability in mind. The shift to microservices from monoliths reflects that, allowing DevOps teams to scale individual components of an application rather than the entire application. This is a significant shift from monolithic applications, and many of the fundamental ideas behind scalable applications directly conflict with the principles and best practices of monolithic applications. DevOps teams need to be aware of these differences and which ones can actually be detrimental to scalability.In this post, we'll look at some worst practices when building scalable applications.

#1: The Golden Hammer

Psychologist Abraham Maslow famously said "it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." The Golden Hammer (or Law of the Instrument) is an over-reliance on a familiar tool even if the tool isn't suited for a particular task. This might stem from familiarity, a lack of awareness of different options, or a misunderstanding of the problem at hand.

Why It's a Problem

The software development landscape is constantly evolving with new tools and technologies. A solution that worked last year may have already been supplanted by another solution that's easier, more effective, or better supported.For example, virtual machines (VMs) were once the best way to run multiple isolated applications on a single system. Now, containers can run many of the same tasks in a much smaller footprint. But if all your team knows is how to use VMs, they will keep using VMs even when containers will do.

How to Avoid It

The Golden Hammer's greatest enemy is education. DevOps teams need to stay up-to-date on tools, technologies, and best practices. By being aware of the different options available, developers and operations teams can make educated decisions on which tool is best suited for the problem at hand. Otherwise, they may be stuck using older, less flexible technologies.

#2: Big Balls of Mud

Big balls of mud are applications with no apparent structure, design, or architecture. They're often the result of rushed development cycles, little to no maintenance or refactoring, or inexperienced developers. As big balls of mud grow they become harder to troubleshoot, maintain, and develop further.

Why It's a Problem

Big balls of mud have a lot of inertia. They consist of a number of tightly linked components and services that must be deployed and managed together. Attempting to scale any one service means scaling the entire the entire ball, leading to a significant amount of overhead and complexity.

How to Avoid It

The best way to avoid a big ball of mud is with a well-defined and modular architecture. Designing for a service-oriented architecture (SOA) is particularly effective since it encourages high flexibility and decoupling between components. If a team is currently working with a big ball of mud, they can still benefit by incrementally separating and refactoring parts of their application into microservices.

#3: Lack of Automation

Automation plays a key role in the DevOps lifecycle, from integrating code changes to deploying the final build to production. Besides performing tasks that would take significantly longer by hand, automation streamlines the flow of information between different teams and departments. The result is a much faster and much more efficient pipeline from development to operations.

Why It's a Problem

System scalability means being able to quickly respond to changes in user demand in order to maintain performance. This requires constantly monitoring the load placed on an application and increasing or decreasing capacity as needed. With the size and complexity of modern applications, DevOps teams can no longer hope to monitor and scale applications by hand. Even a few minutes delay between recognizing increased demand and increasing capacity could have devastating effects on performance and the user experience.

How to Avoid It

Automated tools can respond to changes in demand nearly instantaneously. Cloud computing services—particular Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) solutions—are a common example, since they can scale automatically with little to no input from DevOps teams. Container orchestration tools like Kubernetes also offer automatic scaling for containerized applications.

#4: Lack of Observability

The rapid development cycles that modern applications undergo can lead to any number of performance and stability problems. As a result, observability has become increasingly important as a tool for monitoring system health and debugging problems. Observability presents the state of a system through what is known as the Three Pillars of Observability: metrics, traces, and logs.

Why It's a Problem

Observability is crucial for giving DevOps teams the necessary insight into a system's operations. Not only do DevOps engineers need to identify what problems occur, but they need to understand why they're happening. By analyzing metrics, traces, and logs, engineers can effectively identify problems and trace them back to the cause in a much faster, much more automated way.However, observability in modern applications is a daunting task. For example, Pinterest generates over 100 gigabytes of log data each day. Deploying systems to collect, analyze, monitor, and process all of this data can be just as challenging as deploying the systems that are being observed.

How to Avoid It

There are a number of tools and services for collecting and analyzing logs, metrics, and traces. LogDNA is one such tool. The benefit of a solution like LogDNA is that DevOps teams can immediately begin streaming logs from across their infrastructure to a single centralized location in a matter of minutes. LogDNA processes gigabytes of log data each second, allowing you to monitor, search, and graph changes to your systems moments after they happen.

Conclusion

Users expect fast, responsive, always-available services. Avoiding these worst practices helps DevOps teams design flexible applications that can quickly and reliably respond to changes in user demand.If you need a logging solution that has great scalability with your applications, use LogDNA. LogDNA lets you stream an unlimited volume of log data from any number of sources. Livetail your logs in a single unified stream and retain up to 30 days of historical data. To learn more, visit logdna.com and sign up for a free account today.