VCF Orchestrator: yes or no?

I threw up a quick yes/no question on Reddit to see what the community thinks about VCF Orchestrator. Many people jumped in, sharing their thoughts, doubts, and even some passion for it.

If you’re reading this, you’re probably trying to learn more with the platform and level up your skills. Or you’re thinking of adopting VCF in your organization, and you doubt whether the team will be able to handle it because Orchestrator will be a big part of it. That doesn’t mean you won’t run into issues or have those “Why on earth isn’t this working?!” moments. From my experience, over time, as you progress—step by step—you’ll start to get it. And when that happens, it feels pretty amazing to understand how this whole thing works and “thinks finally.”

My first few month with an early version of 7.x weresuper frustrating when I started. I couldn’t wrap my head around the logic. The whole GUI setup, with all those input/output bindings in the canvas, completely threw me off. But something told me this tool had serious potential—I just had to “crack the code.” Fast-forward a few years, and yeah, I’m a huge fan now. I’ve tested plenty of other orchestrator-style products—some were decent, some… not so much—but I always ended up coming back to vRO (I know, I should call it VCF Orchestrator, but let’s be honest, it’ll always be vRO to me).

Switching from monolithic Windows servers to a micro-services architecture was a smart move, no doubt. Setting up clustered versions of vRO 6 and 7 was a challenge, but it was worth it on a big scale. And while the old standalone vRO client was way better than the early browser-based versions, the improvements over time have been tremendous. It’s still not perfect, but at this point, it covers 80–90% of the typical use cases. And for the rest? And for anything beyond that, we’ve got vRBT to fill in the gaps.

Sure, it’s complex at first, but version 8.x is a much more refined product with killer features (hello, Custom Forms) that you’d be hard-pressed to find anywhere else.

And yeah, it’s still not a fire-and-forget kind of product. Probably, it will never be. There’s a learning curve when adopting it, and that’s something to seriously consider before deciding to go all in. It’ll likely require a specific skill set from the engineers managing it—ideally, more than just one person.

But your chances of success are high if you have the right team. End users will appreciate the self-service portals, and management will love seeing infrastructure maintained as code. Win-win!

So, if you’re interested, jump into the Reddit discussion or drop a comment here—I’d be happy to chat! Or ping me directly.