Fast Friday – Mobility Field Day 4

This week’s post is running behind because I’m out in San Jose enjoying great discussions from Mobility Field Day 4. This event is bringing a lot of great discussion to the community to get everyone excited for current and future wireless technologies. Some quick thoughts here with more ideas to come soon.

  • Analytics is becoming a huge driver for deployments. The more data you can gather, the better everything can be. When you start to include IoT as a part of the field you can see why all those analytics matter. You need to invest in a lot of CPU horsepower to make it all work the way you want. Which is also driving lots of people to build in the cloud to have access to what they need on-demand from an infrastructure side of things.
  • Spectrum is a huge problem and source of potential for wireless. You have to have access to spectrum to make everything work. 2.4 GHz is pretty crowded and getting worse with IoT. 5 GHz is getting crowded as well, especially with LAA being used. And the opening of the 6 GHz spectrum could be held up in political concerns. Are there new investigations that need to happen to find bands that can be used without causing friction?
  • The driver for technology has to be something other than desire. We have to build solutions and put things out there to make them happen. Because if we don’t we’re going to stuck with what we have for a long time. No one wants to move and reinvest without clear value. But clear value often doesn’t develop until people have already moved. Something has to break the logjam of hesitance. That’s the reason why we still need bold startups with new technology jumping out to make things work.

Tom’s Take

I know I’ll have more thoughts when I get back from this event, but wireless has become the new edge and that’s a very interesting shift. The more innovation we can drive there means the more capable we can make our clients and empower users.

IT Burnout – The Task List

Sadly, this picture above is me. I used to think I had one of the best memories in the world. It turns out my memory is well-suited for bar trivia and routing protocol esoterics. My memory doesn’t appear so adept at remembering other little things that are of more important, such as remembering to buy a gift for a birthday or following up on an email that I sent last week.

Human brains are great at processing information. But some of the ones that are best at processing it are horrible at recalling it. I think of it not unlike a three-tiered storage array. The fast access tasks are in the fastest storage tier where they are needed. The longer term but less important info goes into the near-line tier where it can be recalled when needed. And in my case, the bandwidth to that tier is slow and unreliable.

Exciting Things!

One of my solutions to this problem is getting better with task management. As bad as my memory is, it’s also not well suited to writing things down to remember them. The irony is almost too delicious to ignore. I need to write things down so I don’t forget them, but I forget to write them down. I’ve been studying more and more processes like Getting Things Done or Zen To Done to help me change the way I store and process information.

I’ve really been trying to use Things as my go-to task manager. Everyone has their favorites and the best task manager is the one you use on a regular basis. I’m trying to get better about using it to collect my thoughts so I can focus on things like writing posts and answering emails without dedicating time and mental bandwidth to actually remembering to do those things.

It’s handy to have a task manager on every device I use. I can drop tasks where I need them and when I need them. The ability to transfer notes and other writings to my devices and have it all sync automatically is wonderful. But it’s also a curse in disguise.

Too Many Things!

The curse of trying to capture all the information you want to remember is that you have to then process the things you remember for yourself. And trying to do that has made me realized I have a lot of things I want to try and keep going all at once. And even just seeing all the daily things I want to try and keep track of is reminding me that I have lots of juggling that I do frequently.

This idea of seeing all the things I have to do on a regular basis could easily lead to IT burnout in your job. I’ve felt it before in my engineering role when I looked at all the jobs on the board that needed to be done and realized I didn’t have enough hours in the day to finish them all on the schedule that they needed to be done.

It does feel good to see all the tasks that I’ve checked off the list as I get things accomplished, but I also know that I feel a sense of dread when I set a future date for an email or a contact to follow up on. The idea of putting it “out of sight, out of mind” lets me feel better about what I currently see. However, knowing there are things just waiting out there that need to be done another time or that things are getting carried over from day-to-day is enough to give pause.

More and more, I’m finding that the key that I need to adhere to is to work the tasks as they come up and find ways to get things accomplished instead of putting them off. Task management is great because it allows you to prioritize. But it also means it’s easy to delay and reschedule too. You have to find a way to make the things you do important enough so that getting them accomplished lets you clear your plate.

If you keep rescheduling and reassigning tasks, you’re going to get buried. If you can’t keep your plate clear it’s going to fill up before you know it. You have to find the big rocks and deal with them so you’re free to deal with the little ones.


Tom’s Take

