Fast, Free WordPress Hosting in Google Cloud


This article documents deploying the WordPress content management system (CMS) in Google Cloud as a fast, friendly, cheap (possibly free!) platform to blog from.

This is probably relevant for you if:

  • You’re looking to start a blog
  • You’ve settled on WordPress, the top Open Source blogging engine
  • You have some Linux command line skills

I’m not going to discuss choosing WordPress over some other content management platform. Spending too much time worrying about the content management engine is a trap; Get to producing your content and don’t worry about the platform you’re using to publish it. That’s something you can change later on, as most of the major CMS platforms have tools to migrate from the other major platforms.

Why: Motivation

I host WordPress on tiny virtual machines in Google Cloud for administrative performance, and entry-level price. I’ve been asked “how” enough times that I’d like to document it for others.

My Blogging History – Blogger

My writing for the web has been a hobby, not a profession. I got started publishing personal short and medium form content on the Blogger platform. Blogger still exists, and if it fits your purpose, you might want to bypass all of this and just use it. Again, you can always change your platform later. The content is the important thing.

Blogger to WordPress shared hosting

I eventually moved my personal writing and professional musings to shared WordPress hosting platforms. WordPress is probably the most popular Open Source content management system out there. With that footprint comes tons of support, active development, and a large ecosystem of enhancements (themes, plugins, customizations). WordPress hosting services were an easy way to get started using WordPress without thinking about the infrastructure. Over the years I used a variety of vendors including (I think) Bluehost, DreamHost, and iPage.

WordPress shared hosting to WordPress in Google Cloud

After a number of years, I grew frustrated at the slow performance during upgrades of WordPress plugins and themes. I would log in to WordPress, intending to copy some content in and move on, a 2 minute task, only to see the latest group of upgrades that needed my attention. Those upgrades require suspending the WordPress engine and could lock up 10-15 minutes of my time. I ran some tests and found that WordPress running in a small VM could do the same thing in less than 15 seconds. Despite the poor relative performance, shared hosting vendors were expensive relative to what you could pay for in a cloud VM. I had the expertise to do the minimal administrative tasks, so I bit the bullet and migrated my content to self-hosted WordPress within Google Cloud. I’ve been promising/threatening to document that process for years, and have finally gotten around to doing so.

Why blog – Self-documentation

In both professional and personal contexts, I’ve long advocated writing about things one cares about as part of the process of improving skills. When blogging about my profession, I started as a consumer of other people’s technical writing, searching out solutions to my problems in other people’s writing. The thing that pushed me towards doing my own writing was when no one had encountered the specifics of my situation, which forced me to synthesize a number of different articles and documentation to reach my solution. At first I wouldn’t document it, mistakenly thinking it was a one-off situation. Eventually, I’d find myself wasting time re-creating the solution. It took an embarrassing number of times before I finally started just writing and publishing the variations of solutions I needed. And it didn’t take long at all before I was Googling a problem and found my own article on how to solve it.

Why blog – Improve thinking

Writing has benefited me in a number of ways, not just documenting knowledge for my future self. Writing clarifies my thinking. Well, more accurately, it reveals to me when my thinking isn’t clear, and the process of getting the writing done forces me to concentrate on clarifying my thoughts. It organizes my thinking. Writing this article, for example, forced me to separate out the process of deploying WordPress for the first time from the process of migrating to it, migrating instead of upgrading, and using it as a podcast publishing platform. I thought of, and tabled other projects, such as using WordPress as a Knowledge Management CMS.

I don’t think I’ve ever gotten a job or even improved a performance review because of my technical blogging. However, I’ve found that the process of organizing my thoughts and documenting solutions for repeatability has helped me professionally.

Why Google Cloud?

I happened to choose Google Cloud when I first started migrating my sites. I want to disclose that I now work for Google Cloud as a Customer Engineer, but that employment change happened years after I made my blogging platform decision. The main reasons I chose Google Cloud, at the time, was a slight price advantage and the fact that I was already using most of the Google consumer products (Gmail, Maps, Photos, YouTube, etc).

How to deploy WordPress in Google Cloud

The overall process of deploying WordPress to Google Cloud has four overall steps:

  1. Get Google Cloud prepped for the WordPress deployment
  2. Deploy WordPress into a small Google Cloud Engine virtual machine
  3. Configure the path people will use to reach the site
  4. Start publishing

Get Started with Google Cloud

If you have a Gmail account, you already have the basis for getting started with Google’s Cloud services. Here’s the Getting Started landing page. If you haven’t tried it before from that Gmail account, you’ll get $300 in credits for the first 90 days that you’re using it. That’ll make your WordPress virtual machine essentially free during that time for most use cases.

  • Log in to the Google Cloud Console You’ll need a (free) Google account, which many people already have for Gmail. If you don’t have that, your first step will be to get it. You’ll get a click-through Terms of Service statement.

  • Create a Project for the WordPress instance. Use a meaningful name for your project, such as a the name of the blog. A project is just an administrative construct within which you’ll be deploying your cloud resources. Later on, you might want to report on or do budget alerts for the blog. And if you want to publish multiple different blogs, you generally want different projects so you can report on and control them separately. Don’t overthink the permissions discussed in the official documentation; If you’re running a business, you might need to have multiple people with access to the project and different levels of permissions, but as a single hobbyist, project level permissions in the official documentation don’t really matter.

  • Set up payment for your Google Cloud account, (most likely a credit card). Again, you’ll have $300 of free credits to use for the first 90 days, and after that we’ll be using the free tier of services, but you’ll need a payment method for any non-free services.

This discussion is focused on those who want the minimal infrastructure for a self-hosted instance of WordPress on a virtual machine (VM). This involves only two real parts of GCP; Google Cloud Engine is the virtual machine service and getting the underlying static IP address for the site, part of cloud networking.

