Cloud computing

Listen on your favorite service

• 
  Apple Podcast
  
• 
  Spotify
  
• 
  Transistor.fm
  
• 
  Stitcher
  
• 
  Pocket Casts
  
• 
  Castbox
  

• 
  Podcast Addict
  
• 
  Breaker
  
• 
  Player FM
  
• 
  Listen Notes
  
• Amazon Music
• 
  Radio Public
  

share

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Transcript

The Cloud does not have a birthday. The internet does. The web browser and HTML do. The internet protocol (IP) does. The Cloud not so much.

During our lunch walk up and over the near hill, I asked our Rachel: What is the Cloud?

Rachel, at 36 years of age, holds a master’s degree from Rutgers.

Now I understand the starting point.

How come poor cloud has no birthday? We, we IT people, took a cheap short cut when drawing picture of networks in buildings or campuses. We made boxes and connected them with lines that look nothing like Google Maps, but something  like a silly drawing with square-edged boxes and very straight lines. This being the stick-people equivalent to the drawing other types of engineers make. When we finished, or started, our drawing with connected to The Cloud. We dropped a picture of a cloud at the edge of the paper. I was doing this as far back as 1995.

IT people defined “that other place” or “that faraway place” or “the rest of the world” with one simple icon for a cloud. There is here and there is there. When we drew a picture of “there” it was a cloud.

That icon never represented anything but a nebulous, amorphic, impossible to touch entity.  The Cloud shows in computer science and marketing literature for decades. Long before 1989 when Tim Berners-Lee proposed hypertext and the World Wide Web. The first website was published on the 20^th of December 1990. The cloud icon was used even before the Internet Protocol was vaguely defined in 1974. The forerunner to the internet was called ARPANet. It can claim 1966 as its birth year.

Our walk through the autumnal forest took place on a cloudless day. The sky today is a stunning blue – postcard blue. As Rachel explained The Cloud to me, she pointed sky-ward.

Netflix comes from The Cloud. And my iPhone, she says, stores pictures on The Cloud.

And when things go wrong between phone and cloud, you just wait.

It was about then, that her phone got the daily batch of text messages. There is a spot on top of that hill where Rachel gets just enough cellular coverage to fetch text messages. We pause while she scans them, then walk on. She does ask as we start down the side of the hill, how come all of these don’t come when I am on Wi-Fi in the house. I shrugged. “That’s just Apple being Apple. They don’t play well with others.”

Those text messages queued up in The Cloud waiting and hoping that Rachel would appear at the top of our hill.

And then there are those damned blue spinnies when watching TV of an evening.

Oh, and when I push one of my podcast episodes to The Cloud, I entirely kill my network. My music stops and I may as well pace the yard.

This is the starting point. I will strive towards a better and more complete definition for The Cloud – and a definition that will meet the rigors of my technical peers while sating the intellectual curiosity of others. The Cloud remains amorphic.

Definition one: The Cloud is some remote place that stores data such as pictures, movies, words, numbers, and files. A good foundation.

If everyone stored and retrieve data from The Cloud with equal ease and equal speed, then The Cloud would be at the center of the Internet. Normally, if your connection speeds are slower or non-existent, it is because of where you are and where you live and where you are standing. In 2020, I would have preferred that our house was on top of the hill where the cellular reception is. Instead is it lower down where the power lines are. That is a trade-off.

Listen team, the universe is infinitely large and growing yet somehow has no edges. I learned that in school. I grew up with an astrophysicist as a dear and close friend of the family. While tennis was a more common destination for a summer outing, the Harvard Smithsonian Center for Astrophysics was popular with our clade. My first class in astrophysics was in eight-grade, in 1977. And due to the odd form of our household, blackholes and x-ray telescopes got discussed at the dinner table. That was also my very last class in astrophysics, too.

The internet is also infinitely large and growing yet somehow has no edges. We’re launching dozens of satellites into the sky to expand the internet there. I am ok saying that there is a Center of the Internet.

It is exactly as true (or not true) as saying there is a center to the Universe.

Ask the mathematician, if nearly every home, office, and mobile phone gets the data they need is nearly the same time, then each home, office, and mobile phone is equidistant from the center of the internet.

All humans, and their dogs, are roughly 6,371 kilometers from the same point. Every one of us, and our dogs, are equidistant from the same place. That place is the center of the earth.

So, if everyone of us can ping the center of the internet in 50 milliseconds, then bingo, then there we are a brief 50 milliseconds distant from the Center of the Internet.

We want websites to load quickly. Blue spinny-circles disturbs our movie watching experience.

Years ago, the internet had no center. Oh, I am not going to get all Genesis on you, here, just practical.

Commerce was lured into the Center of the Internet starting in the mid-2000s. There are millions and billions of reasons for this, primarily the millions and billions one can earn.

Inside Podcast-Flow, we entirely depend on being at the Center of the Internet. You find us via a website which sends you to a website extoling the amazing and important virtues of Podcast-Flow or one of our courses. Forgive the hint of snark related to the language and tricks of the marketeers (and my friend Kelly). From this website, we send you to a buy page to buy our product and enter your credit card. Within a half-second, 500 milliseconds, your credit card is processed and our system sends your information to firm that helps us identify users and track what permissions they have. Within milliseconds, we establish an account for you. At that same instant, we establish your data profile in our Oracle database.

There are four entirely separate firms simultaneously engaged in the buying process. We expect each of these firms to respond to us via the internet within milliseconds.

