DevOps is a Silo

Silos are bad. We keep hearing how IT is too tribal and broken up into teams that only care about their swim lanes. The storage team doesn’t care about the network. The server teams don’t care about the storage team. The network team is a bunch of jerks that don’t like anyone. It’s a viscous cycle of mistrust and playground cliques.

Except for DevOps. The savior has finally arrived! DevOps is the silo-busting mentality that will allow us all to get with the program and get everything done right this time. The DevOps mentality doesn’t reinforce teams or silos. It focuses on the only pure thing left in the world – committing code. The way of the CI/CD warrior. But what if I told you that DevOps was just another silo?

Team Players

Before the pitchforks and torches come out, let’s examine why IT has been so tribal for so long. The silo mentality came about when we started getting more specialized with regards to infrastructure. Think about the original compute resources – mainframes. There weren’t any silos with mainframes because everyone pretty much had to know what they were doing with every part of the system. Everything was connected to the mainframe. The mainframe itself was the silo.

When we busted the mainframe apart and started down the road of client/server computing the hardware started becoming more specialized. Instead of one giant machine we had lots of little special machines everywhere. The more we deconstructed the mainframe, the more we needed to focus. The direct-attached storage became NAS and eventually SAN. The computer got bigger and bigger and eventually morphed into a virtualized hypervisor. The network exists to connect everything to the rest of the world, and as technology wore on the network became the transport for the infrastructure to talk to everything else.

Silos exist because you had to have specialized knowledge to operate your specialized infrastructure. Sure, there could be some cross training at lower levels or administration. Buy one you got into really complex topics like disk geometry optimization or route redistribution the ability for a layperson to understand what was going on was shot. Each silo exists to reinforce their own infrastructure. Each silo has their norms and their schedules. The storage team will never lose data. The network always has to be available.

Even as these silos got crammed together and subsumed into new job roles, the ideas behind them stayed consistent. Some of the storage admin’s job roles combined with the virtualization team to be some kind of a hybrid. The networking team has been pushed to adopt more agile development methodologies like automation and orchestration. Through it all, the silos were coming down as people pushed the teams to embrace more software focused on the infrastructure. That is, until DevOps burst onto the scene.

OpSilo

The DevOps tribe has a mantra: “Move Fast. Break Things. Ship. Ship. SHIP!” Maybe not those exact words but something very similar. DevOps didn’t come from mainframes. It didn’t even come from the early days of client/server. DevOps grew out of a time when everything was blown apart and on the verge of being moved into the cloud. These new DevOperators didn’t think about infrastructure as a team or a tribe. Instead, it was an impediment to shipping code.

When you work in software, moving fast and breaking things works. Because you’re pushing the limits of what you can do. You’re focused on features. You want new shiny things. Stability can wait as long as the next code commit is right around the corner. Who cares about what you’ve been doing.

In order to have the best experience with Software X, please turn on Automatic Updates so we can push the code as fast as our commits will allow.

Sound familiar? Who cares about disk geometry or route reflectors. Make my stuff work! Your infrastructure supports all my awesome code. I write the stuff that pays your salary. This place would be out of business if it wasn’t for me!

Granted that’s a little extreme, but the mentality is the same. Infrastructure exists to be consumed. IT is there to support the mission of Moving Fast, Breaking Things, and Shipping. It’s almost like a tribal behavior. Everyone has the same objective – ALL THE COMMITS!

Move fast and break things is the exact opposite of the storage and networking teams. You really don’t want to be screaming along at 800Mph when deploying a new SAN or trying to get iBGP stood up. You want careful. Calm. Collected. You’re working with a whole system that’s built on a house of cards. Unlike DevOps, breaking a thing in a SAN or on the edge of a network could impact the entire system, not just one chat module.

That’s why Networking and storage admins are so methodical. I harken back to some of my days in network engineering. When the network was running slow or the storage array was taxed, it took time to get data back. People were irritated but they got used to the idea of slowness. But if those systems ever went down, it was all-hands-on-deck panic! Contrast that with the mentality of the DevOps tribe. Who cares if it’s kind of broken right now? We need to ship the next feature or patch.

DevOps isn’t a silo buster. It’s just a different kind of tribal silo. The DevOps folks all have similar mentalities and view infrastructure in the same way. Cloud appeals to them because it minimizes infrastructure and gives them the tools they need to focus on developing. Cloud sprawl can easily happen when planning doesn’t occur. When specialized groups get together and talk about what they need, there is a reduction in consumed resources. Storage admins know how to get the most out of what they have. They don’t just spin up another bucket and keep deploying.


Tom’s Take

