Explain Cloud Principles

0:03Hey, friend. Bart Castle here. Welcome to explaining cloud principles. Now, if you've been in the information technology world for any amount of time or if you've been a consumer in our modern world, you've probably heard people talk about using the cloud or going to the cloud, or putting things in the cloud. And indeed, for a lot of us that means that internet directly equals cloud. And that's a pretty good starting point. But it does leave a lot of the other specifics out of that explanation. And so, in the videos ahead, we're going to be making sure that we lock down what a cloud computing service is by looking at the key characteristics.

0:33We'll also be checking out the service models that you'll be running into and the deployment models that deal with how organizations actually put cloud services into action. On top of that, we'll also be talking about the important shared responsibility model between a consumer, like, yourself or your organization, and a provider, like, Google or Amazon or Microsoft or Apple or one of the many other types of cloud service providers that are out there. And so, as we begin this journey, I do want to start right off by saying, hey, keep in mind, friends, cloud computing is not a technology in itself.

1:04And I can't stress this enough. Just in the same way that a restaurant is not a food, a cloud service is not the technology itself. Instead, you want to think of it as a service model for making technology available. Just like a restaurant augments the food procurement process by cooking it and delivering it and serving it to you, a cloud service provider delivers technology services for us as consumers to use and leverage. This is exactly where things get really exciting for the world's businesses and for the world's consumers. Using technology through a cloud service might allow us to help solve problems, improve the business experience, improve the user's experience, or even improve the other stakeholders who might have a vested interest in those efforts.

1:45And so stick with me, friends, as we dig into explaining cloud principles.

0:02Hey, friend. Welcome back to Explaining Cloud Principles. Probably the best place for us to start is to establish what the traits and characteristics that make a technology service really fit the cloud computing definition. Because keep in mind, friends, there are a lot of different layers of technology services that are out there. And some of them fit parts of the cloud computing definition, and a lot of them don't necessarily live on the internet either. So you can see there's a lot of variability in some of our understandings around cloud computing. Best that we iron those out right away. Fortunately for us, there is a US-based organization called the National Institute of Standards and Technology, NIST, who has published an internationally accepted definition of what cloud computing is.

0:39And it forms the backbone of a lot of our broad understanding of what we consider a cloud computing service. So let's start out by grabbing a copy of that. Over here on Google, take a look for NIST cloud definition. And then make sure you grab the one that says "detail final". That'll get you over to the actual published document. It's the 800-145. And if you pull that up on screen here, and then let's make that fit nicely, cruise on down a little bit further, and they jump in, first, by establishing what those characteristics are.

1:09And indeed, there they are-- the essential characteristics. So let's find just a few minutes taking a look through each one of these and how that helps shape our understanding of what cloud computing is. So the first one on here is on-demand self-service. And this is where they're talking about consumers being able to provision capabilities on their own without having to necessarily interact directly with the service provider. This might be done through a store, like, the Google Store, the Play Store, the Apple Store, where you're buying an app.

1:39Or it could be something where you're logging into a web page to purchase and sign up for those services. The key principle is that it does not require a direct engagement with a human or, really, a provider directly on the far side of it. It's something that you could do in your jammies, sitting at home with a credit card and bring those services up, keeping in mind that the cost aspect is not necessarily a requirement here. It's more about the mechanism of administration. And this is directly in contrast to traditional models where Bart and his team of people at the organization would have to choose what services we need, talk to some sort of a vendor directly, draw up a contract and an agreement.

2:15It could spend days, weeks, to months provisioning those services. As a contrast, now we're talking about a really simple, often point and click process, where we're able to procure those services. Also, keeping in mind that even though it's self-service, there may still be contracts that are a part of it. They're just also self-service, where you have to accept the terms of agreement or read through some contract as a part of it. That is all part of the self-service model. And again, the goal here is to ensure that consumers don't have to be tied down from a timeline perspective, waiting to engage with the service provider directly.

2:46And keep in mind here, friends, when I say service provider, I could be talking about a big public provider, like, Apple or Google or Amazon or Microsoft. But it could also be the provider that you work with in your own organization. If your company has a self-service portal for building virtual machines in your company, totally private, regular public users can't use it, that still fits the self-service model. Continuing on after that, we look at broad network access as the second characteristic. And this is really important, friends. We're not saying internet. Notice it does not say internet accessible.

3:17It says network accessible-- so over the network in access through a standard mechanism. So the client isn't really important. It could be through a smartphone, it could be through a full-blown desktop computer, it could be through a laptop, or even some weird kiosk thing that's in between. The point is to keep in mind that you're taking access over some sort of network media. This could happen in your own company's internal networks, where just you and your employees and your peers are able to interact with it, or it could certainly happen over the internet, one of the world's largest networks.

3:48And of course, keeping the mind, too, here, that lots of organizations also possess global spanning networks of their own. So we don't want to get locked down into one specific type of network, just recognizing that the cloud computing services themselves are accessed over the internet or over a private network or some combination of the two in between. One final thing to consider here when we talk about network access is also recognizing that it doesn't mean that it's always only online. You could download a piece of software from a service and then run it locally on your computer or if you're just doing a licensing scenario over the network.

4:23Those all fit this model. So just keep in mind that it starts and is largely dependent at some point of its life cycle on that network access. Moving on down past that, we get into resource pooling. And resource pooling is an interesting concept. This one goes directly back to the principles of virtualization. And I know we haven't really talked about virtualization much here. But the basic idea here is that resources are being pooled together, and they often serve multiple consumers at the same time. They also introduce the term "multi-tenant".