This works because we are all located together at the Center of the Internet. The speed of our connections and the size of the circuits connecting the firms are massive. These systems behave as if they are in the same building.

There is zero tolerance for blue-spinnies here in the Center of the Internet.

A decade ago, when I designed and wrote the first version of Tempest-GEMS, a grant management system. I wrote in a language that I first learned in the mid-1980s. I used a database system developed in the 1970s. I used techniques to optimize speed learned over decades of experience with the internet and software development. Of course, the application was fast and gorgeous on people’s browsers because of Oracle APEX.

In time, we wrote a link to FEMA, the Federal Emergency Management Agency. We pulled, we do pull, grant data from FEMA. We do it once per day. The data we get is about three days old. It is good enough.

This is how we all worked for decades. The internet was never really fast enough, nor reliable enough to expect real-time data. We’d all share data when we could and as best as we could. We called it best-effort. We had to engineer tolerance for failures and slow data rates.

The first people to convene at the Center of the Internet were traders in stocks and bonds. They can make millions by being milliseconds ahead of a trend. Those of us working with grant data, auto parts, shipping waybills, even medical data – we never expected services measured in milliseconds.

When working with international shipping of freight during the mid-1990s, as long as the data about the freight arrived before the airplanes carrying the goods, we were doing pretty well. When I deployed a telemedicine application in rural Alaska for the Indian Health Service in the late-1990s, one had time to pour a warm cup of Earl Grey between asking for an X-Ray image and it appearing on the screen.

We moved large data from one edge of the internet to another edge of the internet. We understood that it took time for this movement to happen. The internet was a series of tubes. This is what Ted Stevens, senator representing Alaska. He said that in 2006. Coincidently, Uncle Ted was the individual solely responsible for all of my projects in Alaska, including the telemedicine system we deployed in 1998 and 1999. Our projects had to ask Uncle Ted for more money to build these tubes and pipe into the far reaches of Alaska.

To politicians and medical staff, we had to explain light speed, distance, and all of the challenges of the internet. The x-ray image started in Anchorage, then went to a satellite, then down then across town, then to a computer. There are very serious challenges moving big data from one edge of the internet to another edge of the internet. It takes real time, time you could measure in seconds.

Podcast-Flow cannot wait two seconds for a credit card to process. That would cause your browser spin slowly. And if each task of setting up an account took one, two, or three seconds, that might mean a ten second delay. Ten seconds is the time it takes me to read a short paragraph. Ten seconds is enough time for you to notice a significant delay on your browser.

When we processed a credit card from Puerto Rico yesterday, it took 523 milliseconds about the same amount of time it takes for me to say the word: “One”. We won’t set up your account with PodcastFlow until we’ve gotten confirmation that you have paid. As we setup your account, we send the data to Okta to set up your identity account there. That should take a few milliseconds. We want your entire account setup then trigger your welcome emails within a second. Your first email should arrive at about the same time as the receipt appears on the website.

In 2013 and 2014 when designing Tempest-GEMS, I build a machine that runs on the internet. It uses the internet as if it were a “series of tubes”. You would work via a browser on your desktop or laptop. And the data got stored in our database. This architecture is so classic, I recognize that its roots go back to the beginning of computing. Over here is a terminal with you working. And over here is the database. There you go. Done.

With the internet, we stretched the distance between terminal and database. With time, the terminals became more sophisticated, more colorful, and bigger. That’s just industrial evolution at work.

In 2020, the architecture of our software, PodcastFlow, expands beyond our own computers, beyond our own firm. We are pushing and pulling data from other firms with perfect reliability, with amazing speed, and with no practical limitation on the size of the data.

Instead of building a machine that runs via the internet, that treats the internet as a series of tubes, we built a machine that runs within the core of the internet itself. We are not longer just passing data between a server “in the sky” as Rachel called it, and your workspace. No, the architecture of our machine, our software, 100% depends on all of our partner services operating with the same speed and efficiency that we do.

In the old days – such as a decade ago – if a system had a 100% reliance on some data, you fetched it and stored it. They were them. We were us.

Today, in a fully-integrated internet machine their tools are our tools; their data are our data. The user experiences a fully integrated internet machine that operates smoothly. The software developer building these machines will invest significant time on sharing data efficiently.

It is as if the backbone or skeleton of software blends with into internet. Think: Borg, or Cyborg, or bionics.

I once wrote software that worked handsomely within a boring little Oracle database. I owned the Oracle. I owned the computer server that the Oracle ran on. Today, I write software that trusts and relies on the internet just as if I owned the internet.

I don’t own the internet, we pay for this experience. We pay to put our technology right there in the Center of the Internet. When I reach to the bank to process a credit card, I get a response 100% of the time and done within the blink of a human eye. That bank is not somewhere else. It is at my fingertip, right now, all the time. I write my own software to manage the banking. Then I do the same with our other partners. It is our company’s software pulling and pushing data to the banks and partners. We own that process. We manage that process. We must support that process.

This level of integration within the Center of the Internet, the protocols that allow us to share data at light-speed, the shared interdependence of commerce is The Cloud.

Amazon Web Services (“AWS”) recognizes 2006 as a starting point for several cloud-based services by 2016, cloud-based computing and a real sense of trust of the wire-speed services between vendors gelled. In the early days, it was exotic and expensive to be at the Center of the Internet. In 2020, it is likely the cheapest and most efficient way of providing data services to any organization for nearly any reason.

In future chapters, I will explore the Center of the Internet, the technology there, the tricks of the trade, and the clever tricks used to make it efficient.