[Interview] Harish Pillay, Global Community and Technology Architect, Red Hat Inc

By Nash David Published Date
12 - Dec - 2011
| Last Updated
12 - Dec - 2011
[Interview] Harish Pillay, Global Community and Technology Archit...

We spoke to Harish Pillay, Global Community and Technology Architect, Red Hat Inc. Here's the interview that sheds light on the cloud, apps and other trends in the enterprise market that's relevant to developers.

Harish Pillay, Global Community and Technology Architect, Red Hat Inc


A lot has been spoken about Linux and open source as a whole. It's secure, it's free. For every secure feature spoken about in Linux, there is someone out there working on an attack. How do you plan to address such concerns?

I think the easiest way to answer this question would be to flip it the other way around. When you design something or build something with security in mind, you are always cognizant of the fact that you can have ten measures and if everything works fine, that's great. But on the other side, the other person needs to succeed just once! Whatever ten things you have that is successful, is done away with this one failure. Well that is the story in the proprietary perspective. In the open source perspective, everything that we build is completely transparent. Everybody knows what we are building. So if there is a problem somewhere, that there's something people could try to exploit, you just fix it! So there is a phrase in the open source community that goes, "many eyeballs make all bugs shallow". So the more people looking at stuff, there's no guarantee that everyone would look at it, but the chances are much greater in the open source space than the proprietary space for obvious reasons. Therefore to find something it takes much less time, and happens sooner. This is something that's been proven. If there's an issue it gets solved very quickly and in the case of Red Hat, for example, everything that we do is from scratch. If we have security vulnerability, we know there is a problem and we got to fix it. So our track record has been 95 per cent. We resolve 95 percent of severity 1 queries that need to be resolved within 24 hours. The remaining 5 per cent are solved in the next 24 hours. So over a period of 48 to 72 hours, issues have been fixed. And this is coming from us saying it, this is not Red Hat saying it, this comes from CERT. You can find the details at cert.org.

Since the product was built with security in mind, chances of it having issues are much lower. It's not zero. It's never zero. But it's significantly lower. That's the major plus point here. Security is one of those things where everybody has their own opinion. As long as everything is okay, thing's are fine. The moment something breaks, is where the situation stands out. Our track record here has been very positive. And I don't mean just us here, but open source in general.



The new buzzword around these days is the cloud. Proprietary software developers, enterprise software developers are all promoting a transition to the cloud. Each one of them has an agenda. For example, proprietary software developers want to curb piracy as an issue they face and hence promote the cloud. However in a nation like India where the internet infrastructure has a long way to go, do you see that as a problem?

Oh yes, that would be a problem. That would definitely be a problem. That's an infrastructure problem – until and unless the infrastructure evolves (and it will), since there will always be a demand. As customer demand increases, so will these factors fall into place. Being a capitalist economy, such factors are largely driven by customer demand. So as customer demand increases, the infrastructure will fall into place. Will it happen at a pace that everyone wants, probably no. But it will happen. Assuming I'm an SME, a small manufacturing concern, and I want to check data for my raw material. I realise I am unable to have access to my data because it is all in the cloud, then I'm losing money. That's real tangible, measurable input that will push the investment to increase last mile bandwidth and such factors. So it is such positive reinforcement that will push things forward. So the push will be from service providers, from customers to the ISPs to improve quality of service because it will have an impact on revenue.

What kind of a transition do you see with the preference for cloud based apps? Do you see teams being mobilised for app development?

I think the change will be similar to the transition of building your own thin client based application to a browser based application. That transition happened over the last 10-15 years. It will be that kind of a transition. People will adapt to new models, new ways of doing stuff. They would have frameworks, could be Ruby on Rails, or the JBoss deployment platforms. There are many solutions already in place. The challenge would be whether existing platforms can be moved to that kind of an environment. If it can be done, that would be good. If it can't well, what needs to be done? May be write from scratch. That's an investment. Then the return on this investment needs to be factored. Also there is the option of running the application locally on a VM, and then deploying it from the cloud! So everything that was running in house, is now delivered from off the cloud, but I manage it as if I am managing it locally. So you don't have to throw away your existing investment. So especially to a CIO, it doesn't mean that if your virtualise, you will have to throw out all that you have. In fact the least optimised solution is to virtualise all your existing environment and put it into a virtualised environment, and at some point, move it to a cloud based solution. You still have everything as it was. You now don't have your own hardware. You just manage the application, the OS and the data. So yes, applications will change, and it depends how you adapt to it. This is pretty much the same way it transformed back in the days of thin-clients and browser based apps. Would it happen rapidly? Probably not, because there will be a lot of resistance. At the end of the day it's just people related. Then there are economic conditions. Certain things can accelerate it. If a vendor of an existing solution increases their price, you may have no choice. When he forces you, then you got to do something about it. But things do look good in the long term because it gives you an opportunity to relook at your existing enterprise architecture and analyse whether it is efficient enough. My enterprise architecture may be five years old. Have I been able to review it? Now I am forced to. So now may be I can take off some of the old stuff, clean it up and make it more efficient. So it may turn out to be a blessing in disguise. There are many scenarios that will be played out in different degrees to many different industries. Banks will have a story, airlines will be an entirely different story, manufacturing will be interesting. Because there's 3D printers that are maturing. Would I be required to manuacture in China? May be not because there is a 3D printer available at the corner of the street. So from a production perspective there is an entire change.

