People Evolution: Operational Transformation (2 of 4)

Loading...

En provenance du cours de VMware

Networking and Security Architecture with VMware NSX

5 notes

VMware

Networking and Security Architecture with VMware NSX

5 notes

This 8 week online course equips learners with the basics of network virtualization with VMware NSX. To get the most of this course, you should have familiarity with generic IT concepts of routing, switching, firewalling, disaster recovery, business continuity, cloud and security. At the end of the course, you will be able to: • Understand network virtualization basics • Describe NSX business value and use cases • Explain how NSX is different from traditional networking • Summarize networking and security solution architecture with VMware NSX around these key areas: + Micro-segmentation + Automation with OpenStack + Automation with VMware vRealize Automation + Disaster Recovery and Business Continuity + Operational Transformation • Demonstrate understanding through hands-on experience • Develop a learning plan for network virtualization certification If you are new to network virtualization, download our Network Virtualization for Dummies guide. http://learn.vmware.com/36350_NSX_ITAutomation_Reg?src=af_5acfd24cebb90&cid=70134000001YR9b

À partir de la leçon

Operations (part 2 of 2)

The content covers process automation with VMware NSX using common cloud management platforms like OpenStack and vRealize Automation. In addition the content describes the need for new tooling that provides converged and correlated data of new data center technologies. Finally, the module explains the importance a growth mindset and the evolution of IT organizations away from rigid, well-defined silos to a more collaborative, cross-functional workforce.

People Evolution: Operational Transformation (1 of 4)11:48

People Evolution: Operational Transformation (2 of 4)33:18

People Evolution: Operational Transformation (3 of 4)18:54

People Evolution: Operational Transformation (4 of 4)9:28

Rencontrer les enseignants

Chris McCain
Director of Product Management
Networking & Security

So, let's transition to

talk about this first area in operationalizing and that's people.

I mentioned already that this is often the most difficult area to make transformation.

Processes, we can see business value.

Tooling, we can understand the technology might require it.

But when it comes to people,

we're having to change people's mindsets with the way that they approach not

just their daily work but maybe even the career path that they've chosen.

So, on our agenda for this particular section is to talk about

this question who takes on the role of managing NSX.

We're going to look at some team structures and different makeups.

Some team culture and some mindset.

The roles and responsibilities that we've seen from organizations that have deployed NSX,

and then some learning and education opportunities beyond just what we have here.

So, who takes on this role of NSX?

Well, realistically, the networking and security professionals

that are in IT today should become the experts on NSX,

and there's very good reasons for that.

Particularly, NSX is based on concepts and technology

that require an understanding of networking or an understanding of security.

So, if you take the silos that we have today,

take a virtualization administrator,

they are not as fluent in things like BGP and

OSPF and Packet Walks and ARP request and ARP replies.

There's a lot of things that they just don't do on

a regular basis that would be really new to them.

The networking security engineers have to learn virtualization.

So, while the virtualization administrators might have

trouble understanding some of the concepts of NSX, well,

it's also true that the networking and security folks would have

some problems understanding the concepts that we have inside of virtualization.

Maybe they don't truly understand what a hypervisor does or maybe they don't

understand the abstraction layer that we have with ESXi.

So, there's some different cross training opportunities here for these different silos.

But the shift to virtualization and the shift to software defined networking security,

this is not something that might happen,

this is something that's happening now.

So, it's important that we start to get the people involved

so that we can continue to be successful within the IT organization.

All right, so now let's jump over and we're going to do a light board presentation.

So I've been told that all I have to do is clap and I'll be teleported over.

So, here we go.

Wait I didn't go anywhere.

Hey, I'm up here.

Oh, [inaudible] I was supposed to teleported,

I wasn't supposed to be duplicated.

Jim, it might be a problem man.

I must be the cool cologne. Get this thing done.

All right. So, what we have here is a typical data center architecture.

We've got VMware ESXi as our hypervisor providing compute virtualization.

We've got a physical network infrastructure and we've got our firewalls.

As you can see over the years as the architecture has evolved into something like this,

the colors themselves show that we've got