If you treat DevOps like a siloed tribe you’ll find their behavior is much easier to predict and work with. Don’t look at them as a cross-functional solution to all your problems. Even if you deploy all your assets to the cloud you’re going to need specialized teams to manage them once the infrastructure grows too big to manage by movement. Specialization isn’t the result of bad planning or tribalism. Instead, those specialized teams developed because of the need for deeper understanding. Just like DevOps developed out of a need to understand rapid deployment and fast-moving consumption of infrastructure. In time, the next “solution” to the DevOps problem will come along and we’ll find as well that it’s just another siloed team.

Advertisements

Atmosic and the Power of RF?

I recently talked to a company doing some very interesting things in the mobility space and I thought I’d take a stab at writing about them. Most of my mobility posts are about access points or controller software or me just complaining in general about the state of Wi-Fi 6. But this idea had me a little intrigued. And confused.

Bluetooth Moon Rising

Atmosic is a company that is focusing on low-power chips, especially for IoT applications. Most of their team came from Atheros, which you may recall powers a ton of the reference architectures used in wireless APs in many, many AP manufacturers that don’t make their own chips. Their team has the chops to make good wireless stuff one would think.

Atmosic wants to make IoT devices that use Bluetooth Low Energy (BLE). So far, this is sounding pretty good to me. I’ve seen a lot of crazy awesome ideas for BLE, like location tracking indoors or on-demand digital signage. Sure, there are some tracking issues that go along with that but it’s mostly okay. BLE is what the industry has decided to standardize on for a ton of IoT functionality.

How does Atmosic want to change things in the BLE space? Well, those Atheros chipset guys started out by building a chip that uses 5-10 times less power than before. That’s a staggering number when you think about it. BLE beacons already don’t use a ton of power. They’re designed to be used in concert with APs or with standalone, battery-powered devices. The BLE beacons I’ve seen from Aruba are about the size of the AirPods case. And that battery can last for a couple of years.

If Atmosic really did build a chip that can power those beacons with event 5x less power usage, you’re looking at a huge increase in the lifespan of a beacon! Imagine being able to deploy these things everywhere and have them run for a decade? You could literally cover a stadium or a hotel with them for next to nothing. Even if you included the chip in a new AP, which Atmosic is partnering to do, you could effectively run the BLE side of things for free from a power budget perspective.

This is something that is pretty big news. So why did I suddenly see things start sliding off the rails?

Unlimited Power!

The next part of the Atmosic pitch came when they told me about the the other part of their trinity of power savings. On their technology page, they tout the above mentioned chipset along with the special on-demand wake feature that allows the chips to be put into a deep sleep mode that will only awaken when it receives a special packet designed to rouse the chip like a custom alarm clock.

That third thing, though. Power harvesting. Now we’re starting to get into the real weeds of Wi-Fi stuff. Essentially, Atmosic is saying they can power their low-power BLE beacon indefinitely by harvesting power from RF in the air. Yeah, that’s right. They’re literally pulling nanoamps of power from remote power sources. Evidently, their power system is more reliable because they use known sources like 900MHz for coverage as opposed to just trying to pull the power from whatever happens to be around.

At this point, you’re probably saying one of two things:

  1. This is crap and it will never work.
  2. This is the most amazing thing ever!

Right now I tend to fall on the side of the first one. Why? Because if they really did invent a way to pull power from thin air, some really should cut them a check because they need to be building bigger, badder everythings! Imagine being able to power whatever you wanted without clunky batteries or power cords. It would be a revolution!

Sadly, the reality is that the Atmosic trinity pretty much requires all three parts to be so revolutionary. I talked to a couple of my friends in the wireless industry about this and Jonathan Davis (@SubNetwork) was about as skeptical as I was. Since he’s a real math wizard, he figured out that the amount of power being pulled in by the Atmosic chips through the air has to be pretty tiny. Like below nanoamps. And that’s not enough to run an active BLE beacon.

Building a Lower Powered Mousetrap

That’s where the whole system comes into play. It takes a very low power chip with a custom wake sensor (read: Passive Beacon) in order to be able to run on the kinds of power that you can draw from RF waves. And this is where the utility of the whole thing starts breaking down for me. Sure, you could do something crazy like put this on a piece of paper and “hide” it in the service tag of a piece of equipment like a laptop. Then you have a BLE that can track that device even if it’s powered down. But you still need a way to excite the BLE chip and make it wake up. And, at this point, if you’re doing passive Bluetooth is the solution really any better than a passive RFID tag that has the same lifespan? And is a lot cheaper?