4:54And indeed, this is a safe concept. If you imagine an apartment complex, where there is one building with lots of small different apartments inside of it and then lots of different folks living in those apartments, that's the basic principle they're talking about with resource pooling. Part of the value proposition with pooling is that when a provider buys tools or hardware or infrastructure to run those systems, they're able to buy at large scale and then sell portions of it out to their customers. This is part of the profitability model for them. If they had to buy everything as one-offs for every single customer, it would deteriorate that value proposition pretty quickly.

5:30So resource pooling says that it is a shared set of resources. And again, it is not limited to just public service providers where they're selling their services to private consumers like you and I. It could be, again, in an organization that has a large virtualized data center where they're making different pieces of that infrastructure available to their users or their departments within the organization-- again, across the network, ideally, going to be driven and administered using some sort of a self-service model. And keeping in mind, friends, that we're trying to say that this is an inclusive model.

6:02It needs to have these five characteristics. But they may also have more options beyond that and still fit that cloud computing model. Continuing on down, after that, we get into rapid elasticity. And this one is really special and unique. And it goes directly back to the resource pool in question earlier on. The idea behind elasticity is to simply say that when we're trying to figure out what we need to deliver a system or a service, just imagine the last time you wanted to go shopping for a car or went shopping for a home. You had to take a look at your own specific needs and what those services and our availability out there, how they actually solve that problem for you.

6:39The problem is sometimes your family gets bigger or your auto requirements change over time. And this can leave us in a situation where what we chose at one time is no longer the best choice. For systems in the technology world, a lot of this has to do straight up with capacity planning. Do I need five servers? Do I need 10, 20, 30, 100 servers? And consider, too, that for a lot of organizations, their work, the actual load that they put on their systems, it might be driven by different time of year performance statistics.

7:10So imagine shopping at a holiday season or tax season or end of business quarter. Those are events that happened that require a lot more capacity. But they don't last all year long. And so rapid elasticity focuses on the interest in that we be able to grow the service and then shrink the service back down when we need to based on whatever demand is happening out there. So two important principles here-- how much demand drives how much capacity? If your demand is variable, your capacity needs to be variable as well.

7:41And of course, if you're working with a public service provider, they own huge amounts of infrastructure, and lots of us are all using it together so the ability to grow and shrink each customer, it's an easy no-brainer for them. But if you are in an organization that owns all of the infrastructure, well, that means your IT and your service teams, they have to be concerned about owning enough capacity to meet whatever demand the organization is putting on it. And this is usually where the value proposition gets a little murky for in-house, on-premises data centers and the provisioning and management of those services over time.

8:11So five services so far, we're down to the fifth one. So far, we talked about broad network access, we talked about self-serviceability, we talked about pooling of resources, and then rapid elasticity. So the very last one on here, measured service, is really one of the most important value proposition pieces of it. It says that we should be able to optimize resources and use some sort of a metering capability to understand how that service is being used and furthermore, pay as a consumer for only what we've used.

8:43So this is very similar to the way that a lot of us get power from a power service provider. We're not paying a subscription flat fee every month. Instead, we're paying based on how much we actually use. So in the wintertime, my house needs a lot more heating energy. And I spend a lot more of my electricity to produce that. In the summertime, it could be air conditioning that's kicking on. And in the in-between months, we don't pay as much because our demand is not as high. Now, there's two key principles to keep in mind when we talk about measured service. First of all, as a consumer, you're paying for only what you've used.

9:15And this is usually a good model as long as you maintain it and keep that right visibility. The other side of it is that if you're going to be a service provider, you have to have sophisticated mechanisms to identify what has been used. And of course, if you're not Microsoft Azure or Amazon Web Services out there with a huge sophisticated toolkit, it means that your internal IT department have to come up with a way of identifying what each department has used on those shared resources, especially if it's flexible and dynamic and self-service.

9:45How are they going to keep tabs on it? So this implies additional sophistication in the services around delivering and managing whatever has been built in the back room. And so just looking back across the five key characteristics, self-serviceability focuses on the ease of access. It ensures that there's a simple on-road and map for selecting services, using them, and managing them. This could be through a web page or through a simple sort of app. The other part was broad network access. We said that it could be internet-based or it could be some internal private network or some hybrid version of that in between.

10:18The point is that we're going across the network to access or work with the services or to instantiate them. You might download something and use it. As long as it starts its life on the network or has some dependence on the network, that satisfies this characteristic. The third one, resource pooling, was important because of the sharing and the scalability that comes with it. If a vendor can buy a large amount of infrastructure and then share it amongst all of its tenants, this is going to improve the value proposition for the vendor and also for the consumer. Economy of scale is a big factor in the cloud computing world.

10:50The third one-- or the fourth one-- down there, rapid elasticity, deals with that principle of being able to grow and shrink the services based on the demand. Now, this is a really important characteristic when we consider how unpredictable a lot of workloads are out there. And then the very last one, measured service, goes along with all of these pieces. Because if you're a service provider and you're going to let people build things on their own and then run them for certain amounts of time, you're going to need the right sort of monitoring and metric information to identify what someone has used, how long they've used it, so that you can charge them for it.

11:21And from a consumer's perspective, it means that we're only having to pay for what we've specifically used. So as you begin looking at services in the technology role, ask yourself if it fits these five key characteristics. Without one of these characteristics, odds are it's not really specifically designed as a cloud computing service. And it's certainly a technical service, but it doesn't fit the cloud computing paradigm. And so now that we have an understanding of these characteristics, it prepares us for a look at some of the service models that we're going to find in the cloud computing world, like, infrastructure, platform, and software as a service, keeping in mind that in the end, it's all about the relationship between the consumer and the provider-- what we're having the provider do for us and what sort of controls are left for me as a consumer.