No system is perfect. Everything can be refined given time. But you also have to figure out how best to work within your own limitations. For me, that’s realizing that I can’t start forgetting to write things down. It’s also realizing that I need to focus on the important stuff on my list and keep checking things off so I don’t get overwhelmed. Time is the ally of burnout. Given enough time anyone can end up burned out from overwork or from too much to accomplish. They key is to keep working through your list and don’t let things pile up on you.

I Was A 10x Engineer. And I’m Sorry.

You probably saw the big discussion this past weekend on Twitter about 10x Engineers. It all started with a tweet about how to recognize a 10x Engineer, followed by tons of responses about how useless they were and how people that had encountered them were happy to be rid of them. All that discussion made me think back to my old days as a Senior Network Rock Star. As I reminisced I realized that I was, in fact, a 10x Engineer. And I was miserable.

Pour Some Work On Me

I wasn’t always the epitome of engineering hatred. I used to be a wide-eyed technician with a hunger to learn things. I worked on a variety of systems all over the place. In fact, I was rising through the ranks of my company as a Novell Engineer in an environment with plenty of coverage. I was just learning the ropes and getting ready to take my place in a group of interchangeable people.

Then I started getting into networking. I spent more time learning about routers and switches and even firewalls. That meant that my skill set was changing from servers to appliances. It also meant that I was spending more and more time working on devices that no one else could work on. I had special knowledge that made me much more valuable to the organization. Soon, I found myself spending less and less time working on the Novell command line and more time working on the Cisco CLI.

That was the first extra “x” on my resume. Because I had special skills it meant that I was being relied upon more to do work that no one else could do. Suddenly I wasn’t just a replaceable cog in the machine. Instead, I was a critical part of the infrastructure that needed to be on-site for certain jobs and deployments. I knew that I needed to have someone else to help me out or I was going to quickly find myself overwhelmed with work. But networking wasn’t the thing that ended up pushing me all the way to 10x territory.

A Voice In The Wilderness

In order to truly become an insufferable 10x Engineering talent, I had to pivot into voice deployments. That’s because my skill set went from “important but we’re training others” to “so complicated no one else can understand this”. Thanks to my knowledge of networking, I was asked to pick up the voice banner and run with it. And I ran really, really far.

I was the only person in the office working on Cisco voice deployments. I had my own method of doing things. My own flow for deployments. My notes were contained in a OneNote file that only I had access to. You can probably see all the issues already. But I couldn’t. To me, this was my jam! I had all the tools and talent to make this happen. I could type MAC addresses faster than filling them into a BAT spreadsheet. I could configure crazy hacks to get around limitations thanks to all the extra research I was doing. I was invincible!

I was also gumming up the works. Voice deployments had to be constantly rescheduled if I was out of town. Vacations were a distant memory at best. I wasn’t just the most important cog in the machine – I was the machine. Nothing went forward unless I was doing it. And that’s not scalable at all. Even when my boss realized that I couldn’t scale any more he also knew that getting someone up to speed on my deployment methods and knowledge was a very daunting task at best.

This is the classic setup for a 10x Engineer. All the talent in the world and all of the hubris. Large portions of the line-of-business relying on their knowledge and process. No documentation. No way to get things done other than to go through me. If you’ve ever read The Phoenix Project by Gene Kim you realize that I was Brent through and through. In fact, when I finally did get around to reading it I self-identified with him before I’d even made it 100 pages in.

Pride Goeth Before

Ultimately, it wasn’t failure that caused my 10x Engineering career to come to an end. Instead, it was success. I left my old job six years ago to come to Tech Field Day. I knew I wouldn’t be fixing routers or voicemail systems any longer. I’d be in for an entirely new and different kind of work.

But I couldn’t see how my old job would be able to work without me. I secretly confided to some friends that I thought their business would fall apart without me. How could it survive? I was responsible for so much! I was the only one that knew all of these things! Even a lengthy two-week info dump wouldn’t be enough.

The pride and hubris I displayed is still shocking to me all these years later. To think that a company that had been in business for almost 20 years before I got there would go out of business months after I left because they couldn’t do what I was doing. They did stay in business. They changed, for sure. They moved away from my specialized knowledge and found new ways to utilize their talent. They were able to keep my systems up and running with my notes and when the time came to replace them they used new systems that didn’t need my help to manage and install. They survived because they realized that what I represented was special and couldn’t be replicated.

