Nutanix NPX Architecture Guide How-To (Part 2)

This post is part 2 of 2, of my NPX Architecture Guide how-to series. In this post we will cover sections 9 through 14, from the outline below. You can check out the first part of this series here. At the end I will also give you some more tips on various standard tables that I used throughout the document. 

The major sections in the architecture guide are:

  1. Overview
  2. Current State and Operational Assessment
  3. Design Overview
  4. Nutanix Capacity and Sizing
  5. Nutanix Cluster Design
  6. Host Design
  7. Network Design
  8. Storage Design
  9. Security and Compliance
  10. Management Components
  11. Virtual Machine Design
  12. Data Protection and Recoverability
  13. Datacenter Infrastructure
  14. Third-Party Integration

9.0 Security and Compliance

NPX architectuire guide security and compliance

Security is often a weak point for many architects, so be sure to not skimp on this section. If it's light on details, be prepared for defense questions. Topics to cover here include, but are not limited to: RBAC design (Prism/hypervisor/applications); SSL certificates (Prism/NGT/Hypervisor); system hardening (STIG, PCI/DSS, etc.); network security (microsegmentation, VLANs, ACLs, etc.); patching/compliance reporting; use of SSH and hardening (e.g. SSH keys); syslog configuration (TCP/UDP); PulseHD; use of two factor authentication; Nutanix password complexity settings. 

And depending on your technical and business requirements, there very well could be additional security areas you need to cover. Have you read the Nutanix security guide? Make sure every "i" is dotted and every "t" crossed. 

10.0 Management Components

NPX architecture management components

The control plane for your solution is very important. Don't make management overly complex, as one of the beauties of a Nutanix solution is simplicity. Things to consider here include: Prism configuration; Nutanix patches and AOS upgrades; how to monitor Nutanix, what about OS patches?; Hypervisor patching; what tools are you using to monitor the network?; What about monitoring the hypervisor?; You of course have VMs, so what tools are monitoring them?  

In the management arena don't forget about advanced automation tools such as Puppet, Chef, PowerShell, and Nutanix Calm. What are you using for Syslog? Splunk? Are you using Prism Central or Prism Pro? If so, why, or if not, why not? 

11.0 Virtual Machine Design

NPX Architecture Virtual Machine Design

As called out in the NPX blueprint, you must include your virtual machine design. What is that? Well it should cover topics such as VM templates, VM virtual hardware, are you making use of SCSI unmap or not? And what are the implications of using or not using unmap? What's the difference between Linux/Windows unmap? How about VM affinity or anti-affinity rules? What is the lifecycle of your VMs (cradle to grave)? Do you have monster VMs? What is your NUMA boundary and do any VMs cross it? What are the implications of NUMA? 

12.0 Data Protection and Recoverability

NPX architecture data protection and recoverability

What good is your solution if it's not protecting your business critical data, and ensure that you can recover from a disaster? Here think about covering: Backup software (Netbackup, Veeam, HYCU, etc.); Nutanix data protection (Protection domains, replication, snapshot frequency, sync/async replication, etc.); network configuration protection (e.g. nightly switch config backups); storage protection; hypervisor control plane backups; how to protect critical infrastructure services like AD/DNS; what is your VM backup frequency?; What are your operational procedures for areas such as change control, patch management, and business continuity? 

13.0 Datacenter Infrastructure

NPX architecture datacenter infrastructure

To many people the datacenter infrastructure can be a scary topic, and lightly covered in the architecture guide. But it's critical. What if you miscalulate (or don't calculate at all) the heat load for your proposed solution and it melts down in the rack or causes a fire? What does your rack elevation look like? Did you allow space in the rack for logically placing new nodes? What is the datacenter rating for the maximum heat load of an individual rack? What types of PDUs are you using and how many? Did you adjust your estimated amps usage for the powerfactor? Are you running your PDUs at more than 80%, sustained during a failure situation? What is your datacenter facility rated for in terms of downtime a year? And is that downtime planned or unplanned? How many more nodes can you add to the rack before you exceed the rated limits (cooling, power, or weight)? Is your solution going to fall through the floor because you didn't validate your assumption about maximum load rating (did you even ask?)? 

