Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles SpringSource CTO Adrian Colyer Discusses the Impact of the Cloud on Enterprise IT

SpringSource CTO Adrian Colyer Discusses the Impact of the Cloud on Enterprise IT

At the end of May I attended the inaugural What's Next Conference which took place at 'Le Grand Rex', in the centre of Paris. One of the two keynote speakers was Adrian Colyer, CTO of SpringSource, whose presentation explored the challenges in development and deployment of enterprise applications, and SpringSource's response to them. Afterwards I sat down with Adrian to discuss some of his ideas in a little more detail. The following is a transcript of our conversation.

InfoQ: The first thing I wanted to pick up on was the impact of mobile devices and the general plethora of devices that we have – how you see that impacting how enterprise software is written and designed and how significant you think it is for enterprise developers in general.

Adrian Colyer: Yes, so there are definitely a number of sides to that. Obviously, the thing that everybody thinks about first is the presentation side – all these different form factors and how am I going to deal with it, etc. We seem to have, I guess, three or four different camps at the moment for how that is going to be approached. Right now, I still think the best experience is with native apps, if you really want to nail it. Certainly for Apple I think that is the case. But then there is a camp that says, well all right it's going to be HTML5-based and then there are two ways: are you going to handcraft that for the device, or are you going to use one of these cross-device generation toolkits like a PhoneGap or something like that? I think probably the best result is still going to be taking the pain of picking a set of devices and coding for them.

InfoQ: It was interesting actually because the iPhone rather changed that argument. For a long time everyone was talking, certainly in Europe, about the Java and Java ME thing. It never quite worked, but the general idea was that you had to have Java because then everyone could write for your device and Apple came along and said, "No we're not doing that". And that rather changed things.

Adrian Colyer: It forced a bunch of people's hands, exactly. Now I think it's almost that you are either going to write native or you are going to write an HTML5 app, in some way or another. And if you write that HTML5 app, my view is, let it be a web app that you are accessing on the smartphone rather than trying to emulate a native look and feel. I think that is probably going to work better longer term. There is some really interesting stuff going on in the front-end development community – what they're doing in CSS3 and some of the progressive enrichment stuff – that's pretty interesting. On the client side, there is a bunch of stuff going on and that is certainly going to be a set of new skills. On the back end, it seems that we are settling down on a REST API and you exchange JSON documents. That's the piece of architecture most people can agree on.

InfoQ: You get quite a clean separation with that, don't you?

Adrian Colyer: Yes, you do. If you are doing HTML5 generation, you clearly have got to have some awareness of device types and different view generation back on that side, so there are a bunch of things to think about. And I think the push notifications out to the devices, and how you handle that, may actually change some of those back-end architectures. I have seen a few companies that are pressing more heavily into this, like the media companies, etc. They set up a dedicated node that is going to handle the push notifications. So the way their back end looks is, they have apps generating stuff that put messages on a bus that get picked up by the push notifications, and then it handles the channel out to the devices. And that seems to be a reasonably common pattern, because of the way they are holding all the sockets and all the connections and everything. So that is kind-of interesting. But the other whole dimension to this that really is quite fascinating is actually how the mobile devices are getting into the enterprise at all in the first place, which is largely with executive sponsorship by the back door. I've seen this so many times now. So what happens is – I heard a great story about this last week – some individual says, "I want this on the iPad or the iPhone or this device or that device", and IT says, "Ooh, I don't know about that, it's going to take a long time to do it", and then somebody says, "Oh sod it" and they just do it, and they do it pretty quickly and they get it out there, generally bypassing all the in-house IT processes and procedures and rules to do so. And then the executives see it and they say, "This is fantastic, we love it, we want more" and any kind of punitive measures at that point are completely gone. I've seen this pattern many many times. It's like one of these trends whereby IT are trying to hold off certain things, to prevent things like SaaS and cloud and mobile devices from entering their nice little garden, but there are leaks everywhere. This is definitely one of those. So actually how is it going to affect architecture? Maybe the way it's going to stop is, lots of little ad hoc pockets, and it may not be very well architected as we think of it. It's going to be "just get it done and get it out there", and then eventually there will be a clean-up operation.