The other issue that I have with this solution is the proposed longevity. Forever is the tag on the Atmosic site. For. Ev. Er. Sounds like a great idea in theory, right? Deploy a device in your network that can run forever on free energy and you never have to replace the batteries. Okay, that’s great. How old is your iPhone? Your laptop? Better yet, how old is the oldest piece of enterprise tech that you have on your person right now? I’d wager it can’t be more than 6 years old at this point.

Enterprises get chided for having old technology all the time. Maybe that laptop is 6 years old and still running. Perhaps those servers should have been decommissioned a refresh cycle ago. Compared to the mayfly lifespan of an iPhone, your average piece of enterprise tech is pretty long in the tooth. But not all Enterprise tech is that outdated. Take a look at wireless access points, for example. If you are running the oldest 802.11ac access point made it’s still just barely five years old, the standard having been ratified in December 2013. Most enterprises have already refreshed their 11ac Wave 1 APs. If they haven’t, they’re just holding off long enough for 802.11ax to maybe get certified this year so they can push out hot new hardware.

So, with 5-6 years as the standard for “old” technology in the enterprise, what on earth are we going to do with beacons that are a decade old? With the low-power chipset you’re already looking at a 5-7 lifespan on current battery technology if it really does deliver 5x power savings. Even current BLE beacons are designed with a short lifespan for a reason. Technology changes very fast. If you try and keep that device stuck the wall or a laptop for too long, it’s going to be out of sync with the rest of the tech around it.

Imagine trying to hook up a Bluetooth 2.x device to a current iPhone. It will work because the standards are there but it’s going to be painful because newer devices offer so much more functionality. Trying to keep devices around forever for the sake of doing it isn’t practical. And if you’re going to try and counter the argument by saying IoT devices can be around for quite a while you’re not going to win there either. Most IoT devices that are embedded for long term use wouldn’t use wireless or Bluetooth in the first place. They would be hardwired to cut down on potential points of failure. Sure, you might include something like this in the system, but it’s going to be powered enough already to not need to harvest power through the air.


Tom’s Take

I think the Atmosic people have the right idea for a baseline but their stretch goal is a bit lofty and sci-fi for my tastes. Sure, the idea of being able to harvest unlimited power from RF to run devices without batteries for years is great in theory. But technology demands for both enterprise tech and consumer/enterprise IoT devices is going to drive people to use the lowest common denominator of simplicity. I think that Atmosic has a lot of upside with these new super efficient chips. But I doubt we’re going to see anyone sucking power out of thin air any time soon.

Managing Automation – Fighting Fear of Job Justification

Dear Employees

 

We have decided to implement automation in our environment because robots and programs are way better than people. We will need you to justify your job in the next week or we will fire you and make you work in a really crappy job that doesn’t involve computers while we light cigars with dollar bills.

 

Sincerely, Management

The above letter is the interpretation of the professional staff of your organization when you send out the following email:

We are going to implement some automation concepts next week. What are some things you wish you could automate in your job?

Interpretations differ as to the intent of automation. Management likes the idea of their engineering staff being fully tasked and working on valuable projects. They want to know their people are doing something productive. And the people that aren’t doing productive stuff should either be finding something to do or finding a new job.

Professional staff likes being fully tasked and productive too. They want to be involved in jobs and tasks that do something cool or justify their existence to management. If their job doesn’t do that they get worried they won’t have it any longer.

So, where is the disconnect?

You Do Exist (Sort of)

The problem with these interpretations comes down to the job itself. Humans can get very good at repetitive, easy jobs. Assembly line works, quality testers, and even systems engineers are perfect examples of this. People love to do something over and over again that they are good at. They can be amazing when it comes to programming VLANs or typing out tweets for social media. And those are some pretty easy jobs!

Consistency is king when it comes to easy job tasks. When I can do it so well that I don’t have to think about things any more I’ve won. When it comes out the same way every time no matter how inattentive I am it’s even better. And if it’s a task that I can do at the same time or place every day or every week then I’m in heaven. Easy jobs that do themselves on a regular schedule are the key to being employed forever.

Automatic For The Programs

Where does that sound more familiar in today’s world? Why, automation of course! Automation is designed to make easy, repeatable jobs execute on a schedule or with a specific trigger. When that task can be done by a program that is always at work and never calls in sick or goes on vacation you can see the allure of it to management. You can also see the fear in the eyes of the professional that just found the perfect role full of easy jobs that can be scheduled on their calendar.

Hence the above interpretation of the automation email sample. People fear change. They fear automation taking away their jobs. Yet, the jobs that are perfect for automation are the kinds of things that shouldn’t be jobs in the first place. Professionals in a given discipline are much, much smarter than just doing something repetitively over and over again like VLAN modifications or IP addressing of interfaces. More importantly, automation provides consistency. Automation can be programmed to pull from the correct database or provide the correct configuration every time without worry of a transcription mistake or data entry in the wrong field.