12:02So stick with me, friends. And I'll see you there.

0:02Hey, friend. Welcome back to Explaining Cloud Principles. Now that we have a good understanding of the characteristics and traits that make a service actually fit the cloud computing definition, we can begin talking about some of the responsibilities that get exchanged as we look at the provider-consumer relationship. Keeping in mind that in this scenario right now, I am the provider-- I have created this training content for you-- and you are consuming it. You're the consumer in this relationship. Similarly, if I go and I use Gmail, Google is the provider and I am the consumer. Alternatively, if you're in your own organization and your IT department makes platforms available for your developers to use, they become the provider and the developers become the consumer.

0:42So as we look at this consumer and provider relationship, we recognize that understanding where those responsibilities lie between those two parties is the first part of the story. But also keep in mind that there are responsibilities outside of just the consumers and the providers that we should be aware of, as well. And so, fortunately for us, NIST defined a Cloud Reference Architecture, which is very useful in keeping this conversation moving. So let's actually go take a look at that real quick. Over here on the web, if you take a look for NIST cloud reference, you should be able to find the "Reference Architecture" itself.

1:15It is another document that they produced a few years back. And if you pop that open in your browsers or in your reader there, cruise on down into the table of contents and find the first section here about cloud computing reference architecture. Cool. And so, indeed, this is the diagram that I wanted us to take a look at. What they're describing here are the roles that exist within the cloud computing role. And you heard me talk about one already, and that was the cloud provider. They are the one that's creating and delivering the service. And take a look at all the different facets that they're responsible for.

1:45Indeed, there's a reason why they are the biggest chunk on this picture. They take on a lot of that burden. And for us as consumers, all of those things the provider is focusing on, they are things that we don't necessarily have to focus on. You can also see them calling out the three different service layers-- Infrastructure, IaaS; Platform, PaaS; and Software As A Service, SaaS. So the provider is responsible for all the service management and delivery aspects of running whatever cloud service it is. And we're being generic here, friends. It could be a large infrastructure service, like Amazon Web Services, or it could be a software as a service product, like something you might buy in the Google Play Store.

2:23The point is, though, that that provider responsibility starts and ends with the delivery of those services. The other role you heard me describing was cloud consumer. Consumers are there as the person that creates the demand for whatever service out there has been created by the providers. The other two roles that are on here, the broker and the auditor, are important to keep in mind conceptually. A broker is someone who facilitates access to the service. You see them talking about intermediation, aggregation, and arbitrage. Let me see if I can scroll down a little bit there.

2:53The point is that they could either help you use a service, like a value-add reseller might do. Someone like a car salesman might help you buy the right car. They didn't build the car themselves. They're just an intermediary layer that helps you procure something appropriately from a provider. So brokering is something that your organization might do directly as a service to other cloud consumers, or you might have divisions within your IT department that play that brokering role. It's just important to recognize that for a lot of us, we may work through a broker to obtain cloud services, or we may seek the help of a broker to help augment the delivery of our cloud services.

3:29So an important principle to add to this little melange. The other role they have over here is cloud auditor. And it's great-- it's by design, friends. The auditor is not the provider, not the consumer or the broker. Instead, it is a separate entity, which is all about maintaining and measuring the quality of, the compliance, the security-- indeed, whatever it is-- the congruence to some sort of standard. So the auditor lives outside of this process and says, how is this interaction happening? To what degree is it being executed? And to what level does it meet a specific expected standard?

4:03So the auditors are on here to help play this quality assurance and quality control role, and they are specifically designed to not be the provider or consumer. This is that intermediation-- that disintermediation, I should say-- separating them from the directly-invested parties. It also ensures that they can be on the side of the standard, and not one of the actually consuming or delivering parties. And that brings us down to the very last role on there, the cloud carrier. And this is possibly the most important. I like the way that they've depicted it here. Notice that it goes across all of the other roles.

4:35The point behind this is to recognize that, if you're the consumer, you are dependent on some sort of a network to use the cloud service. Similarly, if you're a provider, you are dependent on a carrier of a network of some sort to facilitate access to your consumers. And of course, the brokers and the auditors that use these services, to augment their delivery or measure their quality and their compliance standards-- they all depend on that carrier and that network, as well. And so this helps us really understand that there is a tightly integrated role between all of these different players.

5:07The provider depends on the carrier to work with the consumer. The consumer needs the broker and the auditor to measure the quality of the service used by the provider. And the best that we can handle all those expectations, the better we can ensure the delivery of the value proposition itself. And so to get a little more specific here, we understand that there's these different actors and roles. The last piece is to recognize that there are different layers of that responsibility that's being exchanged across different service models. And so let's jump over to a slightly different look here.

5:37So this gives us a chance to take a look at the shared responsibility stack. Indeed, we're talking about different layers in which this consumer and provider breakdown might be happening. Recognizing that in traditional IT, when you owned all of the infrastructure and delivered it yourself, you owned every single piece of this and you had control over, and full responsibility for, the delivery of every one of those components, from the physical network up through the storage and the virtualization layers, including the operating system and all of the application components, the data and the authentication layers that allow people to actually use those services.

