There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton
Many computer problems boil down to: How do we configure things? Configuring things is a superset of naming things, so configuration can be a hard thing to figure out.
As a seasoned computer professional, I have spent much of my career dealing with this problem, sometimes called, “Configuration Hell.” I generally see two main solutions:
- Convention Over Configuration.
- We actually can design and implement solutions that minimize or eliminate configuration.
- We actually can design and implement solutions that automatically configure things, can sense their environment, and generally do the right things.
- Directory Services.
- When we must deal with configuration, of all the ways of designing and implementing any configuration solution, using Directory Services is by far my favorite.
- My goal is to persuade you this should be your favorite too.
I have been writing software since 1970, so I can you to death with the multifarious ways of configuring computer applications, systems, software, etc. I will spare you, and assume your imagination can give you a sense of this.
However, the universe of configuration ranges from flat text files, to formatted text files, to binary encoded text files, to active systems utilizing various kinds of database technology, etc. With so many options, how do we know what we want?
Fundamentally, all configuration issues, problems, and solutions boil down to Knowledge, so to appreciate configuration issues, we need to know about knowledge. There is an entire branch of philosophy dedicated to this called Epistemology, and it is the place to go to really know knowledge.
Why is he talking about e-mail?
Published in 1984, the “Red Book” laid out the X.400 International Standard for Message Handling Systems. In 1988, the “Blue Book”, and in 1992, the “White Book” defined new capabilities.
We don’t see X.400 around much these days, but it did spin off some rather excellent technology.
As an aside, I did work with the Defense Message System as an X.500 consultant, for a company customizing and reselling ISODE, an X.500 product. I can say with confidence that for the needs of the US Department of Defense, X.400 was an excellent choice for their very demanding needs.
What X.400 really needed was a way to know who to send email to, and how to send it. X.400 needed knowledge and so was born X.500.
Now, X.400 went way overboard with capabilities and features, and so it needed a knowledge system that went way overboard with capabilities and features. The designers of X.500 really applied a lot of Epistemology to their designs. Maybe too much, but I respect their goals. They really know their stuff.
In the X.500 culture, we liked to say that knowledge was information about information. Some people might say meta information or meta data, but there really is more going on in X.500.
As someone who worked in the X.400/X.500 industry for years, I can honestly say I was not all that impressed with X.400, but I was really impressed with X.500. In terms of knowledge, in the Defense Message System, the DOD really need to know their stuff.
In the late 1970s some bright people at the University of Michigan invented LDAP, or the Lightweight Directory Access Protocol. This preserved the best capabilities of X.500, but with much less bloat.
In 1999, Microsoft introduced Active Directory with Windows 2000 Server Edition, which incorporated LDAP as both and architecture and as an API, the LDAP API.
Identity Access and Management
While Directory Services started out to support email systems, today they are an important tool used in IAM systems, where we access and manage knowledge of identity, knowledge of access, and knowledge of more…
In Microsoft solutions, Active Directory is a key element of their IAM, and for Microsoft customers, Active Directory is often a central element of their IAM.
Swiss Army Knife
Ultimately, once we understand Directory Services such as X.500, LDAP, Active Directory, etc. we should also understand that these are general purpose knowledge management systems, and more, that can be effectively applied to almost any configuration problem.
All configuration problems are a subset of knowledge problems.
In today’s R&D environment, if you are investing research and development in custom configuration tooling, then you are almost certainly reinventing the wheel.
There really is a cornucopia of configuration solutions, so it’s better to shop around, but I hope you will ultimately end up in the Directory Services store. You may not think you need a swiss army knife today, but change is inevitable, and with a swiss army knife, you are better prepared for change.
In graduate school, I researched using X.500 for federating database systems, and implemented a prototype demonstrating many kewl features: Using X.500 to Facilitate
the Creation of Information Systems Federations, so if you are curious why I am so enamored with Directory Services, here is a good place to start.
Largely, the takeaway from my research was systems like X.500 are not only good at representing and managing knowledge, but they can also be good at transforming knowledge, looking at the same knowledge from different perspectices. One of my key insights was: for any given ontology, there are multiple taxonomies. This was not something I was looking for, it was simply a discovery from pushing designs around in interesting ways.
So, when I use a metaphor like a Swiss Army Knife, I know there is much more to Directory Services than what most people see.
In Part 2, I plan to go into some of the more interesting capabilities of Directory Services that make them so versatile for configuration solutions, for configuration management, and for many other things as well.
Given that Forgerock has its own Directory Services product, I will try to express things in those terms, where our product is based on some of the technology I worked with on the Defense Messaging System and in graduate school.