Cloud Computing and AWS


Traditional IT and Cloud Computing

Legacy IT/ Traditional IT

Companies will often lease space in a facility that’s owned by a provider that’s often known as co-location. Now, alternatively, you might actually own the entire data center yourself. If you’re a larger company, then you might have built your own data center. Within the data center, whether you own the actual building or not, the actual IT equipment is stuff you own. So you have to purchase that as a company and then operate and manage that equipment. This model of our pricing is very capital intensive. It takes a lot of money. You need to buy all of this equipment, maybe even the building that you’re putting it into.

Typically, you would then connect your corporate office into your data center and your own IT staff will design, build, operate and manage all of this equipment. So not only have you got lots of capital expense in the infrastructure within your data center but also have a lot of stuff because you’re managing absolutely everything. If you also own the data center building, you even have to supply all of the staff for securing entry to the building, perimeter security, and all those types of things.

Costs

Definition of Cloud Computing

Now, whether you’re aware of using cloud computing or not, you are actually using it every day. So we’re all using services like Facebook and Gmail and Dropbox and many other services that are delivered from the cloud.

Cloud vs Traditional IT

Cloud Computing

  • On-demand, self-service
  • Broad network access

    It’s designed to be consumable from anywhere you have an Internet connection.

  • Resource pooling

    Your resources are placed onto a very large amount of underlying infrastructure. So there’s always enough capacity there to meet your needs.

  • Rapid elasticity

    If the demand for your application shoots up overnight and your application goes viral, then your application will scale automatically and make sure that your customers still receive a good service.

  • Measured service

    You pay for what you use and get an itemized bill.

Traditional IT

  • Requires human involvement

    If you want to launch a new application or you want to be able to allow a larger number of users to access an application, you often might have to go and provision new infrastructure, change, licensing, etc. And that requires some human involvement, potentially quite a bit of cost and time.

  • Internal accessibility, limited public presence

    They’re often designed for accessibility internally within the company. And then if you want to access them from the outside, it’s often a bit more hassle. You’ve got to set up some kind of remote access infrastructure to be able to connect to those applications.

  • Single-tenant can be virtualized

    It’s just your company using the hardware. It’s dedicated to you. There are cost implications to that as well as scalability implications as well.

  • Limited scalability

    You can certainly build in some extra infrastructure for scalability in your traditional IT stack, but it does come at a cost and there are certain limits. There’s always going to be an upper limit to what you can actually provision and have available.

  • Usage is not typically measured

    You can actually implement measuring and perhaps chargeback to certain departments, but it gets very complex. So typically your company is going to wear the whole cost of all of the infrastructure that you deploy and the management of that infrastructure.

Examples of Cloud Computing

Non-Cloud Services:

  • Email Server
  • File Server
  • Customer Relationship Management (CRM)

Cloud Services:

  • Gmail / Office 365
  • Dropbox
  • Salesforce

  • You don’t own or manage the infrastructure on which the service runs
  • Cloud services are offered on a subscription/consumption model
  • The service scales as demand changes

Deploying a website On-Premises

ActivityTimelines
Purchase hardware: Assumes you don’t have a private cloud, or don’t have enough capacity4-12 weeks
Install and build: Depending on the complexity, this could be a short job, maybe a week or two, or it could be a couple of months or more4-8 weeks
Acceptance testing2-4 weeks
Handover to operations1-2 weeks
3-6 months

Deploying a Website in the Cloud

This whole process can be considerably faster because you’re not having to provision that hardware, install it into that data center, or get all the various approvals so that you can do that because that alone can often take a lot of time. Your customers can easily connect over the Internet and start consuming your application. So the whole process of deploying an application in the cloud can be considerably faster, often many months faster than on-premises. And of course, the outlay in terms of capital money is much, much lower because you’re only paying for what you use.

Types of Cloud Service and Deployment


Cloud Service Models: Private Cloud

Now, what this means is it’s somewhere between the traditional IT model where you own everything and you manage everything. But we’ve provisioned some layers of software that will allow us to automate certain things, and it makes it kind of a bit more like a cloud.