What kind of time frame are you looking at?

It depends on several factors, even the economy. It depends how compatibility exists between different countries. In turmoil is when you have an opportunity. And right now, there is opportunity. Whoever is first to go an streamline your process; by streamlining, you need to relook at what you have been doing so far, and ask whether you want to continue to do what you were doing. Can I get the returns that I intended to get? If I move it to this particular environment, will I still get it, or not get it anymore? May be it could be a blackhole. But you have to try.

That was going to be my next question. Is it a blackhole?

Well, it could be. Don't do it blindly. If you don't know what you're doing, don't do it yet. Try in small baby steps. Test the water. You could consider a proof of concept. When you have not-so-critical projects, you could try it out there. This gives you an opportunity to learn and understand what works and what doesn't. This will give you more confidence on how things work. At times, there could be issues. Some of these could even be regulatory in nature. For example, in the banking sector, governments may have laws that state that certain customer data cannot be placed in an environment that is not physically controlled by the bank. So this would be a mutually-learning scenario. We can provide the tools, and the service providers, the SIs, the customers need to figure out what works the best.

As far as Red Hat's business is concerned, how much of it is Cloud enabled? I believe a lot of it is OS based.

Yes, we do have OS components. We also have the middleware component, that is JBoss. All these together make the cloud enabled. They are all cloud enabling tools anyway. Cloud is just the new buzzword. These were the same tools that were there before, expect we just tweak them a bit now because there are certain other expectations to be able to manage and monitor over the web through low bandwidth devices. How do I make sure I have the ability to control systems in a hurry if I have to? So everything that we have provided, has to be provided with that perspective to make it easy for the end user to update and make changes as they require.

So have we tweaked some of our stuff to focus on it? Yes, because the demand was there as well. So we did a couple of things. One of them was OpenShift. OpenShift is a PaaS solution. Are we going to run the PaaS? Well, no. We provide the tools for you, the developer to create and deploy on other hosting platforms, be it Amazon, or somewhere else, not us. Then there is Delta Cloud which is a set of APIs that allow you to migrate from one service provider to another service provider.



So this would enabling moving from one cloud service provider to another?

Yes, you could move from AWS to someone else. We don't want us to have this notion of vendor lock-in. You could migrate from AWS or any platform to say IBM, Savvis, RackSpace and so forth. Some of these are in the process of adding the Delta Cloud API to their environment. If I am a CIO today, I am shopping for a cloud service provider? First, an SLA. Second, how do I exit? That's probably the first question I need to ask. I may like your service, your offering, but at some point in time, we may have to divorce. Products such as Delta Cloud, allow me to exit.

How is that governed? Are there industry standards for migrating across cloud services?

There is reason for a standard there. The idea behind Delta Cloud is exactly that, to create a set of APIs to enable you to migrate from one cloud service provider to another. You might be on IBM today, NTT tomorrow, but the calls are all mapped to the right underlying calls. Delta Cloud is an API that does the mapping. We want to make this industry wide as wide as possible. A lot of people are participating in this project and there's a lot of traction there. It could become a de facto standard because people are using it. In most cases that is more than sufficient. Will it becomes an international standard, well that is altogether a different ballgame.

How is the adoption of open source software by the industry?

Well Red Hat is in a fortunate situation. When economies are doing great, we get customers and so it is good. But when the economy is bad, then it's even better, because they are then stretched to look at alternatives where they can get equal or better performance for a significantly lower price point.


Nash DavidNash David