Tag Archives: IT Career

A new Adventure!

I’ve joined the Product Management team as a PM. Being a member of a small team (Sunny and a few others), we are given the privilege to plan and drive vR Ops to the next level.

Why did I change job?

As a human being, there are 3 levels of what we do: Job, Career and Calling. Out of 7 billions people, most of us have a job. Those luckier have a career. A few have a calling. IMHO, a calling is when you have a balance among the 3M (Money, Meaning, Merry) of what you do. A calling is not perfect, as it’s a trade off the 3 corner of a triangle. Ideally, the triangle is as small as possible, so you’re close to all 3. To read more, follow this.

Some folks asked how I could get a Product Manager job out of Singapore, since there is no R&D, QA, UX, Tech Marketing, Product Marketing, and Management here.

If you want to know, here is a short story.

This job took me >5 years to vrealize. I’ve been doing vR Ops since 1.0, when it was released back in early 2011. I was one of the first to get trained in Asia Pacific. I remember when David Lavigna trained us in Sydney. I saw how I could apply super metric and custom dashboards to help customers monitor and troubleshoot. Instead of spending a lot of time with vCenter performance tabs, I could simply slice and dice the whole environment.

By 2014, I’d already spent a few years on the product. Customers taught me things they need to monitor or troubleshoot. It’s amazing how much you can learn in production environment vs lab. Real problems, real people. I compiled these lessons learned, gave it a structure, and published my first book on Dec 2014.

In 2014, VMware elected me as a member of the CTO Ambassador program. In my 1+ decade in VMware, this is the best “training” program. It opens door. It gave me trips to Palo Alto and RADIO, where I could develop the relationship with R&D.

Sunny and I brought the material to the world at VMworld 2015. We did 2 sessions, ~600 audience. The feedback told me we’re on the right path. That was the turning point to start packaging the dashboards into an integrated suite.

I continued enhancing the material, and published a second edition of my book in March 2016. Product Management team, who had been super supportive of my work, invited me to Palo Alto, VMware HQ in Silicon Valley. They paid for my first Take 2, and I spent 2 weeks in with R&D team in March 2016.

Kenon took the material and turned it into a program in June 2016. He called it Operationalize Your World. He worked with all the regions in Asia Pacific. Both of us traveled heavily and met many customers and partners. He secured the travel funding and worked with local team to get the event going. I am averaging 150 – 200 days a year since then.

VMworld 2016 was another success. I met even more customers, who convinced me that there is a big market for me to focus on. Post VMworld, Product Management team decided to bring on board part of Operationalize Your World. vRealize Operations 6.4 was the first release where we replaced bulk of existing dashboards. It was released in Nov 2016, and the feedback was very positive. Since then I had been privilege to get involved with the release, giving feedback as basically Customer[0].

By this time, Sunny had moved to Palo Alto. That changed a lot of things for me, and I benefited from that close partnership. In life, Sunny gave me an experience that 1+1=3. Each of us will have a solution, and after some fight, we end up with a 3rd and better solution.

In June 2017, I was given the chance to spend 2 weeks R&D. It gave the chance to meet more developers. Their eagerness to make the products better, and most importantly how they treated me like a member of the family, convinced me that this is where I wanted to focus. Since then, I’ve been back 2 more times, for a total of 4 weeks. All were kindly paid by CMBU. Yes, they really treated me like a member of the team.

In VMworld 2017, Product Marketing got me to speak in both US and Europe events. That was my first time meeting EMEA customers. Glad to know Operationalize Your World was resonating. In fact, it resonated better than US.

I got a chance to participate in 6.5, 6.6 and 6.7 releases. My main focus was on the ability to customise. If you compare 6.7 vs 6.4, you notice it’s easier to work with the widgets. They have better control, and look more pleasing too. You also have a lot less metrics, hence it’s easier to know what to pick. We also added a lot of property.

In March 2018, R&D invited me to do a Take 3. It is a 3 month secondment where I was part of the Product Management team. Upon completion of the Take 3, they helped to work with my CS management to transfer me. I’m grateful for my management, who gave their blessings and did the transfer with my interest at heart.

Throughout all these years, customers and partners feedback are clear: vR Ops and Log Insight are useful to them, and they want to use vRealize even more. At the end of the day, it is this assurance from them that made jump into the PM role. I’m blessed to have met probably a thousand customers since 1.0 in 2011. Collectively, they educate me, using their production environment as real examples. Their feedback shape my thought, and give me clear guidance on where we should take the products.

VCDX, meet VCOX

Thanks for the positive feedback on the articles The Rise and Fall of Infrastructure Architect and Purpose-driven Architecture. Do read them first as this post builds from there.

I see Architecture and Operations as 2 equally large realms. While we certainly consider Operations when designing, it is not a part of Architecture. They complete each other, like Yin and Yang. They impact each other, like night and day. While I subscribe to the school of thought that the same person can be good in both Architecture and Operations, I’m yet to meet such person. I’m not a VCDX, so I will focus on what VCOX. Inspired by VCDX, I created this term to acknowledge the size of this world. To be 100% clear, VCOX is just a term I created. It has nothing to do with VCDX.

Architecture is Day 1, Operations is Day 2. Day 2 impacts Day 0, which is Planning. Why?

Because we begin with the end in mind. The End State drives your Plan. Your Plan drives your Architecture. So it’s 2 –> 0 –> 1, not 0, 1, 2.

I’ll use an example to illustrate how Day 2 impact Day 1. Say you an internal cloud provider, and you plan to charge per VM (e.g. $1 per vCPU per month). You plan to have 2 classes of offerings:

  • Gold: suitable for production workload. Performance optimized.
  • Silver: suitable for non production. Cost optimized