People want these kinds of jobs because they afford two important things: justification of their existence and free time at work. The former ensures they get to have a paycheck. The latter gives them the chance to find some kind of joy in their job. Sure, you have some kind of repetitive task that you need to do every day like run a report or punch holes in a sheet of metal. But when you’re not doing that task you have the freedom to do fun stuff like learn about other parts of your job or just relax.

When you take away the job with automation, you take away the cover for the relaxation part. Now, you’ve upset the balance and forced people to find new things to do. And that means learning. Figuring out how to make tasks easy and repetitive again. And that’s not always possible. Hence the fear of automation and change.

Building A Better Path To Automation

How do we fix this mess? How can we motivate people to embrace automation? Well, it’s pretty simple:

  1. Help Your Team See The Need – If your teams think think they’re going to lose their jobs because of automation, they’re not going to embrace it. You need to show them that not only are they not going to lose their jobs but how automation will make their jobs easier and better. Remember to frame your arguments along the lines of removing mistakes and not needing to worry about justifying your existence in a role. That should encourage everyone to look for new challenges to overcome.
  2. Show the Value – This goes with the first part somewhat, but more than showing the need for automation with mistake reduction or schedule easing, you also need to show value. If a person has never made a mistake or has built their schedule around repetitive tasks they are going to hate automation. Show them what they can do now that their roles don’t have to focus on the old stuff they did. Help them look at where they can provide additional value. Even if it starts off by monitoring the automation platform to make sure it’s executing correctly. Maybe the value they can provide is finding new things to automate!
  3. Embrace the Future – Automation allows people to learn how to do new things. They can focus on new skills or roles that help support the business in a better way. More automation means more complexity to understand but also a chance for people to shine in new roles. The right people will see a challenge as something to be overcome. Help them set new goals. Help them get where they want to be. You’ll be surprised how quickly they will get there with the right leadership.

Tom’s Take

Automation isn’t going to steal jobs. It will force people to examine their tasks and decide how important they really are. The people that were covering their basic roles and trying to skate by are going to leave no matter what. Even if your automation push fails these marginal people are going to leave for greener pastures thanks to the examination of what they’re actually doing. Don’t let the pushback discourage you in the short term. Automation isn’t the goal. Automation is the tool to get you to the true goal of a smoother, more responsive team that accomplishes more and can reacher higher goals.

Certifications Are About Support

You may have seen this week that VMware has announced they are removing the mandatory recertification requirement for their certification program. This is a huge step from VMware. The VCP, VCAP, and VCDX are huge certifications in the virtualization and server industry. VMware has always wanted their partners and support personnel to be up-to-date on the latest and greatest software. But, as I will explain, the move to remove the mandatory recertification requirement says more about the fact that certifications are less about selling and more about supporting.

The Paper Escalator

Recertification is a big money maker for companies. Sure, you’re spending a lot money on things like tests and books. But those aren’t usually tied to the company offering the certification. Instead, the testing fees are given to the testing center, like Pearson, and the book fees go to the publisher.

The real money maker for companies is the first-party training. If the company developing the certification is also offering the training courses you can bet they’re raking in the cash. VMware has done this for years with the classroom requirement for the VCP. Cisco has also started doing in with their first-party CCIE training. Cisco’s example also shows how quality first-party content can drive out the third parties in the industry by not even suggesting to prospective candidates that this is another option to get their classroom materials.

I’ve railed against the VCP classroom requirement before. I think forcing your candidates to take an in-person class as a requirement for certification is silly and feels like it’s designed to make money and not make good engineers. Thankfully, VMware seems to agree with me in the latest release of info. They’re allowing the upgrade path to be used for their recertification process, which doesn’t necessarily require attendance in a classroom offering. I’d argue that it’s important to do so, especially if you’re really out of date with the training. But not needing it for certification is a really nice touch.

Keeping the Lights On

The other big shift with this certification change from VMware is the tacit acknowledgement that people aren’t in any kind of rush to upgrade their software right after the newest version is released. Ask any system administrator out there and they’ll tell you to wait for a service pack before you upgrade anything. System admins for VMware are as cautious as anyone, if not moreso. Too often, new software updates break existing functionality or cause issues that can’t be fixed without a huge time investment.

How is this affected by certification? Well, if I spent all my time learning VMware 5.x and I got my VCP on it because my company was using it you can better believe that my skill set is based around VCP5. If my company doesn’t decide to upgrade to 6.x or even 7.x for several years, my VCP is still based on 5.x technology. It shouldn’t expire just because I never upgraded to 6.x. The skills that I have are focused on what I do, not what I’m studying. If my company finally does decide to move to 6.x, then I can study for and receive my VCP on that version. Not before.

