Intro into the Clouds — Part 1 — IaaS Compute

Artem Nikulchenko
Google for Developers EMEA
14 min readApr 28, 2021

I work at two jobs (don’t worry, it won’t be post about that 🙂 ). As Chief Software Architect at Cloud Works (Teamwork
Commerce
) I see the big gap in knowledge of students that come to us to start their career. As Associate Professor at Kharkiv University I feel it is my responsibility to help students to reduce (or even remove that gap). The gap I’m talking about is a gap in understanding Cloud Computing and that is Cloud in general. In University they learn lots of important subjects, write their first complex programs, deploy their code to servers etc. But they don’t work with modern Clouds (at least in my University). And whey they come to their first job, their are bombarded by different terms and options, like AWS, GCP, AppEngine, Cloud Functions, GKE etc.

So, I’ve decided to create materials that would help them to better understand those terms, why those services were created, what problems they are designed to solve… I’m not planning to cover each or any particular services in details (I believe there tons of great materials that covers that already available. In fact I will actually give links and rely on Qwiklabs to provide those details and initial practice). Instead, my goal was to give general overview and share how I understand those services…

Why is it published here? As Associate Professor I know that a lot of times when you share new material to the students, your viewpoint and data is not challenged (with some exceptions of course). But as Software Architect I know that all good things require community and communication to be created. That is why, with a risk to be told that it is all nonsense and useless (or even worth), I’ve decided to publish those lectures here to get your feedback.

For start, I will publish first 4 lectures.

So, if you managed to read at least couple of my lectures and not get bored — please, leave a comment and let me know all the mistakes you found, corrections you suggest, did you liked the format and the way information is presented, and most importantly — should I continue and publish next lectures…

Note 1! I will try to keep my storyline as fair as possible and talk about all the key players in this area. However, as a Certified Google Cloud Architect and a person who has been using GCP from the very beginning in 2008, when it comes to examples of new services, I mostly refer to GCP services (and it is easy to google similar solutions from other providers. Pun intended…). In the end, the purpose of this story is to teach about Clouds in general, and not about some specific details of a particular Cloud provider.

Special thanks to Mykhailo Kotov for reading all my lectures, correcting my English and making them sound better!

What is Cloud and what is not? How is it started? Why Google Cloud Platform (GCP) is a Cloud and another hosting provider may be not? How to understand all the options in Cloud Console? How to learn Cloud if the number of services are changing faster than you read about them?

Well, one option is to pick a leading Cloud provider, get a list of its services and study each of them. Then, switch to another provider and do the same.

For GCP, there is a convenient list of all the services, each described in 4 words:

If you can learn about Cloud this way, well, then you do not need to read the rest of this article.

However, if this approach looks a bit overcomplicated, let me suggest another one:

Cloud computing and all Cloud services are human-made things. And as all human-made things, they are created to serve some purpose and solve some problems (well, or for fun, like Ook!).

So, going back in history, understanding problems and tools that existed at that moment, can logically explain why this or that solution was created and how it shaped Cloud Computing as we know it.

Before we start:

Disclaimer 1! The story below is not intended as a fact-based history lesson. Dates are not provided, some events are omitted and the timeline is bended to focus on the purpose of understanding Cloud.

Disclaimer 2! The story below is not intended as a deep course for IT professionals in virtualization, hypervisors, etc. It is intended for students of CS departments learning what Cloud is. It focuses not on details of a particular technology, but rather on an easy and digestive way to understand the core essence of Cloud Computing.

Note 1! I will try to keep my storyline as fair as possible and talk about all the key players in this area. However, as a Certified Google Cloud Architect and a person who has been using GCP from the very beginning in 2008, when it comes to examples of new services, I mostly refer to GCP services (and it is easy to google similar solutions from other providers. Pun intended…). In the end, the purpose of this story is to teach about Clouds in general, and not about some specific details of a particular Cloud provider.

Note 2! This course is intended for those who want to get the gist of Clouds, all the available services and how to become an efficient “user” of Clouds (meaning, how to build systems using Clouds). It is not intended for those who want to know how Clouds are working internally, because that is a separate topic.

So, if you are still here, to understand a Cloud, let’s start from the very beginning.

It all started with the Big Bang:

Ok, that is too far. Let’s scroll a little further to the point in history, when the Internet was already invented and was growing in popularity. In fact, it became so popular that it started to make sense for a business to have “Internet presence” in the form of a web-site, eCommerce site, etc.

In those days, if you wanted a web-site, you had to write a web-site or hire somebody to do so. (yes, Shopify was not an option yet). And, of course, your business could be more complicated and require more than just a simple web-site or standard eCommerce (e.g. online banking, insurance etc.). Luckily, there were many languages and frameworks available (as well as people who knew them) to do that.

