1 of the most iconic components to running software in production are consoles full of graphs and metrics about how that software’s performing. Generally, they’re called “dashboards,” but in my experience you want something that provides the ability to act on the data being shown on the console as opposed to a dashboard which is generally read-only. That action could take the form of filtering or drilling down on the data being shown, or triggering some administrative task. Like with everything else in life, 1 size, or in this case 1 administrative console, doesn’t fit all. If you group the different types of users who have a need for an administrative console, you’ll find they fall into 3 general personas.
Why should I have 3 administrative consoles?
That’s a good question. Administrative consoles are meant to be a single place that people can go to get information about their software and to perform useful tasks to help maintain it and keep things running. Breaking that up across 3 separate consoles seems counter-productive. But the reason I’m advocating for 3 is because there are 3 distinct groups that have a use for these consoles, with very different requirements. These requirements are, in my experience, different enough that they need 3 functionally different admin consoles. Whether you deliver that experience by packaging and deploying 3 separate consoles, or making 1 that offers a completely different experience based on the logged-in user is up to you.
The developer admin console
First up is the developer’s administrative console. This is likely the most redundant of all the administrative consoles and if any of these were likely going to have to be cut, this would be the first in line. That’s because the data in this console is likely to be replicated across the other consoles that also include other potentially useful information, but the reason I’m including it as a separate administrative console is because these consoles include the ability to perform useful actions, and a development administrative console is the place to include the ability to do any sort of tier 2 and/or tier 3 support action that can be scripted.
Another good use of this console would be to double-check a user’s settings – bad or incorrect user configurations have got to be 1 of, if not the, most common reason behind support tickets that I’ve investigated over the years. Having a tool where developers and/or support personnel can pull those up and confirm they’re correct, without seeing any other sensitive data, are a big help. I don’t recommend including the ability to change them – it seems like a nice thing to do for users, but I’m not a big fan of a company editing any of their users data, even if you do tell them about it. That means the changes get made more slowly, and quite frankly less often, but in my opinion it creates a better experience for the user if they can be assured that the only time their data changes is because of something they did.
Lastly, just because we’re doing stuff with this console doesn’t mean we don’t want to see metrics. This is a good place to track any metrics about the software that could influence development work. Some examples of this would be: number of users, number of VMs/containers, amount of data coming in/going out, etc. This is also a good place to integrate with whatever tool that you use for indexing and searching your logs so developers can query about any possible problems. At the very least, this console should link to the aforementioned log search tool for follow-up research. Whatever data or tools are needed for developers to do their part of keep this software running should be here.
The operations admin console
This administrative console will likely look a lot like the developer one. After all, development and operations are closely intertwined (hence the whole DevOps movement). However, the thing to keep in mind is that operations and development are still 2 separate jobs with 2 separate focuses (in this case, the infrastructure). These are some of the most common dashboards and administrative consoles out there – in fact there are entire companies built around selling software like this. This is an administrative console that you can probably get off the proverbial shelf, whereas the other 2 consoles are likely going to have to be in-house custom implementations (you may be able to get a business administrator console in a tool like Salesforce, but I’m not familiar enough with them to know for sure).
This is the console that should be focused on your infrastructure, keeping track of individual instances, disk space, memory availability, etc. This is also a good place to kick off basic maintenance actions, like deployments, or killing unhealthy instances (to force whatever recovery mechanisms you already have to replace them). This console would also benefit from a link to your logging index (if you don’t have a full-fledged integration) to help with troubleshooting strange behavior in production.
The business admin console
If you’ve ever fielded questions from managers (project or otherwise) about usage, activity levels, revenue, conversions, or any other business-related information that can be put into a presentation and shown to the “powers that be” higher up on an organization chart, then you’ll understand the need for this console. Rather than getting requested for this information every month, you can give the interested parties a URL to an administrative console that has all of this information readily available to them. While 1 of the most powerful parts of the developers’ administrative console was the ability to use it to perform common, scriptable support tasks, the power of this console wold come from being able to search and filter usage-related data to answer any high-level questions related to business metrics.
Of course, good administrative consoles enable users to do useful things, and in this case, this would be the place business-related people can perform tasks related to customer accounts (enabling additional capacity or a higher service level after a customer purchases it, for 1 example). There’s also a lot of potential use to be had in integrating this console with other tools. For instance, if you can detect when a customer is having trouble getting something to work, you could use this console to display a message so that support or an account manager can proactively reach out to them and offer help.
As an “office politics” note, if you’re going to sink a significant amount of time making any of these administrative consoles look “pretty,” make it this one. While developers and operations aren’t eager to look at eyesores, polishing this one up encourages people to share it with the “big bosses,” and being the people who provide a tool like that makes for a nice win for your team.
A note about overlap
You may have realized that there’s a decent bit of overlap between some of the things covered by each administrative console. That’s because there’s no true border between a lot of these concerns. There are some things that are relevant to multiple groups of people, even if it’s for different reasons. Project managers may be interested in a user counts, and how active they are, because it’s a good thing to cite in business presentations because of the correlation with revenue. In fact, they may also pull in revenue-related stats to look at things like what the average revenue per user is, and categorizing which users (if any) tend to spend significantly more than everyone else. On the other hand, developers and operators care about the number of users as it relates to their infrastructure. How much load are those users putting on their system? What are their traffic/activity patterns, is it consistent or bursty, and does the existing scaling strategy reflect that? Could the software be refactored to handle the same load with fewer resources? The operations team and business managers both care about infrastructure and stability, but operations tends to focus more heavily on redundancy and recovering from issues while the business managers are more likely to think about balancing uptime against the costs of running those instances against their operating budgets. The point here is that you shouldn’t get hung up if data appears on multiple consoles.
A particular place of overlap is between the developer and operations consoles. The data the console shows is likely to be almost all overlap. In fact the only real difference between the 2 is likely the actions you can perform from there. It’s going to be tempting to combine them into 1 console for both types of users, but you shouldn’t. That’s because development and operations are really 2 different jobs with 2 different roles (even if they should be working closely together), which means they need to use administrative consoles to do 2 different sets of tasks – and keep in mind that these are tasks that the other job shouldn’t be doing (or, in the case of developers, necessarily have the rights to do).
There are a lot of people involved in building software and getting it out into production, and that’s just the start of the work. The software you released is the product of a lot of different concerns, and it needs to be actively monitored to make sure things are going the way you hoped they would. The problem with dumping all of this information into 1 “has everything” administrative console is that you clutter up the console with information overload (or worse, a bunch of people trying to interpret metrics outside of their area of expertise and derailing your work because they think a random blip in a graph means a major problem). You also still need to limit functionality based on user and/or role, otherwise you’re going to have another set of tools where people can actually do stuff, which likely will pull the associated information with those actions so users can see what they’re doing. That second tool, by the way, will be what actually gets used. That’s why I refused to just let these console just be dashboards. They should be tools you can use for basic support and operational tasks instead of the high-risk approach of logging into production and doing stuff manually. These things are important, so important that you shouldn’t be afraid to build your own if you don’t see a commercial option that does things the way you think they should be done.