For Gold, you don’t overcommit CPU and RAM. Now…., if 1 CPU typically uses 4 GB RAM, then a 40-core ESXi will only need 160 GB. If you buy a 1 TB RAM, then you won’t be able to sell 864 GB as you have no vCPU to sell. This means your hardware spec is impacted.

You also promise the concept of Availability Zone. In the even of cluster failure, you cap the number of VMs affected. If you cap say 200 production VMs, then your cluster size cannot be too big.

In your service offering, you include the ability for customer to check her own VM health, and how her VM is served by the underlying platform. This means your architecture needs to know how to associate tenants with their VMs.

Your CIO wants a live information projected for his peers to see on how IT is serving the business. This requires you to think of the KPI. How do you know NSX is performing fast enough for its consumers?

I hope the above provide examples that Day 2 is where you want to start.

Operations cover the following pillars of management (planning, monitoring, troubleshooting):

  • Budget: Costing, Pricing and the business of IT
  • Capacity: it’s highly related to cost. Insufficient budget à Overcommit à Capacity Management.
  • Performance: focus on proactive and early warning. Performance SLA
  • Availability
  • Configuration: drift management
  • Compliance: security compliance, internal audit compliance
  • Inventory: license, hardware
  • Management Reporting

Notice a big pillar is missing above?

Yes, I did not cover Automation. IMHO, that’s part of Architecture. You should not automate what you cannot operate. So I see automation as not part of operations. Automation is a feature of your Architecture. It’s like automatic car. That’s a feature of the car. How you operate the car so passengers arrive at the destination on time, that’s operation.

VCOX answers questions such as:

  • Prove that the IaaS is cheaper than comparable IaaS. If it’s VMware SDDC, then prove that it’s cheaper than VMware on AWS. If it’s not, then the business case is weakened from CFO viewpoint.
  • Prove that Actual meets Plan. The architecture is built for a purpose. Quantify that purpose, and prove that it’s met.
  • The architecture carries a set of KPI. This enables its performance to be monitored. What are these KPIs. For each metric, what are the thresholds?
  • Is Operations performing? A poor sign of operations are lots of alerts, fire-fighting, blamestorming, hectic and intense day. The team is under stress as they struggle to operate the architecture.

From my interactions with customers, I notice that the Architect is not leading Day 0. They provide input to the Planning stage, but not the lead architect driving it. The Architect tends to focus on technical, something that CFO and CIO value less (hence they spend less time on it).

That’s my observation from travelling 200 days a year meeting customers, partners and internal. I hope it’s useful to you. Let me know what you think, as we are in early days of VCOX.

The Rise and Fall of Infrastructure Architect

I’ve been with IT for almost 2.5 decades. We are fortunate as we experience a once in a life time journey in technology changes. Technology has changed both work and life. Business now runs on IT, and what we know as banks, airlines, telcos, practically depend on IT. Within IT, applications run on infrastructure. This infrastructure has improved drastically that it has become a commodity. With the arrival of the cloud computing, it has become utility too. When something has come down to both a commodity and utility, the human who knows it follow as a consequence. The value of Infrastructure Architect has diminished, as the technology has become good enough, simple enough, and cheap enough for most cases. Granted, mega infrastructure such as AWS and VMware on AWS are complex. But how many of us are working there?

Most of us aren’t doing this mega infrastructure. Most businesses have <10K VMs. At 25:1 consolidation ratio, that’s <400 ESXi. At around 12 ESXi per cluster, that’s just 36 clusters, including HA. Space wise, it will occupy just ~10 racks. 1000 VM per rack for all compute + storage + network are doable.

Compared with say 10 years ago, it’s much easier to architect and operate a VMware environment with just 10K VMs. It’s easier because there are many references architecture, such as VMware Validated Design and VMware Cloud Foundation. For those using VMware on AWS, the design, implementation, upgrade and support are done by VMware.

So what can you do as Infrastructure Architect to progress your career?

If you are not moving into managerial or sales position, you need to add skills that are valued by CIO or Business. That means non-technical, as these folks care less about technical matters. The following diagram shows the career progression:

Since Infrastructure is becoming a service, you need to know how to architect a service (e.g. IaaS, DBaaS, Desktop as a Service).

  • What are the services the IaaS is providing? How you define a service?
  • What metrics do you use to quantify its quality?
  • How many services? How do you distinguish between higher class service and normal one?

You also need to know what type of services are on demand. Yes, this require you to go out and meet your customers. Understand their requirements. What Price/Performance are on demand? From there, you can architect a corresponding services.

I cover this in more details in Purpose-driven Architecture, so I won’t repeat it.

Done reading it? Great!

The next step after Service Architect is Business Architect. This is especially valuable to CIO, who runs the business of IT. It’s also important to Cloud SP, whose business is actually selling the service.

For a start, know the business you are in. Below are the 2 main models. Be clear on the nuance, as Internal IT is morphing towards internal Cloud Provider.

As a Business Architect, you not just know the cost of running the service, but you also know how & when to break even. You do not have to responsible for P&L, as you’re not the CIO or Cloud SP CEO, but you play a strategic role to them. You’re not merely a techie. You know what to price, how to price and your price is competitive.

The world of Cost and Price is a complex one. vRealize comes with a tool to help you manage this part.

Summary

  • Systems Architect needs to evolve, as infrastructure is becoming commodity and utility.
  • Service Architect and Business Architect are the next steps for Infrastructure Architect.

The next post, VCDX meets VCOX, discusses this further.