Course Feedback

[vrabbi]

Overall a very good course! The one comment i have is in regards to the question "TKG installation is supported on which of the following infrastructure platforms? (Select 4)" whilst it technically is not false that TKG as a family could be deployed to all of those platforms it is not 100%. TKGi is different from TKG and i believe that this question can cause serious confusion. when TKG is mentioned on its own and not as TKGi it would be usually understood as Standalone TKG. this can only be provisioned on AWS and vSphere 6.7u3 so i think this should be reworded to something like: "The Tanzu Run Portfolio allows provisioning by at least one of its runtimes on which of the following Infrastructure Platforms?" or keep it as TKG and make it 2 answers and not 4 removing azure and GCP

[vrabbi]

also there seems to be no way to generate a certificate of finishing the course

[afewellvmware]

@vrabbi thanks so much for this feedback and definitely get your perspective here. I think things are moving so quickly and there is so much effort to get products out, we are still working to optimize how we best position and drive understanding of the portfolio. Thus far, if you look at almost all TKG materials, they almost all specifically exclude TKGI. Many in the BU believe that at the initial stages of product education, all editions of TKG including TKGI should be presented as a common family. This is not just a 'marketing' exercise, I believe it is the best way to educate people about the portfolio. In the context of this course in isolation of other exposure to the product, TKG is consistently used to present all TKG editions as a whole including TKGI which I think this course makes clear, but for anyone who has already seen many presentations on TKG/TKGI until now they have always been presented separately, so we are already used to seeing a distinct separation there. I think the most critical thing is that we position TKG products consistently, so my hope is that we will start to see other product and solution decks present all editions of TKG focusing on the commonalities as I have in this deck, but at the same time that principal cant be so restrictive that it limits meaningful improvements. Regardless we will revisit this course again periodically to ensure its consistent with current portfolio positioning strategy. Thats the short answer, I dont want to over-respond if thats all your looking for but I do put a lot of thought into these sorts of decisions and always interested in understanding more perspectives if its something youd like to explore further.

In case you do want to explore further, ive shared more of my thoughts on the matter below, but dont feel you have to read all this if its more detail than you wanted to get into :)

At the 101 level, the majority of IT people are still very very new to K8s and they need to understand the big picture works before the lower level details become relevant. All TKG editions provide kubernetes clusters as a service, they all provide management services that handle the deployment and lifecycle management including monitoring of services and some self healing actions for deployed kubernetes clusters. All editions provide the key services needed to enable enterprise K8s-as-a-service including auth, logging, monitoring, registry etc, and while the exact method that some service gets fulfilled may differ, if you have a functional spec for 'enterprise kubernetes as a service platform" the functionality between tkg and tkgi is almost identical. And for learning, I feel its best to understand this conceptually before learning lower-level details. That is not to say the differences between tkg and tkgi should be diminished, but I believe that if someone doesnt know anything about TKG, the first step is understanding what features does an enterprise need from a KaaS platform, what are the common functional services provided by all TKG editions, and once that understanding is developed, then greater detail about functional specifics can be addressed.

One concern I have had with this approach is if people could mistakenly think we are implying that every edition of TKG can be deployed on every listed target IaaS. Personally I dont think the deck as delivered in the course should create that confusion in isolation, I think the problem especially for those of us close to MAPBU offerings is, we are all very used to seeing TKG and TKGI presented seperately, and while we are used to that, I dont think its normal to position one edition of a product like its totally separate. I think when this is positioned to partners or customers who are new to TKG, if we position all TKG editions as a family they wont have the pretense of TKGI always being treated differently. Regardless of our position on naming, the name TKGI itself says its an edition of TKG, and I am told the same k8s binaries will be deployed to workload clusters on all TKG editions including TKGI. All of our decks about all of our products have higher level slides first and then get into more detail, its more common to see that some new thing is 'supported on vSphere' when positioned at a high level and people seeing that dont just naturally assume that would imply every single version of vSphere, they understand that they need to confirm lower level details as they learn more.