14.0 Third-Party Integration

NPX architecture third-party integration

Another scoring area for the NPX is your ability to cover third-party integrations. What does that mean? For the NPX, that's any non-Nutanix product which you include in your solution. I recommend a separate section, even if you have touched on these solutions throughout your guide. Why? Makes finding it easier, and your panelists will like that. The areas you will cover here a highly solution dependent, so you may have fewer, more, and likely different products to cover than I did. For my solution it used Splunk, NetBackup, VMware vSphere, and also VDI. 

Sample Design Decision Table

NPX architecture design decision table

Throughout your architecture guide you absolutely must thoroughly document your major design decisions. How many design decisions you will have totally depends on your solution, and how thorough you want to be. In my case I had 60 design decisions, and each one was captured using the template above. The I placed full design decision table in the appropriate major section of the guide (e.g. networking, security, etc.). At the front of my architecture guide I had another table, consisting of one line per design decision, for easy reference. 

Now this design decision table is not "perfect" and in fact I would argue needs supplementation. I could, and should, have done it better. But first let's start with what's in the able, and what I left out which I think you should have in it. First, you need to label and capture a one sentence description of the decision. For example, are you using the VMware standard switch or distributed switch? Next, every single decision has an impact. What is that impact? Describe it. Nearly every decision has a risk....what is it? And every risk needs a mitigation, so what is that? 

Now, what do I think you should include that I didn't? "Alternative design decisions". Why do I think you need alternative design decisions for nearly EVERY decision? Because you will likely be asked about it during your defense. For example, let's say Design Decision 40 was to use LACP. Ok that's fine and dandy, but what are the alternative(s) to using LACP and why didn't you use them? Or, what if you chose the NX-3060-G6 node for your baseline node type. What would be an alternative node type that could also work? These are EXACTLY the types of questions you need to be prepared for during your live defense. But thinking about them before AND documenting them in your guide, you are that much closer to successfully defending your NPX design. 

So yes, IMHO, I think every single design decision you have should be documented with: Impact, risks, risk mitigation and alternatives. 

Sample Assumptions Table

NPX architecture assumptions

You might be thinking, what's so special about an assumption table? Don't you just capture all of your assumptions and call it a day? NOPE! Epic fail! For each assumption you need to validate, if at all possible, your assumption. Document how you will validate it. 

Sample Summary Table

NPX architecture design summary table

Now this table I think is optional, but I included it for both my VCDX and NPX designs. At the end of each major tech section (e.g. 4.0 - 14.0) I have a section called "Summary and Design Decisions". The summary is the table above, which captures and quickly displays all of the referenced requirements, constraints, assumptions, risks, and design qualities covered in that major section. I think of the table as a 'double checking' that I've covered all of the requirements, constraints, assumptions and risks applicable to that major section. Is this table required? Nope. Do I like it? Yup. Should you use it? Totally up to you.

Additional Architecture Guide Tips

One of the hallmarks for a "X" level (VCDX/NPX) level architecture guide is traceability. What is that? It means for every labeled item (requirements, constraints, assumptions, risks, design decisions) it needs to be called out at least ONCE in the main body of your document. NPX examiners DO use the search functionality quite often to see, for example, if risk RS05 is actually addressed in your document. As you write your guide, and as a final QA, take an afternoon and search for every single labeled item and MAKE DARN SURE it's referenced in the body of your guide. 

