It’s no secret that technology candidates with Kubernetes skills are in high demand. Large companies are transforming how they build and deploy production services with Kubernetes, and they need skilled Architects to help them with this transformation. Skilled Architects like Hart Hoover who, by way of acquisition of Heptio earlier this year, is now a Senior Kubernetes Architect with VMware.
While no two days or weeks are exactly alike, read on to get a glimpse of what a typical week is like for VMware Kubernetes Architects like Hart Hoover as he works onsite with a customer.
Monday: Wake up
The alarm on your phone goes off. You rub the sleep out of your eyes, snooze the alarm and start checking your networks: Email, Slack, and Twitter. The Cloud Native Computing Foundation (CNCF) ecosystem moves quickly and you’re looking for updates: Is a technology you’ve been following ready for production? What’s the latest on a pull request you submitted upstream? While you’re onsite, some other members of the Kubernetes Architecture team are also onsite at other customers all over the world. The team is making a huge impact on how customers leverage these technologies. You follow up with a London-based Architect over breakfast as they close out their day with questions, answers, and discussion on customer solutions. Last thing before you head out: review the customer’s statement of work and think about what to tackle first. You put your phone down, enjoy your last cup of coffee, and head to the customer’s office.
You check in at the front desk and get your guest security badge. You send a message to the customer via email or text to let them know you’ve arrived and get the tour. Where is the coffee? Where are the bathrooms? Where are we working? You get put into the conference room with six platform IT engineers and get to work. Over the next few days you’ll work with the customer to find out what problems they are trying to solve, where they are in their Kubernetes and container journey, and how you can help.
Every customer you engage with is committed to adopting open source Kubernetes. This is when you find out how far along they are in deployment and what kind of move the company is making. Is this an incremental move from cloud instances to containers, or a part of a gigantic digital transformation project? You’re going to get asked about optimized instance types for Kubernetes, CI/CD tools, logging and security. What’s more: you’ve seen this all before. You’re making real recommendations that are going to make this company successful. You’re documenting everything discussed to hand back to the customer at the end of the engagement for reference and sending a copy to VMware’s Customer Reliability Engineering team. After debugging a few things, VMware Sonobuoy is run on the cluster and it’s all passing. What a day! You check in with your networks throughout the day: email, Slack, and Twitter. You have another coffee (or two).
You get back to the customer’s conference room after lunch and the team lead throws you a curve ball: they saw a demo from a thought leader at a conference and want to put that piece of technology into production. You think you remember seeing that project on the CNCF Landscape… somewhere. Time to dig in and learn something new. You break off with a few engineers from the customer side to see if it’s even feasible (much less recommended). You’re looking at code, documentation, GitHub issues and blog posts, and interacting with other Field Engineers, Kubernetes Architects, and Customer Reliability Engineers to get their perspectives. A product manager saw that same demo, but also remembers that it wasn’t deployed in a highly available configuration. You test and confirm: it CAN’T be deployed with HA, but there’s already an open issue where you can contribute a solution. You present your findings to the team lead and they decide to move forward after the change has been implemented.
After walking through the deployment steps and potential gotchas with the overall team, you note your concerns in the project documentation and file an internal issue with the local team to watch the project. If enough customers are interested in the open source project, it might make sense for VMware to try to get more involved. In any case, your pull request is open.
Thursday: Wrapping up
You have a final meeting with the customer team and summarize the recommendations you made that morning, what was accomplished, and what the plan is for the following day. Once again you check in with Slack to see how your teammates are doing and give your own updates. You add to the project documentation and then head for the airport, where you’ve planned to catch dinner with a friend in the community who’s also on the road. As you board the plane, you get an email that your pull request was accepted to the upstream project. It’ll be in the next release. You make a mental note to touch on that with the customer first thing Monday morning, and finally zone out with some Netflix offline. What a week!
Do you like the sound of this role? Could you see yourself onsite with our customers transforming their enterprise infrastructure? VMware is looking for great Field Engineers just like Hart. Take a look at our open Field Engineer – Cloud Native Applications roles and apply today!