Two words that frequently come to my mind when creating or maintaining software solutions are lifespan and scope. The root cause of many bugs can be attributed to not fully understanding the lifespan or scope of software or infrastructure. These two words apply to essentially everybody in the IT industry, including software developers, product owners, DevOps, QA, and project leaders.
Global variables represent the worst side of lifespan and scope. By definition, long-lived global variables stay around for the lifespan of an application and all parts of the software can change them at any time. Their lifespan and scope are incredibly large, which makes troubleshooting and supporting software very challenging. Ideally, software components should be created at the time they are needed and removed as soon as they are not needed.
There are many constructs and approaches to help narrow the lifespan and scope of software components. Creating well-encapsulated abstractions using classes or modules is one way of reducing lifespan and scope. If a function or variable doesn’t need to be public, then it should be private. Software components tend to be smaller when they are built using a limited lifespan and a narrow scope. Software components that are small and do one thing well are easier to test and maintain.
Accessing data from a database is a common task for a backend software developer. There are many approaches and many opinions regarding this subject, but let’s consider a solution that uses stored procedures to access data from a database. Stored procedures create a data access layer around the database. The application can only access or modify the database by using stored procedures. Stored procedures narrow the scope of the database inside the application resulting in an application that is more secure and potentially easier to maintain.
Let’s consider a web API that uses resources from AWS. The API can contain proxy classes or modules for each AWS resource used by the API. This narrows the scope of AWS with respect to the API and allows developers to easily determine which AWS resources are being used and how they are used.
The concept of lifespan and scope is not limited to software and applies to infrastructure as well. Let’s look at the AWS Simple Email Service (SES). By default, AWS SES throttles the number of emails that can be sent per region. Let’s assume that a region hosts a staging and production environment. If the staging environment uses all the available bandwidth for sending emails, the production environment will not be able to send emails because both environments are in the same AWS region. Proper throttling limits must be implemented in both environments. The scope of these environments with respect to AWS SES must be understood to avoid any disruptions to email.
AWS WAF & Shield is a service that can be used to reduce scope. One feature of this service is that it can geo-restrict a public web API to a specified country. If a particular software solution only runs in the United States, it does not make sense to give the rest of the world access to the API. Narrowing the scope of the API to one country greatly reduces the attack vector.
In one example, a DevOps team was working on an efficient way to spin up application servers. Unknown to them, the servers in the test environment ran a service that pulled billing data from a queue in production. This caused customers to be underbilled. The scope of the servers and their functionality with respect to their environments was not clearly understood by the team.
There are many techniques to help us limit the lifespan and scope of our software and infrastructure solutions. Reducing the lifespan and scope of software components to the smallest possible level increases the quality and testability of software. It’s easy to forget lifespan and scope, and even seasoned developers need a gentle reminder once in a while.
Have a question about your next software development project? Schedule a free discussion today with a lead engineer at Enola Labs.