VMware Lightboards - Cloud Native Fundamentals, 12 May 2017

Previous Meeting

⏯

youtube image

►

From YouTube: An Analysis of IT Technology Silos: Consumers & Providers

Description

Creating a great internal IT organization is a collaborative effort that needs sponsorship at each step of the way across different IT silos from the physical infrastructure layer all the way up to the application development layer. And understanding the different needs of consumers and providers at each technology silo is the key.

In this lightboard talk, Steve Tegeler takes you through an analysis of IT technology silos and talks about what the consumers and providers of each silo care about.

For more information, please visit the VMware’s Cloud-Native Apps website:
https://cloud.vmware.com/cloud-native-apps

A

Hi, my name is Steve Pegler I'm, a director of technical product management here at VMware in our cloud native apps business unit, and this lightboard session is a discussion around the consumers and the providers in IT today, and what I've done is I've drawn a very generic list of the technology silos that exist in IT. There certainly could be a lot more than this and, quite frankly, a lot of these may be consolidated into a single team, but I found.

A

This is a good way to articulate the different technologies in IT and to talk really about the consumers and the providers of the technology, because, if you're the provider of the technology, you probably care about the in the weeds details around the technology versus the people that are actually consuming it. So this is a discussion about that. You can see I've broken it up into certainly the physical infrastructure that everything runs on.

A

We've got the virtual infrastructure layer here then now we've got the Aya's component, so you can think of I, as is really the coordination and orchestration of the specific virtual infrastructure technology.

A

Then you've got at the Aya's layer above that you've got the platform services folks, and this is a highly generic term that can be used for basically the architects that take call it infrastructure, primitives and present them create different technologies and present them up to application developers. So, let's that's a brief overview. Let's talk about each individual layer and if we start off down here at the physical infrastructure layer when I'm in the physical infrastructure layer, what do I actually care about?

A

Well, if I'm on the physical infrastructure layer, most likely I have to make a decision around the compute platform, I use. So basically what server is it adele? Is it at HP? Is it blade? Is it a rack mount then I've got basically the networking decision, so am I using Cisco or Rishta or juniper. Is it layer-3 top-of-rack? What are all those topology decisions? Finally, what about the storage you got to make decisions around the storage, so is it? Is it NFS? Is it I scuzzy? Is a fibre channel direct-attached, so on and so forth?

A

Okay, so I have to make decisions on the physical infrastructure related to this. Now, if I'm up in the virtual infrastructure layer I'm going to have to make decisions as as well about what virtual infrastructure technology that I choose, but when I look down at that physical infrastructure, what do I really care about? What's important to me? Is it the fact that it's a Cisco or juniper or Dell or HP, not necessarily okay? What I really care about is it?

A

Is it x86 for the server do I have the right layer to, or layer 3 connectivity and from a storage aspect? Is it shared storage direct attaches? They have the performance and latency requirements that I need right. So as your again, the consumer of the technology doesn't care about the stuff in the weeds. They really care about these fundamental building blocks.

A

What's the easy abstracted consumption model for me, and so, if I'm at the virtual infrastructure layer, let's take a look at this one, so in this case, I need to make a decision around what hypervisor to use right, what software-defined network platform and then potentially a software-defined storage technology. So this is the fundamental virtualization technology that completely abstract the physical infrastructure from infrastructure which is leveraged by the is component, and so, when I take a look at the ayahs component, what are they doing so in their case?

A

They need to worry about. You know, specifically in that is software, there's, probably some sort of tenancy model, there's probably some quotas for the users and, in essence, there's probably some overall orchestration engine that exists in ayahs which can orchestrate these virtualization technologies.

A

So when I look at that at the eye as layer, these are my requirements of what I'm of what is Asians I need to make in order to be successful here, I demand something from the virtual infrastructure. What I demand? Well, it's actually pretty basic I need the plugins and.

A

Drivers for these specific technologies that I can put into my eye as layer the eye as thing the big King is going to orchestrate all this stuff, so I need to make sure I have these plugins and drivers that work and support the different technologies that exist up here. Okay, so now I'm at the eye as layer. These are. These are the the building block components that I'm worried about, but at the eye as layer do I care about the physical infrastructure, probably not okay, because everything is abstracted to the virtual infrastructure.

A

That's what I interact with and consume now at the ions layer, if, if we work up actually above the eye as layer, here's this generic platform, services team, and so if we look at the consumer or sorry the provider perspective of the platform services team, what are they doing? Well, they're going to take infrastructure, basic infrastructure building blocks and they are going to deploy, maybe they're deploying a full paths environment for their application developers.

A

It could be that or it could be something simple as a kubernetes base technology, where they're going to offer their application developers something or it could be something completely custom that they developed this. The platform services team is a highly generic term, used for a lot of different ways to abstract the complexity of infrastructure, to the application developers these folks up here. They don't really care about infrastructure. They just want to create apps without building blocks. Okay, so back down to the platform services.

A

Folks, they've got paths kubernetes custom, whatever the thing that they demand out of the is the thing that they really want is a very, very simple abstraction model. So they do not want to have to worry about what virtual infrastructure they use. What they do is they issue calls like create virtual machine, create instance, connect to network, apply security, attach block storage right.

A

They just want these very, very simple, API calls and they want a documented API that they can go through and and do this stuff and so again the I as their their their view point is that they need to abstract the complexity of all these other things down here through simple API calls. Now.

A

The interesting thing is: if we look historically, what may have happened is that, if the, if the I as team and below, has not provided the platform services team, the consumption model they want like they haven't, been able to provide this API or it's too difficult to use, or there are too many human beings and manual processes. What happened is that they ended up going out to a.

A

A

And what the public cloud has, if you think about it, is very simple: it has a well-documented API, so notice public cloud, completely abstract, sever, ething below right. We're arguing that the same thing exists here at the eye as layer, we have a simple API: it abstracts all this stuff below. Ok. So what happened is that the platform services team ended up going directly to the public cloud and they bypassed internal IT.

A

So we got to make sure when we're internal IT, we got to make sure that we actually produce or have an IT service that is easily consumable by the teams above us, okay, so there's platform services. Now. The next piece here is the actual application developers. So what do they want? So the consumption model they want and the building blocks that they want are really abstractions even further from the actual infrastructure. So maybe it's like a CI CD pipeline.

A

Maybe it is maybe it's just basic application building blocks and and what do I really mean by basic application building blocks? So, instead of you know going down and having virtual machines that you need to configure or instances or whatnot instead what the platform services team can do is they can actually produce building blocks of for the applications, so it could be Jenkins. It could be some sort of CI CD pipeline that they just want. That may be its database as a service.

A

Alright, maybe it's you know Java an entire Java platform right. So, in effect, what they get are these types of building blocks that completely abstract everything below and what in turn they can do, is they can focus on actually putting those together and building their actual applications that get used by the actual and can user up here?

A

Okay now the interesting thing is: if the platform services team is not providing the application developers what they want, guess what else is available in the private cloud or that sorry, the public cloud here that is all of these building blocks as well, certainly, databases to service and so on and so forth. So, as an internal IT, we have a challenge and our challenge is to create an environment that is easily consumed, but it also takes into consideration. You know, company policy and that sort of thing.

A

This is a collaborative effort and you need sponsorship at each step of the way and you need good communication as well. So thanks for watching and I hope, you found this valuable.

A