Cloudy With a Chance of IBM Think 2019

IBM invited me out here to get a good look at the technologies the company has been working on to transform the back end of businesses around the world in an effort to make those businesses more effective and more powerful. And I'm sharing what I found while I was at that conference, and in this episode, I'm going to talk about cloud computing, which is fitting because of the reigning of cats and dogs in San Francisco with in gusts of more than forty miles per hour, so it's a

pretty blustery day for cloud computing. Before I jump into what IBM is talking about specifically, I figure it's a good idea to do a rundown of what cloud computing is, just as a reminder, cloud computing is sort of like computing on demand. It's being able to take advantage of powerful computers and massive storage over a network connection. Typically, the computers that are actually doing all the work are in a data center, possibly miles or even countries away.

The user, whether it's a big company or an average individual, interacts with this through some sort of interface. When you run an application, that application isn't actually running on your device, at least not completely, but rather is running on a computer in that cloud system and returning the results to you. And it helps to have an example, So I'm going to use one that I think helps illustrate what is going on and the challenges that are involved with cloud computing.

Let's take the example of an m m O RPG, or a massively multiplayer online role playing game. These are games in which you use the game's interface to log into a server and connect with the game world before you go on your merry way smashing or faces or whatever. You're doing your online with hundreds or maybe even thousands of other people who are doing similar things and smashing

orc faces. You can interact with those people. Maybe you work with them, maybe you work against them, maybe you just bust out some sweet dance moves while you wait for a quest to populate. But clearly, all these other people aren't on your computer. They're not connecting directly to

your PC. They're playing the game and controlling characters. But those commands couldn't possibly be coming through onto your machine unless you're running the world's most powerful supercomputer, because otherwise you're gaming rig would just give up if it had to handle all of that processing instead. The game running on your computer is kind of like a poor role into an instance being run on some other machine, specifically the server you logged into at the beginning of the game.

Other players are also logged into the server, and the server is keeping track of where everyone is in relation to the game world and in relation to other players. The server is processing the command streams from each player, whether it's a command to get to work, face smashing or to do the moonwalk. It's relaying all those commands out to the respective client computers so that everyone sees the correct respective reactions in the game world. The game

itself is running in the cloud. Your computer is still running some processes to like rendering graphics, for example, but much of the rest is offloaded to the distant computer, and you can easily imagine some of the challenges that come along with this, such as latency. That's the delay between when you send the command and when you see it executed on screen. Well, latency goes well beyond just gaming. It can be in any kind of application. However, that's

just one challenge. There are a lot more than just that, and we'll touch on those now. There are different types of cloud computing, and you'll typically hear about it in terms of public cloud versus private cloud, and then there's the hybrid cloud. So what the heck is the difference. Well, let's start with the simplest first. A public cloud is a system in which a third party provider is responsible for the data centers that you use. You're using someone

else's computers. In other words, IBM does this, as does Google, Amazon and lots of others. Typically, this is a paper use model of cloud computing, and that clients pay the providers for the use of those computing and storage services. However, it also means that the client gives up some of that data management to the provider, and there is a real concern about data security. The idea that if the data isn't under your constant control. There's a day jew

that could get away from you. Whether or not that fear is justified as dependent upon the provider obviously, but it's always there. A private cloud is typically defined as when a company uses its own data centers and manages them to behave the same way a public cloud would, but typically there's some added security features, added privacy features. They might be working with a third party provider for the private cloud software, but they get to maintain the

whole thing themselves. While private clouds can be hosted on site at headquarters, it's also possible to have a private hosting environment within a larger cloud provider. In theory, it would behave like a public cloud to everyone else. The cost for a private cloud approach tends to be a flat feed based on the capacity required, and so it is a predictable, consistent cost as opposed to the on demand, dynamic version with public clouds. A private cloud has its

own challenges. One, the company owning the private cloud has to continually invest in it. It costs money to maintain, manage, and operate the cloud. Over time, it becomes necessary to replace older computers, and you have to carefully manage the information to transfer it over to new systems. Many companies

use both public and private clouds. Some information may be so important, whether because it's mission critical information, or it represents personal data of customers, or both that moving to a pure public cloud approach is not practical or logical. Of course, it's not really that clear cut. It gets way messier than that. For one thing, Larger companies rarely rely on just one type of cloud computing or storage, which leads us to what is called the hybrid cloud.

