The Welcome to the Other 4 Turtle broadcast.
Have you ever found yourself confused about what a VCF 8
instance or domain is? Well, I invited Gary Blake to
the show to explain all of it. Hey, welcome to the show.
Gary, how you looking? Hey, for those who don't know
who you are, maybe you can explain what it is that you do
for Broadcom slash Vienna. And maybe you can also include a
highlight of your career because you've been at the company for a
while now. So I'm interested to hear about
that as well. Yeah, yeah, absolutely.
Yeah. So, yeah, I've been in 15 years
this year almost as long as you, right.
So I guess in terms of my role, it really falls into a couple of
areas. So primarily, you know, our team
is focused on the architecture for VCF.
So the a key deliverable is the design guide.
So in the product documentation alongside, you know, the usual
procedures and those kind of things, we have an architectural
design where we lay out all of the options within the VCF
platform. Obviously we'll talk about more
about that later. And the second part of our role
is really, I guess it's evangelism, but not evangelism
in the same way that you do it. It's more of, you know, we get
called into customer engagements, customer accounts,
problem accounts, maybe someone's hit an issue, try to
help resolving those problems. And as we move forward under the
Broadcom world, we'll now be involved more with partners.
So actually helping partners understand because there's a lot
of change that's gone on within the organization, as you well
know. And so, you know, we're, we're
close to engineering, we're close to the product management
teams. So, you know, we have good
insight into the futures. So, yeah, we focus a lot on, on
those core things and I guess from a highlight career
highlight, you know, for me, the, the biggest aspect or
biggest part of my career has probably been involved in the VM
Ware validated designs. I think most people, you know, I
ask in sessions, you know, anyone heard of the VVDS and
nine times out of 10, at least 50% of the audience puts their
hands up. So it's something that we
produced as an organization what 10 years ago now, which really
struck A chord with our with our customers.
You know, we had a bunch of products that were very, you
know, integrated, but not integrated well as you as you
know. And what's interesting for me is
seeing that evolution of where we are now as an organisations
where we had sort of these 1015 things that we're now really
trying to push with VM Ware Cloud Foundation as a as a
single platform. So, yeah.
And I guess the the big part of that was helping professional
services teams in terms of building the service offering
around VVD back in the day. So I kind of pioneered the the
service offering before them being pulled in to what was the
validated design team. Yeah.
I think the VVDS were, well very important for customers, not
just for customers, but also for folks internally because I think
a lot of people were challenged with the adoption of all of the
different components and creating a single clout out of
it. So I think it's, yeah, exactly.
I mean, you know, if we kind of go back 10 years, we had so many
moving parts, so many different things, so many different ways
of doing stuff that, you know, we really need to have some kind
of blueprint glue that that brought it together.
And, and I think you're absolutely right.
I think there were a lot of teams internally within the
organization started to realise how complex what we had as a
portfolio really was becoming. So yeah, it was it was a state
for for a long time until VCF came along, Yeah.
I don't think that's still the case, to be honest.
If if you look at VCF, it's still relatively complex.
There are many different constructs involved.
And that's actually going to be the topic of today, because I
was talking to a bunch of people at the V Mag and they all
mentioned that your session was probably one of the favourite
sessions, sessions at the V Mag Connect event, which was
fantastic to hear. And when I started looking at
the content, and of course, I had seen some of the content
already floating around and I've seen some of your sessions in
the in the past, I figured it would be good to get you on the
show to actually talk through some of that content.
Because even for myself, and I've been involved in VM
technology for the longest time, sometimes it's, it's still
rather complex, especially when it comes to VCF.
But before we dive into those specific constructs itself, it's
also probably good to explain from, you know, the highest
level what we really talk about when we talk about the VCF
private cloud. Because even even to me, that's
not always exactly clear what it what is it that that actually
means to you, but also what should it mean for a customer?
Yeah. And you know, I think I've
personally struggled with the concept of a, of a private, you
know, VCF private cloud. You know, we, we call it out as
part of the taxonomy for VCF. And for me, it's not really a
construct, it's more of a concept.
So you know, as you know, you know, Broadcom's very focused
now on private cloud. So you know, we're not really in
the hyperscaler market now private cloud simply to me means
it's private to that organization.
So it's not shared with a another organization.
So you know, a private cloud could be on Prem, it could be,
you know, Co located, it could be a managed service.
But the key thing is it's the dedicated, but the key thing is
it's, it's trying to drive more of an operational model from a
private cloud agile perspective. And that's kind of how I see it
from from where we, you know, we're trying to drive VCF as a
platform. Yeah, I think the operational
model is a important aspect. Now, of course, besides the
operational model, when we talk about VCF, there are also many
different constructs that come into play.
And I struggled with that a lot, especially when those new
constructs started popping up, you know, something like a
fleet, for instance. It wasn't something that existed
back in the days when I was still doing implementations.
You had a, you had a cluster, you had a vcentre server and
there were multiple clusters, etcetera.
But a fleet, it did not exist. So maybe we could start at the
top and then work our way down. So some of the listeners were
not that familiar with the VCF constructs or with VCF in
general, can understand as well what that actually means and you
know what that relates to or how they should look at it.
So maybe we can start at that. What is a fleet?
Yeah, exactly. And you know, I'll be honest, I
struggled with the concept of a fleet as well.
I'd heard the term in the industry and honestly I'd heard
it more from a hyper scaler perspective.
But in essence, what what we're trying to say is from a, the
fleet concept is all about sort of a single set of management
components to help you orchestrate, operate many pools
of infrastructure from a single location.
So think of a simple concept, and we kind of had this in VCF
before 9 dot O things like certificate management, like
being able to configure integration into your Microsoft
CA in one location and then very easily from a single UI be able
to, you know, update and cycle through certificate updates
across your whole infrastructure.
So rather than managing things and on an individual vcenter
level, which is kind of what we've always done, right, it's
you know, okay, you had it enhanced link mode, but it's
very, you know, you do something in one vcenter, you go and do it
again another vcenter and so on and so forth.
So it's more about having this single management control plane
where you have all your infrastructure easily managed.
You can define policies centrally and then you can apply
those policies down onto the underlying components.
So that's the sort of like the top level in terms of of how
we're kind of pushing VCF as a platform in that you create a
fleet and within the fleet you then have all of your cascading
components for your software defined data centre underneath.
Yeah. And some of those cascading
components of course are the, you probably already alluded to
it in an earlier rounds of the instance.
And then we've got a domain as well.
So how does that relate to the fleet and how does that relate
to each other? Because that also got me
confused fairly fast. I mean, I love clusters and
that's usually where it ends. And then of course, all of a
sudden we've got a fleet, we've got an instance, we've got a
domain. Explain it to.
Me so. So first of all, the term VCF
instance, so that that's obviously a well known term in
terms of VCF. So you know in in 3234 and five
we refer to AVCF instance. And the way that I describe
instant AVCF instances is think of it as like a a control or
management boundary. So the the concept of AVCF
instance effectively in the old world is an STDC manager.
So, you know, I think anybody that's familiar with VCF in the
past will know STDC manager was kind of that fleet manager, but
only for the things it controlled.
So essentially the way that you should think about it is that
we're moving the the sort of the the fleet management
capabilities like the life cycle management, which is probably
the biggest one. But again, referring back to
that CERT management and password management capabilities
that we have at the STC manager level, we're moving that up into
the fleet. So you then can have multiple
VCF instances and be able to control those policies.
But an instance really is where you get down into the, the stuff
that you and I know very well, you know, AV centre where you
then have your compute, your resources, network storage,
etcetera, from a software defined data centre.
And when it comes to AVCF instance, we have this concept
of VCF domains. So again, it's a slightly
different change in language, but we're starting to refer to,
you know, VCF instance has multiple VCF domains and then
within the domains you have the next layer of the platform.
Yeah, that that part I, I started to get used to it as as
you mentioned because it was already part of the the VCF
stack for a while now. What kind of confused me then is
when I started looking at some of the diagrams is that if you
look at some of the other products that are involved,
things like VCF automation, VCF OPS, where that boundary is for
those products. So can they actually span
domains, Can they span instances?
How does that actually work and what are your thoughts on?
That yeah. So I guess this is where you
start to bring it together. Now we understand what you know,
a domain is VCF domain, what a fleet is.
We then look at the the the component pieces.
So to your point, VCF automation and VCF operations, those are
referred to as what we define as the fleet level components.
So from a construct perspective, those components sit as a fleet
level. And then all of the VCF
instances which contain your SDC manager, your V centres, your
NSX manager components can all be managed from from those
single fleet level. So as you start to scale out,
you would add more VCF instances and they'll be managed from
those individual VCF operations and automation components.
So right now in VCF 9, for every fleet, you only have one
automation instance and one operations instance.
And I know that that has become, you know, a bit of a change for
some organisations because if you think about certainly
financial services is, is an interesting space because a lot
of financial services have multiple platforms.
And you'll be familiar with this in terms of, you know, they have
a dev platform, but then they have their prod and their pre
prod. Now in the, in the old world,
that was very easy because you could easily segregate them.
And you just say we'll have AV centre manage my dev, AV centre
for my prod and AV centre for my pre prod.
But now it's starting to get customers to think slightly
differently that you've got to up level the management layer.
So you could still have that separation.
Now some organisations will require physical separation of
those platforms, so that might be a compliance requirement.
But by and large prod and pre prod, there doesn't need to be
physical separation in terms of never the twain shell meat, but
you can at least manage them from a specific, you know, from
a fleet level point of view. So think about those VCF
instances like I have AVCF instance which is purely prod
and AVCF instance that is pre prod.
And So what we'll see is as the platform evolves, we'll start to
be able to provide additional service capabilities, but tied
to a VCF instance level. So you kind of start to think
about an instance as being sort of a management boundary or one
way of controlling a set of software defined data center
resources. Yeah.
There are actually two things that I think are interesting to
talk about next. Then is this.
Of course, there's a lot of maximum configurations that we
need to take into account. The other thing that you also
mentioned is the physical separation.
So we'll get into that as well. But let's start with the maximum
maximums that we need to take into consideration and some of
the limitations that there are from a product perspective,
because we've got the fleet level, then of course we have
the instance, we've got the domains.
There are only so many numbers of V centre servers and clusters
and hosts etcetera that you can have and even virtual machines
have a limits on a per cluster basis, on a per vcenter server
basis. So what are some of some of
those things customers need to think about?
Well, I mean, I'm assuming the smaller customers, they're
probably not, you know, overly concerned about those things if
you don't have 100,000 VMS. But what if I have 100,000 VMS?
What does that actually look like and how do I go about
constructing those? Things, yeah.
And it's, I think this is probably the biggest challenge
that our customers are finding actually is, you know, the
concept of I want to control everything from a single fleet.
I think everyone loves they're like, this is brilliant.
I can define a policy once or multiple policies and just push
them down to my infrastructure. In terms of the scales and
imitations, what we've found with the conversations with with
customers so far is they really fall into three key areas.
First of all, you've already mentioned scale.
Scale's an interesting topic and it's a really confusing topic in
my view. You know, we are evolving the
platform, we've etched each new update and each new release.
And you know, the, the, the biggest challenge I think that
we've, we've found is I think we underestimated the sort of the
conversation around the scale numbers.
Because if you, if you look up where we were, you know, 7 or 8
individual products coming together as a single product,
each one of those components had different scale limitations.
And as a customer or, or even as an architect coming in at the
platform and going, well, I've got 50,000 VMS. What does that
look like from an architecture is a real challenge.
So especially when different products use different values
for their scale, Like, you know what, what's, you know, 1 system
might be, it's all about VMS. Another system might be, it's
about objects that you create in, in the platform.
But I think the, the, the biggest, the biggest scale
concern is really sort of if you think what we've done, we've
made operations the centre of the universe for a fleet, right?
So really the key aspect there is around the scale limitations
of operations. And actually operations is
pretty good from a scale perspective.
But it's working out those, those numbers as to how big you
need the appliances to be from the from the outset, because
it's all around metrics being collected, all these objects and
stuff. We continue to add and improve
on those numbers, which I I think is starting to remove the
conversation proof from a scale point of view because you know,
customers do have big infrastructure.
But I think the second limitation actually
counterbalances the first on scale and that's network
connectivity. So we've we've had many
customers come to us and say, I'm a global organization, I
want a single fleet to manage the world.
And then, you know, you start talking latency, bam whips.
And that's where the next challenge comes.
And we've done a lot in the product recently to, to improve
that. So as you know from a, from a
storage, you know, you've got V SAN stretch cluster latency
limitations, then you've got V centre, V motion, DRS latency
limitations, and then you start to layer in operations as well
on top. I think when we first released
VCF 9, we were stating 150 milliseconds was the limitation
for a fleet. Well, you can imagine how that
that went down, right? Literally every customer's
going, Yep, we'll be doing a fleet then because that's just
not going to work in my organization.
So we've we've actually been working quite heavily in those
those areas. I know you know, members of
engineering, the PM team have been focused on that recently.
We recently published a new ports and protocols diagram.
The key thing being 300 milliseconds, which was the
target as being sort of like the the sort of limiting factor when
it talks about fleet managing AVCF instance and such like.
And I think, and this was a question I asked at the V mag
connect in Amsterdam that we were at together, you know, how
many people could actually withstand 300 milliseconds?
And surprisingly, most people in the room put their hands up.
Now, I'm assuming that's because they're not large necessarily
global enterprises because you've always got the odd few
here and there that, you know, will will want to be managing
sort of Asia Pacific plus America's and, you know, Europe
at the same time. And then the third dynamic is
really around organizational placement.
Organizational structure may in itself mean that you need to
consider whether a single fleet makes sense if you've got, you
know, operationally different teams managing different
regions. And so that in itself could mean
that actually one single fleet isn't really a possibility and
that you start to need then already need to sort of consider
maybe multiple fleets as at least an entry point.
But at least you're with the fleet concept, you can I think
scale the the boundary of what you're managing operation
organizationally so that you can start to get those operational
efficiencies of of cloud like infrastructure.
Yeah. I mean, if I look at most of the
customers I talk to on a daily basis, I think for the majority
of them, a single fleet would work, unless we're actually
specifically talking about a solution where, for instance,
disaster recovery or ransomware recovery comes into play.
And The funny thing is that I hadn't actually given this much
thought. But when I started talking
about, for instance, ransomware recovery, the first question one
of the VCF customers I asked is, OK, what do I do from a fleet
management perspective? Because we're also talking about
authentication domain. So what is your opinion on that?
When we talk about those types of constructs, Dr. A ransomware
recovery. So, yeah, so I think the
challenge is that even with any ransomware platform, you've got
some kind of connectivity. So it's more about controlling
the flow and the access controls.
And I don't know if if people listen to this, we're actually
aware, but we did release in 9.0 time frame.
We actually had AVM Ware validated solution.
So I didn't mention this at the top, top of the session.
But I was also tech lead for VM Ware validated solutions for
about 3 years. So that was kind of like the
evolution of VVD as VCF was taking off and how we lay down
additional capabilities on top of the platform.
And we worked very closely with the PM and engineering teams to
build the first ransomware on Prem ransomware recovery.
And in terms of that architecture, the concept is
it's a single fleet. It's just that you've got an
isolated workload domain in the recovery instance.
And then of course, you need to lay down the various components
to make sure you've got the security.
So ensuring that you've got no V defend firewalls so that
replication be sent in. You have immutable snapshot
storage clusters that can be used for storing your VM
replication, that kind of stuff. So I don't feel like customers
need to or I need another fleet just to be able to do ransomware
recovery. I think we have a story, and as
you know, we've been working on improving that story coming in
9.1 with better integration, more automated workflow, because
a lot of the stuff we did in the 9 dot O release was very sort of
relying on the technology that was available, but some of the
orchestrated workflows weren't there.
So I think the ransomware story for me is that, you know, we can
deliver it and we can deliver it within a fleet.
So we shouldn't have to go and build another set of
infrastructure from a fleet management point of view.
But obviously we need to make sure that, you know, we've got
that clear isolated worker domain for the recovery
instance, integrated endpoint detection response solutions to
help do it, and then V Defend, you know, V Defend Firewall not
only helps us secure the communication between the
instances, but also enduring the recovery process.
Yeah. And I guess if you do want to do
an additional fleet just from a, you know, separation
perspective, you can still do that, right.
So it's not. You have the option here.
Absolutely, Yeah. Yeah, there's nothing stopping
you from doing it. I think, you know, we just don't
feel that you have to do it because you know, from an
authentication point of view, and we haven't talked about this
at all, but one of the new features that we have in nine is
the identity broker with what we refer to as VCF single sign on.
And VCF single sign on can be done at different levels.
So you can have instance specific or you can have fleet
wide. So from an authentication point
of view, there's nothing stopping you not enabling the
VCF single sign on features within that instance.
That's your recovery site and that you, you fall back to local
account management or even you create your own dedicated
localised instance of the identity broker to be able to
manage that as a separate authentication domain.
So I think there's, there's enough stuff in the product from
a capability point of view that we can deal with a lot of the
security concerns. It's still early days, I would
say in terms of the on Prem cyber recovery aspect.
But knowing how how popular the cloud version was, the fact that
we're now bringing it on Prem, I wonder how much of sort of, you
know, being part of a single fleet is a concern for, for
organisations because they've already removed it from the, you
know, they were doing it to the cloud.
That involves them going out to the Internet.
So already they're kind of, you know, bringing back on Prem to
help with the security lab. Yeah, I think it's going to be
one of those solutions that will literally, you know, create an
explosion within the the company in terms of people looking for
knowledge everywhere to understand what it is that we're
trying to solve here. Because even with the
conversations that I'm having with customers, sometimes you'll
find yourself, you know, Googling acronyms as you go
through the conversation itself because there's so many new
terms popping up everywhere. It's it's almost impossible.
Now. The other thing also which I
found interesting is when we talk about availability,
recovery ability, etcetera, from AVCF perspective, of course, I
know we support stress clusters. It's one of those things which
you know, a lot of customers, especially in Europe are asking,
asking for. But there's also replication at
the storage level, replication at the VM level.
We also do some things at the application level and that also
can or may apply to the management stack.
So what is it that you typically see customers implemented?
Because I think that's also a big part of what your team does,
right, being involved with the implementation.
So I would be interested in understanding what it is that
customers do. Yeah, and you know, it's an
evolving story when it comes to the management stack.
So, you know, I'd like to say that we have a fully fledged
out, you know, recoverability and availability storage VCF.
The fact of the matter is, you know, 9 dot O was the first
release. As you know, a lot of the focus
was on the single UIS, you know, single operational stack.
We still have some work to do from a recoverability point of
view. But you know, if I kind of go
back to the VVD days, we had pretty good story there.
Recoverability from a management stack point of view was you
know, you have application level HA, so pretty much most
components have, you know, an HA story.
So if you think about things like log management, you think
about automation and VCF operations, you have choices
there. V centre has always been the
interesting one from an application high availability,
you know, we have V centre HAI think probably I don't know how
I would put this, but our team's always been a little bit sort of
hesitant to include V centre HA into our architecture designs.
We've always felt that the the sort of the pain of configuring,
maintaining and operating was far greater than the benefit you
received compared to V sphere HA, right.
Just to be brutally blunt on the topic.
So, you know, VCN, VCN has always been a bit of a single
point of failure except for, well, VCF HA recovers and you
know, how much do you need it from a day-to-day running of the
business application. It's just, you know, when it
comes to management, there's an issue.
Now, obviously, you know, the way that we're building VCF 9
now is, is continuing to evolve. You know, we introduced more of
a containerized platform and you know, we have some limitations
like things like life recovery, being able to protect a
container, right? It's not there.
It's something that we're looking at and you know,
hopefully that will come. So I think we still have sort of
HA from a management component for most aspects of the stack,
backup and restore. Obviously, you know, everyone
needs to be backing up and restore.
You know, we, we have some, some, some areas like automation
is a bit more of a backup and restore for Dr. today that
hopefully will evolve over time. And of course, you know, some
pieces we can still replicate using storage replication.
So you know, we've been a big user of Visa replication in the
past. We now have V SAN replication
built in. So I think the options and the
availability is constantly improving in, in terms of what
we, what we've seen in the past, we've we've certainly seen
stretch clusters in Europe is a big, big thing.
It's, it's always interesting when you talk about V sphere
stretch cluster, you know, is that availability or is that
disaster recovery? Not going to get into that
debate here, but you know, I've had, I've heard customers say
things that I've, I totally disagree with snapshots.
Oh, it's a backup. Is it, is it though?
You know, those kind of conversations that we've
probably had many times and you know, I see you smiling.
You probably had those conversations as well.
So, you know, I think stretched is, is definitely a hot topic in
Europe. US becomes a bit more of a
challenge. So replication, being able to
replicate within the hypervisor obviously is a, is a massive
win, massive capability there to be able to protect stuff.
So it's definitely sort of, you know, we've got a lot of
customers using the storage replication as well, right?
So having orchestrated recovery with live recovery as well, I
think we'll start to see a lot more in that space, which is
actually quite exciting for me because I, I started out as a
consultant, a professional services, as you know, in the
team that used to be in and a big part of my day job was site
recovery manager projects. I did an awful lot of, of
disaster recovery engagements. And yeah, obviously it was all
storage replication back then. So I think sort of, you know,
having the flexibility and choice is definitely making
making the optionality a lot, a lot better for our customers.
I did the very first implementation of Site Recovery
Manager worldwide. And at this point in time, I
mean I haven't done much with Site Recovery Manager since
then, probably not in the last 15 years or so.
But it's all coming back again now with Live recovery and
especially with the ransomware effort that we have have ongoing
and the conversations that we're having with the customers, it
seems to be more important than ever before.
Now you've mentioned that you've seen some of the customers
implementing that before the management stack.
I'm assuming that also applies to their workload domains then,
right? Are they implementing similar
technologies or what are they doing?
Yeah, I think, I think there's a mixture there.
So obviously, you know, there's, there's massive shift to, to
what we refer to as modern applications, right.
And I, I think certainly where customers can, they're, they're
sort of reviewing their applications, how the
applications are built, shifting a little bit away from
infrastructure being the thing that does availability to
actually, well, let's build into the application natively,
because then actually we don't really care about the
infrastructure. It just becomes pools of
resource. So, you know, we see a lot of
that, but where that's not possible, I, I think, you know,
go back to the live recovery visa application.
Those tools work just as well to be able to do the recovery.
I guess the, the biggest challenge with a lot of these
these organisations and lots of customers is fully understanding
the impact of an application. You know, we talked about 15
years ago, I don't think the world has changed that much
because organization, you know, the personnel change, people
that had knowledge move on. So I think the biggest challenge
with application recovery is, well, what happens when this
component fails and what does it talk to and what do I need to
fail with? It has always been the, the
biggest issue and that was always the biggest part of most
of my consultancy engagements was helping them understand and
doing the discovery of what they need to protect as a group of
services to actually fail over an application.
Because, you know, it's very easy to go, well, that's, that's
my application server. But if it talks to three other
things and they're critical, you know, and you don't know about
it, then you don't really have a disaster recovery plan.
And I guess the same applies to to that from a VCF constructs
perspective, right? If you don't know what is
talking to what, how do you know which virtual machines or
services should be part of the same domain instance slash
fleet? I guess the same applies there
as well. Yeah.
And also understanding, you know, not just the
communication, but actually which bits are critical.
And you know, we had this debate internally where product
management was going, well, we need to recover components
ABCDEFG. And then, you know, we look at
it from our experience of going, why we're going to recover AV
Centre that is only managing infrastructure in that data
centre, in the primary data centre.
If the primary data centre has failed and the only thing it
manages is in that data centre, why do I care about recovering
it? So you know, we've had those
conversations. I think it goes, it goes back to
understanding on like you say, what's talking to where, what is
critical versus what's non critical.
Otherwise you can, you know, you can start to be protecting 10
times more than you really need to protect.
And like, you know, if, if you if there's certain things you
want to protect like that, I think you got bigger problems in
your environment than just trying to recover something so
low down in the stack. Yeah, I think it's a valid
point. I've had those conversations
many times in the past where I'm asking the customer the
question, OK, what is it that it actually does and why is it
important? I can understand even why you
would want to replicate it because the cost of replication
may be, you know, fairly low. But do we actually need to fail
over that particular component at this point in time?
Because there's going to be a cost associated with failing it
over. It needs to be powered on.
It's going to claim resources which can't be claimed by other
components. So do we really need it or not?
So I think that is is very valid.
Now, if you look at VCF itself, it's fairly prescriptive and I
know there's a lot of different decisions still to be made.
I mean, we spoke at a bunch of about a bunch of these, right?
Some of the limitations that we have and some of the concerts
that we have. Now when it comes to all of
these design decisions and best practices, where should
customers actually go to or people listening to this episode
if they want to find out more about it?
Because I know your team has written a lot and I know there's
many sessions online, and I'll make sure to Add all of the
links to the show notes so if you have any examples that you
can share, that will be fantastic so people can start
Googling straight away. Yeah.
And so I guess as I mentioned at the beginning, you know, a core
part of what we do is we build this thing called the VCF design
Guide. So that's the thing that I think
customers should go look at first and foremost.
You know, you talk about VCF being prescriptive, I think it's
become more optionality. So it's less prescriptive
ultimately. You know, back in the sort of
the two and three days, it literally, you know, you Click
to go, it did its automation and the thing was built.
You know, one of the things that that has sort of been emphasized
with 9 dot O is that in order to get customers to move us on the
journey to the VCF Private Cloud, we need to meet customers
where they are. So just take vsphere for
example. There are so many configurations
and widgets and dials you can do inside vsphere alone.
So, you know, we've had to sort of expand what we support as a
sort of deployment mechanism. And so really, you know, if we
talk about mentioning validated designs, again, you know, that
was a very prescriptive design. You know, we basically told you
exactly which components to deploy.
We told you exactly how to deploy each component in VCF 9.
You now have choices. You know, at the simplest level,
if you look up VCF operations, which is as we mentioned is like
the central management for the fleet, you can deploy that in
three modes. You can have a single VCF
operations instance, or you can have one that uses multiple
nodes to create an HA in a single site, or you can deploy
it in a continuous availability mode where you actually deploy
it in two separate locations. So optionality has become a big
thing. So we've had to really kind of
rethink our design guide. So we still believe design
decisions are key because that's helped set how each of these
things are deployed in the design guide.
Now we talk about requirements versus recommendations.
So again, in the VVD world, it was everything was a
requirement. This is how you build it.
If you want to be successful, if you want to de risk your
environment and you want the greatest return on investment in
a fast pace, you do what we say. Whereas now what we've had to do
is to take the design decisions and really split them into the,
these are the things that VCF is going to give you as a
requirement and these are the things that we would recommend
you do on top as a best practice.
Doesn't mean you have to, but we're at least giving you a bit
more of a prescriptive way of doing it.
So in that design guide, really it's kind of split into 3
sections. First of all, we have what we
call the architectural options. So this is where I talk about
the optionality. So giving you sort of the 10,000
feet view of, OK, each component that I'm deploying can be
deployed in, you know, 1-2, three or four ways.
What are the benefits and attributes of each?
And that allows you to kind of pick the right model for your
requirements, right, for your needs.
That then flips into the bottom of the document which talks
about the design, detailed design, essentially.
So very similar to the way we used to do VVD, bit more detail
around what your design options are, detail around the design
decisions. But what we also introduced in
that design guide this time around was something called
blueprints. So this again is, is a little
bit back to our roots of a validated design because if
you've now got optionality, you're now elongating the
architecture design process. So what we wanted to do was to
say, you know, from our experience in the last 10-15
years working with a lot of customers, we know that there
are typical deployment models that customers follow, you know,
single site versus multi site versus multi availability zones
across those. So typically 4 core topologies
that most organisations fall into.
Then of course, there's the sort of the minimal footprint.
How do I get this thing up and running like a lab?
So what we decided to do was to build out these blueprints.
So we have 5 blueprints within the zone guide, and each
blueprint has a design profile where we define, from a business
point of view, kind of what we're trying to achieve from
that blueprint. And then each blueprint simply
selects the model of the component that aligns to the
design profile. And all intents and purposes,
all we're trying to do is to say, hey, you're probably going
to align to one of these. You may not be 100% aligned.
In fact, I would argue probably no customer is ever 100%
aligned. But here is a blueprint which at
least gives you the sort of the starter for 10 in terms of your
high level design. And then of course, you would do
your typical architecture design workshops where you'd look at
each component, understand whether you know there's any
adjustments you need. The example I use is like
distributed switches, right? You know, a simple thing like I
think, I think each of our blueprints, we use a single, we
use the single distributive switch model, right?
It's the simplest. It's 2 next happy days.
But let's say you've got an organizational procurement
process that dictates 4 NICs in every single server, right?
Maybe that's your standard and that's, that's fine.
So you can immediately go to the distributed switch section and
go, well, actually we have 4 NICs.
That's what we always buy. That's our standard.
So you can go and swap the model out and pick the model that uses
the four NICs. Now that could be storage
separation because you're using V SAN, or it could be workload
network separation depending on what the requirements are.
So, you know, that's kind of what we've tried to do with with
the design guide. And that's, that's really where
I would tell customers, go look at this, look at the
architectural options, understand your choices, then
look at the blueprint and see which blueprint best matches
what you're trying to deliver. And then take that.
And we do this internally, right with, with our customer
engagements. We take a blueprint or we
understand the customer, understand the the sites, the
the Wan link community limitations, some of the scale
requirements and try to pin a blueprint as the discussion
point and then from there start to dig down into the detail.
Now you've mentioned it a few times and you said customer
engagements. So if I was a customer, how do I
get Gary or someone else from your team like Paulie O'rien on
site, How does that actually work?
I need to ask for those listening.
Yeah. So for our team, it's obviously
an internal Broadcom where we have certain accounts that are,
you know, strategic or maybe there's, you know, opportunities
on the table. So, so we'll, we get involved
very heavily with with those types of customers.
You know, we have a top customer program as you know, most of
well, in fact every one of those top customers has one of my team
aligned with it. But I guess you know, ultimately
there's, there's a big shift towards partners.
Partners are really the, the, the folks now that are going to
be doing, you know, the deployments, a lot of the
architecture designs, you know, we're going to start working
very closely with partners, sharing our knowledge with them
to upskill those people. So I guess to get access to me,
you've got to be lucky, right? You've got to be one of the
right customers on the list. But you know, most of our team
blog, we share information, we do V mug sessions, those kind of
things. So there's always opportunity to
come, you know, and talk to us if if we're at one of those
events, you know, the explores explore on tours.
I'm sure we'll be be on on those shows, those Rd. shows this
year. So yeah.
Yeah. And it makes sense as well to
enable the partners because there's only one Gary, there's
only one party. There are only so many customers
you can meet with. So that makes sense.
Yeah, that's the biggest problem.
It's scale. You know, we really need to make
sure that that we're helping, we're helping the, you know, the
trusted advisors out there that we can, we have access to that
we can help, help them to then help customers.
Yeah, just so people understand, I've mentioned two people, the
two names so far, but of course the the team is much larger than
that. So it's it's not just Porty and
Gary who are part of the team. I'm just mentioning those names
because every once in a while when I get a customer question,
those are the two names that pop up in my head as well.
And I've unfortunately for Pori, I've involved him in in many
very difficult conversations. Whenever he sees a message from
me popping up, he's like, Oh my God, there we go again.
It's another 16 weeks gone. Hey, thanks, Gary, that was
fantastic. Now before I let you go, any
famous last words or any final thoughts you would just like to
share with the audience? So, you know, I guess we've
talked about a lot today, right? We've we've talked about sort of
very high level concepts. You know, what I would say to,
to the customers listening to this is go look at the material,
go understand the architecture. You know, I think there's
probably a lot of V sphere only customers, maybe V sphere with
OPS that they're going to be looking to move to VCF in the
future. So, you know, use the resources
out there, use the design guide. Obviously, you know, if you find
me on LinkedIn, reach out. Happy to, to kind of engage,
work with your trusted advisors, so your partners, maybe you work
directly with Broadcom, your account teams ask the right
questions. And obviously use the community.
You know, the VMO community is, you know, invaluable when it
comes to sharing information. There's a lot of great blogs out
there. As I mentioned, you know, I do
blog when I find time. Most of my team have blogs, you
know, just just sort of, you know, chat amongst yourselves.
You know, it's amazing. Mainly what you couldn't learn
from each other and that I think the V MO community certainly
instills that that confidence and and sharing between between
learnings. Fantastic.
Well, if there's anything new popping up in the VCF space,
I'll make sure to invite you again, Gary, Thank you.
Thank you. Thanks, Duncan.
And that's it. Thanks for tuning into the
Unexplored Territory podcast. If you enjoyed this episode,
don't forget to subscribe and leave a reviewer rating wherever
possible. And please join us again next
time as we cover more insights into cutting edge solutions
shaping the world of IT. Until then, staying comfortable,
keep it.