Friday, February 24, 2017

Podcast: Open source and cloud trends with IDC's Al Gillen

Al Gillen is responsible for open source research and oversees developer and DevOps research at IDC. Al gave a keynote at the Open Source Leadership Summit at which he provided some historical context for what's happening today in open source and presented recent research on digital transformation, commercial open source support requirements, and how organizations are thinking about cloud-native architecture adoption and deployment.

Listen to the podcast for the whole conversation but a few specific points that Al made were:

Digital transformation can be thought of as taking physically connected systems and logically connecting them, i.e. connecting the processes, the data, and the decision-making.

It's important to bridge new cloud-native systems to existing functionality. Organizations are not going to be rewriting old applications for the most part and those "legacy" systems still have a great deal of value.

Enterprises are asking for open source DevOps tools, but most are specifically asking for commercially-supported open source tools.

Audio:
Link to MP3 (00:15:46)
Link to OGG (00:15:46)

Transcript:

Gordon Haff:  Hi, everyone. Welcome to another edition of the "Cloudy Chat" podcast. I'm here at the Open Source Leadership Summit with Al Gillen of IDC, who gave one of the keynotes this morning. Welcome, Al. How about giving a little background about yourself?
Al Gillen:  Hey, Gordon, thanks a lot. Thanks, everybody for listening. This is Al Gillen. I'm a group vice president at IDC. I'm responsible for our open source research, and oversee our developer and DevOps research.
Gordon:  One of the things you went through in your keynote this morning was the historical perspective of how Linux is developed. Both of us have pretty much been following Linux from the beginning, certainly from its beginnings as something that was interesting commercially. Maybe you could recap that in a couple of minutes or so.
Al:  I actually went back to a presentation I delivered to the Linux Foundation, an event at the Collaboration Summit that was back in 2008. I pulled those slides up, because I was curious. "What can I learn from what we talked about back then, and how does that relate to what's going on in the industry today?"
I went back, and I pulled up the deck. I was looking at some of the things that I thought were really interesting. For example, I was looking at one of the first pieces of data, which compared perceptions of Linux from 1999 and 2001.
Remember what the time frame was there. Linux had only just begun to be commercially accepted in the '99‑2000/2001 time frame. One of the things that served as a significant accelerator for Linux at that time frame was the dot‑com bust.
What happened then is we had a big contraction in the stock market. Most large companies, what they did is they went and they started to cut costs. We all know that one of the places they first cut costs is IT.
Suddenly, the IT departments were charged with standing up new Web servers and new network‑infrastructure servers and so forth, and they had no budget to do it. What did they do?
They went and they got a free copy of Linux. They recycled a well‑equipped PC or x86 server that had been taken out of service, and they turned it into a Linux server.
When we look back at the data that we saw then, really, one of the big drivers for Linux was initial price. People said, "Yeah, it was great. The cost was really low." One of the things that was also amazing was the users back then rated the reliability of Linux as very, very high.
In fact, when you compare it to other operating systems, it compared very favorably to much more mature operating systems. That context was really fascinating, but when you think about it, that was just the beginning of a long gestation period for Linux.
Over the next, what, seven, eight, nine years, as Linux became a truly mature and a truly robust commercial operating system that had both the features, had the application portfolio, and had the customer base to use it, it took, basically a decade to get there.
Gordon:  You've been doing some more research recently. What are your numbers showing today?
Al:  A couple of things that I showed in the presentation today. One is we presented data on Linux operating system shipments. One of the things that's happened over the last few years is that Linux has continued to accelerate, in part because of the build‑out of cloud.
Most of the public cloud infrastructure, with the exception of the Microsoft Azure cloud, is almost all Linux. To the extent that Google continues to build out and Amazon continues to build out, and companies like that ‑‑ Facebook, Twitter, and so forth, it's primarily Linux being stood up.
That has driven the growth of non‑commercial Linux, meaning distributions that are not supported by a commercial company you might think of, rather are either they're CentOS, or they're Debian, or potentially Ubuntu, that's not supported, things like that, as well as Amazon Linux, and Google's own Linux and so forth.
That's been really where a lot of the growth is, but that's not to say that there hasn't been growth in the commercial side of the market. There's been growth there as well.
Gordon:  What are some of the drivers that you hear? I know you did some research for us. You also have some research here around commercially‑supported environments and maybe some of the reasons why people buy those.
Al:  That has been something which has been really consistent through the years. We find that large enterprise organizations have a tendency to prefer commercially‑supported software.
That has always been the case with Linux and yes, we find that there is [also] non‑commercial Linux. You'll talk to any enterprise ‑‑ and you could talk to a really big Red Hat shop or a big SUSE shop, and you ask them, "What is in your infrastructure?" They'll typically tell you that, "Yeah, we're 95 percent or 98 percent Red Hat, but we've also got some CentOS," or, "We've got some Debian," or, "We've got SUSE for this one application."
They generally have a mix of other things in there. The same thing, if you talk to a SUSE shop, where they'll say, "Yeah, we're mostly SUSE, but we've got some openSUSE," or again, "We've got some Ubuntu or CentOS, or something else in the mix."
The reason why is that these things get stood up for work loads that are considered not critical. Maybe they might be something simple like a DNS server, maybe something that's a print file server, or maybe a Web server which is providing some internal Web serving capabilities, something that's not critical if it disappears off the network suddenly. There's not going to be customers that are left hanging.
Gordon:  Let's switch gears and talk about digital transformation. This is one of those terms that I think is almost a cliche at this point, at least when you go to these types of events, because we hear it at every one of these events.
As somebody I was talking to recently said, just because it's cliche doesn't mean it's not an important trend. What are some of the things that IDC is seeing about digital transformation?
Al:  If we go out to, say 2025, and we look back, I believe that we're going to look back and say, "Yeah, the mid‑teen years were important years from a digital transformation perspective."
When we at IDC talk about digital transformation, what we're really talking about is we're talking about the interconnection of all of the systems that are in our environments.
When I say interconnection, we're not talking about getting them all on the same network. We've done that. It's been done for 20 years, already. What we're talking about is interconnecting the processes, interconnecting the data, interconnecting the decision‑making. In many cases, that's not done.
We've got systems that are physically connected, but are not connected from a logical sense. That's what's happening with digital transformation. I might add that the way we expect that that's going to happen is it's going to be a model where we're going to be building new applications that are going to essentially bridge the existing functionality that's on these servers.
We're not going to be rewriting those old applications in a cloud‑native format, for example. We're going to keep those applications. We may wrap them with some consistent API so we can get access to the logic and the data.
But at the end of the day, the business value that's in those applications that are in place today remains valuable, and frankly, it's going to mean that the applications themselves and the servers that they run on are workloads that are going to be around for the long term.
Gordon:  I think that's a really important point, because one of the things that I hear a lot when I talk to customers is the importance of this bridging of the older systems that may be modernizing, but as you say, you're not turning them into cloud‑native systems.
On the other hand, you have these cloud‑native infrastructures. I think probably in the industry, there's too much thinking of those as two disconnected islands, and not enough thinking of the bridges, the integrations, and so forth, between them.
Al:  There's a really good parallel here, and I like to bring this story up, especially when I'm in a room full of end users. I like to say, "You guys remember what you were doing in 1999?" You get a little bit of a quizzical look, and I say, "Were you remediating any applications that had ywo digit date codes?"
People start nodding their heads. The next question I say is, "What did you do? Did you fix them?" and the heads keep nodding. I say, "OK, can I see a show of hands? How many of you have gotten rid of those systems, or do you still have them in use?"
All those same people, they put their hands up, reluctantly, I might add, and say, "Yeah, we still have those systems in use." The point being is that the value of the systems does not go away. The value of the systems is in the data. It's in the processes and the business logic that are coded in those applications.
Going forward, we think the same thing's going to be true for the distributed computing environment. All of the Linux servers that you have in place, all of the Windows servers you have in place, have real important business value. The logic and the data there is really valuable to your business, which means that you're going to want to use that going forward.
I do agree with you, when we build that cloud‑native applications, they're going to help bridge these systems, but don't for a minute assume that those old systems have no value left.
Gordon:  As we talk about the new applications that are going to be required for this digital transformation, what are some of the...I think you even used the term, they were the "pivot point," this morning. Tell us a little bit more about that.
Al:  Again, taking a long view, so if we look out, say, if you go out to 2025, and you look back, I think that we'll be able to draw a line in history and say, "Somewhere between 2015 and 2017 or 2018, there's going to be this line where everything before that line will be considered a legacy application, and everything after that line is probably going to be a cloud‑native and a modern application."
Again, let's not associate the term legacy application with something that has no value. Let's assume that that's an architectural statement more than anything else.
When I think about it, I believe we're right in the midst of this transition where we begin to build all of our applications using a cloud‑native format, which means that our applications are built to run on‑prem in private cloud, or off‑prem in public cloud, which means that we have flexibility on where they run, how we want to run them, how we want to scale them.
The other thing I might add is remember that cloud‑native and cloud‑scale are not necessarily the same thing. There's lots and lots of applications that should be cloud‑native, but not all applications have to have cloud scale.
Take for example your average enterprise. You've got ‑‑ pick your number ‑‑ it's 1 thousand, 10 thousand, 100 thousand users, whatever the number is, that access your business applications. That number does not scale up to 1 million or 10 million overnight.
By comparison, somebody who's doing, say, business to consumer, where there could potentially be a consumer event that causes everybody to come in and access that application. There you'd need to have the ability to do cloud‑level scaling.
Gordon:  Al, going back to the commercial support still being important, you certainly see in the cloud an awful lot of this consumption of free software, but you mentioned earlier that enterprises by and large do want commercialized tools. We're not talking just operating systems here.
Al:  No, in fact, operating systems are probably one of the best understood pieces of open‑source software today. As we go up the stack, customers still see value associated with commercialization, so a company that will take your project and make it something that is consumable will provide the support.
The reason why that's so valuable is that then the company does not have to have the expertise on staff. You don't have to have a kernel guy, you don't have to have a guy that knows how to patch Xen, for example, or a KVM if there's a problem.
It's really important to have that taken care of by somebody if you're a commercial organization, which is in the business of selling widgets or manufacturing things, or providing health care. That's your primary business. Your primary business is not being in the business of IT.
We ran a survey earlier this year. I guess it was actually late in 2016. We were talking to people about their consumption of DevOps products. We asked a question which I think was really interesting.
The question was if they have a chance to buy a product, are they going to look at a product which is open‑source, or are they going to look at a product which is likely to be a closed‑source and/or a proprietary‑type product?
What we found is we asked people to rank their preference on these things. The answer came back as 45 percent of the people we talked to ranked their preference for an open‑source base product as their first choice over anything else.
If you asked them what their preferences were, for example, for a proprietary product, only 15 percent of the people said that was their first choice.
The reason why this is really interesting is that when we look at that, these companies are telling us that they want an open‑source base product, but they also told us that they wanted it to be commercially supported.
They could get the bits and run it as a project themselves. We asked that question as well. That's not what they're asking for. They're asking for it to be commercially supported. The reason why is if it breaks, you pick up the phone or you get on your computer and send an email, and you say, "Fix it."
Gordon:  That was true going back with Linux in the early days as well. I think one of the things that's happening today when you look at DevOps tools is there is an incredible amount of innovation and number of products out there. That's good news.
The bad news is there's an incredible amount of innovation, rapidly changing products, and a need to integrate all of those together.
Al:  You know what, Gordon? It's one of the challenges that we've had with fast‑moving markets like this. When I say markets, I'm referring to open‑source, collectively.
The problem we have is that the technology changes so fast that the people, the end‑user organizations, are not able to gain the skills fast enough to keep up with these technology changes.
Frankly, when we asked questions about Linux in the early 2000s, people said one of their top challenges was having the skill set to support Linux. Today, we find the same questions about things like container technology and using DevOps tools.
Gordon:  To net it all out and close this out, what are some of the recommendations, the guidance, that you give on probably pretty much a daily basis to your clients?
Al:  There's a few things. Number one, recognize that cloud‑native applications are going to be architected very differently than classic applications. That's pretty much a given, but when you think about it, it affects your choice of tools, it affects your choice of deployment scenarios, and it affects your skills that you need to have on staff.
Another thing is recognize that we've moved to an era of platform independence far beyond anything we ever had before. We always like to talk about platform independence, but we've never really had it.
Now, with container technology and the ability to produce a true cloud‑native application that's running on some kind of a framework which happens to be available on‑prem or in cloud, you suddenly have the ability to move that application on‑prem or off‑prem, or both ‑‑ run in both places at the same time if so you choose ‑‑ and be able to do that in a way that's been unprecedented in our industry.
Finally, just to reiterate the other point is recognize that the existing applications don't lose their value. They still have value. Yes, they may get bundled up in a VM, or maybe packaged up in container and dropped into somebody's IS cloud, but they're going to be around for the long term, and recognize that that's something you have to support.

Again, driving home that point I made earlier, recognize that all the new applications we build today are going to have to bridge the classic applications we've had, and the data that those applications support together with the modern things that we're going to be doing with our new applications.




Post a Comment