Companies love to make sure their evangelists and resellers are all on the latest version of their certifications because they see certifications as a sales tool. People certified in a technology will pick that solution over any others because they are familiar with it. Likewise, the sales process benefits from knowledgable sales people that understand the details behind your solution. It’s a win-win for both sides.

What this picture really ignores is the fact that a larger number of non-reseller professionals are actually using the certification as a study guide to support their organization. Perhaps they get certified as a way to get better support terms or a quicker response to support calls. Maybe they just learned so much about the product along the way that they want to show off what they’ve been doing. No matter what the reason, it’s very true that these folks are not in a sales role. They’re the support team keeping the lights on.

Support doesn’t care about upgrading at the drop of a hat. Instead, they are focused on keeping the existing stuff running as long as possible. Keeping users happy. Keeping executives happy. Keeping people from asking questions about availability or services. That’s not something that looks good on a bill of materials. But it’s what we all expect. Likewise, support isn’t focused on new things if the old things keep running. Certification, for them, is more about proving you know something instead of proving you can sell something.


Tom’s Take

I’ve had so many certifications that I don’t even remember them all. I got some of them because we needed it to sell a solution to a customer. I got others to prove I knew some esoteric command in a forgotten platform. But, no matter what else came up, I was certified on that platform. Windows 2000, NetWare 6.x, you name it. I was certified on that collection of software. I never rushed to get my certification upgraded because I knew what the reality of things really was. I got certified to keep the lights on for my customers. I got certified to help the people that believed in my skills. That’s the real value of a certification to me. Not sales. Just keeping things running another month.

Risking It All

When’s the last time you thought about risk? It’s something we have to deal with every day but hardly ever try to quantify unless we work in finance or a high-stakes job. When it comes to IT work, we take risks all the time. Some are little, like deleting files or emails thinking we won’t need them again. Or maybe they’re bigger risks, like deploying software to production or making a change that could take a site down. But risk is a part of our lives. Even when we can’t see it.

Mitigation Revelations

Mitigating risk is the most common thing we have to do when we analyze situations where risk is involved. Think about all the times you’ve had to create a backout plan for a change that you’re checking in. Even having a maintenance window is a form of risk mitigation. I was once involved in a cutover for a metro fiber deployment that had to happen between midnight and 2 am. When I asked why, the tech said, “Well, we don’t usually have any problems, but sometimes there’s a hiccup that takes the whole network down until we fix it. This way, there isn’t as much traffic on it.”

Risk is easy to manage when you compartmentalize it. That’s why we’re always trying to push risk aside or contain the potential damage from risk. In some cases, like a low-impact office that doesn’t rely on IT, risk is minimal at best. Who cares if we deploy a new wireless AP or delete some files? The impact is laughable if one computer goes offline. For other organizations, like financial trading or healthcare, the risks of downtime are far greater. Things that could induce downtime, such as patches or changes, must be submitted, analyzed, approved, and implemented in such a way as to ensure there is no downtime and no chance for failure.

Risk behaves this way no matter what we do. Sometimes our risks are hidden because we don’t know everything. Think about bugs in release code, for example. If we upgrade to a new code train to fix an existing bug or implement a new feature we are assuming the code passed some QA checks at some point. However, we’re still accepting a risk that the new code will contain a bug that is worse or force us to deal with new issues down the road. New code upgrades have even more stringent risk mitigation, such as bake-in periods or redundancy requirements before being brought online. Those protections are there to protect us.

Invisible Investments In Problems

But what about risks that we don’t know about? What if those risks were minimized before we ever had a chance to look for them in a shady way?

For example, when I had LASIK surgery many years ago, I was handed a pamphlet that was legally required to be handed to me. I read through the procedure, which included a risk of possible side effects or complications. Some of them were downright scary, even with a low percentage chance of occurring. I was told I had to know the risks before proceeding with the surgery. That way, I knew what I was getting into in case one of those complications happened.

Now, legal reasons aside, why would the doctor want to inform me of the risks? It makes it more likely that I’m not going to go through with the procedure if there are significant risks. So why say anything at all unless you’re forced to? Many of you might say that the doctor should say something out of the goodness or morality of their own heart, but the fact a law exists that requires disclosure should tell you about the goodness in people’s hearts.

Medical providers are required to reveal risk. So are financial planners and companies that provide forward looking statements. But when was the last time that a software company disclosed potential risk in their platform? After all, their equipment or programs could have significant issues if they go offline or are made to break somehow. What if there is a bug that allows someone to hack your system or crash your network? Who assumes the risk?

