Revise MVK documentation: enhance CLI-centric explanations, clarify use cases, and expand introduction with personal experiences and tooling insights.

pages/intro01.md

@@ -12,14 +12,40 @@ What is  MVK ?
 
 <!--
 
-We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
+I work at the command line. 
 
-It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
+It is efficient and powerfull.
 
-Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
+I find that I can get the most done with tooling that is cli first and can automate everything that is.
+
+Infrastrructure used to be manually crafted.
+
+Now it is encoded and version controlled, recoverable, repeatable, maintainable
+
+can be reviewed and quality controlled
+
+MVK as self hosted is more portable across environments
+
+cloud to cloud ( ish ) but mostly
+
+dev => test => pre-prod => prod, all can use similar pipelines and plugins
+
+MVK started out as a means of sharing knowlege and providing a kick-start into k8s
+
+microlearnings
+
+templates
+
+avoids using cloud based servies that cannot port to other providers
+
+k8s has many of these 
+
+storage
+ingress
+load balancing 
+...
+more and more
 
-Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
 
-It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
 
 -->

pages/uses01.md

@@ -1,6 +1,6 @@
 # Minimal Viable Kubernetes
 
-Use Cases ?
+## Use Cases
 
 ### 🏠 Local development
 
@@ -15,14 +15,16 @@ Use Cases ?
 
 <!--
 
-We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
+We must start at the beginning amd continue as we progress toward production
 
-It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
+Development is where everything starts from
 
-Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
+logically we use k8s within development to start 
+
+packaging containers
+testing
+security scanning
 
-Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
 
-It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
 
 -->

pages/uses02.md

@@ -1,6 +1,6 @@
 # Minimal Viable Kubernetes
 
-Use Cases ?
+## Use Cases
 
 ### 🏠 Local development
 
@@ -16,14 +16,8 @@ Use Cases ?
 
 <!--
 
-We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
+proving we have not broken things with changes between componetnts and apps outisde of our own
 
-It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
 
-Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
-
-Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
-
-It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
 
 -->

pages/uses03.md

@@ -1,6 +1,6 @@
 # Minimal Viable Kubernetes
 
-Use Cases ?
+## Use Cases
 
 ### 🏠 Local development
 
@@ -15,14 +15,9 @@ Use Cases ?
 
 <!--
 
-We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
+In pipelines we can deploy production like environments allowing us to try out produciton configurations before going into live
 
-It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
+test and pre-prod environmetns can be entirely or in part ephemeral, cutting cost and proving infrastructure as code
 
-Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
-
-Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
-
-It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
 
 -->

pages/uses04.md

@@ -1,6 +1,6 @@
 # Minimal Viable Kubernetes
 
-Use Cases ?
+## Use Cases
 
 ### 🏠 Local development
 
@@ -15,14 +15,12 @@ Use Cases ?
 
 <!--
 
-We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
+prodduction can be never upgraded, rather, new productdion can replace old, provin infra as code and migrating to major updates
 
-It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
+We are already backing up our data right ?
 
-Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
+how can we prove our backups are valid without DR tests, rehearsals ?
 
-Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
+we can if we have infra as code
-
-It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
 
 -->

slides.md

@@ -57,7 +57,31 @@ Jon Brookes 2025
 <img src="/containers.webp" alt="preload" style="display:none;" />
 
 <!--
-This is an introduction to Minimal Viable Kubernetes (MVK). What it is, why it is brought into being and the tooling around it.
+This is an introduction to Minimal Viable Kubernetes (MVK). What it is, why it is brought into being and its tooling.
+
+17/18 I was working with Docker, for a time then 
+
+and now Swarm, then K8s
+
+one week deploying K8s 
+
+Self hosted, AWS vms and vmware on prem
+
+already on call, the next week on call 24X7 with k8s in the mix
+
+MVK has my experieces and thoughts from this time and untill now 
+
+I've deployed with terraform, tofu of managed k8s on Azure, AWS and now need MVK, so I made it.
+
+It is based on k3s but could as well be
+
+k0s
+minik8s
+talos
+
+I like talos and want to use it more
+
+it is MVK
 -->
 
 ---
@@ -203,4 +227,3 @@ class: text-center
 #### Jon Brookes
 
 [https://headshed.dev/n25/](https://headshed.dev/n25/)
-