6:13So this is an important principle to keep in mind, because as we take a closer look at some of the other service models, like software, platform, and infrastructure as a service, we're going to see a different breakdown across these responsibility stacks. So it's a great primer to get us into the right layers of conversation to talk about, really, where specifically things fall in each one of those service models. And so just to kind of recap what we've discussed so far, as you begin looking at the world of cloud computing, we recognize that there is an ecosystem of roles and actors. And NIST defined a "Reference Architecture," which helps us understand and describe the different roles that are out there.

6:48The two most basic ones are the provider and the consumer-- whoever creates the service and then whoever's purchasing and using the service, just like me as the provider and you as the consumer in this video scenario. On top of that, we said that there's other auxiliary roles, like a broker or an auditor, who either helps in the delivery of, the selection, or the maintaining of those services, or the measuring of quality and security attestations or compliance standards through the auditor. We also discussed the importance of a carrier and how all of those other roles are dependent on what the carrier does and their availability and proficiency at delivering access to the provider and consumer world of cloud computing.

7:25In the end, we also took a look at the basic shared responsibility stack, where we went through all the different infrastructure layers, from the hardware, up into the software and virtualization layers, and then into the data, and the people and authentication layers, as well. These are going to be important models to look at in the next couple of videos, as we take a look at the breakdown between software platform and infrastructure as a service models, and how it affects each one of those shared responsibility layers. So stick with me, friends, and I'll see you there.

0:02Hey, friend. Welcome back to explaining cloud principles. So far, we've established the characteristics and traits that make a service fit the cloud computing definition. And we've also talked about some of the actors and roles that exist in the cloud ecosystem, like the provider, consumer, auditor, broker, and the carrier. This led us into a conversation around shared responsibility. And that's exactly where we're going to pick things up, by looking at the three different service models-- infrastructure, platform, and software as a service-- and how that responsibility shakes down across each one of those. In this first video, let's focus on maximizing control for the consumer by using infrastructure as a service.

0:37And so jumping right on in, we recognize that with infrastructure as a service, when we say that we're gaining more control, it's because the provider is leaving more aspects of this administration to us as consumers. So in infrastructure as a service, they're mostly focusing on delivering it up to the virtualization layer. So this means they're running the data centers. This means that they're out there dealing with the physical infrastructure-- the power, the actual systems, and the racks that are out there, all the fans [WHIRRING] blowing in the data centers out there. Those are all directly the provider's responsibility in most of these scenarios.

1:10Keeping in mind again, friends, that when I say provider, it could be big public providers or it could be somebody in your organization, a technology team that delivers these services for you. On the flip side, then, consumers are left with the ability to administer all of these other layers on top. And this is where that maximizing of control comes in. So this implies that, while the provider is creating the virtual infrastructure for us-- this would include things like the hypervisor, as well-- it means that us, as consumers, can then configure the virtual infrastructure that lives on top of it.

1:43This is going to mean creating virtual machines, creating the virtual network, controlling the IP addressing, the routing of traffic, creating gateways and ingress and egress points. And it also means that we're going to be able to control how we protect those infrastructure components, as well. So I might be creating a firewall rule and then telling the provider to implement that rule for me. In the end, this is a great example of how that shared responsibility works. As a consumer, I choose what traffic I want to allow, but the provider is ultimately responsible for following my instructions.

2:16This goes back to that self-service principle that we were talking about previously, as well. In order for this to work at scale for millions of customers all over the world, providers need a self-service way of allowing this relationship to exist. Furthermore, it also means that for a lot of organizations that have concerns around maximizing control, it means that they definitely still have control over some of the biggest important parts, like the application, the data, and the authentication and authorization layers, as well. Indeed, for a lot of them, they may pick up the existing tools they have in their data centers and just plot them directly down using a lift-and-ship model.

2:52And this allows them to basically keep a lot of the same systems, while simply swapping out some of the provider-added value that goes with using an infrastructure as a service. So to illustrate this just a little smidgen, let's take a look over here at Amazon Web Services, where I've got this pulled up already. And I am taking a look at AWS's virtual private cloud interface. This is basically their virtual networking service. You would use this service to build the networks that you want to use. And that would include defining your virtual private cloud, like these are the high level container.

3:24The subnets-- and those are going to be like the small IP subnets where you could actually run virtual machines. And then it also supports things like creating the routing tables and the routes to control where traffic move between your different endpoints. On top of that, you see internet gateways for selectively allowing networks to access the internet. Or if you look further on down here, they have things like NAT services. They also offer, even further on down, virtual private network services. So all of these are configurable virtual layers on top of the infrastructure that AWS is offering.

3:56You're going to find comparable flavors of this in Microsoft Azure and in Google Cloud, as well. And so in the end, friends, when we talk about infrastructure as a service, it's all about maximizing the layers of control that the consumer is able to effectively administer. Now, this means that the shared responsibility model has consumers depending on service providers to manage the underlying infrastructure, while we get to configure to a high degree on top of it. This is going to include things like the virtual machines, configuring the virtual networks, configuring the routing, managing the firewalling of traffic, and of course, managing all of the operating system, application, and data layers that live on top of it.

4:35One of the most important principles to ask yourself, if you're going to begin studying for something like the Cloud Essentials cert, is to imagine what maintenance activities this is going to require of you. It means that, as a consumer, I'm not going to be patching and managing the hypervisors. I'm not going to be dealing with firmware on the servers. I'm not going to be handling power redundancy for the generators. Those are not concerns for me. As a consumer of infrastructure as a service, I will care about writing firewall rules. I will care about patching the operating systems, choosing what virtual machines I want to run, turning them on, turning them off, managing their survivability, and of course, all of the other application data and authentication layers that live on top of it.