If your provider doesn’t tell you about the risks or tries to hide them in the sales or installation process, they’re essentially accepting the unknown risk on your behalf for you. If they know there is a bug in the code that could cause a hospital core network to melt down or maybe reboot a server every 180 days like we had to do with an unpatched CallManager 6.0 server then they’ve accepted that risk silently and passed it along to you. And if you think you’re going to be able to sue them or get compensation back from them you really need to read those EULAs that you agree to when you install things.

Risky Responsibility

The question now becomes about the ultimate responsibility. These are the “unknown unknowns”. We can’t ask about things we don’t know about. How could we? So it’s up to people with the knowledge of the risk to disclose it. In turn, that opens them up to some kinds of risk too. If my method of mitigating the risk in your code is to choose not to purchase your product, then you have to know that it was less risk for me to choose that route. Sure, it’s more risky for you to disclose it, but the alternative could lead to a big exposure.

Risk is a balance. In order to have the best balance we need to have as much information as possible in order to put plans in place to mitigate it to our satisfaction. Some risks can’t be entirely mitigated. But failure to disclose risks to prevent someone from making a sale or implementing a technology is a huge issue. And if you find out that it happened to you then you absolutely need to push back on it. Because letting someone else accept the risk on your behalf in secret will only lead to problems down the road.


Tom’s Take

Every change I checked into a network during production hours was a risk. Some of them were minor. Others were major. And still others were the kind that burned me. I accepted those risks for myself but I always made sure to let the customer I was working for know about them. There was no use in hiding information about a change that could take down the network or delete data. Sure, it may mean holding off on the change or making it so that we needed to find an alternative method. But the alternative was hurt feelings at best and legal troubles at worst. Risk should never be a surprise.

Wi-Fi 6 Is A Stupid Branding Idea

You’ve probably seen recently that the Wi-Fi Alliance has decided the rebrand the forthcoming 802.11ax standard as “Wi-Fi CERTIFIED 6”, henceforth referred to as “Wi-Fi 6”. This branding decision happened late in 2018 and seems to be picking up steam in 2019 as 802.11ax comes closer to ratification later this year. With manufacturers shipping 11ax access points already and the consumer market poised to explode with the adoption of a new standard, I think it’s time to point out to the Wi-Fi Alliance that this is a dumb branding idea.

My Generation

On the surface, the branding decision looks like it makes sense. The Wi-Fi alliance wants to make sure that consumers aren’t confused about which wireless standard they are using. 802.11n, 802.11ac, and 802.11ax are all usable and valid infrastructure that could be in use at any one time, as 11n is 2.4GHz, 11ac is 5GHz, and 11ax encompasses both. According to the alliance, there will be a number displayed on the badge of the connection to denote which generation of wireless the client is using.

Except, it won’t be that simple. Users don’t care about speeds. They care about having the biggest possible number. They want that number to be a 6, not a 5 or a 4. Don’t believe me? AT&T released an update earlier this month that replaced the 4G logo with a 5G logo even when 5G service wasn’t around. Just so users could say they had “5G” and tell their friends.

Using numbers to denote generations isn’t a new thing in software either. We use version numbers all the time. But using those version numbers as branding usually leads to backlash in the community. Take Fibre Channel, for example. Brocade first announced they would refer to 16GB fibre channel as “Gen 5”, owing to the fifth generation of the protocol. Gen 6 was 32GB and so on. But, as the chart on this fibre channel page shows, they worked themselves into a corner. Gen 7 is both 64GB and 256GB depending on what you’re deploying. Even Gen 6 was both 32GB and 128GB. It’s confusing because the name could be many things depending on what you wanted it to mean. Branding doesn’t denote clear information.

Subversion of Versions

The Wi-Fi Alliance decision also doesn’t leave room for expansion or differentiation. For example, as I mentioned in a previous post on Gestalt IT, 802.11ax doesn’t make the new OWE spec mandatory. It’s up to the vendors to implement this spec as well as other things that have been made option, as upstream MU-MIMO is rumored to become as well. Does that mean that if I include both of those protocols as options that my protocol is Wi-Fi 6.1? Or could I even call it Wi-Fi 7 since it’s really good?

Windows has had this problem going all the way back to Windows 3.0. Moving to Windows 3.1 was a huge upgrade, but the point release didn’t make it seem that way. After that, Microsoft started using branding names by year instead of version numbers. But that still caused issues. Was Windows 98 that much better than 95? Were they both better than Windows NT 4? How about 2000? Must be better, right? Better than Windows 99?1