Deploy a curated version of WordPress

  • For your first VM, deploy on an e2-micro in us-central1 to use in Google Cloud’s free tier. As of the time of this writing, the only machine qualifying for the free tier is a single e2-micro instance running in us-west1, us-central1, or us-east1. Any subsequent WordPress instances I create, I’ll use the N1→f1-micro for between $4-6/month.
  • I rely on the crew at Bitnami to create curated packages to deploy WordPress. More specifically, I use the WordPress with NGINX and SSL Certified by Bitnami and Automattic [Link to Google Cloud Marketplace]

Confirm you’re deploying into the correct project

In the Google Cloud Console, I make sure I’m within the Google Cloud Project I created for this WordPress installation, then navigate to the WordPress with NGINX and SSL Certified by Bitnami and Automattic within Google Cloud Marketplace. You’ll see a fairly prominent “Launch” button. This Launches a configuration page, not the actual instance, so click-through.

Launch the Bitnami WordPress Configurator

On the configuration page, there are several things to change. I make sure there’s some metadata in the name, and that I’m using the cheapest deployment available, a combination of deployment zone and machine type.

  1. Deployment name

I add a name for the instance incorporating the name of my blog and the date I’m deploying the instance: blogname-YYYY-MM-DD. That way, I know exactly when I deployed the VM and this instance of WordPress at a glance.

  1. Zone

For the free tier, you currently need to be in us-west1, us-central1, or us-east1. The latter two are the cheaper regions if you’re outside of the-free tier.

  1. Machine Type

The free tier currently covers a single e2-micro machine

Series – E2

Machine type – e2-micro

You can see the estimated monthly cost to the right of the configurations. These prices are as of June 2022. For your first VM in the free tier, use an e2-micro. Subsequently, I use Series N1, f1-micro for between $4-6/month. If you ever have performance issues, you can just use a migration process to re-deploy to a large instance.

Configure your WordPress VM

The process of creating the instance will proceed, and you’ll have an output which includes the current IP address of the instance and the initial, temporary username and password.

The output of launching the Bitnami WordPress Configurator

Instance configuration

There are a few things to tweak in the installation before we migrate our current blog content over to it. Apply any WordPress updates, install additional plugins, and make your ephemeral external IP address static. After that, point a domain name for the blog at the address, configure secure connections, and configure WordPress to use the domain name as the blog’s name rather than the IP address.

Change the Admin user and password

You can see from the last figure, that there was a user/password generated from the deployment. Add your own account and make it an admin. Choose a strong password that you won’t forget or that you store in a password service (I use LastPass or Google Password Manager in Chrome/Android).

After you’ve logged out and in successfully as the new admin user, remove the user created by the deployment process.

Apply WordPress Updates

  1. Go to the updates page on your WordPress Dashboard http://<instance-ip-address>/wp-admin/update-core.php Normally, you’d want to back up your WordPress instance before making major upgrades, but this instance is empty. If there’s any problems, just delete the VM and start over.
  2. Upgrade WordPress version if there’s one available (for example, I’m upgrading WordPress 5.9.3 to 6.0)
  3. Upgrade the plugins
  4. Upgrade the themes

Basic Plugins

There are a few plugins I like to use which aren’t part of Bitnami’s initial installation, so I install them at this time:

  • Broken Link Checker – Lets me see and correct broken links in my site
  • Image Source Control Lite – Makes sure I’m crediting all the images I use
  • ImageInject – Search and use free images

Chose a Basic Theme

At this point, I like the clean, classic look of the official WordPress “Twenty Fifteen” theme. I’ve never been one to spend much time customizing this kind of thing. There’s plenty of time to do that later. Any time you spend here is just delaying your writing.

Convert your VM’s dynamic/ephemeral IP address into one that’s statically assigned to your site

Your WordPress site was deployed on a VM with an external (internet-facing) IP address that Google Cloud calls “ephemeral.” That is, it might change, at any given reboot of the VM. What we want is a “static” IP address, one which is assigned to the VM as long as we want it to be.

Here’s a link to the official GCP documentation on promoting your ephemeral IP address static.

  1. Go to the External IP Addresses page at the Google Cloud Console.
  2. Make sure you’re in the correct Project for your WordPress instance
  3. On your VM’s current ephemeral IP address row (it should have the name of the VM in the “in use by” column), click “Reserve”
  4. Give a meaningful name for the newly static IP address. I generally use the VM name with “-static” at the end.

Make a DNS entry for your static IP address

If you’ve already registered for your site’s domain name, follow your registrar’s instructions on providing an “A” record for your site’s domain name that points at the static IP address that you just promoted.

Example using Google Domains

I happen to use Google Domains as my registry for convenience. I registered the for $12/year. Here’s instructions on how to buy a domain name using Google Domains. But use whatever domain registrar you’re comfortable with.

After I own the domain, I navigate to the DNS section.

DNS in Google Domains after you’ve registered the name

Then I created an “A” entry for both and all the secondary domain names with an entry for “*”, and an explicit secondary domain record in case someone uses

Create “A” Records mapping the name you registered to the IP address assigned the VM

It might take a few minutes for the new entry to propagate out to the world. You can check using a public DNS service like DNS Checker. This could theoretically take hours, but as long as you can locally resolve your domain name to the IP address, then you’re good to move on.

Configure WordPress to use Domains instead of IP Addresses

From the deployment process, WordPress has been hard-coded to use the machine’s IP address instead of a domain name. Now that we’ve reserved the IP address for the use of this machine and have registered the domain name and pointed it at the IP address, we can change WordPress to refer to itself through the links it shows by domain name instead of by IP address.

This is where we’ll need comfort with the Linux shell. You’ll need to launch an SSH connection to your VM (Google makes this easy from the console)