very clear delineation between what somebody's job role might be.

So, for example, if I was the virtualization person,

my job would encompass everything from here up.

If I was the networking person I would be working down

here in the physical networking space and security is

off here to the side providing all of

the ingress and egress security for the data center.

But what's happening now with NSX is,

NSX is bringing networking up into this layer.

So not just the networking but also the security.

So, what's happening is we're blurring the lines now between who

is supposed to handle which particular tasks,

and to be honest this is not something that

a typical virtualization administrator really wants to add to their workload.

It's really something that's more geared for somebody

who's been managing the physical network,

the constructs, the ideas around switching,

dynamic routing with BGP and OSPF.

Maybe it's packet walks ARP replies, ARP request,

those are skills that are really honed and

are very strong skills among the physical networking folks,

and the same thing is true with security.

When you deal with the way that applications communicate,

the ports and the protocols and the flows of communication between application tiers,

that's really something that's handled by the security team.

So even though we're blurring those lines and abstracting those services now,

it's still very much something where

role-based access control is an important part for the NSX design.

So, we're not suggesting that everybody now gets to handle,

we're not suggesting the networking people are now going to be managing

constructs and components within virtualization piece,

and we're not suggesting that firewall people are going to be

performing the emotions or configuring clusters, managing clusters.

It's simply about understanding,

it's about knowing that if I'm dealing with logical networking from NSX,

I have to have an understanding of these hypervisors.

I have to know the role that they play,

I have to understand the architecture of it and if I'm

the security person and the enforcement point is now being moved into the hypervisor,

I still need to understand the flows and the communication of the different applications,

but now I need to know how to enforce those,

how to create those rules so that that enforcement point can now

make my infrastructure more efficient and ultimately more secure.

All right. So, now that you've had a little bit of a history lesson on how

we got to where we are with regards to these silos within IT,

let's talk a little bit about the psychology of how this is impacting our ability to

create significant change within the people of an IT organization.

So, there's a book that's available,

that I highly recommend it's called Mindset The New Psychology of Success by Carol Dweck.

In this book, Professor Dweck a Stanford PhD,

she defines two different mindsets.

She defines a fixed mindset and she defines a growth mindset.

The book defines the fixed mindset as someone who thinks about intelligence,

abilities, outcomes, personality, character, as fixed traits.

Something that we can't change that's the way that we're born.

On the other hand, the growth mindset

sees intelligence, abilities, outcomes, personality,

and character as something that we can develop,

something that we can exert effort in order to make change.

So, when we look at the comparison of these two different mindsets,

a fixed mindset is one that might avoid challenges or avoid obstacles,

doesn't take criticism or feedback very well,

and is not interested in the success of others.

The growth mindset on the other hand will seek out challenges and overcome obstacles,

they will actually leverage criticism and feedback to make improvements,

and they appreciate the success of others.

They find value in the success of others.

In the book, Professor Dweck talks about something called the natural syndrome,

and it might be something that we see more when we label kids as a natural athlete or we

say girls are naturally good at one thing and boys are naturally good at another.

So, it might not apply directly when we talk about IT organizations,

but the concept of labeling certainly does,

and we just saw that in the light board presentation.

The way that our IT structures have evolved,

we've put ourselves in these boxes and we've put labels onto what we

do that really prevent us from being open to this idea of taking on additional roles,

additional challenges, new technologies.

So the IT culture is impacted by mindset,

it's something that happens internally within the organizations although,

organizationally we could say all the organization has

a growth mindset in the way that it wants to move forward.

But in this case we're talking more about

the internal mindset of the people within the organization.

So having that mindset that says I'm

the VLAN guy or I do all the routing or I'm the security person.

Those silos that we saw in the lightboard,

the idea that we eliminate this ability to go do something else.

I'm not the person that does that right passing the buck onto somebody else

without maybe taking responsibility or accountability for something new,

is a very fixed mindset way to

approach not just what you do every day but your career in general.

So what we need to do,

is we need to foster this growth mindset within the individuals of IT.

We want people to ask questions like "How can I

change the way I work to better support the business?"