Another tip that I find exceptionally helpful for starting a new architecture guide is this: First construct the outline of all the areas in the NPX (or VCDX) blueprint as major sections (e.g. network design, storage design, security and compliance, etc.). The under each major heading, just like I have, construct your sub-headings of conceptual, logical and physical. Then at the end of each major section have a design justification summary, and then your summary table and design decision tables. After you do all of this 'pre' work, you will have a nicely outlined guide that you can now start filling in the details. Easy, right? 

Applicable to VCDX?

So you may be thinking, well thanks for all of the tips for a successful NPX architecture guide, but does this apply to the VMware VCDX certification or other enterprise architect certs? And the answer is ABSOLUTELY! In fact, I used the *exact* same format for my VCDX certification and it was accepted and successfully defended on my first attempt. If it's good enough for NPX/VCDX, it is good enough for customer facing docs? The answer here is also a resounding yes. 

The tips I've provided here are for an enterprise level architecture guide, and "X" level certifications like VCDX and NPX are very similar in the skillset they attempt to asses. So can you take your NPX architecture guide, if based on vSphere, and submit it for VCDX? With only minor modifications to ensure you cover VCDX blueprint areas, the answer is yes! I did the reverse....started out with a VCDX-level design, added Nutanix blueprint areas, and submitted it for the NPX. 


As you can see through these two long blog posts, a "X" (expert) level architecture guide can be a monster. It covers a lot of areas, needs full traceability, must be concise and easy to read, organized so that the examiners can easily score it, and also be technically accurate. It also needs enough depth to be considered "X" (expert) level. Although I will emphasize that there's no minimum page count, I would find it very hard to believe that something as short as, for example, 30 pages for an enterprise architecture guide would pass muster. 

If you follow my advice in these two posts, it should get you well on your way to having a well organized, detailed, and easy to read/score architecture guide for your NPX (or VCDX) defense. 


Nutanix NPX Architecture Guide How-To (Part 1)

A couple of months ago I successfully defended my Nutanix Platform Expert (NPX) certification and became number 14 in the world to obtain the certification. You can read all about that journey here. As part of the NPX certification process you submit a documentation package which should cover all of the areas in the NPX blueprint. This package will consist of multiple documents, but it's entirely up to the author on how to organize and present the content called out in the blueprint. This post is part 1 of a 2 part series, covering how my NPX architecture guide was organized. 

There is no "NPX" document template or "magical" format that will guarantee acceptance of your work, and enable you to do the in-person live defense. So please don't just copy this outline as-is, throw in a few sentences under each topic, and think you are good to go. Just use these two posts as inspiration for your NPX submission, and help ensure you cover all blueprint areas. 

Straight from the NPX Design Review blueprint your documentation package must include the following content, or the submission will be rejected:

  • A current state and operational readiness assessment
  • A web-scale migration and transition plan
  • Documentation of specific business requirements driving the solution design
  • Documentation of assumptions that impacted the solution design
  • Documentation of the design constraints that impacted the design and delivery of the solution
  • Documentation describing risks identified in the design and delivery of the solution and how those risks were remediated
  • A solution architecture including conceptual/logical and physical design with appropriate diagrams and descriptions of all functional components of the solution
  • An implementation plan
  • An installation guide
  • A test and validation plan
  • Documentation of operational procedures

And also directly from the NPX blueprint, the following categories will be judged:

Conceptual/Logical Design Elements

  • Scalability
  • Resiliency
  • Performance
  • Manageability and control plane architecture
  • Data protection and recoverability
  • Compliance and security
  • Virtual machine design logical design
  • Virtual network design
  • Third-party solution integration

Physical Design Elements

  • Resource sizing
  • Storage infrastructure
  • Platform selection
  • Networking infrastructure
  • Virtual machine physical design
  • Management component design
  • Datacenter infrastructure (Environmental and power)

As you can see, the NPX blueprint covers a lot of ground. Although page content is NOT specified, and longer is NOT always better, typical submissions can exceed 200 total pages (spread across multiple documents).

Where to Start

