Speaker 1: Get in touch with technology with tech Stuff from how
Speaker 1: stuff Works dot com. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: How Stuff Works and I heart radio and a love
Speaker 1: of all things tech, and I am at the IBM
Speaker 1: Think two thousand nineteen conference in San Francisco, California. So
Speaker 1: if the audio sounds a little odd, is because we're
Speaker 1: recording this from my hotel room in rainy San Francisco.
Speaker 1: IBM invited me out here to get a good look
Speaker 1: at the technologies the company has been working on to
Speaker 1: transform the back end of businesses around the world in
Speaker 1: an effort to make those businesses more effective and more powerful.
Speaker 1: And I'm sharing what I found while I was at
Speaker 1: that conference, and in this episode, I'm going to talk
Speaker 1: about cloud computing, which is fitting because of the reigning
Speaker 1: of cats and dogs in San Francisco with in gusts
Speaker 1: of more than forty miles per hour, so it's a
Speaker 1: pretty blustery day for cloud computing. Before I jump into
Speaker 1: what IBM is talking about specifically, I figure it's a
Speaker 1: good idea to do a rundown of what cloud computing is,
Speaker 1: just as a reminder, cloud computing is sort of like
Speaker 1: computing on demand. It's being able to take advantage of
Speaker 1: powerful computers and massive storage over a network connection. Typically,
Speaker 1: the computers that are actually doing all the work are
Speaker 1: in a data center, possibly miles or even countries away.
Speaker 1: The user, whether it's a big company or an average individual,
Speaker 1: interacts with this through some sort of interface. When you
Speaker 1: run an application, that application isn't actually running on your device,
Speaker 1: at least not completely, but rather is running on a
Speaker 1: computer in that cloud system and returning the results to you.
Speaker 1: And it helps to have an example, So I'm going
Speaker 1: to use one that I think helps illustrate what is
Speaker 1: going on and the challenges that are involved with cloud computing.
Speaker 1: Let's take the example of an m m O RPG,
Speaker 1: or a massively multiplayer online role playing game. These are
Speaker 1: games in which you use the game's interface to log
Speaker 1: into a server and connect with the game world before
Speaker 1: you go on your merry way smashing or faces or whatever.
Speaker 1: You're doing your online with hundreds or maybe even thousands
Speaker 1: of other people who are doing similar things and smashing
Speaker 1: orc faces. You can interact with those people. Maybe you
Speaker 1: work with them, maybe you work against them, maybe you
Speaker 1: just bust out some sweet dance moves while you wait
Speaker 1: for a quest to populate. But clearly, all these other
Speaker 1: people aren't on your computer. They're not connecting directly to
Speaker 1: your PC. They're playing the game and controlling characters. But
Speaker 1: those commands couldn't possibly be coming through onto your machine
Speaker 1: unless you're running the world's most powerful supercomputer, because otherwise
Speaker 1: you're gaming rig would just give up if it had
Speaker 1: to handle all of that processing instead. The game running
Speaker 1: on your computer is kind of like a poor role
Speaker 1: into an instance being run on some other machine, specifically
Speaker 1: the server you logged into at the beginning of the game.
Speaker 1: Other players are also logged into the server, and the
Speaker 1: server is keeping track of where everyone is in relation
Speaker 1: to the game world and in relation to other players.
Speaker 1: The server is processing the command streams from each player,
Speaker 1: whether it's a command to get to work, face smashing
Speaker 1: or to do the moonwalk. It's relaying all those commands
Speaker 1: out to the respective client computers so that everyone sees
Speaker 1: the correct respective reactions in the game world. The game
Speaker 1: itself is running in the cloud. Your computer is still
Speaker 1: running some processes to like rendering graphics, for example, but
Speaker 1: much of the rest is offloaded to the distant computer,
Speaker 1: and you can easily imagine some of the challenges that
Speaker 1: come along with this, such as latency. That's the delay
Speaker 1: between when you send the command and when you see
Speaker 1: it executed on screen. Well, latency goes well beyond just gaming.
Speaker 1: It can be in any kind of application. However, that's
Speaker 1: just one challenge. There are a lot more than just that,
Speaker 1: and we'll touch on those now. There are different types
Speaker 1: of cloud computing, and you'll typically hear about it in
Speaker 1: terms of public cloud versus private cloud, and then there's
Speaker 1: the hybrid cloud. So what the heck is the difference. Well,
Speaker 1: let's start with the simplest first. A public cloud is
Speaker 1: a system in which a third party provider is responsible
Speaker 1: for the data centers that you use. You're using someone
Speaker 1: else's computers. In other words, IBM does this, as does Google,
Speaker 1: Amazon and lots of others. Typically, this is a paper
Speaker 1: use model of cloud computing, and that clients pay the
Speaker 1: providers for the use of those computing and storage services. However,
Speaker 1: it also means that the client gives up some of
Speaker 1: that data management to the provider, and there is a
Speaker 1: real concern about data security. The idea that if the
Speaker 1: data isn't under your constant control. There's a day jew
Speaker 1: that could get away from you. Whether or not that
Speaker 1: fear is justified as dependent upon the provider obviously, but
Speaker 1: it's always there. A private cloud is typically defined as
Speaker 1: when a company uses its own data centers and manages
Speaker 1: them to behave the same way a public cloud would,
Speaker 1: but typically there's some added security features, added privacy features.
Speaker 1: They might be working with a third party provider for
Speaker 1: the private cloud software, but they get to maintain the
Speaker 1: whole thing themselves. While private clouds can be hosted on
Speaker 1: site at headquarters, it's also possible to have a private
Speaker 1: hosting environment within a larger cloud provider. In theory, it
Speaker 1: would behave like a public cloud to everyone else. The
Speaker 1: cost for a private cloud approach tends to be a
Speaker 1: flat feed based on the capacity required, and so it
Speaker 1: is a predictable, consistent cost as opposed to the on demand,
Speaker 1: dynamic version with public clouds. A private cloud has its
Speaker 1: own challenges. One, the company owning the private cloud has
Speaker 1: to continually invest in it. It costs money to maintain, manage,
Speaker 1: and operate the cloud. Over time, it becomes necessary to
Speaker 1: replace older computers, and you have to carefully manage the
Speaker 1: information to transfer it over to new systems. Many companies
Speaker 1: use both public and private clouds. Some information may be
Speaker 1: so important, whether because it's mission critical information, or it
Speaker 1: represents personal data of customers, or both that moving to
Speaker 1: a pure public cloud approach is not practical or logical.
Speaker 1: Of course, it's not really that clear cut. It gets
Speaker 1: way messier than that. For one thing, Larger companies rarely
Speaker 1: rely on just one type of cloud computing or storage,
Speaker 1: which leads us to what is called the hybrid cloud.
Speaker 1: I wasn't quite sure what a hybrid cloud really was
Speaker 1: when I was on my way to think two thousand nineteen,
Speaker 1: but fortunately I had a chance to speak with Hillary Hunter,
Speaker 1: an IBM Fellow, which by the way, is the high
Speaker 1: honor IBM grants to top researchers, scientists, engineers, and like.
Speaker 1: And she's also the chief Technology Officer and VP of
Speaker 1: cloud computing and hybrid cloud. I figured if anyone had
Speaker 1: a great definition for hybrid cloud, it would be her.
Speaker 1: Here's what she had to say. I'm here with Hillary
Speaker 1: Hunter and IBM fellow, chief Technology officer expert in all
Speaker 1: things cloud. You were the person I needed to go
Speaker 1: to to ask a very important question. Now, my listeners
Speaker 1: are the general public, and we're just now seeing kind
Speaker 1: of a mainstream understanding of the general concept of cloud computing,
Speaker 1: and then we have to go and complicate matters with
Speaker 1: hybrid cloud. So could you please explain to me what
Speaker 1: the hybrid cloud actually means. Yeah, So, people tend to
Speaker 1: think about the cloud is the place that they store
Speaker 1: their documents or store their pictures. From a consumer perspective
Speaker 1: of your general audience, UM, the cloud is certainly a place,
Speaker 1: you know, with a lot of compute orders in it
Speaker 1: and a lot of storage capacity UM. But from a
Speaker 1: business perspective, from an enterprise perspective, it's also a way
Speaker 1: of doing your software, way of doing your computing UM.
Speaker 1: And when we talk about hybrid cloud, what we're doing
Speaker 1: is taking those capabilities that we refer to as cloud
Speaker 1: native function UM specific software. You'll hear the terms kubernet
Speaker 1: Ease and Docker and other things like that. Those are
Speaker 1: kind of the software pieces that define what it means
Speaker 1: to be using a cloud UM, and with hybrid cloud,
Speaker 1: we're taking that and enabling people to also use that
Speaker 1: same software, that same computing method and capability on their
Speaker 1: premises as well, and so rather than having a traditional
Speaker 1: type of a computer system UM that works in a
Speaker 1: certain way with a certain set of software, you can
Speaker 1: take those same computers or by new computers UM and
Speaker 1: use Docker and kubernet Ees and these other things that
Speaker 1: UM constitute cloud native software programming. And you can use
Speaker 1: that where you are where you're doing business. UM. You know,
Speaker 1: in your storageing and factoring sites. UM. You can use
Speaker 1: that in your traditional enterprise data centers that you're using
Speaker 1: to run your financial operations or other things like that. UM.
Speaker 1: And so you can do your processing of credit card
Speaker 1: transactions UM you know very you know, securely and in
Speaker 1: the location that you want to do it UM, but
Speaker 1: using cloud type of software UM. So hybrid cloud UM
Speaker 1: just refers to using both public clouds, which consumers are
Speaker 1: more familiar with because of their music and their files
Speaker 1: and their pictures and stuff, UM, but also being able
Speaker 1: to use that same underline software that's driving cloud technology
Speaker 1: at your place of business. And obviously that would be
Speaker 1: helpful if you are working with extremely mission critical information,
Speaker 1: or maybe it's the private information of individuals, maybe it's
Speaker 1: a g d p R concerned. It's these sort of
Speaker 1: things that people have to take into account that you
Speaker 1: might not want that data on a third party public cloud.
Speaker 1: Is that correct? Yeah, so that's a good way to
Speaker 1: think about it. There are many reasons, UM, It's not
Speaker 1: just one reason why someone might have a private cloud
Speaker 1: UM and hybrid is that combination of public and private clouds. UM.
Speaker 1: Some of the reasons you mentioned related to data policies.
Speaker 1: Certain countries want certain types of data UM in order
Speaker 1: to protect consumers in particular kept within their countries. UM.
Speaker 1: So some companies will choose to use a public cloud
Speaker 1: provider in their country, or they'll choose to then implement
Speaker 1: their I T implement their software UM in their own
Speaker 1: data center in a cloud way so that that data
Speaker 1: stays within you know, what the government has defined as
Speaker 1: the boundaries. Other things have to do with you know,
Speaker 1: just the process of updating and upgrading what you're doing right,
Speaker 1: so you know, you can take an existing server that
Speaker 1: you already own and you can put UM private cloud
Speaker 1: software on it also and start to create new capabilities
Speaker 1: related to you know, AI or data processing and other
Speaker 1: things like that and mix and intermingled with your existing
Speaker 1: business function. So there's a lot of reasons why people
Speaker 1: end up using private cloud technology. Some of it is geographic,
Speaker 1: some of it's you know, data is concerned. Certainly though
Speaker 1: it's possible in a public cloud to set up very
Speaker 1: secure environments, and so sometimes what people do actually is
Speaker 1: make their own private cloud inside of a public cloud. UM.
Speaker 1: And so that's kind of where this whole story tends
Speaker 1: to get a little complicated and technical. UM. But you know,
Speaker 1: it's not necessarily only security UM. It can be lots
Speaker 1: of policy things are just you know, the computers that
Speaker 1: people already own and moving that forward into a more
Speaker 1: modern software construct. Now you've mentioned security, and you've mentioned
Speaker 1: the complex nature of this this uh, this new landscape
Speaker 1: that we're looking at. I imagine those present certain challenges
Speaker 1: when you're talking about managing the data across these different clouds,
Speaker 1: and perhaps you have an application that needs to pull
Speaker 1: from different clusters and different clouds. So from I understand,
Speaker 1: that's one of those big areas of development at IBM.
Speaker 1: Is that correct? Absolutely? Yeah. So when we're talking about
Speaker 1: cloud based UM workloads, cloud Blace deployment, I kept coming
Speaker 1: back to, you know, what the software side of cloud
Speaker 1: is in addition to kind of the hardware and storage. UM.
Speaker 1: What we're talking about is the ability to quickly create
Speaker 1: function and then deploy that function where you need to
Speaker 1: have it deployed UM to update it in response to
Speaker 1: changes in your business or changes in the software capability UM,
Speaker 1: changes in compliance, changes in regulations UM. So cloud also
Speaker 1: enables you to create function and push it out to
Speaker 1: these different locations UM. And one of the challenges that
Speaker 1: that introduces is how do I then manage multiple clouds?
Speaker 1: How do I know what software is running where? UM?
Speaker 1: Am I spending the amount that I want to spend
Speaker 1: in a certain cloud? UM? Is everything been patched and
Speaker 1: updated according to the latest vulnerabilit ease or according to
Speaker 1: my latest capabilities UM, the latest AI technologies, whatever it
Speaker 1: is that I want to deploy. So we have something
Speaker 1: that we call Multi Cloud Manager UM and i'd be
Speaker 1: as Multi Cloud Manager enables a single dashboard across these
Speaker 1: different clouds, so you can see what's going on, you
Speaker 1: can set policies, you can ensure that you're meeting you know,
Speaker 1: compliance and other constraints UM. And that really then helps
Speaker 1: simplify the fact that the world really is hybrid. It
Speaker 1: isn't just one public cloud sitting somewhere that everyone is
Speaker 1: using people are adopting private cloud because of you know,
Speaker 1: the software advantages, the agility, the new capabilities that that brings.
Speaker 1: So that is the reality. The world is hybrid, and
Speaker 1: so once it's hybrid, we want to simplify the visibility
Speaker 1: to what's going on and simplify the complexity and the
Speaker 1: control of what's going on in this in this hybrid
Speaker 1: cloud era. Gosh, well, Hillary Hunter, I am so thankful
Speaker 1: that I got a chance to speak with you. You've
Speaker 1: really helped clear things up. This was an area that
Speaker 1: I'm very familiar with cloud computing in general, but the
Speaker 1: more I was getting into this new world, and I
Speaker 1: believe this might have been the first time this conference
Speaker 1: the first time I heard the term Kubernetes, and I
Speaker 1: went on a deep rabbit hole around that to get
Speaker 1: an understanding. I feel like I've got a much better
Speaker 1: grasp of that. So thank you so much, absolutely, And
Speaker 1: if you want any more. Description of kubernet is, the
Speaker 1: way I like to think about it is it's sort
Speaker 1: of the orchestra conductor. Right. So those two words we
Speaker 1: were talking about before and in containers and Kubernetes, we
Speaker 1: call kubernet is actually orchestration software for a good reason,
Speaker 1: and that you know, you've got all this stuff and containers,
Speaker 1: that's your cloud workload, and someone's got to coordinate running it,
Speaker 1: and how much of it runs, and kind of how
Speaker 1: loud and quiet it is. And so the orchestra conductor
Speaker 1: is a useful analogy. So Kuberneti is that orchestration orchestration
Speaker 1: layer for the cloud. Fantastic, My listeners know, there's very
Speaker 1: little I love are than an analogy except maybe a pun.
Speaker 1: So I think that's the perfect way to end this interview.
Speaker 1: Thank you so much, thanks for having me pleasure being here.
Speaker 1: This gets more critical the more highly regulated and industry is.
Speaker 1: According to IBM, the average large corporation has about sixty
Speaker 1: of its data in the public cloud and in the
Speaker 1: private cloud, but for more heavily regulated companies, the opposite
Speaker 1: tends to be true. Private clouds might hold six of
Speaker 1: their data and public clouds, So the more regulated the industry,
Speaker 1: the more data ends up in private clouds. For companies
Speaker 1: operating in the European Union, which recently put the g
Speaker 1: d p R rules in place, these sorts of concerns
Speaker 1: are absolutely critical, as violating GDPR rules results in stiff
Speaker 1: financial penalties and restrictions. One other term we should define
Speaker 1: is the edge, not the guy from you too, I'm
Speaker 1: talking about edge computing. This is a somewhat vague term
Speaker 1: and that it can mean different things to different people,
Speaker 1: but in general, the edge is defined as being geographically
Speaker 1: close to the request or the source of data. See.
Speaker 1: Cloud computing has a big limitation, and that is the
Speaker 1: speed of light. That's the fastest anything can go. And
Speaker 1: if you're dependent upon a centralized data center that's hundreds
Speaker 1: or thousands of miles away, your request has to travel
Speaker 1: all the way there, and then the response has to
Speaker 1: travel all the way back, and that can come across
Speaker 1: as latency. Edge computing means building in some computational power
Speaker 1: or features into the devices that connect users to the
Speaker 1: cloud itself. In other words, some of the work gets
Speaker 1: done on the mobile device or the computer or personal
Speaker 1: voice assistant or whatever you're using, as opposed to the
Speaker 1: model where everything just gets sent up to the cloud,
Speaker 1: process there and then sent back again. In our m
Speaker 1: M O RPG example, the graphics rendering may be done
Speaker 1: at the edge on the gamer's own computer. Next, I'm
Speaker 1: going to cover something that was a total enigma to
Speaker 1: me heading into Think two thousand nineteen, which would kubernettes.
Speaker 1: But first, let's take a quick break, all right, I
Speaker 1: need to talk about Kubernetes, and Hillary mentioned this briefly
Speaker 1: in our conversation, but I really wanted to kind of
Speaker 1: get down to it. Those developers out there in the
Speaker 1: audience likely already know what I'm talking about, but I
Speaker 1: gotta be honest with you, guys. I don't think I
Speaker 1: had ever encountered the term before going to Think two
Speaker 1: thousand nineteen, and it took a lot of smiling and
Speaker 1: nodding to cover up the fact that I was frantically
Speaker 1: googling what the heck it was? So, what the heck
Speaker 1: is it? And why is it important? First to understand Kubernetes,
Speaker 1: we actually have to take a step back and talk
Speaker 1: about a concept called virtual machines. Then work our way
Speaker 1: up to containers and stick with me. For though they're
Speaker 1: being madness, yet there is method in it. So a
Speaker 1: virtual machine is kind of what it sounds like. It's
Speaker 1: a simulated, emulated, or otherwise virtual representation of a computer.
Speaker 1: You might create a virtual machine in order to run
Speaker 1: specific software. For example, let's say it's a personal computer, approach.
Speaker 1: You have a Mac computer and you want to run
Speaker 1: virtual Windows machine on your Mac computer so that you
Speaker 1: can run and access Windows based software, or you might
Speaker 1: want a separate virtual machine to run new applications. The
Speaker 1: virtual machine is sequestered from other parts of the computer,
Speaker 1: so it won't affect the other parts of the computer.
Speaker 1: You have a nice development and test environment within which
Speaker 1: you can build, run and break stuff, and it's not
Speaker 1: going to affect everything else on that physical machine. But
Speaker 1: virtual machines are resource hungry and they're not always practical,
Speaker 1: so there's an alternative called containers. Containers are much more
Speaker 1: light than virtual machines, meaning they require far fewer resources.
Speaker 1: They can sequester features, and because of this, they are
Speaker 1: rate for the rapid development and deployment of applications. An
Speaker 1: application might provide numerous services, and each service or feature
Speaker 1: can live inside a container, so while one team of
Speaker 1: developers is working on their specific service, other teams can
Speaker 1: work independently and each service is inside a different container
Speaker 1: as Docker. A particular flavor of containers defines it quote
Speaker 1: package software into standardized units for development, shipment, and deployment.
Speaker 1: A container is a standard unit of software that packages
Speaker 1: upcode and all its dependencies so the application runs quickly
Speaker 1: and reliably from one computing environment to another. A DOCTOR
Speaker 1: container image is a lightweight, stand alone executable package of
Speaker 1: software that includes everything needed to run an application code, runtime,
Speaker 1: system tools, system libraries, and settings end quote. So developers
Speaker 1: can deploy these containers across different clusters of computers, whether
Speaker 1: they're actual physical computers or virtual machines. The applications depend
Speaker 1: upon the services within these containers to present all the information,
Speaker 1: but to manage that you need some sort of strategy
Speaker 1: to oversee the containers. In general, it's called container orchestration.
Speaker 1: It's all about deploying, managing, scaling, and networking containers and
Speaker 1: container based applications, and that's what will bring us to Kubernetes.
Speaker 1: Kubernetes is a container orchestration open source project. You heard
Speaker 1: Hillary describe it as being an actual sort of orchestra
Speaker 1: conductor as an analogy. It's a system that automates deployment
Speaker 1: and management of multi container applications and can do so
Speaker 1: at scale. The project works with Doctor containers, but also
Speaker 1: any other containers that are based on the Open Container
Speaker 1: Initiative or o c I, which standardizes the container format.
Speaker 1: More importantly for this episode, Kubernetes has effectively become the
Speaker 1: standard for application deployment environments and strategies across numerous clouds,
Speaker 1: and it can scale up or down as demand warrants.
Speaker 1: The architecture of Kubernetes depends upon certain abstractions. At the
Speaker 1: top level of abstraction, you have the Kubernetes clusters. These
Speaker 1: refer to the actual machines or virtual machines in the
Speaker 1: Kubernetes systems and the containers managed by Kubernetes. In those clusters,
Speaker 1: the cluster must have a master which is the command
Speaker 1: and control center for the Kubernetes machines. You can actually
Speaker 1: have multiple machines capable of running Master jobs, but only
Speaker 1: one may be active at any given time. Within a
Speaker 1: cluster are nodes, which represent individual physical machines or virtual machines,
Speaker 1: and within the nodes are pods, the most basic objects
Speaker 1: in Kubernetes. A pod is a single instance of a
Speaker 1: process or instance of an application. The containers themselves exist
Speaker 1: within pods, and a pod may have one or more containers,
Speaker 1: but the pod is really the basic unit. To do
Speaker 1: anything meaning full in Kubernetes itself. Now it gets more technical,
Speaker 1: but I think this is enough for us to get
Speaker 1: understanding of the system and the whole point, like I
Speaker 1: mentioned above, is to have a platform for the deployment
Speaker 1: and maintenance of applications that run multiple services. It's a
Speaker 1: dynamic approach that can scale up or down as demand requires.
Speaker 1: Another thing that Kubernetes introduces is the argument for open source.
Speaker 1: I'll talk more about open source in a related podcast,
Speaker 1: but it's a great time to touch on the idea here.
Speaker 1: Open source is an approach to development that is in
Speaker 1: opposition to the proprietary approach that a lot of companies take,
Speaker 1: and the goal of both strategies is ultimately the same
Speaker 1: to develop technology that hopefully works, but the way it
Speaker 1: happens is very different. With a proprietary approach, everything is
Speaker 1: locked down. A company has dedicated developers and engineers, or
Speaker 1: they've contracted with people who are dedicated to a specific project,
Speaker 1: and those people develop the technology, which is typically patented
Speaker 1: or kept as a trade secret. Now this means that
Speaker 1: if anyone else wants to make use of that technology,
Speaker 1: whether it's hardware or software, they have to license it
Speaker 1: from the entity that created the tech in the first place.
Speaker 1: Or they have to figure out a different way to
Speaker 1: essentially accomplish the same result without copying the original design.
Speaker 1: Apple is an example of this approach. They take the
Speaker 1: proprietary approach almost every single time. The company maintains a
Speaker 1: tight control over its own hardware and software. The company
Speaker 1: is famous for this and doesn't tend to look kindly
Speaker 1: on those who attempt to circumvent the proprietary nature of
Speaker 1: Apple's technology. Now, I don't mean to say this is
Speaker 1: the wrong approach for Apple, or that the proprietary approach
Speaker 1: doesn't have merit. It totally does. Apple wants a specific
Speaker 1: experience with its products. It wants to define that experience,
Speaker 1: and it can only really guarantee that if it takes
Speaker 1: such a firm hand in defining what that is all about.
Speaker 1: But at the same time, Apple is dependent upon the
Speaker 1: ingenuity of a relatively small number of developers and innovators. Now,
Speaker 1: let's contrast that with open source, which is a AND's
Speaker 1: parent approach to developing technology. An open source project allows
Speaker 1: anyone to see how the project works. Typically, such projects
Speaker 1: invite people to take tech and play with it, and
Speaker 1: they can add to it or modify it, or otherwise
Speaker 1: try to make it do more than what it could
Speaker 1: do before, or do what it does even better and
Speaker 1: more efficiently. One of the biggest benefits of open source
Speaker 1: is that it encourages innovation from a broad spectrum of developers.
Speaker 1: You don't have to be on a special project team
Speaker 1: in a specific company to contribute your ideas and designs
Speaker 1: to an open source project. Ideally, this results in technology
Speaker 1: that evolves super fast as different people apply their ideas
Speaker 1: to the project, and a project might branch out numerous
Speaker 1: unpredictable ways and shepherded by these open source developers. For IBM,
Speaker 1: perhaps the most important part of going with the open
Speaker 1: source approach is that allows for a standard that can
Speaker 1: apply across numerous systems. It's not proprietary, so it doesn't
Speaker 1: lock anyone into a particular ecosystem. And I'll explain why
Speaker 1: in just a moment, but first let's take another quick break. Okay,
Speaker 1: so why would IBM care if clients can move their
Speaker 1: stuff around other providers? Well, it's because a fear of
Speaker 1: lock in is one of the many reasons that companies
Speaker 1: are reluctant to move more into the cloud, particularly when
Speaker 1: it comes to mission critical applications and data This reluctance
Speaker 1: is understandable for the reasons I mentioned earlier. There's a
Speaker 1: legitimate fear about data security. There's worries about privacy. There's
Speaker 1: the fear that a company might make a decision to
Speaker 1: go with a specific provider and then they get stuck there,
Speaker 1: even if a better deal comes along later. And then
Speaker 1: there's the overall concern that as a company's data and
Speaker 1: computation needs grow more complex, it becomes harder to manage everything,
Speaker 1: and a company might grow itself out of business if
Speaker 1: everything becomes an unmanageable If they have a dozen clouds,
Speaker 1: some private, some public, and their applications are dependent upon
Speaker 1: multiple clouds, and it's getting harder and harder to coordinate
Speaker 1: all that they might not be able to innovate anymore. Now.
Speaker 1: Since one of the big businesses for IBM is to
Speaker 1: sell products that help companies manage their cloud operations, it
Speaker 1: has a strong incentive to encourage companies to move into
Speaker 1: the cloud. So to do that, IBM has to make
Speaker 1: sure that such a move actually makes sense, and it
Speaker 1: has to meet the business needs of clients, has to
Speaker 1: keep their data safe, and it has to avoid the
Speaker 1: pitfalls of vendor lock in. So that's why cloud computing
Speaker 1: is such a big deal to IBM. Not only do
Speaker 1: they have their own cloud computing services, they also offer
Speaker 1: management software to handle activity across numerous clouds, and it's
Speaker 1: an IBM's best interest to support an open source approach
Speaker 1: to discourage lock in and remove those barriers of entry
Speaker 1: to going to the cloud and inspiring rapid innovation in
Speaker 1: the space. One of the things I got to see
Speaker 1: here at Think two thousand nineteen was a demonstration of
Speaker 1: IBMS Multi Cloud Manager tool, and I thought it was
Speaker 1: pretty neat. Company executives owed off how the product lets
Speaker 1: you look at containers across clusters no matter where those
Speaker 1: clusters might be. You could have an application that pulls
Speaker 1: data that lives on Amazon servers, Google servers, and your
Speaker 1: own private servers, and the multi Cloud tool allows developers
Speaker 1: or managers to view and manipulate the containers for that
Speaker 1: application no matter where they might be located. So when
Speaker 1: you consider that these are all very different companies with
Speaker 1: their own hardware, this is pretty impressive. IBM feels that
Speaker 1: cloud computing will take on a growing role in the
Speaker 1: corporate world moving forward, and that the nature of the
Speaker 1: complexity of cloud computing provides opportunity for products like the
Speaker 1: Multi Cloud Manager tool, as well as the chance to
Speaker 1: apply the Watson platform to numerous cloud based processes and applications.
Speaker 1: The company has a strong business incentive to push for
Speaker 1: this future. So what do I think? I think the
Speaker 1: cloud approaches are pretty much the future because it makes
Speaker 1: far more sense to me to use the cloud architecture
Speaker 1: for development, deployment, and ongoing management of business processes. The
Speaker 1: strategy moves away from systems that could become legacy machines,
Speaker 1: that is, obsolete systems that a company has to maintain
Speaker 1: or else risk losing valuable information or software. The cloud,
Speaker 1: whether it's public or private, can be a scalable solution.
Speaker 1: You can continuously add new equipment, you can port information
Speaker 1: to the new equipment. You can sunset the older equipment.
Speaker 1: So as a company grows, it can add more capacity
Speaker 1: and its cloud, either by building it out itself or
Speaker 1: working with a provider like IBM or Google or Amazon
Speaker 1: or Microsoft. Now, to the average person, this might not
Speaker 1: matter that much, at least not until you download the
Speaker 1: latest app from your favorite brand or store or whatever
Speaker 1: and it doesn't work properly because it can't pull the
Speaker 1: data in needs, then you'll care a bit, but you
Speaker 1: might not know the reason behind the app's failure. I
Speaker 1: think the open source approach is likewise an important element
Speaker 1: to this future. A company that goes all in with
Speaker 1: a proprietary strategy might find itself out of luck if
Speaker 1: the provider should experience problems. Imagine putting all your eggs
Speaker 1: in the proprietary basket, and then the company you entrusted
Speaker 1: reveals has been the target of a massive data breach.
Speaker 1: Then imagine as that provider starts to struggle in the
Speaker 1: wake of that revelation and then begins to falter. You'd
Speaker 1: be worried that all your information and all your systems
Speaker 1: were inside the computers of a company that's on the
Speaker 1: verge of falling apart. An open source approach using a
Speaker 1: standardized format, I mean, you'd be free to move your
Speaker 1: data to any provider that used that same standard. So
Speaker 1: I think IBM is on the right track here. Now
Speaker 1: will I ever need to worry about this myself? It
Speaker 1: is doubtful. I haven't received any phone calls from major
Speaker 1: companies asking if I might be their chief information officer.
Speaker 1: But I recognize the importance of the tech and how
Speaker 1: it powers or at least enables a lot of the
Speaker 1: stuff I rely upon on a daily basis, So attending
Speaker 1: Think two thousand nineteen and getting a deeper understanding and
Speaker 1: appreciation of the technology was a pretty cool experience, even
Speaker 1: if some of it was over my head and nearly
Speaker 1: all of it over my pay grade. That wraps up
Speaker 1: this episode of tech Stuff. If you guys have any questions,
Speaker 1: or you have comments, or you have ideas for future episodes,
Speaker 1: send me a message. The address is tech stuff at
Speaker 1: how stuff works dot com, or you can hop on
Speaker 1: over to the web check out text stuff podcast dot com.
Speaker 1: That's our website where we have the archive of all
Speaker 1: of our older shows, plus links to our social media
Speaker 1: so you can get in touch with me there, and
Speaker 1: also a link to our merchandise store. So go check
Speaker 1: that out and I'll talk to you again really soon.
Speaker 1: For more on this and thousands of other topics, is
Speaker 1: it how stuff works dot com.