InsanIT is a vision for an operational platform simulation for digital educators. Rather than focusing on a sample system, it simulates a full DevOps control plane including continuous delivery, monitoring, collaboration, coordination, and governance. This is not built yet. Deck is to stimulate discussion and interest.

1. InsanIT
Towards a next generation platform for digital education

2. • InsanIT is a platform to simulate a realistic digital environment for
training students in a comprehensive set of characteristic duties
• System envisioning
• System development and deployment
• System operation
• Collaborative work related to the system (team level)
• Coordination of work at larger scale (“system of systems,” “team of teams”)
• Governance (including security and architecture)
• InsanIT is a free and open source project.
• InsanIT is a successor to the original Calavera project.
What is InsanIT?

3. • Providing a continuous delivery toolchain that students can
experiment with
• Providing a simulation of a “production system” including
monitoring, event and alert management, and operational response
• Exposing students to real-world interactions of collaboration and
coordination tooling vis-à-vis actual operational systems
• Providing grounded examples of architecture and portfolio concerns
(which can be too abstract otherwise from a textbook perspective)
Educational scenarios

4. • It is not the purpose of InsanIT to simulate individually complex digital systems requiring
significant software engineering, e.g. a sample ecommerce system. These already exist (e.g.
https://github.com/GoogleCloudPlatform/microservices-demo).
• It is the purpose of InsanIT to simulate the operational matrix for digital delivery:
• Development and continuous delivery infrastructure, including quality and security assurance
• Team and team of teams/system of systems automation
• Load simulation
• Monitoring (basic, end user, security) and event management
• Operational response
• Governance automation including financial tracking, risk and security, records and information, and
architecture/portfolio including technology lifecycle (patching, sunset).
• The Digital Professional Body of Knowledge shall serve as a framework scoping the educational
objectives InsanIT supports
• InsanIT focuses on defining control planes over the operational system.
InsanIT principles and scoping

5. • For the intended objectives, it is critical to not distract the student with intricate functional
software engineering. There is sufficient complexity in the surrounding delivery fabric!
• The fundamental unit of the InsanIT system is a trivial 10-20 line microservice (http GET and
POST) that can easily be adapted by students of varying skill levels, but is technically
fundamental and transparent enough to provide real operational experience (rather than being
overly abstracted and “magic”).
• The service will be replicated to arbitrary levels of scale, possibly with minor variations injected.
• Advanced courses might use InsanIT to operationalize more complex systems, but this is not the
initial focus.
InsanIT principles and scooping (2)

6. • The support of vendor partners will be essential for InsanIT.
• However the fundamental InsanIT stance is vendor neutrality.
• InsanIT will have a modular architecture and vendor partners will be
encouraged to develop alternative containerized, “as-code” modules
with supporting documentation featuring their products.
Industrial context for InsanIT

7. • InsanIT should be cloud-native in orientation
• However, because it deals with significant operational load (implying
potentially unacceptable cloud costs), it must also be operable on-
premise by institutions
• It also must be cloud-provider agnostic
• All aspects of the system must be specified “as-code” and stored
under source control
• However, experience also dictates that all specified binaries (whose
build is out of scope for the simulation) be archived in a repository
(preferably a package manager but at least a file system), to protect
the simulation from upstream volatility.
Platform vision

8. Architecture vision
Micro
service
Load driver
Test
data
Monitor
Logging
Production platform
Micro
service
Operational response (ie incident)System intent
Portfolio (functional and technical)
Construction
Micro
service
UAT/load platform
Micro
service
QA platformDev platform
Micro
service
Micro
service
Micro
service
CI
Source Package
Infrastructure platform and automation
CD
Change
Governance plane
Coordination plane
Continuous delivery control plane
System (of systems) under management
GRCAnalytics
Release (including SCA) Provisioning

9. • Version 1: pure microservice/K8S
• Version 2: other platforms (VMs, IoT, bare metal, mainframe).
Increase in underlying tech enables more robust portfolio learning.
• Version 3: evolutionary programming applied to microservices to
make them change dynamically
Roadmap