Setting up a Lab
Since we are all VMware Tanzu, our engineers should be familiar with the products our sales folks are selling in the field. If our customers have a target platform of TAS or TKG, we need to know how to architect our system to take the most advantage of that platform. These are normally our target platform, and not knowing them does a disservice to our customers.
Therefore, one of our first actions as a leadership team was to give our engineers a place to practice on TAS and TKG. We believe that doing is a great way of learning, and giving our team a place to “do” should be a good thing.
So, we went spelunking. We discovered that our internal confluence page already had instructions on how to get a sandbox TKG or TAS environment! Sweet! Ship it, we’re done. On to the next problem.
Well, maybe not. We should take a deeper look at this. Are these instructions any good? Are they up to date? Let’s go find out before we send our engineers that direction.
We started with TAS. The instruction set was a good start. It pointed to an API. But it didn’t say that we were set up for SSO/Workspace One login. That might be confusing. And logging in with the cli requires the ` — sso` option… that might be useful if they want to use the command line. (I’m a big proponent of using the command line. Command line executions are so much easier to automate than clicks on a web page.)
Ok! We’re in! Now what? Looks like there isn’t a guide anywhere showing how to interact with this. Docs are available but learning by docs isn’t a great experience. Time to write a guide.
Spring-Music has been around for almost as long as Cloud Foundry has. It’s a great illustration of how to use profiles, cloud connectors, and is a pretty easy way to get used to some of the basic concepts of pushing an app.
So, we wrote up a guide using this app and these basic steps:
1. Login to the apps console
2. Install the cf cli and connect to your instance
3. Clone spring-music and run locally with an in-memory database
4. Push the app to TAS (introducing the manifest file and tailing logs)
5. Verify the behaviour of the in-memory database on the TAS instance
6. Scale spring-music to two instances
7. Create and bind to a mysql instance (service brokers FTW! restaging!)
Its very much a TAS 101 experience, but this guide can be completed in less than two hours. It introduces a lot of the basic concepts and gives a much better start than just pointing to the docs.
Cool! One platform down. Let’s go check on the state of the TKG confluence page.
Oof… its a ticketing process. That’s less usable. Ok, let’s try the ticket… and we’ll see how it goes.
In the meantime… what would a TKG guide look like? Can we do the same thing as spring-music? There’s a lot of background that’s necessary to do any kind of kubernetes deployment. Whereas TAS just pushes your app, for kubernetes you need to understand pods, container registries, deployments, replica sets, services, sidecars… and to get a database like we did for spring music we’re getting into the Tanzu Application Catalog area which seems pretty intensive for just a TKG 101.
So do we write a “kubernetes on your mac” guide? That doesn’t sound like a great idea… there are literally hundreds of those already out there. Maybe have a base set of requirements so we write a 200–300-level guide as opposed to a kubernetes 101? That seems a little more promising… although that guide already exists on the confluence page. Maybe this work is already done… need to step through that existing guide and see where we can better qualify the pre-requisites.
In the meantime, we’ve reached out to the group that owns the TKG instances, and are working through ways of removing the ticketing friction. And we’ve also recognized that we’ve only touched on two of the products in the entire Tanzu suite. There are quite a few more. To figure out which makes the most sense, we’re going to start a survey of our engineers and see where we can best prioritize our efforts.
Armed with this information, we can be more surgical with the guides we write.