5:15One of the last things to keep in mind here is that when we talk about shared responsibility, there's often multiple different layers of administration. I will need permission, as a consumer, to build resources in a cloud service provider's environment. This is different than needing permissions to log into a Windows domain that might be running in your cloud service provider's world. So keep those two worlds separate-- the service provider-level permissions for creating cloud resources and then all of the application-level permissions that also go into using those services.

5:46In later service models, coming up next, we'll be talking about how that layer begins to get pushed more and more off to the provider, leaving less controls for us as consumers, but remembering that this is often desirably so. So stick with me, friends. In the next lesson, we'll take a look at platform as a service. I hope this has been informative for you, and I'd like to thank you for viewing.

0:02Hi, friend. Welcome back to explaining cloud principles. In the last lesson, we talked about the infrastructure as a service model of cloud computing and how it focuses on maximizing control for the consumer. Indeed, keeping in mind that the provider is focusing on delivering the virtual infrastructure, and then it's up to us as consumers to decide what sort of virtual machines, and networks, and systems, and services we want to run in those environments. Moving into platform as a service, possibly the most important and complex layer of all the service models, we are pushing burden off onto the cloud service provider.

0:32And we're saying, largely, we don't care about the underlying infrastructure as much. We care more about the functionality of the applications, and the data, and the security, and management of those layers, instead. And so as we get into platform as a service, I usually try to get people thinking about three key aspects of platform as a service. And the first one there would be build from pieces. So in almost every example of a platform, they are going to be giving you some sort of rudimentary components that you can use to build larger functionality from.

1:05Now, this might be a really simple way of just assembling components on a page, like drag and drop wizards or workflows. Or it could be something extremely granular, like using a system developer's kit, where there is code to allow you to shortcut some of the administration process. The point is, just like a box of LEGOs, they're giving us pieces that we can build from. The other key distinction I try to get people to think about are using APIs. Now, we're going to use APIs all around the cloud computing world. But for a lot of platform as a service offerings, it could be the only thing we talk to is an API itself.

1:39This implies that you could be using an API to create and build functionality, or you could be using it to access data. The point is that you don't get to manage the infrastructure in the background. The provider is giving you an API to talk to and interact with that you might be able to use as a part of building those pieces. One of the final concepts on here, then, is the notion of using containers. And there is a lot more to say about containers. But the basic principle behind a container is that it's a lightweight-style virtual machine that focuses more on providing libraries and platform functionality for a specific type of application or a specific language of code.

2:14And so as we look at the shared responsibility model and as you look at examples of platform as a service, look for these patterns of being able to build from pieces, using APIs, and then leveraging containers to shortcut the application development process. Indeed, for a lot of organizations, platform as a service is largely targeted at the consumers or at the developers themselves. And so as we take a closer look at the shared responsibility model, with platform as a service, the name of the game is all about focusing on those application layers.

2:45So this means that we're extending all the way up through the operating system and all the way up into the runtime and middleware in allowing the provider to handle most of that infrastructure. Now, keep in mind here, friends, that when we have them managing the runtime and the middleware, often, the client or the consumer still has the ability to choose those environments. For example, if you're using an Azure function, they have Python functions. They have functions for .NET. They have functions for Go and for Ruby. So you're still getting to pick what flavor of platform.

3:15But largely, the developer can just focus then on, what does the application do? And then further deal with the data and the administration of the people, authentication, and authorization layers. And you can see that we just took a huge bite out of the shared responsibility stack [GROWLING] and we passed a lot of that off onto the provider. This is what I meant by it being possibly one of the most important layers or service models within the paradigm. Infrastructure focuses on control. Platform focuses on increasing value by allowing us to customize and modify with the least amount of effort.

3:50Going back to those principles I used earlier on, building from pieces, using APIs, and leveraging containers. So as you look at the platform-as-a-service model, we recognize that we're increasingly dependent on the provider to deliver a high level of quality. And as I described with infrastructure as a service, on the exam, you're going to want to be thinking, what sort of maintenance does this leave for me? What sort of day-to-day actions am I going to be dealing with? So with platform as a service, I am not going to be designing the virtual networks, necessarily. I'm not going to be running a virtual machine, per se, or patching the operating system.

4:23Most of that is going to fall directly on the cloud service provider to deliver that part of the functionality. What I am going to be concerned about is choosing the right runtimes, choosing the right flavor of the platform, and building from the pieces that the service provider has offered me. I am going to continue to be concerned about the data security, and I am going to continue to be concerned about the authentication and authorization layers. And so platform as a service gives us a wide array of opportunities. For a good example behind this, one of my favorite platforms over the years is WordPress.

4:55Now, you can run WordPress blogs on your own systems. You can go out there and build a Linux server out there, install Apache and MySQL on it, and get that up and running. Or WordPress.com also offers a hosted website flavor. So this allows us to just jump straight into using the application without having to manage any of the other infrastructure components. Indeed, if we take a look out here on the web-- let's jump over to WordPress.com. Yeah, you can see that WordPress.com offers a couple of different options. You can see they offer blogs, websites. They have domain hosting opportunities here, as well.

5:28And they do also offer managed self-hosted options, as well. So in this way, WordPress is making it easier for you to get down to the part you really care about, which was running the blog or delivering the website that you're trying to use and less on buying servers, choosing the operating system, installing all of the components. So this is where that principle of building from pieces comes from. They are giving you the pieces you need so that you can jump directly in and begin using them. Furthermore, as you get further into this paradigm and start using your WordPress site, they have other modular plugins that are available there, as well.