Here is the Bitnami documentation page for configuring the WordPress domain name. We’re deploying a self-contained image, so using Approach A to change the domain name.

    sudo vi /opt/bitnami/wordpress/wp-config.php

Within the file, replace:

    define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');
    define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/');


    define('WP_SITEURL', 'http://$DOMAIN/');
    define('WP_HOME', 'http://$DOMAIN/');

Where “DOMAIN” is your site’s actual domain name.

Optional, but Best Practice: Enable Secure Connections to the site with https

Modern web browsers try to connect to every site using an encrypted connection (https). This is something we can support on our blog using Secure Sockets Layer (SSL) and the free third party certificate authority, “Lets Encrypt.”

Generate And Install A Let’s Encrypt SSL Certificate

This is where we’ll need comfort with the Linux shell again. Since we’re using a Bitnami VM, we can use Bitnami’s instructions creating and registering an SSL certificate. I’ve directly linked to “Approach A: Using system packages.”, but you can check for yourself which approach you should use depending on the build of the VM. You’ll need to launch an SSH connection to your VM (Google makes this easy from the console:

To make sure which approach you should be using:

test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation."

Again, I’m using Approach A.

  1. Install the Lego client

    cd /tmp
    curl -Ls | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -
    tar xf lego*_linux_amd64.tar.gz
    sudo mkdir -p /opt/bitnami/letsencrypt
    sudo mv lego /opt/bitnami/letsencrypt/lego
  2. Generate A Let’s Encrypt Certificate For Your Domain This step depends on DNS entries correctly pointing to your blog’s IP address.

  • Turn off Bitnami services

    sudo /opt/bitnami/ stop
  • Request a certificate for all the domains that someone might get your site by. I’ve included both the primary domain and www in this code. Assign values for your domain and email address!

    sudo /opt/bitnami/letsencrypt/lego --tls --email="$EMAIL" --domains="$DOMAIN" --domains="www.$DOMAIN" --path="/opt/bitnami/letsencrypt" run
  1. Configure The Web Server To Use The Let’s Encrypt Certificate
  • Link the certificates to where the web server can access them. We’re using NGINX for this installation, Approach A, so follow those instructions.

    sudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.crt /opt/bitnami/nginx/conf/bitnami/certs/server.crt.old
    sudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.key /opt/bitnami/nginx/conf/bitnami/certs/server.key.old
    sudo mv /opt/bitnami/nginx/conf/bitnami/certs/server.csr /opt/bitnami/nginx/conf/bitnami/certs/server.csr.old
    sudo ln -sf /opt/bitnami/letsencrypt/certificates/$DOMAIN.key /opt/bitnami/nginx/conf/bitnami/certs/server.key
    sudo ln -sf /opt/bitnami/letsencrypt/certificates/$DOMAIN.crt /opt/bitnami/nginx/conf/bitnami/certs/server.crt
    sudo chown root:root /opt/bitnami/nginx/conf/bitnami/certs/server*
    sudo chmod 600 /opt/bitnami/nginx/conf/bitnami/certs/server*
  • Restart Bitnami services

    sudo /opt/bitnami/ start
  1. Test the configuration
  • Can you go to your blog using https in the URL?
  • Do you see the padlock by the domain name in the browser window, indicating that the connection is secure?

Assuming that everything went well, you now have secure https access to your site set up!

  1. Set up automatic renewals of the certificate

Create a script to automatically renew the certificate:

sudo mkdir -p /opt/bitnami/letsencrypt/scripts
sudo nano /opt/bitnami/letsencrypt/scripts/

The contents of the script should be:


sudo /opt/bitnami/ stop nginx
sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL" --domains="DOMAIN" --path="/opt/bitnami/letsencrypt" renew --days 90
sudo /opt/bitnami/ start nginx

Make sure you put your email address and domain name in for the placeholders!

Make it executable:

sudo chmod +x /opt/bitnami/letsencrypt/scripts/

Open the crontab editor:

sudo crontab -e

Add the following entry to periodically run the renewal:

0 0 1 * * /opt/bitnami/letsencrypt/scripts/ 2> /dev/null

Now renewals should be automated!

Get Publishing

  1. Write
  2. Edit
  3. Publish
  4. Repeat

In general, I do my writing outside of WordPress, using Google Docs. I write plain text using Markdown, and copy/paste the content into a [ordPress Markdown Block. Here’s instructions on Enabling Markdown blocks in WordPress . I add any images I might have captured to the post, then schedule publishing.

Set Up Backups

I use the UpdraftPlus WordPress Plugin for backups, namely because it can, with my authorization, place the backup files inside my Google Drive. And it does so for free. You might think that if I’m writing my posts in Google Docs, there’s no reason to backup. You’d be wrong. While it’s technically possible to re-create your posts, it’s incredibly painful, especially as you write more. Just set up backups to a personal Drive.

Optional but Best Practice: Set up Budget Alerts for the Project

I mentioned before that a Google Cloud Project is a really good abstraction to report on, especially to create cost warnings. For our purposes, we’re planning on running this WordPress blog in the free tier, so any spending over $5 (for example) would warrant a warning. So let’s set that up.

Here’s the subsection on Google Cloud’s official documentation on Budgets which deals with actually creating a budget (bypassing a lot of the enterprise/business concern about permissions and roles).

  1. Create the budget Go to Billing → Budgets on the Google Cloud console. There’s a “Create Budget” button along the top.
Create Budget button
  1. Set the scope of the budget
  • Name the budget something meaningful. I use the name of the blog and the budget. “vJourneyman $10”
  • We’re looking for an alert every month, so time range is “Monthly”
  • We want to alert only the project that houses WordPress, so select that project from the Project dropdown.
  • Then select “NEXT”
Budget Scope configuration
  1. Set the details on the Budget Amount
  • The default should be to “Specified Amount”.
  • We’re going to have a $10 budget and have an alert emailed when half of it is used.
  • Select “NEXT”
Budget Amount configuration
  1. Set the actions
  • The defaults should work here. We’re being alerted when 50%, 90%, and 100% of our budget is consumed.
  • The way we’re being alerted is emails sent to the billing admins and users.
  • Select “FINISH”
Budget Actions configuration

Congratulations, your budget setup is all done!


I hope this article has been helpful in getting you closer to launching your blog. Hopefully you’ll agree with me that WordPress in Google Cloud is both faster and cheaper! If you have any feedback, such as problems following a specific step, I’d love to hear it.

Most importantly, get writing sooner rather than later. If you have problems getting this setup up and running, don’t let that stop you from writing. Write in a Google Doc so you can copy/paste into your blog later. Get writing!

v2g: A Former VMware Solution Engineer Joins Google Cloud


In October 2019, I left my position as a VMware Solution Engineer and joined Google Cloud as a Customer Engineer. This post is a description of the process of onboarding and my early days at Google Cloud.


Google onboards employees in-person (before Covid-19) at one of a few rally points around the world. At the time, new employees were either flying to Mountain View or New York City. And that was going on almost every single week.
I was local enough to Mountain View to ride the famous Google Bus in. It was a bit of a hassle to figure out the closest stops to me and the schedule. The morning came and I calmly got on the bus. The wrong bus. It turns out there’s one that goes to Sunnyvale and one that goes to Mountain View. Fortunately, there’s a transfer that goes between the campuses, and I got where I needed to go with plenty of time to spare.

A few hundred of my closest friends and I were led through getting badges, laptops, and a hot breakfast before the main event started. I met people from all over the world headed to many different parts of Google (Legal! Treasury?!). Early process focused on most of the Human Resources functions you’d expect (benefits enrollment and the like). Then we got a serious dose of how Google’s culture differs from the outside world. We walked through a high-level structure of Alphabet and the component organization. Of course, just the various parts of Google were too much to hold in my head.

The third day was just the people who were joining Google Cloud. One of the first things I found out is that I’d been referring to the organization incorrectly. I thought it was called “GCP,” but the organization is Google Cloud and Google Cloud Platform is one of the products. Who knew? Even more cultural discussion followed; Surprisingly little time was spent on the actual products in the Google Cloud portfolio.

Early Rush

After Google and Google Cloud orientations, I visited the office I’d be working in for the first time on the Thursday of my first week. During my evaluation of Google Cloud, the work conditions were something I’d had to think about seriously. I hadn’t had a desk in an office for the previous 6 years, and I knew it would be an adjustment to come into the office most days. A colleague working in a different part of the company told me that the first year would be the most important, building relationships and replacing the web of connections I’d walked away from at my former employer. Perhaps after that I could calibrate how often I’d be in the office to the needs of my position.

Unfortunately, the San Francisco office didn’t have a Google Bus route from where I lived, so I experimented with a few different methods in the early days. At first, I tried the ferry from the Oakland/Alameda area. It was relaxing, but involved about 20 minutes of driving and 20 minutes of ferry time.

Early morning views of the Bay Bridge and Treasure Island

There was a benefit of beautiful views, but a downside of less flexibility in arriving and leaving. I eventually standardized on riding BART, the Bay-Area Rapid Transit light rail system. It’s crowded, but reasonably quick, cheap, and had a stop 5-10 minutes away. It also had trains every 15-20 minutes, so offered lots more flexibility.

Escalator out of order: Temporarily Stairs. We apologize for the convenience. – Mitch Hedberg

Learning the Portfolio

My manager gave me some clear training and certification objectives and told me to maximize the first few weeks of training, as I’d probably never have another block of my Google career where I’d wouldn’t have someone else trying to get some of my time (so far, he’s right!). As a younger technology portfolio, Google Cloud hadn’t seemed to be looking for people who had previous experience with the technology; Rather, the emphasis was on learning new things quickly. So, I spent the next block of weeks studying Google Cloud’s product portfolio, and getting my architecture certification. That process was eye-opening; The only exposure I’d had to Google Cloud was hosting this WordPress site on Google Compute Engine. Almost every solution in the portfolio sat at a higher level than infrastructure.

I had to learn a lot of things about a lot of product categories that I’d been glossing over in my career. Analytics suddenly became a key product instead of something that someone else was delivering to me. An Enterprise Data Warehouse is something that I’d had problems defining before coming to Google Cloud. At VMware, we’d been involved in the infrastructure that something like a Data Warehouse would run on top of, but not in the solution itself. Suddenly, I found myself needing to become way more knowledgeable in analytics solutions.

I was excited to dig into the app modernization portfolio as this was one of the areas that I thought could be directly relevant to customer lines-of-business. However, I soon realized that almost everything we were delivering fit that description. Most customers were intrigued by analytics, app modernization, AND how Artificial Intelligence and Machine Learning could help them.

My new team was great, with a bit different professional background than the colleagues I’d had at VMware. Again, as a newer organization, there just weren’t that many IT veterans with years of Google Cloud experience to pull from. They were and continue to be extremely supportive in my exploration of the Google Cloud organization and portfolio.

Google as a company is fairly famous for its perks, serving 3 meals a day at various cafes at the various campuses. On the other hand, I was on campus almost every day instead of working from home 90% of the time. That worked to my advantage, as I worked and socialized with my peers throughout the day, constantly (and probably annoyingly) picking their brains. It was still an adjustment to become a regular commuter.

It’s easier for my colleagues to tolerate my Noogler questions with the views from the roof


Coming into the 2020 calendar year, I was assigned some sales territories to cover, mostly residing in the Healthcare and Life Sciences. It was an industry vertical I hadn’t had much experience with other than a few medical equipment manufacturers. It was also a set of customers without much commitment to Google Cloud; Most of my career had been spent with customers with a large pre-existing relationship which I was trying to expand in either different lines of business or in different product lines.

The biggest challenges I’ve faced are learning about the new industry, customers, and product portfolio at the same time. On the other hand, it’s been very exciting to face the challenge. There’s no growth if one’s perfectly comfortable, right?! I’ve had the benefit of a lot of internal training about the industry, many veteran salespeople who have covered it before, and an organization supportive of exploration and growth. It’s an ongoing process, but one that’s been extremely rewarding. Hopefully I’ll share some of what I’ve learned in future blog posts!

v2g: Moving From VMware To Google Cloud


In October 2019, after almost four years as a VMware pre-sales technical engineer, I left and found a position as a Customer Engineer at Google Cloud. I left for mostly personal reasons, and still regard my team, management, and executive leadership in a very positive light. I just needed to make a change. Doing the same job at Google Cloud has been a big change. Though there have been ups and downs, the positives far outweigh the negatives. I’d like to deliver on my promises to blog more on what I’m learning, but no promises!


First things first, why did I leave VMware? It was a combination of personal reasons, including the passing of my father, that came crashing together with unfortunate timing. I decided I needed to make a professional change despite having great relationships with my manager, peers, sales rep, extended team, and even my skip (director).

Almost ten years earlier, I’d set my sites on an SE position at VMware as my dream position. I could potentially have found a home in that position for many more years, but decided the best thing for me was to leave. I knew I’d miss my colleagues and the customers I’d build relationships with. Regardless, I moved forward.

The Google Interview Process

The Google Cloud recruiting team was who called me back. To be honest, I’d had a big blind spot when it came to Google Cloud in the Enterprise. To their credit, they knew they weren’t the market leader. Every person I asked throughout the process had no illusions about Google Cloud’s market position, but felt that the company had some key differentiators. They felt that the product and engineering was so good that the path to success was only dependent on getting enough high quality sales and technical sales teams up to speed; They felt that covering key customers fast was going to be critical.

After passing an HR phone screen, the process was fairly intense with 4 hours of on-site interviews to get approved as “eligible to hire,” by a hiring committee. That was followed by a matching process, with the managers who had open spots reviewing the interview output and possibly doing an additional qualification interview. If the manager wanted me, then the recruiter negotiated on my behalf with a separate compensation committee for an offer. It’s a fascinating process which is apparently well known in the software engineering industry, where people routinely investigate working at Google; I’d never heard anything about it, though. I had to seriously weigh what seemed like big factors at the time: Working from a Google office when not meeting customers and using Google’s office and productivity tools instead of the ones I’d grown used to at VMware. Leaving VMware’s Single Sign-On solution felt especially difficult, but ultimately those were just tools. The big change would be commuting to an office most days.

About halfway through the process, I remembered that I knew people who worked at Google, though not necessarily where I was targeting. They confirmed that the days of brain-teasers were far in the past. There were a pretty structured series of three or four interviews detailed at the How We Hire page (if you care). Topics covered included General Cognitive Ability (“learn how you approach and solve problems. And there’s no one right answer—your ability to explain your thought process and how you use data to inform decisions is what’s most important”), Role-Related Knowledge (“how your individual strengths combine with your experience […] how you can grow into different roles—including ones that haven’t even been invented yet”), Leadership (“how you have used your communication and decision-making skills to mobilize others”), and Googleyness (“how you work individually and on a team, how you help others, how you navigate ambiguity, and how you push yourself to grow outside of your comfort zone”). It’s actually all there on the web site, and now that I’m on the inside, it all seems very clear. Looking back, though, it seemed a bit mysterious.

Well, I passed the on-site interviews and was qualified to be hired. A manager from the San Francisco office wanted to interview me for an open position. My wife and I had had a serious, on-going discussion about the lifestyle change involved in me working in an office, but the overall opportunity seemed too exciting to turn down. Soon, I found myself restlessly tossing and turning the night before my first day at Google.

I had the standard first-day-of-school nightmares, but managed to catch a ride (and a selfie) on the Google Bus the next morning.

Up Next, Onboarding and the Early Rush

One Year of Podcasting – The Nerd Journey Podcast

It’s been a year since Nick Korte and I published the 30-minute "Podcast Trailer" for the Nerd Journey podcast. It’s been a terrific year of hard work, interacting with fascinating people, and personal growth. I wanted to take a moment to reflect on the past year of podcasting in the hopes that it might benefit someone else who’s thinking about getting involved in the extended community of technologists. You can read Nick’s thoughts about this year in his Network Nerd blog post, "The Journey Continues … A Year Later" and listen to our first anniversary review podcast episode here. This inspired me to reflect on the origins of the podcast and talk a bit about the early days. Hopefully others can learn from some of what we did. I’d also like to reflect on the evolution of the podcast and myself. It’s been an interesting journey of introspection and self-discovery. Finally, I’d like to look forward to what I see for us on the horizon. I can’t say I’ve ever measured my guesses about the future, but maybe I can start with goals and progress to guesses as well.

Genesis of Nerd Journey

Nick and I

Nick and I have a friendship that spans years and at least two previous jobs for each of us. We first encountered each other on the Spiceworks Community. At the time, I was the sole member of a small/medium-sized business’s IT department, looking for guidance, opinions, and community from other Information Technology practitioners. Over time, I learned a lot, applied the knowledge, and began answering questions of others. I made a number of connections with members of that community who I really respected and helped push me to advance my career. Nick was one of the people whose opinions I grew to respect greatly. We actually met for the first time in-person at a Spiceworks conference and spent hours just chatting.

Personal Advancement and Offering a Hand

Eventually I left my jack-of-all-trades job and took a position at a technology distributor as a technical specialist focused on VMware’s place in the portfolio of resellers and integrators. It really opened my eyes to how the reseller channel works and the possible career paths that I hadn’t been directly exposed to before. After a few years, I left the distributor to work for VMware directly as a pre-sales systems engineer, helping customers to understand how the company’s portfolio of solutions would align with the problems they were facing. Throughout this process I kept leaning on the relationships I made at the Spiceworks Community and kept in touch. I tried to refer those I knew a bit better to positions near them. So many of those people helped me to progress to where I’d gotten, that I couldn’t help but think I owed the community some payback. Nick was someone who took me up on the offers of help; Just three years after I started at VMware, he excitedly told me that he’d accepted a systems engineering position at VMware as well. It was an amazing moment of a good person working hard, persevering, and triumphing.

We Should Podcast

Throughout the years we’d been talking about career, we’d spent a ton of time on the phone, strategizing about resume writing and interviewing. It struck me as he was about to start, that we should somehow document what he’d gone through somehow. I was also extremely interested in hearing about his observations about joining a large company like VMware after working in SMB IT. There was the shift in working in a pre-sales position instead of operations. Sometime after he accepted the position, but before he started, I suggest that we start a podcast to record some of this for others to benefit from. I thought we also had some opinions to offer about news and happenings in our industry as well.

A Very Little Relevant Experience

As some background on podcasting, I’d been an avid consumer for several years, including ones covering the IT industry, such as VMware’s Community Roundtable, the Geek Whisperers. A couple years into my job at VMware, I ran into Eric Nielsen, who hosts the Community Roundtable. After chatting a bit, he invited me to come in and co-host the podcast whenever I was available, lending my field technical viewpoint to the discussion. It was a bit of good fortune, and I’d been soaking in as much information about the production side as I could. When I told Eric that I’d had an idea for a solo project, he laughed and told me that I was following a well-worn path of people who got interested in starting after trying it out. He offered some great advice, but the thing that was immediately applicable was to "just get started" and not to invest too much in equipment until we knew we were serious about continuing.

Other Resources

As part of being part of the podcast, I’d started attending a few local meetups on podcasting, one in San Francisco and one in Oakland. I connected with a group of people interested in the field from the point-of-view of amateurs just putting their voices. Both groups were well connected, with the structure of bringing in long-time veteran podcasters on a variety of topics. I don’t want to over-simplify the process of getting started. I’d done a lot of studying about getting started in the production side, including an excellent behind-the-scenes episode of the Virtually Speaking podcast. As much as I wanted to pull out the credit card, we actually made minimal investments in equipment, keeping Eric Nielsen’s advice in mind. I realized it was a black-hole of gear I could get lost in. We made the tactical decision to focus on recording, figuring out our process, and gradually investing in the equipment over time if we felt we were going to stick with it. To this day, we still don’t sound as good as the Virtually Speaking crew do! grin We started recording the weekend before Nick’s start date and just dove in, learning about how to plan out episode topics and recording several episodes which we knew only had a vague chance of seeing the light of day. In fact, the first episode that we recorded that was actually published, was technically just a "release candidate."

Evolution of the Podcast

Nick and I recorded for several months, trying to find our voice. It was a great learning experience and we added structure over time to our process.

Not Launching

During the first six months, we recorded but didn’t publish; Most of that delay fell on my shoulders. Ultimately, it’s not that difficult to self-host an instance of WordPress and use the PowerPress Podcasting plugin by Blubrry to host a podcast. However, I tried to make it more complicated than it needed to be. I was interested in using the opportunity to learn how to containerize WordPress having had a previous experience with keeping the underlying PHP installation up-to-date. Ultimately, a discussion with Nick really brought me some clarity on this block. I was using Bitnami’s excellent library of pre-built WordPress images to deploy to the Google Cloud Platform (Bitnami has recently been purchased VMware, my employer). WordPress has some plugins to make exporting and importing a site fairly easy, so migrating the site to a new WordPress image would be simpler than upgrading the components in the image. And much simpler than bumbling through my attempts to learn to do things inside Docker Containers.

The Push to Launch

Nick and I were both attending VMware’s user conference, VMworld, in Las Vegas last autumn; Nick suggested that we launch before the show and have a few episodes released going in as a basis for networking for people possibly interested in our advice and points of view. I had to quickly get past my platform block to get the technology stack up and running. We recorded an "episode zero" as an introduction to ourselves and to get some conference-oriented advice out as our calling-card. Our wives both pitched in, Nick’s donating our logo, and mine arranging our music. The members of the podcast meetups were an interesting accountability point. It became more and more embarrassing to attend the meetup and face the question on when we would launch.

Constraints and Emergent Behavior

The next task was editing and publishing our catalog of recordings. We realized pretty quickly that we should focus on the career-aspects of our discussion ("the career advice we wish we’d been given earlier in our careers"). It was essentially "evergreen", while anything we put about industry news, product launches, or the like was ephemeral. That meant cutting out some of the segments we’d recorded. We were pretty honest (and at time brutal) about identifying segments where we had little to say or just seemed off of our core topic. We have a particular point of view, influenced by resources that we use, like the Career Tools podcast. The advice we were offering started out very tactical, (advice on resumes and interviewing but also discussed skills development, goal setting, and more strategic career management. We had fun with a segment examining article on career which popped up LinkedIn, decided whether they were career clickbait or not.


At VMworld, we had a chance to chat with people about their career journeys and challenges, offer advice, and get invested in the career trajectories of some new friends. We got overall positive feedback from listeners and lots of suggestions. I participated the SF Podcast Meetup’s "Hotseat" which involved having the membership listen to some sample episodes and give candid feedback. This was particularly helpful as they had quite a bit of constructive criticism from sound quality, branding, to looking for more contrasting points of view. It was a terrific experience and was a valuable lesson in soliciting detached feedback.


I’ll give Nick credit for pushing us forward (notice the pattern there?) on bringing people in to interview on Nerd Journey. It’s been a great addition, often resulting in more than one episode. We’ve met and talked to a number of fascinating people. I don’t think we’ve had a bad conversation yet, but a couple stick out, like Tom Delicati’s sniper approach to applying for jobs, Jimmy Tassin’s ability to parlay his experience running a Minecraft server into an IT career, or Jon Hildebrand’s recovery from being unexpectedly laid off. We also talked to other tech-industry podcasters like Ramzi Marjaba of We the Sales Engineers and Ethan Banks of the Packet Pushers network.

Looking to the Future

Lessons Learned

  • I’m glad we’re finding our voice and topic focus. If you’re starting to get involved in the technology community with a technical blog, having a number of different topics you post on is very acceptable; it’s fine to write on deploying infrastructure, trip reports on attending a User Group meeting, and a technical breakdowns on how to cook a brisket on the same site. In the podcast format, we found we needed more focus. We couldn’t be yet another infrastructure virtualization opinion and news podcast while offering career advice.
  • I’d definitely pass along the advice that I was given about just recording episodes and worrying about technology, platforms, and anything beyond basic process until you’re fully invested in podcasting. The podcast community consensus is there are some break points around 10-20 episodes published, and around 100. Those are the numbers where "pod-fade" can set in. It’s easier to quit than to continue, and sometimes one’s priorities change. It’s not worth investing tons of cash in equipment until you’re committed. Perhaps we could do a follow-up on budget recording gear…
  • We’ve been pretty good about the discipline of constantly working. Each episode requires preparation, recording, and post-production work. We’re constantly workshopping new ideas and working to prep and post-process our episodes.
  • I think one thing that’s been consistent has been a commitment to helping others in their career journeys. It’s really about mining our minds and those of the wider community for the greater good and knowledge of all.
  • Like anything complex, the more we examine the topic of career development, the more complexities are reveled. It been humbling to dive into these complexities and learn along with our audience.


I don’t think that I’ve been in a position to collaborate with someone on an external-to-work project for so long. It’s been a terrific partnership with each of us having strengths that complement the others. I’ve been more invested in the platform, the process, and some of the behind-the-scenes technical details. Nick’s really pushed us forward with schedule, structured brainstorming time, and follow-through on that brainstorming. I’m really fortunate to have a partner like him in this project.

Speculation and Goals

  • I’d like to return to VMworld and record some interviews on-site with people who might have a quick piece of career advice or story they’d like to share. If you’re going to be there, let me know, and we can set up some time to record. We’ve talked to at least one other group of podcasters about doing some quick-hit recording.
  • I’ll be at VMworld in San Francisco this year; It would be great to connect with other vCommunity and vExpert community members to chat, even informally and off-mic about career journeys.
  • It might be nice to take the show on the road and do something at a VMUG, similar to the Geek Whisperers at the SV VMUG.
  • If we can enough content together, perhaps we could pitch a session next year on career
  • Every once in a while we check out listenership stats and see them growing steadily. I’m not sure it’s good for us to set download counts and chase those with topics or content we think might get us there. I think Nick and I are on the same page about that
  • I think we should follow-through on our series on the decision to go into people-management. We’ve got some ideas and would welcome community suggestions when it comes to topics to cover.
  • If anything, I’d like to clarify what is working best for our audience and what we can do better. Some of that is topic diversity. But there might be other, technical changes we could be making to improve the listening experience. I’d like to find another opportunity to get some candid feedback from non-listeners.


The past year of podcasting has been a serious investment of time and attention. It’s been extremely gratifying to get some positive feedback from our peers in the community who have enjoyed the conversations we’ve published. I don’t see us stopping any time soon. Every discussion spawns a few other ideas to chase down. It’s been terrific to get some ideas from the listeners and follow-through with our thoughts. It’s been interesting to look back on how my attitudes towards the topic have evolved. I’m looking forward to whatever comes next!

VMworld Prep Part 1

I’m headed to Las Vegas for the show next week and am trying something new for my VMworld prep. I’ve got two a last-minute purchase, a goal, and an on-going action for my run-up to the show. By the way, if you’d like to meet up and chat, hit me up on twitter: @vJourneyman. I don’t know if you’re looking forward to anything specific at the show, but I was re-reading my post about VMware Validated Designs in 2016, and am looking forward to seeing what the Integrated Systems Business Unit announces for VVD and Cloud Foundation. 

Purchase: Conference Charging

Conferences tend to intensely use phones these days. You keep your registered session schedule in the app, map the conference in the app, network with other attendees in the app, etc. You might take pictures of slides, get on a phone call for your day job, text with other attendees, and so on. So, I recommend a USB battery pack which can provide two full charges for your phone. Why two? Because sometimes you forget to charge overnight… I’ve got a phone and tablet which both USB-C, so I’ve got that additional requirement.
Here’s The Wirecutter’s article on USB-C Power Banks.

In addition, I’d recommend a USB hub to recharge multiple electronic items overnight. I’m charging my phone, a tablet, Bluetooth earbuds, and the USB battery.
Here’s The Wirecutter’s article on USB-C PD (Power Delivery) chargers. I use USB-A to USB-C cables to charge my phone and battery pack while the USB-C PD port charges the tablet. And one port for USB Micro Bluetooth headset. That means I need a USB-C port and three USB-A ports as a worst-case scenario.

That being said, you can get batteries as giveaways on the show floor, but they’re generally lower capacity. Its right up against the latest time you can buy something from Amazon for home delivery before traveling. Staying juiced up is a critical part of my VMworld prep.

Goal: Get fully packed by Friday for my early morning Sunday flight

I need to break out of the pattern of staying up all night doing laundry and packing the night before the flight. Before the early, early morning flight. I did that in February and knocked out on the plane before it took off. I was out so hard that it took my seatmates more than a few minutes to wake me up to get past me for the bathroom. Not good.

Good VMworld prep for me involves not stressing about packing the night before the show. I’d prefer to spend that time with my family.

Action: Start waking up on my conference schedule

My goal is to get to the conference breakfast as the doors open, usually 7 am. That means getting out of the hotel room by 6:30 am. So I have to wake up by 5:30 am.

I think I mentioned this tactic in the Nerd Journey Trailer episode about conference success. As much as I value the late-night networking, I want to maximize my daylight time at the conference. I don’t quite have a job which focuses more on the after-hours networking than the in-conference attendance, and the cost of my pass came out of someone’s budget. 

So this part of my VMworld prep means I’m waking up pretty early. And getting a solid week of good sleep before the show means I’m going to bed early.

What are you doing for your VMworld Prep?

UX/Design Team at VMware is Hiring

I’ve been watching several internal programs, non-product demos, and ideas-stage discussions on design at VMware for the past few years. Just recently, I noticed that we’re in the middle of a big hiring push for the UX/Design team, so I thought I put up a couple resources for those interested in exploring that career path.

First, here’s my list of open UX/Design positions:

And just as a reminder I maintain more lists of open VMware positions by type and recruitment campaigns:

Next, here’s an interview with Jehad Affoneh and Anna Marie Panlilio of the UX/Design team back in June of 2018. The spoke about their philosophy of design, how they conduct end-user research into the design process, and some ideas on the future direction of VMware product design. Unfortunately, I wasn’t at the recording session, but fortunately, there’s a recording!

It was interesting to hear they’re doing NDA design sessions at VMworld. I checked and they’re almost all full. If you can sign the agreement and sign up, it would be interesting to see that information-gathering first-hand.

Also, here’s the design site they mentioned, and their design blog. If you’re interested in applying and are looking for some background on what they do and why, it’s worth a read.
VMware Design Blog on Medium

Oh and you might want to check out one of their public projects, the Clarity System.

Clarity on Github

Clarity Design System Training video (in a VMware Clarity YouTube Playlist):

VMware Wavefront Acquisition

Yesterday’s VMware Communities Roundtable podcast centered around the VMware Wavefront acquisition. Bill Roth (@BillRothVMware), Director, Product Marketing at VMware’s Cloud Management Business Unit, was in studio to talk about what Wavefront’s product is and the thinking behind the acquisition. We (maybe just me) went down an interesting speculative path of what might be done with the product. Eric was especially interested in

Continue reading VMware Wavefront Acquisition

Reactions to WannaCry Ransomware

Here are some quick thoughts on the WannaCry ransomware threat that emerged this past Friday [L.A. Times, Bloomberg, etc], as I get ready for the work week.

  • I wouldn’t want to be the person in the office of the CISO who wrote a security exception for Windows XP this week
  • The Shadow Brokers disclosure of this vulnerability isn’t what enabled this attack, it’s the lack of disclosure from everyone who knew about it but didn’t tell Microsoft.
  • It sure would be nice to have an easy way to see what computers are and aren’t patched against the vulnerabilities swiped from the NSA toolkit. Or to work for a software company that sold a solution that could give you that information (I don’t).
  • PAN discussed how the attack spreads after getting past a perimeter. I’d encourage anyone with a micro-segmentation solution to make sure that they’re mitigating the methods of attack spread.

Angel Villar Garea, a VMware Systems Engineer, has a video out on how to block the spread using NSX.

How about physical machines? While platforms like NSX provide increased security via hardware VTEPs, I don’t think we yet have a mature way to push down security controls to the physical switch that the desktop is plugged into. Or the WiFi router. Again, in my view, the strength of a platform like NSX is it’s ability to integrate with next generation physical firewalls from other vendors to extend security policies to the physical world.

WannaCry is only the latest ransomware to come along. It’s probably only the first to leverage to tools from the Shadow Brokers leak of stolen US Government zero-day attacks. What are you doing in your organization to block the next one?

Photo by bbearnes

VMware Career Saturday 2017 Week 19

This week in VMware job listings, I’ve changed formats slightly. I dropped market segment [EDIT: and seniority or role type] as that was taking a bunch of time to generate. I managed to automate things enough to post a refreshed version of every job category I’m monitoring: SE, Sales, Consulting, and TAM in the US/Canada and EMEA. Each of those has it’s own page with it’s weekly, refreshed, complete listing. In this post, I’m going to highlight the new jobs posted in each section. Those listings are in the single digits, so I’m not going to bother having them in a table with a sort/filter function. Continue reading VMware Career Saturday 2017 Week 19

VMware Career Saturday 2017 Week 18

UPDATE 2017-05-13: I’ve added individual pages (wherever my navigation currently has menu structure, currently on the left) with a weekly refreshed, complete listing of all listed positions for SEs, Sales, TAMs, and Consultants in both USA/Canada and EMEA. Those tables will have filters and sortability. My weekly posts will have new listings without the complexity of sorts and filters.

This is my weekly Saturday update of new open positions at VMware. I’m hoping this helps anyone looking to start a VMware Career! There were no new Field Sales and TAM positions posted in the US, and only a single SE and two Consulting positions posted. At readers requests, I added the listings for EMEA sales, EMEA SEs, EMEA consulting, and EMEA TAMs. I must not know anyone in Canada, LATAM, APAC, or ANZ. There’s some Bay area local positions I want to highlight and a note about what the open position on Advisory Services is all about. Continue reading VMware Career Saturday 2017 Week 18