I wasn't quite sure what a hybrid cloud really was when I was on my way to think two thousand nineteen, but fortunately I had a chance to speak with Hillary Hunter, an IBM Fellow, which by the way, is the high honor IBM grants to top researchers, scientists, engineers, and like. And she's also the chief Technology Officer and VP of cloud computing and hybrid cloud. I figured if anyone had a great definition for hybrid cloud, it would be her.

Here's what she had to say. I'm here with Hillary Hunter and IBM fellow, chief Technology officer expert in all things cloud. You were the person I needed to go to to ask a very important question. Now, my listeners are the general public, and we're just now seeing kind of a mainstream understanding of the general concept of cloud computing, and then we have to go and complicate matters with hybrid cloud. So could you please explain to me what

the hybrid cloud actually means. Yeah, So, people tend to think about the cloud is the place that they store their documents or store their pictures. From a consumer perspective of your general audience, UM, the cloud is certainly a place, you know, with a lot of compute orders in it and a lot of storage capacity UM. But from a business perspective, from an enterprise perspective, it's also a way of doing your software, way of doing your computing UM.

And when we talk about hybrid cloud, what we're doing is taking those capabilities that we refer to as cloud native function UM specific software. You'll hear the terms kubernet

Ease and Docker and other things like that. Those are kind of the software pieces that define what it means to be using a cloud UM, and with hybrid cloud, we're taking that and enabling people to also use that same software, that same computing method and capability on their premises as well, and so rather than having a traditional type of a computer system UM that works in a certain way with a certain set of software, you can take those same computers or by new computers UM and

use Docker and kubernet Ees and these other things that UM constitute cloud native software programming. And you can use that where you are where you're doing business. UM. You know, in your storageing and factoring sites. UM. You can use that in your traditional enterprise data centers that you're using

to run your financial operations or other things like that. UM. And so you can do your processing of credit card transactions UM you know very you know, securely and in the location that you want to do it UM, but

using cloud type of software UM. So hybrid cloud UM just refers to using both public clouds, which consumers are more familiar with because of their music and their files and their pictures and stuff, UM, but also being able to use that same underline software that's driving cloud technology at your place of business. And obviously that would be helpful if you are working with extremely mission critical information, or maybe it's the private information of individuals, maybe it's

a g d p R concerned. It's these sort of things that people have to take into account that you might not want that data on a third party public cloud. Is that correct? Yeah, so that's a good way to think about it. There are many reasons, UM, It's not just one reason why someone might have a private cloud UM and hybrid is that combination of public and private clouds. UM. Some of the reasons you mentioned related to data policies. Certain countries want certain types of data UM in order

to protect consumers in particular kept within their countries. UM. So some companies will choose to use a public cloud provider in their country, or they'll choose to then implement their I T implement their software UM in their own data center in a cloud way so that that data stays within you know, what the government has defined as

the boundaries. Other things have to do with you know, just the process of updating and upgrading what you're doing right, so you know, you can take an existing server that you already own and you can put UM private cloud software on it also and start to create new capabilities related to you know, AI or data processing and other things like that and mix and intermingled with your existing business function. So there's a lot of reasons why people

end up using private cloud technology. Some of it is geographic, some of it's you know, data is concerned. Certainly though it's possible in a public cloud to set up very secure environments, and so sometimes what people do actually is make their own private cloud inside of a public cloud. UM. And so that's kind of where this whole story tends to get a little complicated and technical. UM. But you know,

it's not necessarily only security UM. It can be lots of policy things are just you know, the computers that people already own and moving that forward into a more modern software construct. Now you've mentioned security, and you've mentioned the complex nature of this this uh, this new landscape that we're looking at. I imagine those present certain challenges when you're talking about managing the data across these different clouds, and perhaps you have an application that needs to pull

from different clusters and different clouds. So from I understand, that's one of those big areas of development at IBM. Is that correct? Absolutely? Yeah. So when we're talking about cloud based UM workloads, cloud Blace deployment, I kept coming back to, you know, what the software side of cloud

is in addition to kind of the hardware and storage. UM. What we're talking about is the ability to quickly create function and then deploy that function where you need to have it deployed UM to update it in response to changes in your business or changes in the software capability UM, changes in compliance, changes in regulations UM. So cloud also enables you to create function and push it out to