So, now your site is ready. But where do you host it?

You can buy a PC (similar to one that was used by kids to play games) and host it there. But what if your PC breaks down? What if you just need to restart it? (Cause the general purpose OS is not really suitable for running 24 / 7 for a while).

Well, you can buy some more expensive hardware specifically designed to be a Server. And you can set up a specifically designed OS on it. But if that breaks down too?

Well, you can utilize RAID for your storage, you can buy a proper server rack, duplicate your servers. And yes, at this point you will definitely need a trained sysadmin to take care about all that. Or, maybe, even several admins to cover 24/7. But what if all that’s got stolen?

Well, you can hire a guard. Or, even several.

But what if electricity goes down? Or fire starts?

Well, I think you’ve got the point. There is no limit to levels of protection you can add, but, of course, they cost money and a huge amount of that. If you are a bank or a big insurance company, you probably can afford that. But what if your business is smaller or just starting?

Interestingly enough, you don’t need 100% of those resources. Security guards can secure one server as well as a thousand, sysadmins can handle one server as well as a hundred, a reserved electricity line can be shared between 10 000 servers, etc.

So, what is very expensive for 1 server, shared across many servers becomes more reasonable. And that was a problem that provided business with opportunities.

And Public Data Centers were created…

Disclaimer! As I mentioned in the beginning, this story is not designed to be a history lesson. Of course, data centers existed before and were used by the military and big corporations, who could afford to own one. Here, we are talking about Public data centers, meaning that almost anyone can rent a server within it.

Public Data Centers were (and still are) a building (a part of a building or even several buildings) used to house the computer system and associated components. Such Data Centers are built by a company who was not planning to use them directly, but rather to re-sell (or rent out) some space or particular servers from this data center to other companies. The latter were not able to afford their own data center, but wanted to enjoy fast Internet connection, security as well as stability of a proper data center.

Are those the Clouds? No, wait, we are not there yet.

So, now we have Public Data Centers, and as a business owner, if you want to have a server, you don’t need to build your own data center. You can just buy or rent a server from any Public Data Center and enjoy security and reliability.

But what if you need a new server? Or you want to change the existing one (e.g. add a disk or RAM, etc.)?

Well, you can call a Public Data Center support, make your order, they will buy a new server (or parts) for you and have one of their sysadmins install it (of course, coordinating this with you). This will definitely take some time.

Note! Some of you, who have already heard about Clouds or used them a little may be thinking now “What an old-fashioned and outdated solution it was!”. Well, you may be surprised to know that each modern public cloud still supports this option. It is usually called “bare metal” solutions. (e.g. GCP Bare Metal, AWS EC2 Bare Metal). There are still cases when you may need such solutions.

So, it was better than building your own data center. But what were the problems?

  1. Changing amount of resources. As we have already mentioned, time needed to change anything is one problem.
  2. Entry level. There was still an entry level to that solution. It was not possible to get data centers to waste their time and resources to install a small server for you (which would run a small web site).
  3. Long term commitment. In most cases, you had to buy a server (or have a long term rent). So, you can’t get a server for 1–2 hours to make calculations for your home work and give it away.
  4. Sharing resources. And finally, if your business is big and stable enough, and you can actually afford a nice server for a long time — all your departments had to share it. Sales wanted to run their programs, the accounting department wanted to run theirs, the same with eCommerce, and CRM etc. Each of them was not big enough to have their own server, but sharing one server created problems with security and resource isolation (your sysadmin responsible for the eCommerce site could get access to the accounting DB, find out that he had the smallest salary and leave. You requested an urgent report from Accounting to see all the sales and raises for the last 5 years, and running this report consumed so much CPU and RAM that your eCommerce site just went down for 1 hour…).

As you probably have already guessed, when there is a problem — there is a solution. And in this case, such solution was virtualization:

So, what is virtualization in simple words? Instead of running an OS on top of the hardware and then running several applications in this OS, a virtualization layer was installed on the hardware. This allowed for “slicing” hardware resources into pieces. A separate OS would run and use only the piece of hardware dedicated to it, and only one dedicated application would be installed on that OS. Those “dedicated” OS were now called Virtual Machines (VMs).

Note 1! It is worth mentioning that there are two types of hypervisors (that implement this virtualization layer). Type 1 (also known as native or bare-metal) runs directly on the host’s hardware to control the hardware and to manage guest operating systems. Type 2 (also known as hosted) requires an OS to be installed on the hardware and then runs inside this OS (as other computer programs) to support host OSs.

Note 2! Yes, this adds an additional layer, and as a result, additional “resource expenses” between hardware and the final application (which is what User is interested in). But this extra “expense” is worth the flexibility that such solutions provided.