One of the first tasks when you are starting down the NPX path is to plan out your documentation, and decide what NPX blueprint content will be in what documentation. Again, there's no hard and fast rule here. And as an "X" (expert) level architect, you should have a good idea how to do this. Logical organization is KEY to allowing the NPX panelists to quickly and properly evaluate your documentation. If it's hard to find the blueprint areas for scoring purposes, you are not doing yourself any favors. Make it dead easy find each and every required documentation criteria. 

For my joint submission with my NPX partner Bruno Sousa, we decided on the following physical documents (in no particular order):

  • Completed NPX application PDF form
  • Resume
  • DevOps essay
  • Architecture Design Guide
  • Implementation Plan
  • Installation Guide
  • Operational Vertification
  • Operations Guide

In this blog post I will focus on the Architecture Design Guide, as that is where the majority of the content lives. That's not to discount all of the other docs, but time wise, I found myself spending the most on the Architecture Guide.

NPX Architecture Guide

As can see from the NPX blueprint, you are required to have conceptual, logical and physical elements to many design areas (virtual machines, networking, etc.). A natural progression from conceptual, logical and physical in your documentation makes following your thought process easy. As you will see from my documentation outline, for most areas I made specific headings called "Conceptual Design", "Logical Design" and "Physical Design". That makes it super obvious that 1) You've covered the areas in the NPX blueprint 2) You know the difference between each 3) Allows the reader to logically follow your thought process. A simple but key tip. I've seen more than one NPX submission that made it very difficult to follow the author's thought process.

With all of that being said, now let's dive into the actual outline of my NPX Architecture Guide so you can see how it was organized. Again, this is not the magical outline, and you can diverge from this to suit your style and design. This is just how Bruno and I organized the document.

The major sections in our architecture guide are:

  1. Overview
  2. Current State and Operational Assessment
  3. Design Overview
  4. Nutanix Capacity and Sizing
  5. Nutanix Cluster Design
  6. Host Design
  7. Network Design
  8. Storage Design
  9. Security and Compliance
  10. Management Components
  11. Virtual Machine Design
  12. Data Protection and Recoverability
  13. Datacenter Infrastructure
  14. Third-Party Integration

The remainder of this blog post will touch on highlights from each area, and have screenshots of the actual outline from our submission.

1.0 Overview

NPX Overview

The overview is a very brief 3-4 page description of the entire solution, at a 30,000 foot level. Why was this project needed? What are the roles and responsibilities of all parties involved (hint: use a RACI chart)? What was the customer project sign off process?

2.0 Current State and Operational Assessment

NPX current state and operational assessment

If you are in a brownfield environment and are doing any type of upgrades, migration, etc. you will need a current state and operational assessment section. As you can see from the outline above, it needs to be very comprehensive. For example, I included the following:

  • Performance baseline (storage, compute) - Charts, graphs, and IOPS/bandwidth measurements
  • Full VM inventory (OSes, largest VM, high performance VM metrics, etc.)
  • Full operational readiness assessment
  • Gap analysis

Giving the reader a good picture of the current state environment is key, as the remainder of the document will build upon this foundation. Capturing performance metrics is key, so that you know how to properly size the new environment, and then validate the new environment can support the projected workload.

3.0 Design Overview

NPX design overview

The design overview is massively important, as this section captures requirements, constraints, assumptions, risks, and design decisions. And it also has 10,000 foot conceptual, logical and physical diagrams of the proposed solution. 

Each requirement, constraint, assumption, risk and design decision should have a unique reference number, which will be used throughout your entire documentation package. Tip: If you have requirement R10 (for example) in the table, but don't reference it anywhere in your doc package, that's a big problem. Validate each and every item that has a unique identifier is used at least once elsewhere.

The screenshot below is a small sample of what my requirements table looked like. The number of requirements will vary greatly from design to design. In my case I had 22, but you may have dozens more if the solution is complex. 