these different locations UM. And one of the challenges that that introduces is how do I then manage multiple clouds? How do I know what software is running where? UM? Am I spending the amount that I want to spend in a certain cloud? UM? Is everything been patched and updated according to the latest vulnerabilit ease or according to my latest capabilities UM, the latest AI technologies, whatever it

is that I want to deploy. So we have something that we call Multi Cloud Manager UM and i'd be as Multi Cloud Manager enables a single dashboard across these different clouds, so you can see what's going on, you can set policies, you can ensure that you're meeting you know, compliance and other constraints UM. And that really then helps

simplify the fact that the world really is hybrid. It isn't just one public cloud sitting somewhere that everyone is using people are adopting private cloud because of you know, the software advantages, the agility, the new capabilities that that brings. So that is the reality. The world is hybrid, and so once it's hybrid, we want to simplify the visibility to what's going on and simplify the complexity and the control of what's going on in this in this hybrid

cloud era. Gosh, well, Hillary Hunter, I am so thankful that I got a chance to speak with you. You've really helped clear things up. This was an area that I'm very familiar with cloud computing in general, but the more I was getting into this new world, and I believe this might have been the first time this conference the first time I heard the term Kubernetes, and I went on a deep rabbit hole around that to get an understanding. I feel like I've got a much better

grasp of that. So thank you so much, absolutely, And if you want any more. Description of kubernet is, the way I like to think about it is it's sort

of the orchestra conductor. Right. So those two words we were talking about before and in containers and Kubernetes, we call kubernet is actually orchestration software for a good reason, and that you know, you've got all this stuff and containers, that's your cloud workload, and someone's got to coordinate running it, and how much of it runs, and kind of how loud and quiet it is. And so the orchestra conductor is a useful analogy. So Kuberneti is that orchestration orchestration

layer for the cloud. Fantastic, My listeners know, there's very little I love are than an analogy except maybe a pun. So I think that's the perfect way to end this interview. Thank you so much, thanks for having me pleasure being here. This gets more critical the more highly regulated and industry is. According to IBM, the average large corporation has about sixty of its data in the public cloud and in the private cloud, but for more heavily regulated companies, the opposite

tends to be true. Private clouds might hold six of their data and public clouds, So the more regulated the industry, the more data ends up in private clouds. For companies operating in the European Union, which recently put the g d p R rules in place, these sorts of concerns are absolutely critical, as violating GDPR rules results in stiff financial penalties and restrictions. One other term we should define is the edge, not the guy from you too, I'm

talking about edge computing. This is a somewhat vague term and that it can mean different things to different people, but in general, the edge is defined as being geographically close to the request or the source of data. See. Cloud computing has a big limitation, and that is the

speed of light. That's the fastest anything can go. And if you're dependent upon a centralized data center that's hundreds or thousands of miles away, your request has to travel all the way there, and then the response has to travel all the way back, and that can come across as latency. Edge computing means building in some computational power or features into the devices that connect users to the

cloud itself. In other words, some of the work gets done on the mobile device or the computer or personal voice assistant or whatever you're using, as opposed to the model where everything just gets sent up to the cloud, process there and then sent back again. In our m M O RPG example, the graphics rendering may be done at the edge on the gamer's own computer. Next, I'm going to cover something that was a total enigma to me heading into Think two thousand nineteen, which would kubernettes.

But first, let's take a quick break, all right, I need to talk about Kubernetes, and Hillary mentioned this briefly in our conversation, but I really wanted to kind of get down to it. Those developers out there in the audience likely already know what I'm talking about, but I gotta be honest with you, guys. I don't think I had ever encountered the term before going to Think two thousand nineteen, and it took a lot of smiling and nodding to cover up the fact that I was frantically

googling what the heck it was? So, what the heck is it? And why is it important? First to understand Kubernetes, we actually have to take a step back and talk about a concept called virtual machines. Then work our way up to containers and stick with me. For though they're being madness, yet there is method in it. So a virtual machine is kind of what it sounds like. It's a simulated, emulated, or otherwise virtual representation of a computer. You might create a virtual machine in order to run

specific software. For example, let's say it's a personal computer, approach. You have a Mac computer and you want to run virtual Windows machine on your Mac computer so that you can run and access Windows based software, or you might want a separate virtual machine to run new applications. The virtual machine is sequestered from other parts of the computer, so it won't affect the other parts of the computer.