So everything from the piece of hardware on the bottom, the hypervisor that virtualizes your operating systems. And then the operating systems add the various layers of your application stack, everything is managed by you. Now, the reason it’s called a private cloud is that things like that on-demand capability, the self-service, the multi-tenancy, and the metering and elasticity can be enabled within certain constraints in a private cloud environment that you own in your own data center. But you’re still managing the entire stack. It can be very complex and very capital intensive to build a private cloud. With a private cloud, an analogy would be a house. With a house, you might buy your house, you own the house, you’re responsible for anything that goes wrong with a house and you’re responsible for furnishing the house or the contents that go into it.

Cloud Service Models: Infrastructure as a Service (IaaS)

The hardware and the hypervisor, they’re gone. With Infrastructure as a Service, you are not responsible for the underlying hardware. You’re responsible for the actual operating system that you run. An analogy here would be a hotel. With a hotel, you don't own the building, but you can lease some space in that building. So you can rent out a room for a night and if you want to rent a room for a few nights, then obviously you’ll pay more. You’re responsible for the container as shown above. The operating system, Windows or Linux, and the application that you put on top of it. But the underlying hardware that enables you to run that particular virtual server in the cloud is not your responsibility.

Cloud Service Models: Platform as a Service (PaaS)

Now, you’re not responsible even for that operating system, the Windows, or the Linux instance that you had to manage before. You would have to patch manage it and tune it and make sure that it’s secured. In this case, all of that goes away. All you have here is the data and the Web application. So you’re essentially uploading data and code, nothing else. You’re not responsible for anything else.

Cloud Service Models: Software as a Service (SaaS)

In this case, you’re really not responsible for anything, which is why I’ve crossed out the Managed by you. You don’t manage anything. You’re purely consuming the service. If you use Facebook, for example, or Salesforce.com, these are both examples of SaaS software. You’re not responsible for anything. You just sign up with an account. In some cases, you pay like with Salesforce.com and you just consume it. But you don’t have any flexibility to control how that software is designed. You just have to use what they give you.

Cloud Service Models: Comparison

Delivery Models / Deployment Models for Cloud Computing


Private Cloud

Here, you build your own infrastructure like your virtualization infrastructure, your storage, and your backup systems, your network and firewall systems, and you build and manage all of this. But then you layer on top of it some various software capabilities that turn this from being a traditional operating model into a private cloud. So it’s a bit more like a public cloud, but you still own all the infrastructure. That’s why it’s called a private cloud because it’s not shared with any other companies. It’s within your own data center and it’s your own management and you own the actual infrastructure as well.

Public Cloud

Here you’re connected via the Internet or in some cases a private link from your corporate office to the public cloud, and the public cloud is where the services are delivered. So you’re a consumer of those services. Services like compute and storage and network and database.

Benefits:

Hybrid Cloud

Hybrid Cloud is where we actually have a private cloud and public cloud connected together. Now, sometimes that would be via the Internet or potentially a private link. But it means you’re getting the best of both worlds. This allows companies to keep their critical applications and their sensitive data, perhaps in the traditional private cloud environment, but they could also put them into the public cloud as well. You can utilize the cloud for what it’s really good for, which is things like platform services and software as a service and using infrastructure as a service and having those elastic resources. It also facilitates the portability of data and applications so you can fail over into the cloud or you can burst into the cloud when you need more capacity or you simply want to migrate your systems between these two environments for certain reasons.

Multicloud

This is where you’re taking advantage of multiple different cloud models. So you might have a private cloud on VMware, a public cloud on Azure and AWS, and maybe another private cloud stack on OpenStack. So you’re really getting the best of each of these different providers and putting your applications wherever they’re best suited.

Overview of Amazon Web Services (AWS)


I’m sure you’re aware, that their sales can be very variable. At certain times a year like Christmas, they get huge amounts of sales, whereas other times of the year they’re still getting a lot of sales, but compared to those peak periods, it’s a lot less. During these peak periods, a significant amount of infrastructure is required. They need a lot of application processing power to serve their customers during these really busy periods. But then during other times of the year, that infrastructure was sitting idle. It’s not doing anything because they don’t have as much demand. AWS solves this problem for its customers. And they do that by giving you the ability to utilize their infrastructure when you need it. And if your business model is like theirs and you have very variable amounts of demand throughout the year, that’s okay. You’re never paying for idle infrastructure and you always get the infrastructure you need when you need it.