I have seen candidates break out 'technical requirements' (TR) and 'business requirements' (BR) into separate tables. That's certainly a valid approach, and makes perfect sense. I combined all of mine in one table. 

NPX requirements

For your risks table, it's not adequate to just list the risk. You must also have a mitigation for each and every risk. 

4.0 Nutanix Sizing and Capacity

NPX sizing and capacity planning

As previously covered, you can see here that I used specific headings of "Conceptual Design", "Logical Design" and "Physical Design" for the sizing and capacity section. This forces you to think and present logically your solution. 

For each logical sizing unit (compute, memory, storage) I had a table similar to the following, which clearly shows my assumptions and how I arrived at the logical sizing unit. This logical sizing unit is then used later for the physical sizing of the cluster. 

NPX server virtualization CPU logical sizing

5.0 Nutanix Cluster Design

NPX Nutanix cluster design

I'll get tired of saying this, but for the Nutanix Cluster Design I also followed the conceptual, logical and physical flow. Key areas to cover here are scalability and resiliency, in addition to all of the physical components. 

6.0 Host Design

NPX host design

Host design covers the compute design plus the hypervisor of your choice. And again, I used the progression of conceptual, logical, and physical to enable the reader to understand my thought process. 

7.0 Network Design

NPX network design

The networking section is pretty self explanatory. You need to have sufficient depth here that you convey your "X" level knowledge of networking. For example, are you using ECMP? Why or why not? Where in the network is routing taking place? What routing protocol? Are you using leaf/spine or a 3-tier design? Microsegmentation? Any SDN solutions? LACP? NIC teaming? NIOC? How many network ports does your solution require? How many free ports are there for future expansion? How would the network scale out as more nodes are added? What's your network security look like? 

Networking is often a weak point for architects, so if that is your situation, I suggest seeking out experts to help with your design. For example, do you know any CCIEs? Or is there a networking best practices author within your organization? If you just brush over key network details in your documentation, don't be surprised if during your defense you get quizzed more. So be prepared! 

8.0 Storage Design

NPX storage design

Just like networking, the storage section is pretty straight forward. Conceptual, logical and physical headings make another appearance. Be sure to cover all Nutanix storage details here, such as compression, dedupe, EC-X, data locality, shadow clones (if used), RF-level, etc. 


As you can see from the first eight sections of the NPX Architecture Guide, there are a ton of details that you need to cover. It took me over 96 pages to cover these eight sections in what I thought was sufficient "X"-level detail. In Part 2 of this series, I will cover sections 9 - 14, and give you more tips about what I included in each section.

My Journey to Nutanix Platform Expert (NPX) #014

Almost four years ago to the month my career took a major turn. I just successfully passed the VMware VCDX datacenter virtualization certification, to become #125 in the world. You can read about my VCP5 to VCDX journey in 180 days here. And the following week I joined this somewhat little known and scrappy startup, called Nutanix.

Back then HCI (Hyperconvered infrastructure) was a new fangled technology that many, many were quite skeptical of. Was it enterprise ready? Was it good for anything more than VDI? Could it run SQL, Oracle, Exchange? Can it compete toe-to-toe with vBlock? Would Nutanix go belly up or be acquired? Betting my career on HCI was risky in 2014, but it's paid off in more ways than I could ever imagine.

