Understanding modern software applications isn’t just a question of what; it’s also a question of why. Why do we choose to use a particular technology? How does that technology serve the overall business needs? And when you have a problem, how do you figure out what’s wrong? If you’re in the position of trying to understand a modern software application for the first time, these questions can seem unanswerable. Good news: every person you work with, and everyone you look up to, has had the same issues. When you understand the kinds of problems modern infrastructure is designed to solve, its pieces make a lot more sense. In this post, we’ll talk about what makes up a modern software application and tools that make it easy to understand your application’s performance.
What Does Modern Infrastructure Include?
Before we start, an important caveat: this is a high-level view of infrastructure. I might talk about things in this post that don’t make sense for your application. Additionally, there might be parts of your software stack I don’t touch on. Every application is unique! While many pieces of modern infrastructure include similar elements, no single part of the puzzle is used everywhere. Not even something as common as a database is the right fit for every application. This post is a guide, not a universal truth.
When your users think about your application, they’re thinking about the client. The client is the interface through which your users interact with your application. For some applications, the client is the entirety of the application. Often, we think of clients as being a graphical user interface (GUI), but it’s not the only form they take. If your application sends data to and from a server, you might have a GUI. You might have a mobile client running on Android or iOS. You might have a command line client that makes HTTP requests, like cURL. The “why” of a client is simple: without it, nobody can use your product.
This is the beating heart of most software applications. It’s where all the logic lives for whatever the application does. If you’re a software developer, this and the client are the parts of the code you touch most often. The application server accepts requests from your client. It processes those requests, then responds. When we talk about application servers, we’re talking about everything from authentication and authorization to validation and data persistence. You’ll often hear this part of the application called the “back end” in conjunction with the database. The “why” of an application server is also simple. Any time more than one client needs to coordinate with another, you’ll need an application server involved.
Usually, your users don’t want to do something once and never touch it again. They want to do some work, then rely on you to save their work, so they can come back to it later. Often, but not always, you’ll need a database to do this. Most applications—whether they run on an application server or merely through a local client—use some type of database to organize application data. The “why” for databases is also straightforward: they provide a structured way to both persist and retrieve data. Databases use a special programming language, the Structured Query Language. Importantly, database interaction often takes a significant portion of application processing time. When we get to application monitoring, we’ll talk about how to understand your database’s performance.
Data persistence doesn’t just mean databases, though. Sometimes, it also means long-term file storage. Take Imgur, an image-hosting website, for instance. Imgur needs a database to hold information about its images, plus file storage for the images themselves. Your site might need a similar setup. Databases aren’t good at storing and retrieving larger files, so putting images into the database is a bad idea. The logic for storing and retrieving data, both from the database and other types of storage, is found in the application server.
Here’s where things start to get a little more complicated. Your client takes input from a user and makes requests to the application server, which processes the request. Maybe it interfaces with a data persistence layer to save or retrieve some data. Finally, it sends a response back to the client, which displays the result of the request to the user. If you have one user or a hundred users, that’s probably enough for your application. But what if you have a million? Ten million? Suddenly, your application server is straining under the load from all those concurrent users. This is where a load balancer comes into play. Put simply, a load balancer is a small server that sits in front of your application servers. Yes, in this case, you need more than one application server. While we’ve come a long way in multi-core and multi-thread CPU architecture, application servers can still only handle a few dozen to a few hundred requests at the exact same time. Modern infrastructure solves this problem by running multiple copies of the application server at once. The load balancer does what it says: it balances the load between those servers. The load balancer knows how many requests each server is handling at any time. It generally distributes new requests to the least loaded servers, keeping them from overloading.
Astute readers will notice our application infrastructure has gained a lot of complexity. We’ve gone from a simple client making a request to a simple server reading from a simple database to multiple servers interfacing with multiple clients in parallel. What’s more, for applications serving many customers, you need to keep those applications running all the time. This is where orchestration software like Ansible or Chef comes into play. These programs define infrastructure through code, then integrate with infrastructure APIs and physical hardware to materialize that infrastructure.
These software stacks define your entire infrastructure and make sure hardware meets all your needs. Instead of manually provisioning three application servers, you can write code to tell an orchestration service you need enough processing power to handle the current load. If the load increases, your orchestration software provisions a new application server and automatically connects it to the load balancer and the database. When the load decreases, the orchestration service deprovisions hardware, so you don’t pay for more CPU power than needed.
How to Monitor Modern Infrastructure
When you’re scaling a big piece of software, you need to know how all the pieces fit together. Not just conceptually, but moment to moment. Slow responses and application failures lead to frustrated customers. It’s critical for a team to know about infrastructure issues as soon as possible. Each piece of infrastructure introduced above has its own logging system, but it’s not enough. A log entry from a load balancer corresponds to an action in the client and a response from the server. You can’t see the whole picture with just one piece of the puzzle. You need something to give you a view of your entire application’s infrastructure at once, so you can quickly identify problems. A tool like SolarWinds® AppOptics™ gives you such visibility.
We mentioned earlier that database performance can be a thorny situation. Many applications devote most of their resources to their database, which means poor database management can lead to poor app performance. Luckily, AppOptics excels at providing easy integration with many database systems. Connecting AppOptics to your application lets you see how parts of your infrastructure affect your overall response times. These connections give you visibility into how your customers experience your application in real time.
Modern Infrastructure Is Complicated, but You Can Manage It
Modern infrastructure might still seem overwhelming. That’s OK! It’s a big topic. The key is to remember why architects choose each of these tools. They serve a unique purpose, and none is chosen without care. As you develop your infrastructure and scale your application, remember you need insight into how your application performs at every level. Choosing the right monitoring tools provides you the optics you need to keep your application humming and your customers happy. If you haven’t been monitoring your application, it’s easier than you think to get started. Find out what you’ve been missing and try AppOptics today.
This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the U.S. government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.