You have a nice development and test environment within which you can build, run and break stuff, and it's not going to affect everything else on that physical machine. But virtual machines are resource hungry and they're not always practical, so there's an alternative called containers. Containers are much more light than virtual machines, meaning they require far fewer resources. They can sequester features, and because of this, they are

rate for the rapid development and deployment of applications. An application might provide numerous services, and each service or feature can live inside a container, so while one team of developers is working on their specific service, other teams can work independently and each service is inside a different container as Docker. A particular flavor of containers defines it quote package software into standardized units for development, shipment, and deployment.

A container is a standard unit of software that packages upcode and all its dependencies so the application runs quickly and reliably from one computing environment to another. A DOCTOR container image is a lightweight, stand alone executable package of software that includes everything needed to run an application code, runtime, system tools, system libraries, and settings end quote. So developers can deploy these containers across different clusters of computers, whether

they're actual physical computers or virtual machines. The applications depend upon the services within these containers to present all the information, but to manage that you need some sort of strategy to oversee the containers. In general, it's called container orchestration. It's all about deploying, managing, scaling, and networking containers and container based applications, and that's what will bring us to Kubernetes.

Kubernetes is a container orchestration open source project. You heard Hillary describe it as being an actual sort of orchestra conductor as an analogy. It's a system that automates deployment and management of multi container applications and can do so at scale. The project works with Doctor containers, but also any other containers that are based on the Open Container Initiative or o c I, which standardizes the container format.

More importantly for this episode, Kubernetes has effectively become the standard for application deployment environments and strategies across numerous clouds, and it can scale up or down as demand warrants. The architecture of Kubernetes depends upon certain abstractions. At the top level of abstraction, you have the Kubernetes clusters. These refer to the actual machines or virtual machines in the

Kubernetes systems and the containers managed by Kubernetes. In those clusters, the cluster must have a master which is the command and control center for the Kubernetes machines. You can actually have multiple machines capable of running Master jobs, but only one may be active at any given time. Within a cluster are nodes, which represent individual physical machines or virtual machines, and within the nodes are pods, the most basic objects in Kubernetes. A pod is a single instance of a

process or instance of an application. The containers themselves exist within pods, and a pod may have one or more containers, but the pod is really the basic unit. To do anything meaning full in Kubernetes itself. Now it gets more technical, but I think this is enough for us to get understanding of the system and the whole point, like I mentioned above, is to have a platform for the deployment

and maintenance of applications that run multiple services. It's a dynamic approach that can scale up or down as demand requires. Another thing that Kubernetes introduces is the argument for open source. I'll talk more about open source in a related podcast, but it's a great time to touch on the idea here.

Open source is an approach to development that is in opposition to the proprietary approach that a lot of companies take, and the goal of both strategies is ultimately the same to develop technology that hopefully works, but the way it happens is very different. With a proprietary approach, everything is

locked down. A company has dedicated developers and engineers, or they've contracted with people who are dedicated to a specific project, and those people develop the technology, which is typically patented or kept as a trade secret. Now this means that if anyone else wants to make use of that technology, whether it's hardware or software, they have to license it from the entity that created the tech in the first place.

Or they have to figure out a different way to essentially accomplish the same result without copying the original design. Apple is an example of this approach. They take the proprietary approach almost every single time. The company maintains a tight control over its own hardware and software. The company is famous for this and doesn't tend to look kindly on those who attempt to circumvent the proprietary nature of

Apple's technology. Now, I don't mean to say this is the wrong approach for Apple, or that the proprietary approach doesn't have merit. It totally does. Apple wants a specific experience with its products. It wants to define that experience, and it can only really guarantee that if it takes such a firm hand in defining what that is all about. But at the same time, Apple is dependent upon the

ingenuity of a relatively small number of developers and innovators. Now, let's contrast that with open source, which is a AND's parent approach to developing technology. An open source project allows anyone to see how the project works. Typically, such projects invite people to take tech and play with it, and they can add to it or modify it, or otherwise try to make it do more than what it could do before, or do what it does even better and

more efficiently. One of the biggest benefits of open source is that it encourages innovation from a broad spectrum of developers. You don't have to be on a special project team in a specific company to contribute your ideas and designs to an open source project. Ideally, this results in technology that evolves super fast as different people apply their ideas to the project, and a project might branch out numerous

