Intro to Cloud Computing
October 23rd, 2019, Google announces it as achieve the impossible goal of quantum supremacy, a machine more than 100 million times faster than your 16 inch MacBook. Only one month later AWS releases quantum computing as a service in the cloud.
If you’re a software developer in today’s world if there’s a good chance your infrastructure is on the cloud and very likely with a big provider like AWS Azure, DCP, or IBM. 90% of companies are on the cloud, 60% of workloads run on the cloud and 30% of IT budgets are allocated to the cloud generating hundreds of billions of dollars in revenue, and those numbers are only expected to increase in the coming years.
Introduction
Cloud computing is a win-win both for companies that provide the services and the companies that use them. The providers make tons of money in fact AWS makes up more than 13% of Amazon’s total sales and operates at a much higher profit margin than its retail business. But it’s also a huge win for their customers. Instead of buying and managing its own hardware a start-up today has all the infrastructure it could possibly need right at its fingertips. The startup only pays for what it actually uses, it takes almost no effort to scale things up or down and you don’t need to hire an IT guy to wire the thing up.
I like to think of cloud computing like a power plant you don’t care where or how that power is being generated you just plug in your device and then pay the bill. In fact, we might as well just call that electricity as a service.
Origins
The modern cloud can trace its roots back to 2006 when Amazon launched ec2 and s3. ec2 stands for Elastic Compute Cloud and it’s essentially a virtual computer with its own RAM and CPU along with an operating system you can administer in an IP address for networking. When you spin up a server in the cloud it’s called a virtual machine you haven’t actually allocated any specific piece of hardware rather the cloud has virtualized a simulated environment for you that resembles a piece of hardware. There’s a lot going on behind the scenes to make this possible that you don’t really need to know like how they use hypervisors on top of bare metal to handle CPU scheduling and memory allocation.
IaaS
The other big service launched by AWS back in 06 was s3 which is basically a hard drive with a file system in the cloud where you can store things like images and videos things like storage buckets and virtual machines are known as infrastructure-as-a-service. They’re the low-level building blocks of the cloud so it’s up to the developer to manage and scale them.
SaaS
Once infrastructure became available and created explosive growth in a new type of software software-as-a-service. A great case study is Dropbox. In the early days, the company didn’t have the money to roll out its own infrastructure so it uploaded its user's files to s3. So it didn’t even really start out as a file storage company. It was more of a software company that helped people get their files uploaded to the cloud and it just goes to show you that you can build a billion-dollar business by focusing primarily on the front end user experience. So infrastructure as a service abstracts away hardware.
PaaS
It took no more than a couple of years to see cloud computing rise to another level a platform as a service. When developing an application developers have a lot more concerns than just hardware. You have to think about security and how to scale the workload and how to put all the pieces together into a cohesive unit. That’s what platform-as-a-service aims to do.
Some famous examples include Elastic Beanstalk, Heroku, and Google App Engine. Let’s imagine a developer has built an app with Ruby on Rails. In order to be used by people around the world that app we’ll need a database and a web server with a very specific configuration. The platform is designed to take care of the configuration part. In theory, the only thing that developer has to do is upload their code and the cloud takes care of the provisioning of the database, provides security, and scales the traffic. So what we have here is a platform for creating software as a service.
BaaS
But we can still take things one step further. The cloud can also provide SDKs that bring the cloud directly into our front-end applications and that means a developer might not need any back-end code at all. Give us a back-end as a service. The two big players in this space include Firebase from Google and Amplifi from AWS.
With just a few lines of JavaScript anybody can create a real-time application with user authentication hooked up to a cloud database that’s way more reliable than any back-end you had built from scratch.
Trade-offs
The more you rely on services offered by a given cloud the more likely you are to experience vendor lock-in. The cloud can help you get your software off the ground but once you become successful like Dropbox your opinion might start to change.
Hybrid Cloud
In 2016 Dropbox started to move its customer's data off AWS to their own data centers and cut at least 75 million from their operating expenses. In this case, it made sense to move off the cloud to on-premises but they’re actually not fully on-prem they still use the cloud to handle about 10% of their file uploads especially for edge cases and regions that their data centers don’t cover and that’s what we call a hybrid cloud.
It generally refers to big enterprises that run a private cloud on their own data centers but also combine it with services on the public cloud. And by public, I mean the cloud where you can just sign up with an email address and credit card and start doing stuff.
Multi-Cloud
This refers to a single architecture or application that combines services from multiple public clouds usually to prevent things like vendor lock-in and optimize pricing.
SLA
AWS alone offers more than a hundred and fifty different services and API's but one thing all these services share in common is a service level agreement or SLA. This is a contract between you and the cloud provider the provider generally guarantees a certain uptime and error rate for the service and will generally provide a financial credit or refund back to the client if it fails to meet those SLA requirements.
Quota
On the other side of the coin, the client generally has a quota that they must stay within when using the service. Sometimes I like to say the cloud scales infinitely but I don’t mean that to be taken literally the quota tells you how far you can push the limits.
IAM
When getting started with a cloud provider a great place to start is with Identity and Access Management the opposite of Who am I I am. It’s the front gate to your infrastructure and you shouldn’t just let anybody in.
Policy
You can secure your services by attaching security policies to them. For example, you might have a storage bucket and that policy controls who in the organization can actually access the files inside it.
Roles
Now if your organization has thousands of employees it would be very cumbersome to manage policies for every single resource. That’s where roles come in. They allow you to group permissions together into a unit that can be reused throughout the cloud and you can assign roles outside of your account if you’re working with consultants or some other third party.
Service Account
Now in some cases, your machines might need to communicate with each other. For that, you can define resource-based policies or service accounts. This would allow a virtual machine for example to access a database somewhere else in your cloud.
Compute Resources
Now that we know a little bit about security let’s take a look at the backbone of the cloud compute resources. On Google Cloud, we can create a virtual machine with a compute engine. It will give you some options when you create this machine. The region represents the actual physical location of the data center. A region closer to your end-users should be faster but some companies must follow data residency regulations that dictate where a customer data can actually be stored. Now each region is actually a campus with multiple isolated data centers that means if you have a mission-critical workload you can put it in the same region in multiple zones. If a meteor destroys one of those data centers you’ll still have a reliable service in that region that gives you high availability and redundancy. Azure actually has the most data centers of all the clouds and they have two secret government locations that we don’t even know about.
The next option is the Machine type which defines the amount of memory and CPU in this virtual machine. The bigger they come the more they cost but the great thing about the cloud is that everything is pay-as-you-go. You’re billed down to the second and you can shut the instance off at any time.
From there you need to determine the operating system by selecting a disk image. You have a bunch of different flavors of Linux or Windows to choose from.
From there you can specify a service account if you have other services that need to access this VM. By default, you have a firewall that makes this instance inaccessible to the outside world but we can change that by allowing HTTP traffic. Now when it comes to networking it’s important to understand that the instance has an internal IP address and an external IP address. Both of these values are ephemeral or short-lived by default that means if you rebuild the instance it could be assigned a new IP address however if you have a service that relies on an IP address you can reserve a static one. So what’s the difference between an internal and an external IP the internal version can only be used to communicate with other compute instances on the same cloud. If you need to communicate with others so services on the Internet then you’ll use the external IP.
Egress & Ingress
When it comes to networking you might come across these weird terms egress and ingress. Egress defines outbound data that are being sent from your instance to the outside world. Ingress is the exact opposite data that’s being sent from the outside world into your instance. Egress is typically the one to watch out for because it can have an impact on your bill.
Now, remember we’re just talking about a simulated computer here if we want to access the command line for that instance we can do so directly in the console with a cloud shell session and inside the session, you can do pretty much anything you could do in a regular Linux or Windows terminal.
So now that you know all this stuff about virtual machines it’s time to let you in on a little secret. For most applications, it’s pretty rare to create them manually. There’s just better ways to handle your compute resources and a lot of it has to do with the way that they scale. Let’s imagine we built an app on this VM. It’s popular and now our users are maxing out the CPU and memory on the instance. One option would be to scale it vertically. We could do that by adding additional CPU cores and more memory to make this single VM more powerful but we can only do that to a certain extent. So another option is to scale horizontally. Instead of making our VM bigger we’ll just create more of them, we can create them in regions all over the world and then distribute the workload accordingly. When you distribute VM's like this you also need to worry about load balancing. You don’t want all of your traffic going to a single VM while the others are just sitting there idle but all the clouds offer load balancer services to help you manage this stuff.
Containerization
But what if you never had to worry about scaling your infrastructure at all well there are actually already to cloud computing paradigms that make that possible today the first one we’ll look at is containerization. Now a container provides a way for you to simulate an operating system that may sound very similar to a virtual machine but there’s one key difference. A virtual machine sits on top of the hardware directly but a container sits on top of an underlying operating system to simulate another operating system or application.
This is a really awesome thing for development because it means you can put your application in a container and then take it and deploy it to any cloud you want or in other words you avoid the vendor lock-in. All of the clouds have container registries where you can upload your containers and then use them across other services.
Kubernetes
Now most companies using the strategy have multiple containers to run different services. You might have one container for your node.js webserver another for sending email and another for training your machine learning algorithms and as your business becomes more complex you’ll need a way to orchestrate all of these microservices and that’s where Kubernetes comes in. It organizes all of your containers into groups of pods then it can automatically scale those pods up or down based on the amount of traffic or utilization. When the traffic goes up Kubernetes will allocate more virtual machines to run more containers when the traffic dies off it’ll shut down those virtual machines so they’re not sitting there idle costing you money.
Serverless or FaaS
In 2020 we have Serverless or functions as a service. It was first introduced in 2014 with AWS lambda. It allows you to run code in response to events like a regular HTTP request or when something happens and some other cloud service like a write to the database. The code you deploy to one of these functions will scale automatically so you never have to worry about containers, VMs, or anything like that and it’s truly pay-as-you-go because you only pay for each individual function invocation. Now prior to 2019 the big trade-off was that you had no control over the actual runtime so if you needed to install some os-level software you wouldn’t be able to do that but just in the last year so AWS released the runtime API and Google released a service called Cloud Run and that means today we can do pretty much anything we want in a serverless environment. There are still some other trade-offs but generally speaking, it’s the easiest most cost-effective way to deploy back-end code that scales.