AWS Service Categories (a few examples)

AWS is really fast in the way they develop, improve their products and bring out new services. It’s happening all the time and it’s quite hard to keep up.

AWS Pricing Fundamentals

AWS generally doesn’t charge you for uploading data into the cloud, but when you want to bring it back out of the cloud, there is a charge and it can be considered as well.

The AWS Global Infrastructure


What is Global Infrastructure?

The global infrastructure is the regions and availability zones and other services that are provided geographically around the world. So firstly, we have our Regions and this is a physical location in the world and it’s completely independent of other regions. Within a Region, we have what we called Availability Zones. Each of these is composed of one or more data centers. The Regions are connected together using a high bandwidth connection, which is known as the AWS Global Network. So, all of the regions can communicate internally without going out to the Internet. Each region will have at least two or possibly more availability zones. Local Zones is a way that you can extend the region closer to end-users. That means the connectivity between your clients, the users of your applications, and AWS can be over a shorter distance because there are more of these around the world.

Deploying Services Globally

We can launch things like virtual server instances and databases into different regions. This is one of the really great benefits of the cloud. It’s very easy to be able to extend your applications all over the world. And when you do that, you’re leveraging the infrastructure that has its own built-in high availability and redundancy. So if an availability zone fails, there’s another availability zone. So you split your applications between them. If a region goes down, which is very rare, but it could happen then if you’re deployed in another region as well, then again, you have resilience for your applications. So AWS is really giving you great capabilities to make sure that your applications are highly available and whatever happens, whatever local events might take place, then you can still make sure that your application is running somewhere in the world.

AWS Shared Responsibility Model


At the bottom in orange, we have AWS and they’re responsible for what they term as security of the cloud. Then we have the Customer at the top who is responsible for the security in the cloud.

So here you can think of AWS as being responsible for the physical data center, the data center security staff, the network routers and switches, and the physical servers. Anything physical is going to be AWS. The physical storage systems, the disk drivers, and the database servers, this is what AWS is responsible for. You’re then responsible for things like training your staff, making sure they know how to use AWS, putting your data into what are called buckets and making sure you’ve encrypted it and secured it properly, encrypting your data, giving access to the users and configuring multi-factor authentication, configuring the network layer with your security groups, your firewall settings, and then managing things like patch management and automatic scaling. AWS gives you lots of capabilities, but you’ve got to use them and therefore it’s your responsibility to make sure that you do.

Application Programming Interfaces (APIs)


Application Programming Interfaces (APIs) - Building a house analogy

Let’s say a client here wants to build a house and he’s talking to a builder and what happens is that the builder provides a set of standard options. So the builder says, well, these are the types of houses I can build and there are the various configurations you can use. The client will then fill that information out.

Now, the builder will then hire the electrician and the carpenter and the construction workers, and all the various different people who he needs to build a house. The builder is able to give instructions to the workers in a language that they understand because he is an expert in this trade. The client wouldn’t be able to talk directly to the electrician or the carpenters or construction worker because he just doesn’t understand how to build houses and they’re going to ask him questions that he wouldn't be able to answer. So what we’re doing here is we have the builder who is basically interpreting what the client wants and then forwarding on to the relevant back end, in this case, workers in a language that they can understand.

So how is that similar to an API? With an API, we have a client. The Client is connecting to the API with the HTTP protocol. The same protocol you’re using when you’re using a Web browser. The API proves the instructions developers use in their code and those instructions are sent to the API using HTTP. Now, on the back end, we then have various different services and the API is able to then communicate to those services in their own languages. So they have their own interfaces, their own protocols that they use and the API is able to talk to them.

So what it means is you’re able to have a single language and through that language, you’re able to communicate and work with the various back-end services that might have their own different ways of doing things.

Flight Aggregator Example