6:02This allows me to go in and choose things like adding a shopping cart or adding some other pluggable authentication for working with Google or working with other types of authentication providers out there. To get to be maybe a more pure platform model, if we take a look over on Amazon Web Services and take a look for Lambda, Lambda is a code execution environment that allows me to go in and create what they call a function. And I can write these from scratch. They support a variety of runtimes that are available in here.

6:32And what I'm going to do then is simply plop down some code and have Amazon run it for me in the background. So in this way, I'm shortcutting the process of using the platform and building the platform, and just going into the process of actually delivering the applications and the functionality itself. And so just to summarize, friends, platform as a service moves the responsibility model even further up. We're pushing more burden off onto the provider, which usually means a good, strong value return. And as consumers, we're largely focusing on what we can do with the platform components.

7:02Keeping in mind that they're largely focusing on giving us things that we can build from, pieces to use, or APIs that we can interact with, or offering a container execution environment where we can take already containerised application code and have them rune it for us. All of these share that one key theme, in which we are trying to reduce the effort required for developers to get their applications up and running. So as we begin looking forward into the next model, software as a service, keep in mind that for a lot of cloud computing services, they're built on these other layers.

7:35There are many platforms out there that run on infrastructure as a service. Similarly, as you get into the software as a service layers, you're going to find them also leveraging platform and infrastructure as a service, as well. So remember, these layers build up as you get into the more complex services into the software as a service world. So stick with me. In the next lesson, we're going to take a look at the penultimate tier, the one that allows the consumer to get the most value with the least amount of effort, and that's software as a service. Hope this has been informative for you, and I'd like to thank you for viewing.

0:02Hey, friend. Welcome back to Explaining Cloud Principles. So far we've talked about two of the three service models that NIST defines in the cloud computing world. That was infrastructure and platform as a service. In this video, let's take a look at the third, final, and penultimate tier of cloud service delivery, software as a service. And keep in mind, friends, as we move through these different service models-- from infrastructure, to platform, and now to software-- the key theme is pushing responsibility off onto the provider. And so, with software as a service, we see the maximum amount of offloading occurring. Here, take all of that.

0:33And so, as we take a look at the stack, in software as a service, the provider is now responsible for an increasingly larger number of layers. So we're moving all the way up past the runtime and middleware of the platform, moving up into the application, and then even into some of the data storage and management elements here. And that means, for us, as consumers, we are responsible for really just configuring the application and storing our data in it. Keeping in mind that it doesn't mean that we have the ability to control the selection of applications. We may be able to choose features that are available, and all that kind of fits in the configuration realm.

1:06So here we are as consumers, and the providers then are handling the most layers across all of the other service models. Keep in mind, too, that data is kind of interesting, because data is something that both us are responsible for. I might be storing it there, but I get to choose things like permissions models around it-- who can access and work with the data. And then I'm trusting the cloud provider to keep that information secure to the expectations that we've set. Another kind of aspect of this is to keep in mind that there's a few different variations on the software as a service theme.

1:37The first one will be simply not having to install software locally on your computer. So if you can do it directly through a web browser, that might be one option that you're doing. OK? And a lot of great browser based applications are out there. On the flip side, many browser based applications, like Google Gmail or Google Apps for Business, also often have a mobile app that could be available as well. So you could go into the Play Store and get the Gmail app and install it, and that would be the same flavor of software as a service. The client is then changing a little bit.

2:08Keep in mind, too, that, when we get into talking about browsers versus apps, there's also this other aspect where we're thinking about thick PCs-- regular desktops and laptops as well. And so the ability to support all these different platforms in a very flexible fashion is a great hallmark in the software as a service model. The final one that I want you to think about, too, is the notion that we might just be buying licenses directly through a cloud service. So maybe it's not so much about using it in a web browser, but rather being able to use a subscription or purchase a license where you can download the software, and then use it locally on your computer.

2:42In the end, friends, because software as a service pushes so much responsibility off onto the provider, it leaves a very strong value proposition for those us who are consuming those services. The other big thing to recognize is that, with software as a service, a lot of these providers are going above and beyond what we might be able to do deliver directly doing this in our own environments. Good example would be like Microsoft Exchange, is an enterprise email service that we've been running in our data centers for years. I used to be an exchange administrator. And now most of the clients I work with, they leave all of that exchange administration to Microsoft Office 365, a fully cloud based version of that server service, and Microsoft is running it for them in the background.

3:21And so the beautiful part is they get to have these enterprise tools. They get to reduce the amount of effort. And we can count on good old Microsoft, or Google, or our service providers to leverage their expertise in running and operating these systems. Because even on my best day as a good exchange administrator, I am still not the support infrastructure at Microsoft. And if I have to escalate a ticket, guess who I'm calling? I'm calling that provider. And so, often leaving it to their specialized hands, and being able to leverage things like a global infrastructure, where the exchange mail is now available in China, in Australia, in Europe, in South Africa, in Brazil, in North America, all over the world through infrastructure that Microsoft is delivering for us.

4:03And so let's spend a few minutes chatting about some other examples here. Some of you might be familiar with the Google Apps for businesses. And that would include something like Gmail. Gmail is a service that has grown a lot over the years. It used to be just for basic email. But now it has hooks into the other calendar suites, reminders. You've got Google Hangouts that's a part of that environment for messaging as well. And the browser based version is one option. And, like I mentioned, I can go and get that same application on my smartphone. Oops, there it is right there. So I have all of that mixed mode functionality.

4:36And here at CBT Nuggets, the rest of our company is using the enterprise version of Google. And so this is a great example of where we see tiers of service in different subscription levels that are available. If you're just a regular consumer and you want to use Gmail, there is a class of service that's freely available for you to use. Just provide some identification information and go from there. Or if you're a company, like us here at CBT Nuggets, we're actually paying for an enterprise support plan and subscription service that allows all of our hundreds of employees to use the Gmail service and some of the other enterprise tools, not to mention their document editors, like Google Docs, the spreadsheets, there's PowerPoint variations on that.

5:14And of course, as we consider some of the other alternatives there, we see products like Microsoft 365, which, again, offers a variety of options for how to interface with their service. It could be browser based. I have the mobile version of Microsoft Word on my phone here as well. And then, on top of that, I also have Cloud Storage, like things like OneDrive that's available. So you're talking about not just one simple cloud service, but an entire suite of services. And indeed Office 365 is very sweet and Google Apps for businesses is also a very sweet suite, and we love the fact that we can pick and choose a la carte which parts we need for each organization.

5:50These are all great hallmarks of the cloud software as a service model. One thing, to kind of pause here, too, is to recognize that, in most of these scenarios, even though you're doing it self-service, there is still some sort of a contract that's happening in the background. When I sign up for Office 365, I'm agreeing to their terms of service. And in there is some sort of expectation that's exchanged around what Office 365 will do for me, and what is expected of me as a user of their service. And so that principle of a contract, being fully self-service available, just a little checkbox that I can choose, is, again, another principle of software as a service.

6:25And one final aspect is to recognize that, if I'm using this product for a while, and it doesn't meet my needs, I can change the subscription. I could return it completely and stop using it, or I can make some other transformation and maybe move those services into some other flavor that Microsoft has available. So the ability to move and port between these services may also be another feature that's important to you and your organization. One final one that I use a lot here at CBT Nuggets are the Adobe Creative products. Indeed, when I'm doing my little whiteboards that you just saw me drawing on a few minutes ago, that's in Adobe Illustrator, and I edit all my video in Adobe Premiere.

7:00All of the licenses and the software that we use for that are available through something called the Adobe Creative Cloud. And the cool thing is they actually have a little like client application, which is this little app right here. And so I install that on my desktop-- oops, come back here. Yeah, so I install it on my desktop computer, and it gives me a gateway into their services. And, from here, I can go in and take a look at all the software I already have installed. Or if there's something new that I want to try, I can jump over here and take a look-- like, see here's Premiere Rush that they have available. I can install and download that.

7:31They've got some other cool 3D audio and 3D video editing tools here as well. And it's all about that licensing model. And so, just to kind of recap, friends, what we've talked about today is probably the most important and simplest to obtain software as a service model of all the cloud platforms that we've talked about. With infrastructure, it was all about maximizing control, giving us the most layers of control. With platform as a service, it was about a sweet trade-off between allowing the vendor to manage some of the more important layers of the infrastructure, and then giving us, as software developers, control over all the other components on top of that.

8:06Keeping in mind that we were able to build from pieces, leverage APIs, and leverage containers to run our workloads in. In this last video, here, where we were talking about software as a service, we said that we're focusing on ease of use, being able to obtain cloud services, either directly through a web browser, through a mobile application, or being able to leverage subscription and licensing models, like the Adobe Creative Cloud, where we're downloading the software and running it locally, but the licensing is still variable, flexible, and can be turned on and off. Which, again, fits some of those themes when we were talking about the key cloud characteristics.

8:39Now that we've talked about the service models and the core characteristics, in our next and final video, let's chat a little bit more about some of the deployment variations. As you heard me say, you can run cloud services in your own data center, and you can run them in the cloud as well. Heck, you can even dance if you want to. And connecting the dots together is another option with hybrid. So stick with me in the next lesson as we take a look at cloud deployment models. I hope this has been informative for you. And I'd like to thank you for viewing.

0:02Hey, friend. Welcome back to Explaining Cloud Principles. So far throughout this video series, we've been focusing on dispelling some of the myths and misunderstandings around what a Cloud computing service is or is not. It was very helpful for us to check out the published standards that NIST puts out there. This led us to looking at the cloud definition and their "Reference Architecture"-- the characteristics, the service models, the actors, and the roles that exist out there. And in this last video, let's take a look at one final additional aspect, and that is the deployment models that we'll find. This would be private, hybrid, public, and community cloud.

0:34And the first thing to keep in mind is, as you look at the deployment models, take it out of your head. It's not a question about where the services are running. Instead, it's more about the audience and the level of exclusivity. Similarly, we can go back to NIST and make sure we have that "Reference Architecture." So jumping on over to the web again, if we take a look for NIST Cloud definition-- there we go. And grab that same document. Yep, pop that open. There we go. And then cruise on down into I think it's like on page five. Yeah. There we go, great.

1:04Passt the Service Models and on down to Deployment Models. Here, you can see NIST taking a stab at defining private, community, public, and hybrid cloud. I want you to have this handy, specifically because the verbiage they use here is better than the common understandings that a lot of people come to. When we say private cloud, first of all, it does not mean it's running in your data center. Instead, they're saying that it is talking about use by a single organization. So exclusivity is the key trait that they're focusing on there. So just like in a public bank, if you were using a bank in your own town, that is a public institution.

1:38But when you put money into your account, it doesn't end up in my account. It doesn't end up in your neighbor's account. It has exclusive levels of access for your use of that service. So you do want to recognize that private cloud is about exclusivity. They're also saying that it could be owned, managed, or even operated by that organization, a third party, or a combination of them, both on or off-premises. So we're really saying that, again, it's not about where it lives, necessarily. It's about that level of exclusivity. And so as I take another look at this, I'm going to do a little bit of drawing here.

