Manageability

Table of Contents


MANAGEABILITY

TTM ROI Sellability Agility Reputation

The ability to easily manage a system or estate in an efficient and effective manner.

DEFINITION

Dictionary.com describes Manageability as something: "that can be managed; tractable; governable; achievable".

One of software's key selling points is its softness. In relation to hardware, it's cheap to change, deploy, and distribute. These qualities promote regular change.

I've already described how digital industries are increasingly focused on scale and change (How We Got Here?, DORA Metrics). Today, successful businesses tend to be the ones who emphasise rapid and regular change (e.g. low lead times), and almost instantaneous distribution. It's therefore in our interests to support easy change, and thus, Manageability.

MANAGEABILITY & MAINTAINABILITY

We've already seen a similar principle to Manageability in an earlier chapter. If you remember, Maintainability relates to how easy it is to manage and change code, whereas Manageability works at a more abstract level of change, one of interconnected components and systems. Both relate to managing change, but work at different scopes.

For us to better understand Manageability, let's pause briefly and consider what it means to manage software. The most common forms of (software) change typically fall into one of the following buckets:

They all involve some form of management. Quite a list, and one - I hope - that promotes the role of Manageability? Can you imagine performing all of these activities in an uncoordinated, unautomated manner? Me neither. Yet, that's what some businesses still do.

MANAGING ARCHITECTURES

For decades, the Monolith was our go-to architecture. Monoliths are both easy, and difficult, to manage. They tend to dominate an estate - there aren't many of them, they're stacked with features, and are relatively easy to identify and catalogue. They're the good points on Manageability. On the flip side, Monoliths contain many Assumptions, configuration (that's often irrelevant for the task at hand), and are riskier change propositions (due to the size of change).

Modern application architectures paint a different picture. There's a general trend away from the centralised (monolithic) model, towards a distributed model (Distributed Architecture), to satisfy the needs of increasingly sophisticated consumers and businesses. Read through the How We Got Here section if you'd like to know more.

Distributed Architectures (such as Microservices) make few assumptions, they're granular, and their configuration is sufficiently fine-grained to solve the problem at hand. But… there's lots of them, you must configure each to talk to others (since dependents don't coexist in the same environment), and each instance tends to have (intentionally) shorter lives. So, whilst Manageability is more focused, the overall estate requires more configuration, it changes and evolves more regularly, and there's more moving parts.

The consequences of this complexity shift are before us. In earlier times, we were quite comfortable documenting systems and inventory using diagrams and wiki pages. It still happens, but it's becoming increasingly common to employ a tool (e.g. Config Management Database (CMDB)) to manage this complexity on our behalf. It says something about modern Manageability needs.

Let's now look at Manageability through the secrets management and scaling scenarios.

SECRETS MANAGEMENT EXAMPLE

Software components rarely permit unrestricted access. Most consumers - whether they're users or other systems - are required to authenticate in order to use it. Perhaps the most common example of this is the relationship between a service and its database.

A service typically authenticates with its database using a shared secret (i.e. a password). If it matches, it's granted access. Pretty sensible so far, but how does the service get the secret in the first place?

Let's assume that we've already agreed on an appropriate database password, now we must decide how to manage it. At first glance, this doesn't sound particularly tricky, but consider the following. Where should we store the password? Should we store it in clear text, or encrypted? When (at what stage in our component's lifecycle) should we make our component aware of the password? What mechanism should we use to deliver it? What about when it changes? These are all management-related questions for what's a seemingly simple use case.

There's multiple ways to achieve this, some better than others. One option is to store our secret directly within the component's source code, or configuration, and commit it into version control. This, however, is ill-advised, even when encrypted [1].