So we have a user and the user is on the Internet and has connected to a flight aggregator. These are services like Monondo or Skyscanner or Expedia. So what happens when you go to these websites is you search for a flight and you put in your times and your dates and it’s then going to go and find some flights for you. And it does so by actually searching various different airlines. Here we have a few airlines websites, and what will happen is the flight aggregator is able to talk to these different websites using an API, so they each have their own application programming interface. And the flight aggregator can then communicate with those different services and pull some information out of their databases so that it can find out what flights they have available that might suit the customer. As you can imagine, each of these airlines has built its own platforms. And if you wen to their websites, their website would be very different from another website of another airline. So the API really simplifies things because it gives that single language for the aggregator to go and request flights information.

Launching Cloud Services


AWS Management Console

As you can see, there’s a series of categories, and within those services that you can go in and configure or launch resources.

Command Line

Here using a command prompt or terminal program to run a command.

Software Development Kit

This is where we’re interacting programmatically, directly with the API. And in this case, a developer would write code in an Integrated Development Environment, what’s known IDE. The code is leveraging what’s called a Software Development Kit to work with cloud services. The Software Development Kit is just some software that’s provided by AWS to help developers to create applications that work with AWS services.

AWS Public and Private Services


In AWS, you have services that are connected directly to the Internet. They have an endpoint. That is an address that you can connect to directly from the Internet. Those services include the storage service, Amazon S3, the database service, DynamoDB, we’ve got the DNS service, Route 53, and a Content Delivery Network called CloudFront. Now, on the other hand, on the right-hand side, we have something called a Virtual Private Cloud a VPC. It’s essentially a virtual space in which you can create your own resources and they can be private. So think of it as a virtual data center in the cloud. And within that virtual data center, you can launch resources. Now, those resources can be made public in some cases, but you can also make them completely private so they don’t have any direct connectivity to the Internet. So the private services can have a public IP address, but otherwise, you can choose not to give them a public address, and then they’re totally private. On the other hand, the services on the left side are public services and they have public IP addresses and public domain names. Now, if service in a private space here wants to connect to public service, it does so via an Internet gateway.

The 6 Advantages of Cloud Computing


1. Trade capital expense for variable expense

So remember how in the traditional model you spend a lot of money buying equipment and paying for data centers. It’s a Capital Expenditure or CAPEX, whereas in the cloud you’re paying for your services in a pay-as-you-go model and that’s an Operational Expenditure or OPEX. So rather than purchasing servers, you’re just paying for what you use. Another advantage is that with CAPEX, your expenses are tax-deductible over a depreciation lifetime and that can be several years depending on your country. Whereas with an OPEX model, your expenses are deductible in the same tax year.

2. Benefit from massive economies of scale

3. Stop guessing capacity

In the beginning, when you’re planning a new workload, you often have an idea of what you need in terms of the amount of processing, power, storage space, and so on. And the reality is that often once you’ve deployed your workload, you find out what you really need and it’s much less. So that means a lot of wasted resources. With the cloud, we just don’t have this problem because we can actually adjust our capacity based on our demand.

4. Increase speed and agility

Speed is the ability to deploy resources easily and quickly. And you can do so through API calls, through the command line, or through the management console. And you can do so around the world as well. So you can not only deploy fast, but you can go global. Agility is the ability to react, to change, and bring things to make faster. So it means that in a competitive situation, you can respond to your customer’s needs better than your competitor because you have agility.

5. Stop spending money running and maintaining data centers

AWS wants you to stop spending your money and also your time maintaining data centers and instead put that time and that money into innovations. The way AWS sees it is that spending time and money on data centers is low value. It doesn’t differentiate your business, whereas if you’re a bit more intelligent and you put that time and that money into new innovations, bringing new services to market, then that’s a way that you can differentiate your business and get a competitive edge.

6. Go global in minutes

With AWS, you have the ability to deploy your resources all over the world. That used to be a very difficult thing to do, but now with cloud computing, it’s actually very easy.

Exam-Cram


Cloud Computing and AWS Exam Cram

There are 3 types of Cloud Computing Model:

There are 4 types of Cloud Deployment:

Fundamentals of pricing:

The AWS Global Infrastructure is made up of:

The AWS shared responsibility model defines customer / AWS responsibilities

The 6 advantages of cloud: