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.
One area that I haven’t had good luck in organizing for content is on the software development side. There are currently 130 open software engineering jobs at VMware (in the US) which doesn’t seem like a large data set to organize, but the question is how. For the Network and Security Business Unit, previous experience with network stacks is a constant theme. However, some specialties don’t sort that way (UX design, for example). Sorting by languages and tools doesn’t seem like a good idea, though an anlysis of what’s being used by Business Unit might be a separate, interesting task. At any rate, if you’re looking for a software development position at VMware, head to the recruiting site and choose “Engineering and Technology-Software Engineering” from the department drop-down.
Regardless of the type of role you’re looking for, I’m happy to chat about my understanding of the job roles and team structures, eyeball a resume for format and impact, and chat about what it’s like to work at VMware. I’m including a contact form at the bottom if you’d like to get in touch with me. And of course, I’m on LinkedIn and Twitter.
My past 18 months at VMware have been a whirlwind of training, customer relationships, and new product announcements. I’m starting to see a pattern of questions, especially about where new VMware products fit into the portfolio. This is the first of series of posts about the VMware portfolio in 2017, all my humble view of things, of course. First up, VMware Cloud Foundation (VCF). In the future, I’ll take a look at VMware Cloud on AWS and vRealize Automation. Please let me know if you have a burning desire for my perspective on something else. *grin*
The continuing theme is “Technology I wish I’d paid more attention to before I came to VMware.” Of all those technologies at VMware, vRealize Log Insight might be the most overlooked by everyone. At the same time, it’s a great tool for the sneakers-on-the-ground IT personnel working hard to keep the lights on. At it’s core, Log Insight is a Continue reading vRealize Log Insight at VMworld 2016
I’ve had a significant proportion of my clients (maybe a third?) ask for my advice and guidance on VMware Oracle licensing. They seem to be scared (either through first or second-hand experience) of a bill from Oracle for their entire virtualization infrastructure because the potential exists for vMotion-ing Oracle server workloads from machine to machine and now across vCenters (since that’s a feature now in vSphere 6!). As a result, I have clients not even connecting their virtualized Oracle hosts to vCenter at all. But what’s myth and what’s fact when it comes to Oracle licensing on VMware?
One of the things I’ve been meaning to write about more is the cool technology that I didn’t realize existed inside the VMware portfolio. One of the main themes that’s emerged with my clients is having a true private cloud infrastructure. If this is on your mind, I’d encourage you to go check out the sessions on VMware Validated Design (VVD) at VMworld 2016.
Today I began learning Python and ended the day with a script that successfully automated a process for me. Nope, I’ve never written Python code before and don’t code for my day job. In fact, it’s been over 20 years since I first took an introductory computer science class. The most significant project I worked to completion was less than 500 lines of perl, an Electronic Data Interchange (EDI) translator for the odd purchase order format that our customer used. But I’ve laid out two goals for myself, work myself up to light scripting competence in Python and light analysis competence in R. OK, those two goals are over 10 years old, so what got me moving?
Well, it’s happened again. I wasn’t looking to make a job change, but an opportunity I couldn’t turn down found me. In November 2015, I joined VMware’s San Francisco Bay Area Enterprise Systems Engineering team.
My previous role had me educating solution providers on the VMware software portfolio as well as teaching partner Systems Engineers about pre-sales systems engineering for their customers. I now find myself working for VMware directly as a Systems Engineer, assigned to cover a group of Enterprise level named accounts. My fiancée and I moved from Southern California to the Bay Area for me to take this job. An upheaval (and a risk!), but also an amazing opportunity to work directly for one of the most innovative and disruptive software companies around.
What does that mean for my writing? Well, I pretty much fell on my face when it came to maintaining a regular cadence during my time in the distribution channel. I’m going to try my best to do better now. There’s certainly a different emphasis within the portfolio for enterprise customers. Hopefully I can provide insight into the solutions engineering process from the inside.
Some things you probably won’t see from me:
Product speculation; Even with limited insider knowledge, this seems inappropriate.
Customer information; Maybe it goes without saying, but I’ll have to generalize my lessons learned.
Things I’ll try to add to the topic list:
Career advice that I’m finding helpful
Industry news that I’m finding relevant and impactful
Products I’m discovering within the portfolio
So thanks to anyone who’s found my writing useful so far. If there’s anything you’d like to see my thoughts on, please ask away!
This is part three in a series of posts discussing lessons I learned from helping a partner engineer a 400+ TB VSAN Solution. It turns out that high capacity VSAN nodes are a slightly different beast than the standard off-the-shelf solution. Part one discussed different density issues as related to disk configurations. Part two worked through a hypothetical 1TB/day, 365 day retention engineering solution. In part three, I’ll be continuing with that example and exploring possible models for purchasing and growing such a solution.
This is part 2 of a series of lessons learned and examples worked based on a 400+ TB VSAN solution I helped a partner engineer. I’m comparing high capacity VSAN nodes with standard configurations. This post will focus on calculating the IOPS required to de-stage writes from the caching layer, then examining the implications on hardware choices.
I was recently asked for some help engineering high capacity VSAN nodes for a large storage solution which brought up some issues I thought would be interesting to share. By high capacity, I mean the customer was looking for 400TB with the ability to grow to a petabyte. I found that the standard building blocks didn’t make economic sense for the customer’s ratio of workloads to storage. As a result, we examined the available platforms for greater capacities per node.
The first thing I’d like to examine are the various density trade-offs that can be made in choosing a configuration.