Windows even dropped the version numbers for a while with Windows XP (version 5.1) and Windows Vista (version 6.0) before coming back to versioning again with Windows 7 (version 6.1) and Windows 8 (version 6.2) before just saying to hell with it and making Windows 10 (version 10.0). Which, according to rumor, was decided on because developers may have assumed all legacy consumer Windows versions started with ‘9’.

See the trouble that versioning causes when it’s not consistent? What happens if the next minor revision to the 802.11ax specification doesn’t justify moving to Wi-Fi 7? Do you remember how confusing it was for consumers when we would start talking about the difference between 11ac Wave 1 and Wave 2? Did anyone really care? They just wanted the fastest stuff around. They didn’t care what wave or what version it was. They just bought what the sticker said and what the guy at Best Buy told them to get.

Enterprise Nightmares

Now, imagine the trouble that the Wi-Fi Alliance has potentially caused for enterprise support techs with this branding decision. What will we say when the users call in and say their wireless is messed up because they’re running Windows 10 and their Wi-Fi is on 6 still? Or if their cube neighbor has a 6 on their Wi-Fi but my Mac doesn’t?2

Think about how problematic it’s going to be when you try to figure out why someone is connecting to Wi-Fi 5 (802.11ac) instead of Wi-Fi 6 (802.11ax). Think about the fights you’re going to have about why we need to upgrade when it’s just one number higher. You can argue power savings or better cell sizes or more security all day long. But the jump from 5 to 6 really isn’t that big, right? Can’t we just wait for 7 and make a really big upgrade?


Tom’s Take

I think the Wi-Fi Alliance tried to do the right thing with this branding. But they did it in the worst way possible. There’s going to be tons of identity issues with 11ax and Wi-Fi 6 and all the things that are going to be made optional in order to get the standard ratified by the end of the year. We’re going to get locked into a struggle to define what Wi-Fi 6 really entails while trying not to highlight all the things that could potentially be left out. In the end, it would have been better to just call it 11ax and let users do their homework.


  1. You’d be shocked the number of times I heard it called that on support calls ↩︎
  2. You better believe Apple isn’t going to mar the Airport icon in the system bar with any stupid numbers ↩︎

iPhone 11 Plus Wi-Fi 6 Equals Undefined?

I read a curious story this weekend based on a supposed leak about the next iPhone, currently dubbed the iPhone 111. There’s a report that the next iPhone will have support for the forthcoming 802.11ax standard. The article refers to 802.11ax as Wi-Fi 6, which is a catch branding exercise that absolutely no one in the tech community is going to adhere to.

In case you aren’t familiar with 802.11ax, it’s essentially an upgrade of the existing wireless protocols to support better client performance and management across both 2.4GHz and 5GHz. Unlike 802.11ac, which was rebranded to be called Wi-Fi 5 or 802.11n, which curiously wasn’t rebranded as Wi-Fi 4, 802.11ax works in both bands. There’s a lot of great things on the drawing board for 11ax coming soon.

Why did I say soon? Because, as of this writing, 11ax isn’t a ratified standard. According to this FAQ from Aerohive, the standard isn’t set to be voted on for final ratification until Q3 of 2019. And if anyone wants to see the standard pushed along faster it would be Aerohive. They were one of, if not the, first company to bring a 802.11ax access point to the market. So they want to see a standard piece of equipment for sure.

Making pre-standard access points isn’t anything new to the market. Manufacturers have been trying to get ahead of the trends for a while now. I can distinctly remember being involved in IT when 802.11n was still in the pre-standard days. One of our employees brought in a Belkin Pre-N AP and client card and wanted us to get it working because, in his words, “It will cover my whole house with Wi-Fi!”

Sadly, we ended up having to ditch this device once the 802.11n standard was finalized. Why? Because Belkin had rushed it to the market and tried to capitalize on the fervor of people wanting fast connection speeds. The AP only worked with the PCMCIA client card sold by Belkin. Once you started to see ratified 802.11n devices they were incompatible with the Belkin AP and fell back to 802.11g speeds.

Belkin wasn’t the only manufacturer that was trying to get ahead of the curve. Cisco also pushed out the Aironet 1250, which had detachable lobes that could be pulled off and replaced. Why? Because they were shipping a draft 802.11n piece of hardware. They claimed that anyone purchasing the draft spec hardware could send in the lobes and get an upgrade to ratified hardware as soon as it was finalized. Except, as a rushed product the 1250 also consumed lots of power, ran hot, and generally had very low performance compared to the APs that came out after the ratification process was completed.