So it's important that from a top down approach,

that the sea level is sharing the vision and strategy of the organization,

so that people within IT can understand that and then

think about how they can work better to support that vision,

or maybe how do current processes impact the line of business and or my co-workers in IT?

So rather than just kind of doing your thing

and not thinking about the impact on someone else,

thinking about what can I do to facilitate my coworkers and as we saw in the lightboard,

with the abstractions of networking and security into the hypervisor,

it really becomes that single space where everybody has to operate and understand.

Then finally a growth mindset individual,

might ask a question like what value can I bring to

a more closely aligned team that can drive success for the company?

To as an individual looking to say what can I learn?

What can I study? What certification could I get?

How can I bring more value to the team and ultimately help the organization?

So mindset for change.

Leaders have to be a mindset for change or have to have the change mindset,

to influence behavior and align these new ways of working.

We need people who will catalyze this change,

we need people who will embrace this change.

We need to build a coalition of like-minded change agents.

We look at the current model for IT,

the current mindset again fixed mindset hoarding of scarce resources, owning of assets,

managing assets and costs so we can be a low cost provider,

commending controlling told only what they need to know

and execute without any type of context whatsoever,

and then controlling change and eliminating risk completely.

Whereas the target mindset what we would like to evolve into,

is more of a growth mindset for the sharing of resources,

taking on challenges and experimenting to improve.

So over the past few years I've met with some customers that have

a very fixed mindset when it comes to a new technology,

they're scared of the new technology,

"oh we might fail,

there might be a problem,

there might be something that we have to overcome",

and then there's the organizations that say, "look,

we know that with any new technology there's going to be some type of challenge,

but we know that as an organization,

in order to grow in order to succeed,

then we have to be able to take calculated risks with what we're doing".

The target mindset, we want to deliver a service that

provides value to the business and competitive advantage.

We would like to empower our teams,

we want teams that are self aligned to

the core mission of the organization and have decision-making authority.

Bringing those traditional silos together to make decisions

about a next-generation architecture or a new tool a new technology,

and then finally embracing and driving

continuous or repeated change and managing risks to the right level.

What does this team makeup look like?

We'll stop and think for a moment,

what would the ideal team look like for

your service or your set of applications in your organization?

Maybe it's based on the use case,

maybe it's based on the people that you have in your organization, it could vary.

Ultimately, the cross-functional self service oriented team

with diverse skill sets across technology domains and disciplines,

is going to serve the largest number of customers in the best way.

A self-sufficient team or an autonomous team with decision-making authority,

means that we can do things faster,

we can be more agile,

if we don't have to continue to go to levels above us to ask

questions or ask if we can make design decisions or changes,

then we're able to achieve a more rapid and dynamic infrastructure.

Change agents, leaders and evangelists with a growth mindset are

critical to moving forward and evolving our IT transformation.

Incentivized based on goals of the cross-functional team.

So rather than building incentives for

the networking team or incentives for

the virtualization team or incentives for the security team,

we should build incentives that are service driven where

all of the teams have to participate in order to achieve success.

VMware does offer additional training and

certifications as well as documents for architects,

for engineers and for operators,

so that you can continue to learn more within your respective area.

So here's an example of some IT organization,

some simplified IT structures and if you work for

a company now you can think about which model best looks like your organization,

if you're new to IT then you get an idea of what some different models look like.

In the first model, this is really our functional siloed model,

most organizations operate in this way.

We have compute team,

we have storage team,

we have network team, we have security team.

Now, realistically sense probably VMware infrastructure three,

the compute team and the storage team,

really started working more closely together.

Network still operate it on their own,

security kind of still operate it on their own,

but the compute and storage over the past decade or so have slowly come to work more

closely together because the line wasn't as clear between those two teams.

In model two, it's more of a product or platform

or service-based organizational structure,

where we're defining IT structure on a service or an application and then model three,

is really the hybrid of both of those right?

Take this siloed functional model and

overlay it with this service platform model and now we

get this convoluted complex model for trying to manage IT services and structures.

So, the current model of the culture within

IT is that we communicate mainly within the silos.

There might be some communication across silo

but it's certainly not as much as what happens within the silo.

We have domain-specific, infrastructure-focused carried out by multiple silos.

This is especially true when it comes to things like design, or engineering,

or troubleshooting where the networking team might get something and say,

"Oh, well, maybe it's not us."

and we toss it over the wall to

the virtualization team who then spend some time looking at it,

"Oh, it's not us, let's toss it over the wall to the security team."

So, nobody's really interacting with one another,

they're only communicating within the silo to determine that,

"Hey, it wasn't us."

Right? Of course, the old adage goes that it's, blame the network,

it's always the networking team,

but that's not necessarily the case.

But when don't communicate among these silos,

then we're extending the amount of time it takes to find a resolution to a problem.

The culture today is highly specialized in

a particular technology domain and mostly around physical infrastructure,

like physical routing and switching,

physical security or the physical compute which includes the hypervisor stuff.

Issues and feedback can be hidden and kept within the silo.

There's often concern about blame.

"I don't want to be blamed for a particular problem."

So, if we do solve a problem,

then we don't really tell anybody what it was.

Okay. It's running joke where we might say, "Oh, there's a problem.

Well, blame the network.

Hey, networking guys, there's a problem."

Then all of sudden, the problems fixed, and what did you do?

Nothing. It fixed itself, I guess.

But we want to prevent future mistakes.

Specialists learn together within their technology domain and

discipline and we have local optimization for the infrastructure.

So, if I've been in that historical networking silo,

then most of the education I get, the courses I take,

the certifications I get,

are all focused around networking.

That doesn't support the way that the industry is going.

If you look at the cloud model,

the cloud model doesn't support having

individuals that understand only one particular technology.

If your organization is looking at some type of hybrid cloud,

maybe it's Amazon, maybe it's IBM,

maybe it's any of the other partners that VMware has,

we're going to need individuals that understand multiple cloud architectures.

You might have to be certified in Cisco for

physical networking and VMware for hypervisor,

virtualized networking and security,

and then maybe even an Amazon certification

in order to bring all of these different pieces together to really

create that next generation hybrid cloud environment

that your organization is looking to achieve.

So, that's what brings us to this new model.

Let's focus on customer experience.

Let's focus on adding value.

So, rather than trying to find a solution within the area that we are experts,

let's grow our expertise so that we can

provide solutions that are a better experience and more value.

Members have an area of expertise but should strive to

become more knowledgeable across the full-stack, more of a generalist.

Now, it doesn't mean that you can't have technical depth in a particular area,

but you should also have some technical knowledge across a broader range of technologies.

Continuous learning from incidents,

failures and waste and a focus on improvement in order to prevent future issues.

Then finally, in the new model,

we want end-to-end optimization at the service level through sharing of information,

innovation, practices and skills development.

So, over the past few years working with customers,

we've come up with an IT model that we feel and customers feel

really supports the way that NSX has affected the IT structures.

If you look at this model,

we've got an architecture team,

an engineering team and an operations team.

But each of these teams is made up of individuals that have knowledge on compute,

storage, networking and security.

So, there are people with technical depth and each one of those,

but they also understand all of the different technologies.

So, what's the difference between the roles and responsibilities

of architecture engineering and operations?

An architect, cloud architect,

cloud network architect, cloud security architect,

maybe these job roles aren't things that you find

are dominating the job boards today but these are certainly

things that you're going to start to see will come about as

this cloud initiative continues to get driven within the industry.

So, at the architect level,

this role has a good understanding of use cases and business value for virtualization,

for networking and security technologies.

So, the architect is a unique individual in

that they can understand technical solutions but they

can apply those technical solutions to solve

business problems by making architectural decisions.

The architect is the person who sees the business problem,

applies a technical solution as the "why" part of a design.

Why do I use this particular technical solution?

Is to solve this business problem.

So, examples of architect might be somebody with

a VMware certified design expert certification or somebody

with a CCIE or a Cisco architect certification.

The responsibilities for the architect,

identify and prioritize use cases for business requirements.

