Design and Build a CMDB for Cloud Infrastructure
- The Scenario
A customer contracted me to develop an automated, code-based framework for supporting operations in The Cloud.
In the I.T industry this is generally called "Landing Zones" or "Cloud Foundations" and is used to support the "Cloud Standard Operating Environment".
In short, the customer's infrastructure in The Cloud would be defined using "Infrastructure as Code", deployed and configured using CI/CD pipelines and automation and managed using a DevOps/SRE philosophy.
In simple terms, my task resolved to:
"Write a complex collection of Terraform, BASH and Jenkins pipelines to define Cloud infrastructure and security guardrails, deploy resources to the cloud and configure the infrastructure thereafter. Make this code integrate with existing authentication systems, networks and security systems. Make it support production and non production environments across all business units of the customer's organisation."
This approach of managing Cloud infrastructure "as code" with maximal automation is a departure from an earlier era of manually or semi-scripted management of Cloud operations by teams of I.T staff. It aspires to bring about a fully automated, fully "code defined" cloud operating model for businesses who have their I.T infrastructure and applications hosted in the cloud.
It maximises the value, purpose and capabilities of "The Cloud".
2. Existential Questions
Given that the task is to develop "Infrastructure as Code", what has CMDB got to do with all of this? Do we need a CMDB at all? What value overall does it offer? What are the alternatives?
When writing infrastructure code for large, complex organisations (not startups or small businesses!) the situation inevitably arises that large amounts of complex configuration needs to be maintained for the infrastructure code in the cloud, a few examples are:
- IP addressing information for subnets assigned to applications
- Cloud accounts, projects or subscriptions assigned to applications/teams or business units
- Environment Domain and environment profiles for each application (prod/non-prod, sit/uat/dev/sat etc ...)
- Access profiles for various application teams and users in the cloud
- Integration information for Infrastructure code to access API endpoints providing additional configuration services
- The actual provisioning and status of resources/services in the cloud relative to applications and teams using them.
Very soon, one finds that this information cannot be efficiently included in the Infrastructure Code as variables or parameters in flat configuration files while still keeping the codebase as "abstracted" as possibled.
Another requirement that develops is that other systems within in the organisation want to access the shared configuration, or perhaps are the "single source of truth" for some configuration information. For example, perhaps IP addressing information is maintained by a networking team in an IPAM of sorts and this information must be regularly refreshed.
Some kind of actively maintained centralised database of configuration data is required in this case. A database perhaps, with a frontend and automation capable of integrating configuration data, which could be used to supply the configuration parameters for abstracted infrastructure code.
3. Philosophy of Approach
Before investing effort into implementing a CMDB it made sense to think more deeply about it from a "systems" perspective:
- The "meaning" and implications of CMDB in I.T infrastructure
- The importance of Agility, Simplicity, Flexibility, Robustness
- The "Minimal Viable Product"
4. The Scope of the Task
The scope of the CMDB implementation has to be clearly understood, defined and documented (yes, in that order!) before any formal implementation is done. The primary reason for this is to ensure the best work can be focused on the parts of the CMDB solution that matter most to it's eventual users.
- Context is Key
- Defining the MVP
- The needs of the moment vs. the needs of the future vs. the needs of the past
- The needs of the many vs. the wants of the few
5. Dividing and Conquering
"The Whole is Greater than the Sum of its Parts" - Aristotle
- The Sum of the Parts
- The Parts
- The Whole
6. The Build
"A journey of a thousand miles begins with a single step" – The Tao
Building a CMDB, no matter how "lean" we attempt to architect it is always a complex and labour intensive task, primarily because it is a bespoke integration task tailored to the organisation we're building it for. Yes, there are some common elements but ultimately there is always a requirement to integrate with at least a few legacy elements of the customer's infrastructure and some unique legacy choices they've made. These few variations are enough to permute to a significant amount of complexity in practice.
However, this can all be mitigated by breaking the implementation into tiny, manageable tasks using the SCRUM methodology.
7. Was it all worthwhile? The Retrospect
"Was it all worth it yeah yeah, giving all my heart and soul
Staying up all night, was it all worth it
Ooh living breathing rock 'n' roll this never ending fight
Was it all worth it, was it all worth it
Yes it was a worthwhile experience
Ha ha ha ha haa
It was worth it
Ha ha" – Queen