InfoQ: For businesses that are adopting cloud and platform as a service, what do you see as the main drivers for that? Why would I do that as a business?

Adrian Colyer: There are certainly a few. One is back to this internal pressure felt on IT. So in a number of companies, the IT organization is responsible for providing a service, and for the first time in a long time the business is able to say to them, "Look, I can go outside and I can get this for whatever price it is and I can have it the next day. How long would it take you and how much would it cost me per unit?". And suddenly they can ask questions of the IT department that they weren't really able to formulate or think about before. That's putting a lot of pressure on internal IT. But the thing that really seems to drive it is speed. I've seen a few people for whom it's about cost but mostly it's about speed. It's about taking out those six weeks to get my box set up. How quickly can I move, how quickly can I have what I want from a business perspective? Don't hold me up. Get it there quickly, and if you are going to tell me it's twelve weeks and I can go outside in two days, again we are talking about the control being broken down. There is a temptation there to go outside, then people start doing it and then it breaks down. So often it's about, "How do I get this level of speed and agility internally?" That's the primary driver. For some companies, there is an element of "Here is another go we can have at standardizing our architecture", so we move everything to this single internal platform as a service. Other companies are thinking more about, "Maybe we'll have multiple platforms as services inside our organization", which is a strange thought to some people when they first come to it. But you think initially, "Well, I've got a dev and test cloud, I've got a production cloud", then you think about the different business groups who might today have different software stacks. Pure green field is pretty hard to come by. So there are two things around this. One is some people think private PaaS is anathema; "What are you talking about, private PaaS doesn't make any sense." But it makes sense because it is that model and that speed that people want, and yet they are scared of trusting their enterprise applications and core data outside their own boundaries at the moment. And so you get those two forces together and suddenly private PaaS looks really logical from that perspective, even though you don't get the same economies of scale, etc. It's still compelling.

InfoQ: So do you think there will be a shift over time so enterprises will start possibly doing their own private PaaS thing and then they move to public offerings?

Adrian Colyer: I actually see it working two ways. One is clearly there are several organizations out there thinking they will never touch the public offerings. Some of these really are now looking at private PaaS and they are starting to stand up that model and so I see that central architecture corporately controlled model coming in. At the same time, remember we talked about those pressures around the mobile applications and just getting them done. So I'm betting that in a bunch of those companies that think they've got it all under control, there are still pockets of small departmental apps that say, "Let's just put it out in the cloud and just do it". And so they are going to end up, whether by conscious design or by subversion plus some conscious design, in a hybrid cloud world. And they have to figure out how to manage and operate and deal with that kind of environment. I suspect once people start to get confidence from the plan perspective – get confidence with the PaaS model in a private setting – then maybe what you do is you get a relationship with a service provider or some other partner that you trust, who are operating an external cloud on your behalf with secure connections to it. That's the next step the business may be comfortable with and then possibly beyond that they may be more open to the public kind of models. Right now – primarily I am speaking for Europe as I go around Europe – most customers are thinking, "I want to do this and I want to do it internally in a place I can trust and control". We have a lot of regulations and things here as well which compounds this whole issue.

InfoQ: Certainly in the UK there are data protection laws and that kind of thing. There are a lot of complications to taking core data off site or into environments that you are less sure about.

Do you think that "cloud" is one of those terms that seems to be have been bandied around forever without necessarily the most clear definition?

Adrian Colyer: I know I almost don't like using the word, I feel a bit dirty when I say it. It's been hijacked by marketing departments and doesn't have much technical meaning at the moment.

InfoQ: Yes, it's hard to say it without feeling like you've just wandered into a Dilbert cartoon or something. But do you think the nature of it is in itself changing? I mean, Amazon Elastic Compute Cloud (EC2) was the first thing that seemed to catch people's imagination and take off.