The architect would have that capability to

talk with stakeholders within an organization,

take that information from the stakeholders and then prioritize and say,

"Okay, here's the place where we're going to start.

Here's that first use case where we're going to leverage this new technology."

The architect will design the enterprise architecture and the services while taking

into account five key areas that every enterprise needs to think about.

That's availability, manageability, performance, recoverability and security.

So, whether we're talking about compute,

storage, networking, it doesn't matter.

All of those different elements,

we need to take into consideration those five key components.

The architect will guide the implementation strategy.

So, they've done their job,

they've talked to stakeholders,

they've created a design document and now it's time to take this design document,

this "why" and we're going to hand it off to the engineering team.

But it doesn't mean that we don't communicate with the engineering team.

It doesn't mean that we don't work with the engineering team.

We're just creating this and then we assist the engineering team so that they

understand from an operational perspective what the on-boarding looks like,

what the standards are for.

The architect will design standards and templates

for automated provisioning and configuration management.

When we talk about the automation use case with NSX and maybe OpenStack or vRealize,

in creating those blueprints,

those blueprints are meant to deploy an application stack in its entirety.

Deploy the virtual machines,

deploy the networking, deploy the security.

So, it's important that the architect role step in to say,

"Okay, here are the components that make up that blueprint."

That way, we're comfortable knowing that every instantiation of an application through

the automation engine is going to build that application exactly as we expect it.

So, we're creating this environment where self-service

and isolation eliminates the need to have to come back

to make an architectural decision every time we want to deploy

an instance of an application Virtual Machine or some service.

The architect, importantly, has the job of

identifying and mitigating risks in the enterprise design.

This is especially important because when we look at

those five components that I mentioned a moment ago,

you're not always going to be able to maximize all five of those components.

You're going to have to find where the priorities lay between those.

Take, for example, manageability and security.

Anything more secure is not likely to be easier to manage.

So, if an organization is looking for easier manageability,

better manageability of the infrastructure,

but also calling for more security,

those two don't go hand in hand.

It's going to be the architects decision to weigh them out based on communications with

stakeholders or business requirements and then determine which one is more important.

At that point, we've introduced a risk into the design

because we're not able to achieve something they said that they might have wanted.

So, we have to identify those risks and we have to identify how and

if those risk can be mitigated by maybe different design decisions.

Then finally, the tools.

The architect having this broad knowledge

across these different technologies will be able to

identify different tools that will support not just orchestration and automation,

but the operations of this next generation data center design.

They will look at the impact on visibility,

they will look at the impact on monitoring and they'll

look at the impact on troubleshooting and try and find

a way to simplify the tool set that's used for this architecture that they've designed.

Now the engineer.

So, we take the engineering role.

Again, Cloud Engineer, Cloud Network Engineer,

Cloud Security Engineer, Automation Engineer,

Tooling Engineer, all these different.

They may not exist as specific roles today,

but with the way that we're going in the industry don't be

surprised to start to see these types of roles come about.

So for this role, this role understands the infrastructure design documentation.

The engineer has that deep deep technical know-how,

so that they can implement and manage the infrastructure using relevant tools.

The architect created this high level conceptual design,

maybe a logical design and a physical design,

and then turns around to the engineer and says,

"Okay engineer, here's my document."

and the engineer understands the document.

The engineer might not know the why.

The engineer might not have that capability to type business requirement to technical,

but they have the ability to implement the technology.

So, they can use provisioning tools and they can use command line or scripts,

vRealize Automation, OpenStack, PowerShell,

Chef, Puppet, whatever the different tools are.

They have that technical knowledge to leverage those tools

to create this infrastructure that's been designed by the architect.

Certifications here might be something like

a VMware Certified Implementation Expert or a CCIE.

The responsibilities: deploy, test, validate,

certify the infrastructure and the tooling,

ensure fulfillment of technical requirements,

not business requirements, technical requirements.

So, here's where the engineer would understand,

because of their deep technical knowledge.

They would have an understanding of whether technical requirements have been met.

This might be for something like capacity.

Do we have enough throughput to support application X?