We’re seeing the same rush again with 802.11ax. Everyone wants to have something new when the next refresh cycle comes up. Instead of pushing people toward the stable performance of 802.11ac Wave 2 with proper design they are going out on a limb. Manufacturers are betting on the fact that their designs are going to be software-upgradable in the end. Which assumes there won’t be any major changes during the ratification process.

Cupertino Doesn’t Guess

One of the major criticism points of 802.11ax is that there is not any widespread adoption of clients out there to push us to need 802.11ax APs. The client vs. infrastructure argument is always a tough one. Do you make the client adapter and hope that someone will eventually come out with hardware to support it? Or do you choose to instead wait for the infrastructure to jump up in speed and then buy a client adapter to support it?

I’m usually one revision behind in most cases. My home hardware is running 802.11ac Wave 2 currently, but my devices were 11ac capable long before I installed any Meraki or Ubiquiti equipment. So my infrastructure was playing catchup with my clients. But not everyone runs the same gear that I do.

One of the areas where this is more apparent is not in the Wi-Fi realm but instead in the carrier space. We’re starting to hear that carriers like AT&T are deploying 5G in many cities even though there aren’t many 5G capable handsets. And, even when the first 5G handsets start hitting the market, the smart money says to avoid the first generation. Because the first generation is almost always hot, power hungry, and low performing. Sound familiar?

You want to know who doesn’t bet on non-standard technology? Apple. Time and again, Apple has chosen to take a very conservative approach to introducing new chipsets into their devices. And while their Wi-Fi chipsets often seen upgrades long before their cellular modems do, you can guarantee that they aren’t going to make a bet on non-standard technology that could potentially hamper adoption of their flagship mobile device.

A Logical Approach

Let’s look at it logically for a moment. Let’s assume that the standards bodies get off their laurels and kick into high gear to get 802.11ax ratified at the end of Q2. That’s just after Apple’s WWDC. Do you think Apple is going to wait until post-WWDC to decide what chipsets are going to be in the new iPhone? You bet your sweet bandwidth they aren’t!

The chipset decisions for the iPhone 11 are being made right now in Q1. They want to know they can get sufficient quantities of SoCs and modems by the time manufacturing has to ramp up to have them ready for stores in October. That means you can’t guess whether or not a standard is going to be approved in time for launch. Q3 2019 is during the iPhone announcement season. Apple is the most conservative manufacturer out there. They aren’t going to stake their connectivity on an unproven standard.

So, let’s just state it emphatically for the search engines: The iPhone 11 will not have 802.11ax, or Wi-Fi 6, support. And anyone trying to tell you differently is trying to sell you a load of marketing.

The Future of Connectivity

So, what about the iPhone XII or whatever we call it? That’s a more interesting discussion. And it hinges on something I heard in a recent episode of a new wireless podcast. The Contention Window was started by my friends Tauni Odia and Scott Lester. In Episode 1, they have their big 2019 predictions. Tauni predicted that 802.11ax won’t be ratified in 2019. I agree with her assessment. Despite the optimism of the working group these things tend to take longer than expected. Which means Q4 2019 or perhaps even Q1 2020.

If 802.11ax ratification slips into 2020 you’ll see Apple taking the same conservative approach to adoption. This is especially true if the majority of deployed infrastructure APs are still pre-standard. Apple would rather take an extra year to get things right and know they won’t have any bugs than to rush something to the market in the hopes of selling a few corner-case techies on something that doesn’t have much of an impact on speeds in the long run.

However, if the standards bodies prove us all wrong and push 11ax ratification through we should see it in the iPhone X+2. A mature technology with proper support should be seen as a winner. But you should see them move telegraphed far in advance with adoption of the 11ax radios in the MacBook Pro first. Once the bigger flagship computing devices get support it will trickle down. This is just an economic concern. The MacBook has more room in the case for a first-gen 11ax chip. Looser thermal tolerances and space considerations means more room to make mistakes.

In short: Don’t expect an 11ax (or Wi-Fi 6) chip before 2020. And if you’re betting the farm on the iPhone, you may be waiting a long time.


Tom’s Take

I like the predictions of professionals with knowledge over leaks with dubious marketing value. The Contention Window has lots of good information about why 802.11ax won’t be ratified any time soon. A report about a leaked report that may or may not be accurate holds a lot less value. Don’t listen to the hype. Listen to the people who know what they’re talking about, like Scott and Tauni for example. And don’t stress about having the newest, fastest wireless devices in your house. Odds are way better that you’re going to have to buy a new AP for Christmas this year than the hope of your next iPhone support 802.11ax. But the one thing we can all agree on: Wi-Fi 6 is a terrible branding decision!


  1. Or I suppose the XI if you’re into Roman numerals ↩︎