Me? I’m happy they did. I didn’t want my 10x Engineering efforts to be an anchor around either of our necks. I couldn’t go back to fixing my old systems with my new workload. And my old company couldn’t count on me being available to fix things when I was gone. They made the right choices to put themselves into a position to keep going. And just like most positive 10x Engineer stories they found a happy ending.


Tom’s Take

I’m not proud of my engineering roots when it comes to how bad I was at times. It wasn’t always intentional. It was a product of where I was and the work I was doing. But I totally couldn’t see the forest for the trees. I realize now that I should have taken more people under my wing and helped them understand what I was doing. I should have documented my work and used repeatable methods to build processes that could be done by anyone. My institutional knowledge should have been a resource, not a crutch. And I should have had the humility to understand that companies can live and grow past a single engineer. Knowing all that today makes me realize that I may have looked like a 10x Engineer but everyone is much better off now that I’m just a simple ex-engineer.

What Happens When The Internet Breaks?

It’s a crazy idea to think that a network built to be completely decentralized and resilient can be so easily knocked offline in a matter of minutes. But that basically happened twice in the past couple of weeks. CloudFlare is a service provide that offers to sit in front of your website and provide all kinds of important services. They can prevent smaller sites from being knocked offline by an influx of traffic. They can provide security and DNS services for you. They’re quickly becoming an indispensable part of the way the Internet functions. And what happens when we all start to rely on one service too much?

Bad BGP Behavior

The first outage on June 24, 2019 wasn’t the fault of CloudFlare. A small service provider in Pennsylvania decided to use a BGP Optimizer from Noction to do some route optimization inside their autonomous system (AS). That in and of itself shouldn’t have caused a problem. At least, not until someone leaked those routes to the greater internet.

It was a comedy of errors. The provider in question announced their more specific routes to an upstream customer, who in turn announced them to Verizon. After that all bets are off. Because those routes were more specific than the aggregates they became the preferred routes. And when the whole world beats a path to your door to get to the rest of the world, you see issues.

Those issues caused CloudFlare to go offline. And when CloudFlare goes offline everyone starts having issues. The sites they are the front end for go offline, even if the path to those sites is still valid. That’s because CloudFlare is acting as the front end for your site when you use their service. It’s great because it means that when someone knocks your system offline or hits you with a ton of traffic you’re safe because CloudFlare can support a lot more bandwidth than you can, especially if you’re self hosted. But if CloudFlare is out, you’re out of luck.

There was a pretty important lesson to be learned in all this and CloudFlare did an okay job of explaining some of those lessons. But the tone of their article was a bit standoffish and seemed to imply that the people whose responsibility it was to keep the Internet running should do a better job of keeping their house in order. For those of you playing along at home, you’ll realize that the irony overlords were immediately summoned to mete out justice to CloudFlare.

Irregular Expression

On July 2nd, CloudFlare went down again. This time, instead of seeing issues with routing packets or delays, users of the service were greeted with 502 Bad Gateway errors. Again, when CloudFlare is down your site is down even if you’re not offline. And then the speculation started. Was this another BGP hijack? Was CloudFlare being attacked? No one knew and most of the places you could go look were offline, including one of the biggest offline site detectors, which was a user of CloudFlare services.