I cant say exactly how things will be positioned a year from now, but this is still new, currently there is a lot of momentum towards positioning all TKG editions as a common family at the introductory level, and accordingly there will be some higher level slides that position the features of the family at the family-level. I think this approach is actually much more normal than what we have been doing by presenting TKG and TKGI in isolation of each other. My intent for courses on modernapps ninja is to have a common course for all TKG editions at the 101 level, I plan to have seperate 201 level courses for different editions, in alignment with the HOL's that are planned.

One last thing on this topic, I have noticed a very very strong pattern from students who come from traditional IT background, when learning about cloud native, there is a strong natural tendency to impose legacy constraints onto new cloud native deployment efforts. A LOT of the early devops efforts have been from isolated devops teams working directly with cloud provider infrastructure, where the people who managed infrastructure were not part of the conversation. Which means most the many powerful examples of cloud native apps from the early leaders and all their benefits can be shown in cases where devops teams used cloud provider infra and had no ability to turn low-level infrastructure knobs, and in fact tried to abstract themselves from needing to be concerned with low-level infrastructure knobs. Yet in my experience, when infrastructure ops people from traditional background start to plan how to implement k8s clusters, there is a strong tendency to want to turn lower level infrastructure knobs, how the new thing can meet legacy backup or ha models, and lots of various policy constraints that are based on legacy ideas that are often no longer relevant.

I really feel here that if anyone is going to do kubernetes and cloud native right, having the right perspective is hugely important, attaining and approaching design problems with a cloud native perspective is an important thing that needs to be taught, I dont think we have focused enough on this on the training we have done until now and I intend to make it a bigger area of focus in all courses going forward. We use k8s for running apps, when we deploy apps to k8s, we use tools from CI/CD to CD to App deployment tools like spinnaker, none of the tools used to deploy k8s apps care about low level infrastructure knob tuning, you can have k8s clusters deployed anywhere and app deployment tools dont care, they just deploy apps to whatever clusters you want according to whatever policies that will be inevitably implemented at the app deployment/orchestration tooling layer. I think part of the proper cloud native perspective when developing distributed multi-site application architectures is treating a given kubernetes cluster as a disposable entity, and focusing more on policy at the application deployment layer than the infrastructure. And if you have this focus, the lower level differences between TKG editions and TKGI or wherever a k8s cluster is deployed, dont matter nearly as much. Everyone will interface with multiple IaaS solutions, in each case there is an opportunity for low level provider specific tuning, the more required policy that can be delivered above the IaaS layer results in far greater strategic benefit for all use cases that dont specifically need lower-level entanglements.

Sorry if thats too much detail, not trying to beat that to death, just want to share my rationale and thinking here.

Thanks!

[afewellvmware]

@vrabbi also thanks for pointing out the certificate issue, I will open a ticket with the provider and let you know when its fixed.

Thanks!

[vrabbi]

Thanks @afewellvmware for the long and detailed response. Definitely understand your perspective here. I think that in general I agree with your perspective on presenting tanzu as a family of products and not as a bunch of standalone products. Just a few thoughts though in this regard. I worry someone could think that with a given solution (whichever edition) they could deploy to all 4 cloud providers mentioned which today is not yet the case. I agree with the points you make about cloud native mindset and the immutable nature we should give to k8s clusters where we shouldn't really care where it runs, however with tkgi this becomes very difficult. Almost all other solutions today (else,also,gke,anthos,tkg,vanilla k8s etc.) All follow certain general principals especially in terms of networking that tkgi simply does not adhere to. This is not a bad thing at all and ncp is an amazing tool and has positioned VMware in the k8s ecosystem for enterprise companies very well. However due to this fact that the solutions end result today is still very different (service type loadbalancer, ootb integrations with vRealize stack, UI for management, ncp, routed pods, etc.) The agnostic view is still not there. I believe also that because of these issues there is a problem with positioning of the different editions and that is why the general decks and presentations I have seen all sperate the different editions. I know there is plan to have the same bits included for tkg and tkgi but currently as far as I know that's not yet the case and hopefully in the next releases would be the case. Tkg is evolving quickly and the features that are coming soon (after seeing some of the roadmap) position the tanzu run portfolio much better as a full solution and not sperate products.