Adrian Colyer: Yes. Because that's what they saw; they thought, "This is what cloud is". They attached the word "cloud" to what Amazon was offering. And even what Amazon was offering has changed massively. People still pigeonhole them as an infrastructure as a service kind of offering. They do have that, they have a tremendous number of services on that platform as well. Even, latterly, with Beanstalk, they've got the application execution engine and things as well. I do think there's a shift in focus in what people want from the cloud, from easy infrastructure to, "Actually, I just want a place to run my apps". I see that externally, but I've also got some good evidence again from talking to customers. A number of them have put in place internal infrastructure as a service offerings, and the IT department is really proud of it and they can do all that really quickly and then they say, "But it doesn't get used nearly as much as we thought it would". It's a bit disappointing. You actually come to realize there are still gaps between what an application team needs and what infrastructure-as-a-service is providing, and it's enough of a barrier that we do need to start going higher. And they are thinking about maybe not going all the way to full platform as a service in one hit but can I offer a "Database as a service" service, can I offer "Messaging as a service" service, rounding out some of their classic infrastructure services in more of a self-service manner. You see that inside the enterprise as well, this realization of, "We need to move up the stack" is starting to come.

InfoQ: Obviously you launched Cloud Foundry a couple of months ago. What's the take up, how successful is it?

Adrian Colyer: Phenomenal, we're really pleased with that. We set certain targets for where we thought we'd get in a year; we exceeded those targets within a week. We've on-boarded tens of thousands of people now. We still have a backlog of accounts we're processing as fast as we can. Obviously with that comes a lot of apps, and the other nice thing is that we see the statistics of what those apps are doing; it's a good mix across the three primary languages we initially supported, so there is plenty of Java and Spring, and there is also a good amount of Ruby, slightly less node.js than those two but still significant. And there is also very good usage across all the different services – not only lots of people hitting it but also all the different facets of it really starting to get good traction. We see this just as a beginning; there is a whole lot more to come.

InfoQ: What are your revenue streams for it?

Adrian Colyer: Right now, there is no revenue; it's free. We give away the core software open source and we stand up; you don't pay us anything. Right now, it's a negative revenue stream.

InfoQ: Presumably you have a plan?

Adrian Colyer: Absolutely. So it does a number of things. One is that it's a key place for us to learn what it takes to operate a private PaaS. As I have alluded to, we're in conversations with a large number of both end-user customer organizations and also service providers who want to create their own PaaS environments. We're doing it based on Cloud Foundry technology plus a vSphere underneath; don't forget a PaaS has a huge drag on the underlying infrastructure as a service stuff. So you've got all of those avenues for the future. And then one day there might be a model such that if you want to run production stuff on a Cloud Foundry-hosted site, maybe there will be some way to increase your allowances and things.

InfoQ: So, similar to the kind of idea that Amazon has with paid-for resources.

Adrian Colyer: What we try to do at the moment is to attract as big a developer audience as possible to learn what it should look like to host applications in a platform as a service environment – how you build them and what services you need – and then on the flip side to learn as much as possible about operating such an environment, so we can go and help others who want to do so set up a world like that.

InfoQ: Right, yes. That makes sense. Is the micro-cloud idea – essentially putting a cloud on a laptop for debugging purposes – unique to Cloud Foundry? I don't think I've seen anyone else doing that.

Adrian Colyer: I think it is, yes.

InfoQ: And that is a very interesting piece because suddenly I can effectively be developing in that environment.