Now Public Data Center was able to buy hardware themselves, and sell “pieces” of the right size to whoever wanted it.

How did that solve the problems we listed above?

  1. Changing amount of resources. First of all, now data centers took hardware responsibility on their shoulders and ensured that hardware is new, fast, and stable. And if you needed more resources for your VM, if it was running on the hardware that still had some resources — new resources can now be allocated to your VM in a matter of minutes (and your VM restart). Obviously, reducing the amount of resources was even simpler.
  2. Entry level. Technically, if the data center wanted, technology now allowed for slicing into chunks as tiny as you want.
  3. Sharing resources. While physical hardware resources technically were shared, VMs provided enough isolation not to actually feel it . Each VM-owner operated in his own fully isolated environment.

You have probably noticed that there is no Long term commitment above. Let me explain…

Data Center businesses started buying hardware resources and re-selling a part of those as virtual resources to everyone interested. However, as a business model, that only made sense if hardware resources were highly utilized (up to 80%-100%). If you buy very expensive hardware and rent out only 10% of that, no margins will make it profitable).

That created a few problems:

Data Centers had to ensure that hardware is used to 90%-100% of capacity, which means:

  1. If you wanted more resources, they may not be available on the same hardware, so your VM had to be moved to another hardware server (which was a little longer)
  2. If you wanted less resources, hardware servers were becoming unutilized. So, data centers may need to move your VM to another server (or move another VM to this server to occupy freed resources).
  3. Since moving a VM from one server to another required restart, the data center had to negotiate it with the VM-owner. So, the less they had to do it — the better, which means data centers still preferred longer commitments from their Clients.

So, the following two things would make the above easier for data centers (and their Clients, consequently):

  • Technical. Ability to move a VM from one hardware server to another as fast as possible.
  • Business. Agreement with a Client that their VM can be moved (and restarted in the process) from one hardware to another at any moment (during a maintenance window) within a reasonable amount of time.

Note! Those two things are related: the faster the VM can be moved with little to no downtime, the easier it would be for the business to get Clients accept it.

And if, on top of that, data centers can provide an easy to use way to request/change/operate with those VMs (for example, a nice UI or APIs instead of phone calls and faxes), that would be a game changer!

And it was!

Interestingly enough, this “game change” has not come from where it had been expected. If you’ve read the whole story above, you probably would expect that some of the big data centers at that time would come up with it. But no, actually the first cloud computing did not originate from companies traditionally selling VMs. It originated from companies that, to solve their business problems (which were not in the area of renting VMs), built their own data centers, their own operation tools , made them efficient and easy to use (for internal teams), and then realized that those solutions can actually have a huge demand outside of their company.

The first one, and still the biggest, was Amazon Web Services launched in 2006 and made publicly available in 2007, with its two still most popular services — Amazon Elastic Compute Cloud (EC2) and Simple Storage Service (S3).

And that is how the revolution in computing, and what is now known as Cloud Computing, was started by a bookstore…

Note 1! In 2006, that was actually a relaunch of AWS. First, AWS was launched in July 2002 with only one service — SQS. Technically, now we would consider that just a service, and not a Cloud at all. Then, in 2006, having got enough traction, AWS was relaunched with 3 services:

  • EC2 as a computing service, which was the main topic of the first part,
  • S3 as a storage service, which we will talk about later,
  • Amazon Simple Queue Service (SQS), which is a distributed queuing service, one of the first truly “cloud native” services.

Note 2! Having read that story you may get a feeling that making this step was easy. But to be fair to all the people involved in that history-defined project, I need to mention that there were tons and tons of complicated problems to solve as well as elegant solutions to come up with in order to make this concept a reality: decoupling computing from storage, live VM migrations, lots of advancements in hypervisor technology. Since, as promised, this course is not designed for deep understanding of those solutions, we won’t go in detail, but still will take a moment to appreciate all that was done to make Clouds possible.

So, if both data centers and AWS were renting out VMs, where was the difference? What is Cloud and what is not? There are still no clear criteria to answer this question. I mean, everybody agrees that AWS, GCP, and MS Azure are Clouds. And at some point, lack of clear criteria allowed most of “traditional” data centers to call themselves “Clouds” too.

We will try to define those criteria later. But now let’s look into the history of GCP, who took a very different path…

Suggested labs:

Note! While in first part we have mostly talked about AWS, all labs here and further are based on GCP:

Part 2 (PaaS) is here

--

--

Artem Nikulchenko
Google for Developers EMEA

Chief Software Architect with 10+ year of experience, PhD, Associate Professor, IT Univer co-organizer, GDG Organizer