Humor me for a moment here…
I have been reading a lot of books on k8s and I realized that you could probably categorize automation into three categories. Very similar to the Kubernetes object types used inside K8s clusters to support applications. We will forego the "Set" lingo and just use the main terms.
- Daemon
This is something that is running all of the time. Most of the time running some control loop to watch for an event. These can kick off when things are noticed but are generally not used in user interaction. These can be for system maintenance and background process.
- Job
This is similar to a Daemon but is actually ran on routine rather than control loop. This job usually produces some tangible results that are consumed for reporting or simply a routine task. Massage some data or take some action required on a strict schedule. These run daily, hourly etc…
- Service
This is where the user comes in. This automation requires an entry point. A place where you can go a request, submit, POST or PUT. This automation service is usually supported by the daemons and job automation categories.
Why do I mention this stuff?
Well I always look for ways to move operational tasks into these categories with some form of automation. These can be written in different languages, housed on multiple platforms even written into containers. Why not right? If you think about the automation in this manner you are better suited to produce reusable code and loosely coupled programs. Let's call them modules 🙂
The end goal being to produce self service and self driven IT operational process that are self documented and produce the exact same results every single time or fail. This allows for standardization across the enterprise and quick time to market. Automated processes can be tied into Source Control Management Processes that relate or tie directly into Change Management Process. With your ITIL/MOF or whatever ticketing system. Couple in security controls into this automation and viola!
Some might say this "in-house coding" increases support risks but I believe if this is done right with the proper controls it will absolutely decrease support risks.
TL;DR
Here we show a process in the video that takes multiple products stacked together to support multiple platform requirements. This process can produce VMs and Kubernetes clusters on top of VXRail, vSphere, NSX-T and Pivotal Kontainer Service.
This ties a bunch of technologies together and is what I would consider a fair representation of orchestrating provisioning in a software defined data center.
- VMs – Check
- K8s Clusters – Check
- Multi-Platform – Check
- Multiple Sizes – Check
- Approval Process – Check
- Fully Documented – Check
The beauty of this is that the ServiceNow instance is simply being used for the catalog. You could use any ticketing self service thingy that had a catalog and workflow for these offerings in the same manner.
Add in some more policy driven options for placement and you could easily provision hybrid cloud with this same technique and little code change.
Enjoy!