2:10With private, the focus is on exclusive. That's the key term that they're talking about here. The other big thing to recognize is that, typically when we say private, there's often an enhanced level of security to it because of the level of control that's given to the consumers themselves. Keeping in mind, too, friends, that were also still contrasting this across these different service models. So the deployment model deals with the audience and the exclusivity, whereas the service models dealt more with the shared responsibility with the provider. The next layer that we look at is the one that many of us have come to know as basically internet-accessible, and they're talking about the public offerings here.

2:47The general public is the general term that they're trying to use for this part of it. And the basic principle here is that with just a credit card and basic internet access, you can go and obtain this public services. And they're meant to be broadly accessible. This is an interesting contrast here, friends. Most of the time when we say public cloud, we're pointing out that you don't really need to meet some specific use case scenario to leverage their services. On top of that, you may recognize, too, that there are going to be levels of privacy and exclusivity that still exist within the public cloud.

3:17It's not a free-for-all buffet where everybody can use your data and access your tools. Instead, we're pointing out that it's generally available for most organizations to leverage. The final one that they have on here is hybrid. And this stitches multiple ones together. Hybrid is saying that it's a combination of private, public, and then possibly the community model, as well. Hybrid is also probably going to be the most common one that you will run into. And the value behind it is very strong, because it allows organizations to choose which flavor of service and deployment scenario is best suited for them.

3:51So you may see them using a public software as a service provider for their email and their communications mediums. And then you may find them using portions of an infrastructure layer that they're running in their own data centers or maybe in a colocation facility. The point is that as a consumer, we're able to a la carte choose which types of services and where we want to run them. This is exactly where that hybridization concept comes from. On the exams, you would want to keep some of those key terms available. If it's highly exclusive, that would be the private model.

4:22With the public model, it's about general accessibility. And with the hybrid model, it's about combining one or more of the other deployment models that we've talked about. And that brings us down to the very last one, community. Community is an interesting beast, because a lot of us don't operate in a community world. The key term that they use there is for a specific demographic. Big old were there. And when we say that, we're talking about a very specific niche audience that has a common set of shared interests. That's the other big term here-- shared concerns.

4:57One great example of this would be a lot of the government flavors or the highly secure versions of some of the public cloud providers. For example, Amazon Web Services has something called Gov Cloud, and Azure has a government flavor, as well. And if your organization does not have the right levels of certifications or quality and control expectations-- indeed, often a lot of them are invite-only scenarios-- they won't be able to leverage those services. So as a community offering, you're focusing on addressing specific concerns, often around compliance with security.

5:27But it's not limited to that completely. You may also find that a community service may be specific to a research scenario. You may also find that they use a common set of data that might be shared between them. You look at a lot of the artificial intelligence and machine learning offerings that are available out there, community clouds focus on that specific set of shared interests and concerns. And so wrapping all of this back together, we see that the NIST definition is not as simple as just saying where the services are running. Private is all about exclusivity.

5:59Community is all about meeting specific organizations that have shared concerns. The public cloud is all about general public usage. And then hybrid cloud is a composition of two or more of the different distinct cloud models. And so in the end, as an organization choosing what cloud services to use, we want to start first by identifying how much control we need to maintain. Some of this might be totally up to our druthers to decide. Others might be dictated us by the industry that we work in, by the geography and some of the national expectations around security and quality, or simply the data that you're working with, and maybe the audience or the nature of the service that you provide.

6:37Infrastructure maximizes our control. Platform allows us to develop and customize to a high degree of control, while still getting a good value return with the provider handling a lot of the administration. Software is the easiest on-ramp, but it also limits the options around how we want to control those particular deployments. The other aspect was deciding what deployment models are going to be most appropriate for us. Can we use publicly hosted data in shared data centers? Do we need to use private resources or need a higher degree of exclusivity of control?

7:08On top of that, we also looked at the hybrid and community models and how they allow us to blend together different deployment options. And if it's a very specific niche need, or you meet a certain shared concern model, like security or compliance, you may find yourself using some of the special community secure cloud versions that are available out there. In the end, friends, by using the NIST cloud definition document and the "Cloud Reference Architecture," we ensure that our technical teams and our operations and business support teams are speaking the same language about using Cloud services so that when someone says private, and they really mean running it in their own data centers, we're not going to be confused and walk into that trap.

7:46On top of that, it also leads us down a conversation about those key characteristics. If it doesn't possess all five of the characteristics, odds are, it may not fit the cloud computing definition. And in the end, friends, the whole goal here is to make sure that organizations understand what they are getting themselves into as they begin sharing responsibility. And I'll tell you right now, friends, the idea of sharing responsibility-- it's not new. It's not a exclusive cloud computing concept. I've been working with customers who run in data centers, like colocation, or managed service providers for years and years way before the cloud service term was ever coined.

8:19So the idea of sharing and outsourcing resources is not new to businesses. And indeed, for a lot of us, when we first start talking to businesses about cloud computing, coming at it from an aspect of outsourcing may be the best inroad for helping them understand what's actually happening. It is a trade-off in control and responsibility. And ultimately, how we break down that control and responsibility directly affects the value, the maintenance, and the ongoing relationship of what we get from our cloud service providers. And so stick with me, friends, and hopefully in future lessons, I'll see you out there as we continue digging further into the wide world of cloud computing.

8:51I hope this has been informative for you, and I'd like to thank you for viewing.