Do we have enough CPU and memory collectively to

support all of the applications to be deployed on the environment?

Or portability?

Where are we going to be able to move

these workloads either within the data center or off premise?

Security, compliance,

the service level agreements that had been defined by

engineering in conjunction with the application owners,

and then assisting operational teams with on-boarding and establishing new processes.

The engineer will implement orchestration and

automation of provisioning, configuration and operations.

They will manage security information like logging, auditing and reporting.

The engineer oftentimes has really good knowledge of tools that support things like,

compliance requirements, government requirements, industry requirements.

The engineer will backup and restore NSX manager data.

They will upgrade and patch the infrastructure,

and they will implement routine tasks,

they will approve exceptions and changes in the infrastructure.

Finally, the operator. So, the operator roles: Cloud Administrator,

Cloud Network Administrator, Cloud Security Administrator,

Cloud Network Support Technician.

These are all some of the titles that you can expect to see for this particular role.

The operations role provides oversight of an enterprise infrastructure by creating,

monitoring and updating standards and processes.

The operator will have technical expertise,

maybe not deep into the technology,

but certainly around the performance thresholds,

the alerts, the notifications,

and then problem resolution.

The operator might work with application owners to define service level agreements,

and then create alerts and alarms,

so that they can be notified when

these service level agreements are either in jeopardy or not being met.

Example certification here might have a VMware certified professional.

The roles and responsibilities: monitor

the physical and logical network and security infrastructure,

and take action on events prior to impact.

They will proactively monitor network performance (latency, the throughput).

They will monitor the health (faults, failures, connectivity).

They will monitor availability, configurations and security,

to make sure that we're achieving the goals that were set forth in the design document.

The operator will update and maintain the infrastructure using alarms,

alerts and notifications, investigate and

diagnose physical and logical network and security incidents.

Finally, manage and engage in

high-priority incidents and escalations affecting logical networks,

narrowing down the problem to

a particular physical or logical location within the environment.

So between the architecture,

the engineering and the operators,

these are just some of the examples of the responsibilities that we've

come up with in seeing how customers are transforming their IT organization,

and what they are looking for these roles to be able to do.

So, it's not an all-inclusive list.

You may find there are other things,

you may find that there's some overlap between architecture,

engineering and operations, but that's okay.

Alright. So, let's take a moment now to think about where you are,

or where your organization is from a people perspective.

If you had to think about where your mindset is,

if you had to think about the way that you view your character, intelligence,

abilities, would you see it more as something you've been born with or would you

see it as something more that you could put effort into in order to create change?

Are you more of an infrastructure-focused type individual or are you

more of a customer and business value focused type person?

Do you work more as a functional Silo?

Do you work more as a cross-functional team?

Do you have very domain-specific skillsets

or are you a cross-domain skillset type person?

So, it's okay if you're looking at this survey and you're thinking,

"Yeah, I'm more towards the one and two space."

It's awareness and education that's going to help you move towards

the more four and five areas in the ending states where we'd like it to be.

Here's some additional topics to think about when it comes to the people transformation.

From a learning perspective,

how do we develop the skillsets and knowledge of our people,

and the environment in which they operate?

What are some things that organizations can do?

What are some things that you can do as an individual to develop skillsets?

How do we encourage team members to learn, grow and improve?

And how can continuous learning be built into the team structure and how it operates?

From an alignment perspective,

how do we get people to understand and believe in the same mission and the same goal?

How do we get them to want to be a part of a team and align themselves?

Culture. How do we optimize for a culture that prizes

the consumer perspective and value orientation?

How do we foster a growth mindset for sharing of resources,

experimenting with new technologies and continuous improvement?

And then finally, for change.

What are effective strategies and methods for leading change?

How do you engage people at different levels and with

different perspectives to sustain change and maximize its benefits?

How do you enable change agents that are trying to shift others into this new mindset?

So, I challenge you to take some of these questions,

think about them, take notes,

and if you can bring them back into your organization or use them personally to get

yourself towards a more growth mindset type attitude,

I think that you'll find a lot of this becomes easier for you to digest.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play