Adrian Colyer: Even in this little space of time, we've seen interactions of PaaS change the things that developers do because it lowers barriers to entry. One other thing that wasn't expected. Derek Collison [chief architect of VMware's Cloud Services division] told the story. He was working with Mark Lucovsky [technical director at VMware], one of the key founders. Mark was trying to do some stuff with apps and said, "I think I have a problem here, this isn't quite working". And Derek said to him, "What happens when you run it locally outside of the cloud?" Mark said, "I don't know, I haven't tried". And they suddenly realized they had come to this switch point where everything is being done in this micro-cloud environment running locally because it's so much easier to get to all the services from there. And so this micro cloud is a really powerful idea. I think it's also a SpringSource heritage kind of thing to think about, from the developer's perspective, "What's the tooling, what does it feel like, how does this work?" Rather than "there is a runtime server, go deploy to it".

InfoQ: Is SpringSource as a company changing? I guess most people still think of you as Spring the framework and predominantly a Java company. And a lot of Cloud Foundry is written in Ruby.

Adrian Colyer: Cloud Foundry itself is a Ruby app, yes.

InfoQ: So, is there a kind of shift in what you are thinking or what you are thinking about?

Adrian Colyer: At the point of acquisition, we were completely a stand-alone entity and we came in as the SpringSource division of VMware, and I think if you look externally you'll see that. But what has begun to happen, and it's good that it has begun to happen, that the hard boundaries between "here is SpringSource" and "here is some other piece" have been broken down. And really, as I think of it, we have an application platform team. In fact, we have it all under one management structure which comprises people who came from SpringSource, people who came from the acquisitions SpringSource did, like the Rabbit team and the Gemstone team, plus the other runtime components that fit alongside as services in the Cloud Foundry world eventually but that didn't happen to come by the SpringSource path, plus the guys who wrote the core Cloud Foundry application which is a key part of that the PaaS story, plus some people who came across from something called Mozy, which is the backup engine, who had experience in operating services. And we are all one team. So there is an external identity as SpringSource, but internally we are much more merged and fused, which is a really good thing.

InfoQ: The other thing you touched on in your presentation today was the mixing and matching of different languages, which is something that is being talked about a lot but I am not entirely sure how much is really happening, over and above the inevitable consequences of web apps and therefore we've got HTML and JavaScript and all.

Adrian Colyer: The great thing about hosting a platform as a service is you get to see what people are actually doing. One of the surprises is that now you make it so much easier, people are doing it more. I agree it has been talked about forever: polyglot programmers are going to be what you find, but what you really found was a Java team or a Ruby team, and they got on and did their thing. But when it's so easy – because it's the same runtime environment and it's the same services in it – to write each module or part of your app in whatever is the easiest and most natural way, then suddenly it's a much more natural thing to think about doing. If I am deploying to WebSphere application servers – if that's my company's internal standard – writing a little bit on the side in node.js is a pretty painful and awkward thing and the Ops Team are going to reject it. If I've got a platform as a service that doesn't care whether I'm pushing a Java component or a node component or a Rails component, suddenly that barrier is gone.

InfoQ: Is there not an inherent risk to that, though? I mean, one of the arguments that IT teams and companies always seem to use is that we have these standard languages and those are the things we write in and so we have to consider skills, maintenance, all that stuff. If I've got bits written in Ruby and bits written in Python and bits written in Java, and if we assume this thing is going to be in production for several years, I now need Ruby people and Java people and Python people to maintain it.

Adrian Colyer: I think there is a distinction. Here with Cloud Foundry, the thing right now is attracting developers and buzz and interest etc. That developer community loves to be on the cutting edge and wants to use all this new stuff, etc., and really enjoys that side of it. And they are doing things that really are in advance of the banks in London whom I talk to. They are not doing all that stuff; they are much more standardized, controlled, a little more behind the curve. But what those developers are innovating now eventually does start to trickle back. So what people are doing today on Cloud Foundry may be what they are doing in eighteen months or two years time inside the enterprise. Don't make the mistake of thinking what you see on Cloud Foundry as a developer platform today is what's in the enterprise today because there is definitely a time gap between them.

InfoQ: But you think that's where it will go?

Adrian Colyer: I think once there are PaaS-like environments around, then yes I do see more of that happening.

About the Interviewee

Adrian Colyer is the Chief Technology Officer of SpringSource, a division of VMware. He is a key member of the SpringSource team setting strategy and direction for VMware's Cloud Application Platform - which combines the Spring programming model and core runtimes with the vFabric platform services for applications, messaging, and data. Adrian has a long-standing interest in software design and modularity. He led the AspectJ project at, and founded the AJDT and Spring Dynamic Modules projects. In 2004 Adrian was recognised by MIT Technology Review as one of the Top 100 "young innovators" in the world. Adrian has also served on a number of industry groups including the Aspect-Oriented Software Association Steering Committee, the OSGi Enterprise Expert Group, and the Eclipse Architecture Council.

Rate this Article