CloudFlare [eventually posted a blog owning up to the fact that it wasn’t an attack or a BGP issue, but instead was the result of a bad web application firewall (WAF) rule being deployed globally in one go. A single regular expression (regex) was responsible for spiking the CPU utilization of the entirety of the CloudFlare network. And when all your CPUs are cranking along at 100% utilization across the board, you are effectively offline.

In the post-mortem CloudFlare had to eat a little crow and admit that their testing procedures for catching this particular issue were inadequate. To see the stance they took with Verizon and Noction just a week or so before and then to see how they had to admit that this one was all on them was a bit humbling for sure. But, more importantly, it shows that you have to be vigilant in every part of your organization to ensure that some issue that you deploy isn’t going to cause havoc on the other side. Especially if you’re the responsible party of a large percentage of traffic on the web.


Tom’s Take

I think CloudFlare is doing good work with their services. But I also think that too many people are relying on them to provide services that should be planned out and documented. It’s important to realize that no one service is going to provide all the things you need to stay resilient. You need to know how you’re keeping your site online and what your backup plan is when things go down.

And, if you’re running one of those services, you’d better be careful about running your mouth on the Internet.

The Good, The Bad, and The Questionable: Acquisition Activities

Sometimes I read the headlines when a company gets acquired and think to myself, “Wow, that was a great move!” Other times I can’t really speak after reading because I’m shaking my head too much about what I see to really make any kind of judgement. With that being said, I think it’s time to look at three recent acquisitions through the lens of everyone’s favorite spaghetti western.

The Good – Palo Networks Alto Buys Twistlock: This one was kind of a no-brainer to me. If you want to stay relevant in the infrastructure security space you’re going to need to have some kind of visibility into containers. If you want to stay solvent after The Cloud destroys all infrastructure spending forevermore, you’re going to need to learn how to look into containers. And when you’re ready and waiting for the collapse of the cloud, containers are probably still going to be relevant.

Joking aside, this is a great move for Palo Alto Networks. They’re getting a lot of container talent and can start looking at all kinds of ways to integrate that into their solution sets. It lets people in the organization justify the spend they have for security solutions by allowing them to work alongside the new constructs that the DevOps visionaries are using this week.

By the way, you can check out more about Palo Alto Networks June 19th at Security Field Day 2

The Bad – HPE Buys Cray?: Hands up if you were waiting for Cray to get purchased. Um, okay. Hands up if you thought Cray was actually still in business? Wow. No hands. Hmmm…

HPE has a love affair with HPC. And not just because they share a lot of letters in their acronyms. HPE has wanted to prove it has the biggest, baddest CPUs on the block. From all their press about The Machine to all the work they’ve done to build huge compute platforms, it is very clear that HPE thinks the future of HPC involves building big things. And who has the best reputation for having amazingly awesome supercomputers?

Here’s my issue with this purchase: Why does HPE think that the future of compute lies outside the cloud? Are they secretly hoping to build a supercomputer cluster and offer it for rent via a cloud service? Or are they realizing they have no hope of catching up in the cloud race and they’re just conceding that they need to position themselves in a niche market to drive revenue from the kinds of customers that can’t use the cloud for whatever reason? There isn’t a lot of room for buggy whip manufacturers any more, but I guess if you make the best one of the lot you win by default.

Given the HPE track record of questionable acquisitions (Aruba aside), I’m really taking a wait-and-see approach to this. I’d rather it be an Aruba success and not an Autonomy debacle.

The Questionable – NXP Buys Marvell Wi-Fi: This one was the head scratcher of the bunch for me. Why is this making headlines now? Well, in part because NXP is scrambling to fill out their portfolio. As mentioned in the linked article, NXP had been resting on their laurels a bit in hopes that the pending Qualcomm acquisition from last year would give them access to the pieces they needed to move into new markets like industrial and communications infrastructure.

Alas, the Qualcomm deal fell apart for political reasons. Which means people are picking up the pieces. And NXP is getting one of the pieces their desperately needed for just shy of $2 billion. But what’s the roadmap? Sure, Marvell has a lot of customers already that use their wireless and Bluetooth chipsets in a wide range of devices. But you don’t make a acquisition like that just for an existing customer base. You need synergy. You need expansion. You need to boost revenues across both companies to justify paying a huge price. So where’s the additional market going to come from? Are they going to double down on industrial and automotive connectivity? Or are they thinking about different expansion plans?


Tom’s Take

Acquisitions in the tech sector are no different from blockbuster trades in the sports world. Sometimes you cheer about a big pickup for a team and other times you boo at the crazy decisions that otherwise sane people made. But if you follow things closely enough you can usually work out which people are crazy like a fox as opposed to just plain crazy.

The Blogging Mirror

Writing isn’t always the easiest thing in the world to do. Coming up with topics is hard, but so too is making those topics into a blog post. I find myself getting briefings on a variety of subjects all the time, especially when it comes to networking. But translating those briefings into blog posts isn’t always straight forward. When I find myself stuck and ready to throw in the towel I find it easy to think about things backwards.

A World Of Pure Imagination

When people plan blog posts, they often think about things in a top-down manner. They come up with a catchy title, then an amusing anecdote to open the post. Then they hit the main idea, find a couple of supporting arguments, and then finally they write a conclusion that ties it all together. Sound like a winning formula?

Except when it isn’t. How about when the title doesn’t reflect the content of the post? Or the anecdote or lead in doesn’t quite fit with the overall tone? How about when the blog starts meandering away from the main idea halfway through with a totally separate argument? Or when the conclusion is actually the place where the lede is buried like the Ark of the Covenant?

All of these things are artifacts of the creative process. We often brainstorm great ideas halfway through the process and it derails our train of thought. That leads us down tangents we never intended to go down and create posts that aren’t thematic or even readable in some cases.

It happens all the time. In fact, even in writing this post I thought of a catchy title for a subject heading and had to move it when I was done because the heading didn’t fit the content of the section that followed. It’s okay to have the freedom to change that as soon as you see it. Provided you have a plan for the rest of the post. And that’s where the key here comes into play.

Strike That, Reverse It

I find the easiest way to plan a blog post is to actually write it in reverse. Instead of thinking about things from a top-down method, I start off by thinking about thinks bottom up. Literally.

  • Start From The End – It’s easiest to write the conclusion of your post first. After all, you’re just restating what you’ve been arguing or demonstrating in the post, right? So start with that. Use it as the main idea of your writing. Always refer back to it. If what you’ve typed doesn’t fit the tone of the conclusion, you either need to support it or cut it.
  • Support Your Conclusion – Now that you know what you’re going to be talking about, figure out how to support it. that means figuring out how to break your argument in to paragraphs and logical sections. Note that even though you’re trying to optimize for reading on screens today, you still need to follow basic structure. Paragraphs have multiple sentences that support the main idea. One you have two or three of those arguments, you’ve got support for your conclusion.
  • State The Topic – After you build your support for your conclusion then you can write the topic. After all, you just spent a lot of time spelling it all out. This paragraph at the top is where you state the purpose or theme of the post. Don’t worry about getting into too much detail here. That’s what the support is for. Your readers will get the idea by the time they get to the conclusion, which serves to wrap it all together.
  • Build Your Anecdote – If you are the type of writer that likes to open with an anecdote, much like a cold open in a drama, this is where you write it. Now that you’ve basically outlined the whole post you can tie your anecdote into the rest of the narrative. You don’t have to worry about building your discussion to support the really cool story. Because you’re adding the story at the end of the creative process you can guarantee that it’s going to fit.
  • Title Card – Now that you’ve written the post you can title it. This keeps you from making a title that doesn’t fit the narrative. It also allows the title to make a bit more sense in context. Either because you called the post something cute and catchy or because you made the most SEO optimized title in history to reap those sweet, sweet Google searches.

Tom’s Take

As you can see, posts are easier to write in reverse. When you think about things the opposite way from the restrictive methods of writing you’re much more free to express your creativity while also keeping yourself on track to make sure everything makes sense. Some people thrive in the realm of structure and can easily crank out a post from the top down. But when you find yourself stuck because you can’t tie everything together the right way try looking in a blogging mirror. The results will end up the same, but backwards might just be the way forward.

Silo 2: On-Premise with DevOps

I had a great time stirring up the hornet’s nest with the last post about DevOps, so I figured that I’d write another one with some updated ideas and clarifications. And maybe kick the nest a little harder this time.

Grounding the Rules

First, we need to start out with a couple of clarifications. I stated that the mantra of DevOps was “Move Fast, Break Things.” As has been rightly pointed out, this was a quote from Mark Zuckerberg about Facebook. However, as has been pointed out by quite a few people, “The use of basic principles to enable business requirements to get to production deployments with appropriate coordination among all business players, including line of business, developers, classic operations, security, networking, storage and other functional groups involved in service delivery” is a bit more of definition than motto.

What exactly is DevOps then? Well, as I have been educated, it’s a principle. It’s an idea. A premise, if you will. An ideal to strive for. So, to say that someone is on a DevOps team is wrong. There is no such thing as a classic DevOps team. DevOps is instead something that many other teams do in addition to their other jobs.

That being said, go ask someone what their job is in an organization. I’m willing to be that a lot of people will tell you their on the “DevOps Team”. I know this because some did a report, which I wrote about here and it includes responses from the “DevOps” team. Which, according to the classic definition, is wrong. Right?

Well, almost. See, this is where this tweet of mine comes into play:

“Pure” DevOps is hard to manage. It involves organizational shifts. It pisses people off because it’s hard to track metrics. You can’t track a person that does some traditional stuff and some of that new Dev-Op stuff. Where does that part of their job end up on a report? Putting someone in a team or a silo is almost as much for the purposes of managing that person as it is for them to do their job. If I put you in a silo, I know what you do. Or, at the very least, I can assign you tasks and responsibilities that you should be doing and grade you on those. If your “silo” is a principle and not a team, it’s crazy to grade the effectiveness of how you integrated with the developers to deliver services effectively. It can be tracked, but not as easily as a checkbox.

Likewise, people fear change. So, instead of putting their people into roles that cross functional barriers and reorganize the workflows, they instead just take the young people that are talking about the “new way” of doing things and put them in a team together. They slap a DevOps on the door and it’s done. We do DevOps now. Or, worse yet, they take the old infrastructure teams, move a few people off of them into a new team, and tell them to figure out what to do while they’re repainting the team name on the door. This has rightly been called “DevOps Washing” but a lot of people.

But what happens when that team starts Devving the Ops? Do they look at the enshrined principles of The Holy Book of DevOps and start trying to change organizational culture a little bit at a time to get the happy ending from The Phoenix Project? Do they eliminate the Brents of the world and give the security teams peace of mind?

Or, do they carve out their own little fiefdoms and start behaving like an integrated team with responsibilities and politics? Do they do things like deploy new projects to the cloud with little support from other teams. With the idea that they now “own” that workflow and can control how it’s used and how their team is viewed? If you read the article above with the report from Veriflow, you’ll find that a lot of organizations are seeing this second behavior.

Just as much as people fear proper change, they also get greedy in their new roles and want to be important to the business. And taking ownership of all the new initiatives, like cloud development, is a great way to be important. And, as much as The Phoenix Project preaches that security should be integrated into the DevOps workflow, you still half the 330 respondents to the above survey saying there is an increase in security threats to their new initiatives in public cloud.

Redefining DevOps

In a way, this “definition” of DevOps is like the title of this post. I’m sure more than a few of you bristled at the use of on-premise. Because, in today’s IT landscape we’re fighting a losing battle against a premise. When you refer to something as happening in a location, you say “on-premises”. If you say “on-premise”, you should be referring to an idea or concept. And yet, so many people in Silicon Valley say “on-premise” when referring to “on site” or “on location”. It’s grammatically wrong. But it sounds hip. It’s not the classical definition of the word and yet that word is slowly be redefined to mean what people are using it to mean. It literally happened with “literally”.

For those railing against the DevOps Washing that’s going on, ask yourself this question: Why? If the pure principles of DevOps are so much better and easier, why is everyone just slapping DevOps on existing teams or reforming other people into teams and running with the DevOps idea instead of following the rules as laid down by the sacred DevOps texts?

It could be that all organizations that are doing it this way are wrong. But are their more organizations doing it the proper way? Or is the lazy way more prevalent? I don’t know the answer, but given the number of products I see aimed at “the DevOps team” or the number of people that have given me feedback about how their organization’s DevOps teams display the same behaviors I talked about in my other blog post, I’d say there are more bad apples than purists out there.

So, what does this all mean for DevOps? Are we going to go on pointing and laughing at the DevOps-In-Name-Only crowd? Are we going to silently moan about how Real DevOps doesn’t happen and that we need to stay pure to the ideals? Or are we going to step back and realize that, just like every other technology or organizational shift that has ever occurred, nothing really gets implemented in its purest form? Instead of complaining that those not doing it the “proper” way are wrong, let’s examine why things get done the way they do and figure out how to fix it.

If businesses are implementing DevOps teams to execute the things they need done, find out why it has to be a dedicated team. Maybe they’re doing it wrong, or maybe they’ve stumbled across something that wasn’t included in the strictest definitions of DevOps. If people are giving work to those teams to accomplish and excluding other functional teams at the same time, don’t just wag your finger at them and tell them that’s not the “right way”. Find out what enabled that team to violate the ideas in the first place. Maybe the DevOps Team is responsible for all cloud deployments. Maybe they want some control over things instead of just a nebulous connection to an ideal.


Tom’s Take

DevOps in theory is a great thing. DevOps as presented in The Phoenix Project is a marvelous idea. But we all know that when theory meets reality, what we get is something different than we expected. It’s not unlike von Moltke’s famous quote, “No plan survives first contact with the enemy.” In theory, DevOps is pure and works like it should. But we’re seeing practice differing greatly from reality. The results are usually the same but the paths are radically different. And for the purists out there, if you don’t want DevOps to suffer the same fate as on-premise, you need to start asking yourself the same hard questions we are supposed to ask organizations as they start to deploy these ideas.