Having the VCDX certification under my belt really prepared me well for dual role at Nutanix as both a Solutions Architect in engineering and a consulting Architect in our sales organization. As a solutions architect I wrote a number of published customer facing Nutanix Best Practice Guides, such as SQL, Veeam, Lync, Microsoft DFS, and others. And as a field Consulting Architect I worked with dozens of customers over the years in projects of all sizes and shapes. Both roles helped refine my enterprise IT architecture skills, and hands-on with our own products including AHV (Nutanix's hypervisor).

NPX (Nutanix Platform Expert)

Just about a year into my career at Nutanix in March 2015, Nutanix announced the NPX certification. You can read my blog post about it here. I was honored to be part of the team that helped develop NPX and came up with the criteria for what it means to be NPX. The bar that was set was even higher than other defense based certifications, such as VCDX. Why? You have to know two hypervisors at the "X" level as well as demonstrating enterprise grade IT architect skills. Our MQC (minimally qualified candidate) bar is high, and the first time pass rate is far from 100%.

Now you may wonder why it's now 2018, three years after NPX 'went live' and I am just now defending. Well to be frank, having dual roles in Nutanix for over 3 years left little to zero time in my life to do blogging or spend the hundreds and hundreds of hours it takes to prepare for the NPX. For my VCDX I estimated I spent over 1,000 hours of preparation and 250+ pages of documentation. So I knew NPX would be even harder.

I am a competitive person, and I also like proving to myself that I can be on a similar footing as my colleagues which I have immense respect for. They were getting their NPX's and they kept badgering me to get mine. Plus, I want be the best customer facing consultant that I can be, and I knew doing NPX would take my VCDX skills to an even higher level. I also very recently shifted roles a bit within Nutanix to focus on our largest global accounts. The job description for that role requires NPX-level skills. Immense pressure was building on me to successfully defend NPX.

The NPX Design

In early 2017 I decided to start putting time into my NPX preparation. NPX requires a real-world design that you've done, so I thought there's no better choice than taking my UCS/HP 3PAR VCDX design and migrate it a Nutanix based solution. So I dredged up all my VCDX documentation from 3 years ago, and read it over. I was shocked to remember how complex 3-tier solutions are, and in particular the SAN/RAID/LUN configuration.

Going through my VCDX design I was ripping out page after page of complexity. LUNs? Gone. SAN? Gone. Fibre Channel switches? Gone. Boot-from-SAN? Gone. Cisco service profiles? Gone. You get the idea. And the best part about it? The actual environment that my VCDX was based on, I was actively involved in the account to migrate them to almost entirely Nutanix. So my NPX had a dual purpose of both defending, and transforming a real Nutanix customer from 3-tier to Nutanix simplicity. Win-Win!

NPX Preparation

For anyone starting down the NPX path, the freely available NPX Blueprint is your Bible. It has all the topics you need to cover to properly submit and successfully defend for NPX. To get a copy, email It is absolutely critical that you follow the Blueprint to the letter and cover everything, including all of the required documents. Although all of the documents are important, to me the Architecture Guide is where you will spend the majority of your time. My VCDX Architecture guide was 185 pages, and my NPX version was 134 pages. That's nearly 50 pages less, nearly all due to removing complexity, while covering more topics for the same ​environment.

After you get all of your documentation in order, next comes submission time. The NPX application is quite detailed and requires things such a resume, 3 professional references, a web-scale essay, plus all of the documents you've spent probably 6-9 months working on. After submission your documentation is scored, and if it scores high enough, you are then invited to an in-person defense. Submission time is roughly 3 weeks prior to the published defense dates.

If accepted, now is time to start working on your PowerPoint slide deck for your defense. You will use this slide deck to walk the panelists through your 90 minute defense, where you will be asked questions about your design, alternatives, and why you did what you did.

Pro Tip: Take all the blueprint topics and create one slide for each topic. Fill each slide with what you think are the top items to cover. Even if you don't verbally cover all bullets on the slide, have the content there so the panelists can ask questions.  I had approximately 23 content slides in my presentation, plus a number of indexed backup slides. 

I've included my TOC for my NPX deck below. This is not a magical's all directly from the blueprint. This is just one way to do what feels right to you. 

​Now that your slide deck is ready, you need to mock mock mock! Don't use a potted plant to talk to...use social media and your contacts to find other NPXs or people working on their NPX. Do a webex, Zoom, etc. Practice practice! Heck, if your design is based on vSphere, hit up VCDXs.

But don't forget to mock the troubleshooting and design scenarios. Those two areas are also key for scoring, and just don't wing it during your defense. Aim for multiple mocks for each of the three areas: defense, troubleshooting, design scenario.

My personal goal was to get through the slide presentation, uninterrupted, in 30 minutes. That leaves 60 minutes for panelists to ask questions. YMMV, but I'd advise not going much longer or you jeopardize your scoring chances.

​Dooms (I mean Defense) Day

​By now you should be comfortable with your design, mocked each of the three major sections of the defense, and probably didn't sleep too well the night before. But be rested! Also if you are traveling across time zones, try to arrive a couple of days early to help adjust. You don't want to be a jetlag zombie during your defense.

When you step into the defense room, for those that have done your VCDX, everything will look familiar. Three panelists, moderator, whiteboard, and a projector. The moderator will give you the rules of the road, then you start your presentation. Panelists can interrupt at any time during your presentation to ask questions. Questions are not bad! In fact, they are asked to help improve your score and make sure you know your design. After the 90 minutes you get a 15 minute break. 

Next up is the 30 minute troubleshooting scenario. You will be shown a few slides, then the timer will start. The panelists are looking for a methodical approach to solving the problem, not a scattershot process of asking random questions or throwing out guesses to the root cause. The goal is not to solve the problem, but show how you would solve it. Curve balls can be thrown if you get close to the 'real' answer. At the end of 30 minutes you get a 5 minute break.

Finally, is the 60 minute design scenario. Just like the VCDX, you are shown slides for a particular fictitious customer. The panelists then act as the customer, and you ask them questions about requirements, constraints, assumptions, and risks. You then start down the design path answering questions as you go. And before you know it, the 60 minutes are up!

Now that you are totally mentally drained, now is the waiting game. Thankfully, you won't have to wait long. My results came in about 90 minutes after I was done. I was on the London underground, which has quite spotty cell service. I got the results via Slack and email, but then cell coverage dropped for a few tube stops. So I couldn't tell anyone I had passed! LOL I did shed a couple tears of joy and a couple of passengers were looking at me oddly. 

​Final Thoughts

​Is the whole process worth it? Yes! Even if you don't successfully defend, just the entire learning process makes you a better enterprise architect. Passing is just icing on the cake. Just like VCDX, the first attempt pass rate is fairly low, so don't be discouraged if you don't do it the first time around. Think of it as a chance to make yourself even better and really kick butt the next time! ​

I want to give a huge shout out to my NPX partner in crime, Bruno Sousa. We collaborated on the entire design, and split up the documentation work. His insight and knowledge was impeccable.

As a side note, pair/group submissions are allowed, but each contributor will defend individually.

I also want to thank the numerous people that supported mock sessions, document reviews, and pushing to keep my head down and being a success to become NPX #014.

The New High Bar: Nutanix NPX Certification

NPX logoToday Nutanix is proud to announce their Nutanix Platform Expert (NPX) certification. You can read the official press release here. The goal of this certification is to become the most rigorous technical computing qualification in the IT industry. That’s saying a lot, given other live performance based certifications that people are going through today, such as Cisco CCAr and VMware VCDX. They are very rigorous and anyone getting through those live defense processes should be VERY proud of their accomplishments.

Offered at *no charge* this live-defense based certification aims to set the bar even higher, by testing a wider variety of knowledge. For example, you must have “X”-level knowledge of at least two hypervisors of your choice (vSphere, Hyper-V or KVM), “X”-level knowledge of the Nutanix platform, familiar with web-scale concepts, plus the world-class architect and soft consulting skills required for successful global enterprise deployments.

I was lucky enough to be involved in the creation of the NPX program, along with more than a dozen other Nutanix consulting architects, solutions/performance engineers, SEs, and other staff. The bar we set for the minimally qualified candidate is high, comprehensive, and will be a challenge ready for conquering by the brightest minds in the IT industry.

The NPX process consists of two parts: Developing a Nutanix-based enterprise-ready design consisting of a number of documents (see the handbook for more details but this includes a CV, references, emerging technology essay, current state review, migration plan, architecture guide, etc.), submitting that design for review, and then if minimal scoring is met, being invited to defend in front of a live panel. The actual defense will consist of three parts: solution design presentation (90 minutes), hands-on troubleshooting exercise (40 minutes), and quizzing of a 3-tier-to-web-scale migration and second hypervisor solution stack (60 minutes).

During this defense the following skills will be assessed:

Consultation skills

  • Discovery of business requirements
  • Identification of risks and risk elimination or remediation
  • Identification of assumptions and constraints and removal or accommodation in the solution design
  • Incorporation of Web-scale technologies and operational models
  • Evaluation of organizational/operational readiness
  • Migration and transition planning

Conceptual/Logical Design Elements

  • Scalability
  • Resiliency
  • Performance
  • Manageability and Control Plane Architecture
  • Data Protection and Recoverability
  • Compliance and Security
  • Virtual Machine Logical Design
  • Virtual Networking Design
  • Third-party Solution Integration

Physical Design Elements

  • Resource Sizing
  • Storage Infrastructure
  • Platform Selection
  • Networking Infrastructure
  • Virtual Machine Physical Design
  • Management Component Design
  • Datacenter Infrastructure (Environmental and Power)

I was very impressed with the PhD from Alpine Testing that guided us through the rubric creation process, and feel that the result is very fair, relevant, yet obtainable by the right candidate. While there are a set of recommended third-party certifications that the NPX suggests you have passed, there is not a hard requirement to have passed any other third-party certification exam. You must have passed the Nutanix NPP, though.

Click on the graphic below to expand it, and take a look at the recommended primary and secondary certifications. For example, if you wanted to defend on vSphere and Hyper-V, then you should have the skills of a MCSE-Private cloud and VCDX (DCV, DT or Cloud). Again, this is a self-assessment and there is not a hard requirement to have passed these certifications to apply for NPX. But be assured the screening process will weed out those falling short, so don’t think you can fudge it and get NPX certified. Be brutally honest in your self-assessment. 2015-03-13_8-35-27 The screening process for the NPX applications will be comprehensive, and only those meeting a minimum score will be asked to defend. If you don’t meet the documentation bar, or fail the live defense, there are program guidelines for resubmission rules that you can read further about in the NPX documentation. Bottom line, is if you are a Nutanix customer, partner, or work for Nutanix and want to achieve a world class architecture-level certification then download the handbook and read up on exactly what is involved to see if you qualify. If you don’t yet qualify, then get cracking on the requirements, such as “X”-level knowledge of dual hypervisors of your choice.

Personally, I would recommend you actually take and pass the recommended third-party certifications. For example, I found going through the VCDX program to be invaluable on many levels. But Nutanix realizes for various reasons sometimes people can’t sit for those exams (or find little value in multiple choice tests), and we didn’t want that to be a barrier but that in no way lowers the bar since our screening process is very rigorous. Our minimally qualified candidate standard is very high so don’t just throw a 50 page design together and think it can pass.

Other performance based “X” level certification enterprise documentation packages can take months to prepare and run in excess of 200 pages and the NPX certification will be no different. This certification is NOT about showing off your technical prowess, and throwing every possible solution into your design. You shouldn’t include every Nutanix platform in your design, nor should you throw the entire ecosystem of hypervisor products into it either. It’s all about meeting business requirements in an efficient, simple, and easy to manage methodology using a web-scale approach.

To get started on your NPX certification just go to the registration page here. By registering you can download the free NPX Design Review Preparation Guide and the NPX Program Application. You can also contact Mark Brunstad, the NPX Program manager, at

If you are aspiring to be an NPX, be sure to check out Rene Van Den Bedem’s NPX Link-o-Rama.

Good luck!