unpredictable ways and shepherded by these open source developers. For IBM, perhaps the most important part of going with the open source approach is that allows for a standard that can apply across numerous systems. It's not proprietary, so it doesn't lock anyone into a particular ecosystem. And I'll explain why in just a moment, but first let's take another quick break. Okay, so why would IBM care if clients can move their

stuff around other providers? Well, it's because a fear of lock in is one of the many reasons that companies are reluctant to move more into the cloud, particularly when it comes to mission critical applications and data This reluctance is understandable for the reasons I mentioned earlier. There's a legitimate fear about data security. There's worries about privacy. There's the fear that a company might make a decision to go with a specific provider and then they get stuck there,

even if a better deal comes along later. And then there's the overall concern that as a company's data and computation needs grow more complex, it becomes harder to manage everything, and a company might grow itself out of business if everything becomes an unmanageable If they have a dozen clouds, some private, some public, and their applications are dependent upon multiple clouds, and it's getting harder and harder to coordinate all that they might not be able to innovate anymore. Now.

Since one of the big businesses for IBM is to sell products that help companies manage their cloud operations, it has a strong incentive to encourage companies to move into the cloud. So to do that, IBM has to make sure that such a move actually makes sense, and it has to meet the business needs of clients, has to keep their data safe, and it has to avoid the pitfalls of vendor lock in. So that's why cloud computing

is such a big deal to IBM. Not only do they have their own cloud computing services, they also offer management software to handle activity across numerous clouds, and it's an IBM's best interest to support an open source approach to discourage lock in and remove those barriers of entry to going to the cloud and inspiring rapid innovation in the space. One of the things I got to see here at Think two thousand nineteen was a demonstration of IBMS Multi Cloud Manager tool, and I thought it was

pretty neat. Company executives owed off how the product lets you look at containers across clusters no matter where those clusters might be. You could have an application that pulls data that lives on Amazon servers, Google servers, and your own private servers, and the multi Cloud tool allows developers or managers to view and manipulate the containers for that application no matter where they might be located. So when you consider that these are all very different companies with

their own hardware, this is pretty impressive. IBM feels that cloud computing will take on a growing role in the corporate world moving forward, and that the nature of the complexity of cloud computing provides opportunity for products like the Multi Cloud Manager tool, as well as the chance to apply the Watson platform to numerous cloud based processes and applications. The company has a strong business incentive to push for

this future. So what do I think? I think the cloud approaches are pretty much the future because it makes far more sense to me to use the cloud architecture for development, deployment, and ongoing management of business processes. The strategy moves away from systems that could become legacy machines, that is, obsolete systems that a company has to maintain or else risk losing valuable information or software. The cloud, whether it's public or private, can be a scalable solution.

You can continuously add new equipment, you can port information to the new equipment. You can sunset the older equipment. So as a company grows, it can add more capacity and its cloud, either by building it out itself or working with a provider like IBM or Google or Amazon

or Microsoft. Now, to the average person, this might not matter that much, at least not until you download the latest app from your favorite brand or store or whatever and it doesn't work properly because it can't pull the data in needs, then you'll care a bit, but you might not know the reason behind the app's failure. I think the open source approach is likewise an important element to this future. A company that goes all in with a proprietary strategy might find itself out of luck if

the provider should experience problems. Imagine putting all your eggs in the proprietary basket, and then the company you entrusted reveals has been the target of a massive data breach. Then imagine as that provider starts to struggle in the wake of that revelation and then begins to falter. You'd be worried that all your information and all your systems were inside the computers of a company that's on the

verge of falling apart. An open source approach using a standardized format, I mean, you'd be free to move your data to any provider that used that same standard. So I think IBM is on the right track here. Now will I ever need to worry about this myself? It is doubtful. I haven't received any phone calls from major companies asking if I might be their chief information officer.

But I recognize the importance of the tech and how it powers or at least enables a lot of the stuff I rely upon on a daily basis, So attending Think two thousand nineteen and getting a deeper understanding and appreciation of the technology was a pretty cool experience, even if some of it was over my head and nearly all of it over my pay grade. That wraps up this episode of tech Stuff. If you guys have any questions, or you have comments, or you have ideas for future episodes,

send me a message. The address is tech stuff at how stuff works dot com, or you can hop on over to the web check out text stuff podcast dot com. That's our website where we have the archive of all of our older shows, plus links to our social media so you can get in touch with me there, and also a link to our merchandise store. So go check that out and I'll talk to you again really soon. For more on this and thousands of other topics, is it how stuff works dot com.