A more dynamic approach might be to inject it on the initial deployment of our service. We could add our secrets as environment variables and then reference them from code. It's certainly better than the code-only option, but we're now suggesting that someone (or something) must go into each environment, grab a password from our password store (they're also aware of that password in some way, which may broach security concerns), set a variable to represent that secret in our environment, and then deploy and start the service. What happens if we need to change that password with a matter of urgency? Surely we don't need to revisit every environment, stop it, find the new password, change the relevant environment variable(s), and finally restart the service? Is that a manageable approach?

Another approach is to use a Password Vault - a centralised keystore designed specifically for secrets - and permit our component to (securely) retrieve the (encrypted) password at a time that suits it. This deals with delivering the secret, although it isn't without challenges.

The point here isn't necessarily to discuss the relative merits of one secret management model over another, but to articulate how different approaches make Manageability easier or harder, and needs consideration.

SCALING EXAMPLE

Let's change tack and pursue another common management activity - scaling a software component.

Today's architectures generally favour Horizontal Scalability (rather than Vertical). The most direct consequence of this is the need to manage a larger number of (ephemeral) instances, (virtual) hosts, and applications in a highly distributed manner. The consequence of this is that it makes the manual management of software increasingly untenable.

A wind of change has swept through the world of software management over the last decade, from one that's predominantly imperative, to a declarative one (Declarative v Imperative). This is no accident. Whilst the imperative model has served us well for many years (and will continue to do so), it has limitations (e.g. it doesn't scale particularly well). The declarative model - on the other hand - uses Abstraction, suggesting automation, and a simplification of our interactions (with it), sometimes to the point where intervention is unnecessary.

DECLARATIVE TOOLS

The uptake of Orchestration, Serverless, the PAAS, and the Cloud demonstrates this. We now have a wide range of declarative tools to manage software to support: scale, resilience, integrations, and deployments (in various forms).

Returning to our scaling problem, one approach might be to scale out manually - i.e. we manually execute a series of deployment steps to expand our estate; but that's relatively slow and imperative. We could miss the traffic spike, or forget to terminate those instances once we're done with them etc. Clearly it's unmanageable when we're talking big numbers, or fast lead times. At the other end of the spectrum, we could set a very high (possibly unlimited) scaling threshold, and allow our systems to figure out how and when to scale. This moves much of the (scale) management away from us, but has its own detractions [2]. A middle ground is one where we set a maximum capacity, and allow the system to manage it itself. This is the power of the declarative model. We describe what we want, and allow the system to figure out how to get there, managing all of the intricacies on our behalf.

OBSERVABILITY & MANAGEABILITY

Our ability to manage software also depends on our ability to contextualize it, both in terms of what we have (our estate), but also its current state (its health). Observability fits in here. It's not Manageability per se, but a supporting counterpart quality of it.

Again, my purpose here isn't to discuss the relative merits of a scaling approach, but to emphasise that our decisions (or lack of them) affect our ability to manage software.

PILLARS AFFECTED

TTM

Systems exhibiting poor Manageability are more difficult to change, so take longer to do so. Excess effort (time) may be spent in: the imperative world (e.g. the insufficient abstraction of potentially reusable, or "simplification" functions), manual intervention (e.g. manually nursing a poorly system back to health), verification (e.g. failing to employ alerts or autonomic processes), and even responsibilities (e.g. the responsibility for upgrading and patching operating systems also falls on your shoulders).

ROI

Where Manageability is poor, more time (money) is spent - well, managing - e.g. discovering the current position, what to do and where to do it, verification, planning activities, and more manual intervention (staffing costs). Of course Balance is required - there's also the possibility of Gold Plating - overdoing it, automating everything, when there's little financial imperative to do so.

AGILITY

Good Manageability makes it easy to make change. It removes (or reduces) Unknowns and Surprises. It enables us to adapt more quickly to unexpected events, like traffic spikes (scaling), and system failures (recoverability). Consequently, we become more agile.

REPUTATION

The inability to easily manage (make) change makes future change less likely. That's not a healthy proposition for any business. It stymies Innovation and Evolvability, and without intervention will eventually impact your Reputation.

SUMMARY

Manageability covers a lot of ground. Anything that needs deployed, scaled, observed, configured, discovered etc, needs some form of management. It's not a binary (on or off) state. Everything is managed, it's simply a question of how well.

A utopian state might be one where everything is easily configured, discovered, integrated, scaled, compliant etc, but that's financially and temporally impractical. Like any of our qualities, it's important to know what we're aiming for, and judge where to make an investment. That being said, the advent of new techniques and technologies continues to make Manageability easier, albeit with the caveat that systems continue to increase in complexity.

MANAGEABILITY IN A COMPLEX ESTATE

The size and complexity of the software estate also influences our ability to manage it. A large, complex, heterogeneous estate suggests a wide diversity in approaches, tooling, technologies, and experience, that makes (the management of) change harder.

FURTHER CONSIDERATIONS