Interview With Brian Sullivan Ė Open Platform As A Service

I would say that we did this interview because the world needs just one more "cloud" post, but that's hard to justify. Still, the cloud seem to be segmenting into infrastructure as a service (IaaS) providers, and platform as a service (PaaS) providers. IaaS (like Amazon Web Services) is basically virtual machines in the sky, and this differs from traditional hosting because with a cloud provider, you should be able to start and stop dozens or hundreds of VMs through an API, and pay only for the CPU hours you use. PaaS (like Google App Engine) gives you a framework to code against, and it's a much more restrictive environment (moving to PaaS is usually a rewrite), but you never worry about individual machines, patching, or all that Jazz.

In this interview, we explore the concept or layering an arbitrary PaaS implementation on top of an arbitrary IaaS provider. HmmmÖ

Scott Swigart: To start, please just take a minute and introduce yourself.

Brian Sullivan: OK, great. Iím the president of Sullivan Software Systems, which makes Open Platform as a Service. We officially launched on June 30th of this year, although we have had it percolating for some time.

Before this, I had various jobs in some large and small corporations and start ups. My background is in development, and I got into web development pretty much at the beginning of the web. My first browser was Mosaic, and I was fortunate enough to work at the first commercial ISP in Boston, Massachusetts, where I was born and raised.

Iíve been doing web development ever since then, so Iíve seen a lot of ideas, concepts, organizations, movements, and standards come and go. It was really a natural conclusion, rather than fight all the different forces that are in play on the Internet, to borrow the best ideas from different realms and try to apply them into a coherent framework that makes sense.

Thatís really where Open Platform as a Service came fromĖthe grassroots of developing hundreds of applications and websites over the years with different teams and folks. Itís also been self-challenging for me.

A lot of developers arenít all that challenged in their nine to five jobs. Thereís a lot of mundane work involved with just trying to get the project out the door, on schedule and on budget. Many donít really get a chance to do things that are that interesting to them, although it helps if youíre in basic or applied research where there isnít the profit pressure.

Part of the motivation for Open Platform as a Service is to do something that makes a lot of sense, rather than chasing after the latest catchy buzzword. Itís an opportunity to try to come up with a whole ecosystem that really makes a difference in software development where the rubber meets the road.

Scott: What does Open Platform as a Service offer to the development process?

Brian: At 10, 000 feet, itís a framework for Platform as a Service. Itís the top layer that the developer interacts with, and it doesnít have any slant toward any of the underlying tools or methodologies. The developer is free to choose whatever tools they want to get the job done.

To drill down a little bit with an example, letís say youíre at a company that has a lot of Java code, and they want to add to that system, but for whatever reason, they donít want to use Java. Maybe its legacy code and theyíve switched to something else.

With Open Platform as a Service, they can keep all that Java code and add different code, functions, applications, or systems from one or more other servers, in a disparate, heterogeneous environment.

Open Platform as a Service will glue that all together and make it all work, so it will handle all the traffic and calling in order to make different code on different servers work together seamlessly to the end user.

For the developer, this approach opens up a lot of opportunities, because youíre not limited to expanding the environment in any particular language. You can leverage your existing code base and the millions of lines of code that are out there on the web with an amazing amount of flexibility.

To take our view down to 5,000 feet, itís a way to make all different code on all different servers interact in real time for the end user and for other developers. You can also expose the functionality to other users and developers.

Scott: Is all of that happening on the server side or the client side? Is it a server-side integration, or is it more like a browser mash-up kind of technology?

Brian: Open Platform as a Service would make standard HTTP calls over the web, so you would dictate where the calls are made, and which parameters are passed. You would get the return results from whichever function that you called over HTTP, and then you can do whatever you want with it.

For example, we could have a CRM system where functions are called from a combination of web services, home-brewed PERL scripts, Ruby on Rails, PHP, and .NET. With Open Platform as a Service, you can leverage all that different code on different servers but at the same time make it all work together seamlessly in a standardized format that makes sense in terms of what developers are used to seeing.

For anybody who comes from a background using any sort of IDE, Open Platform as a Service will be very easy for them to use. They could get up and running literally in a matter of minutes, and it doesnít have any of the legacy baggage of trying to somehow capitalize on an existing investment in a given technology or infrastructure.

Weíve built on top of all of that in the most open way that we could think of.

Scott: Is it accurate, then, to describe it as a tool for building platform as a service that gives you a uniform way of getting data to and from other services, regardless of the programming language theyíre using?

Brian: Thatís a big part of it. Itís standard calls via HTTP to any web server you want, which is important in having an open system.

Scott: What does Open Platform as a Service run on? Is it a Linux technology? Is it a Windows technology? Is it sort of OS agnostic? What does it need underneath it to run?

Brian: Itís OS agnostic, and it can be implemented in any programming language. The actual development environment right now is in PHP, but there are also other languages available. The public cloud weíre running right now is PHP on top of Amazon Web Services for the underlying infrastructure.

Scott: That makes sense. Are there examples of things that are built on this technology that you can point to?

Brian: Yes, there are real applications using it now. I canít go into names, but suffice to say some of the biggest software companies in the world are developing some applications and systems with us.

Scott: You mentioned running on PHP on top of Amazon web services. This is an interesting areaĖproviders who are providing infrastructure as a service. Amazon provides the equivalent of virtual private servers, and while I could still go to a hosting company and get a virtual private server, I could also go to Amazon and through a self service portal and API, I could spin up and down instances myself. Iím only paying per hour, but basically what Iíve got is a full virtual machine.

On the other end of the spectrum, people like Google App Engine are providing platform as a service, but itís very locked in, in the sense that they have a fairly constrained way of development. Theyíve got a couple of languages I could pick.

Originally I could use Python, and now theyíve got Java. One day to store a program against, very constrained, but assuming Iím willing to play in that sandbox, I get the promise of free up to a certain amount of use and just infinite scalability.

And so what Iím seeing is opportunity in this niche that you seem to be fitting into: something in between where I can choose whatever infrastructure provider I want. It could be Amazon, or in the future maybe it could be other infrastructure providers like VMware or other infrastructure as a service providers.

So I can pick whichever one of those makes sense for me, and then I can pick a platform as a service to lay on top of it. I can sort of mix and match the way I want to build code and who I want my infrastructure provider to be, and I can even run it internally, if I want to. Can you speak to that environment Iíve just described and elaborate on it a bit?

Brian: Similar to how we are not forcing anybody to use a particular programming language, we are not actually forcing anybody to use a particular anything. Weíre not coming into this as a cool way to slap some moniker on it, like platform as a service or cloud or whatever just to get in on that rush.

Weíre coming at it from a pure play perspective, to build an open ecosystem that makes sense for developers so they can save time and make better applications in a standard format. Just as we invite people to use any language they want, the same holds true for every component up to development, creation, and delivery in the life cycle.

So pick any programming language you want, use any tool that you want. Use the same tool that you are using today, implement it on any server you want, implement it on any infrastructure, use any database you want, put it anywhere, put any of the parts anywhere you want.

Developers make functions so we can break down something thatís complex and make it reusable and manageable, as well as to distribute the development. Weíre taking that same concept and mapping it over the web, so functions can be anywhere in any language.

The same reasons it makes sense to break down an application into functions, in our opinion, are why you would want to use Open Platform as a Service. From a developerís perspective, it allows you to stand on the shoulders of the right people and try just to do things that make sense.

You could take any language you want, put the code on any server you want, use any cloud you want. You might want to use Amazon for some stuff, but not all of it. You could also use Google for some of the stuff and your corporate server for some other stuff, for example.

With Open Platform as a Service, you can do that; youíre not wedded to one or two. Mix and match whatever you want, use the best tools. Go into the shed, pick the best tools out, go out in the yard, and get the job done. Thatís really the approach to the whole ecosystem of Open Platform as a Service. Other people in your company are counting on you to make the decisions, so weíre saying we agree with that.

This approach also helps standardize the way that you do things, rather than forcing you to be completely ad hoc, trying to glue stuff together as a one-off every time. After all, the most time and effort in software development happens after itís been hacked together the first time. Itís the maintenance and upgrades over time that require most of the time and effort.

With Open Platform as a Service, youíre not stuck with a one-off solution thatís a beast to maintain, because the process has been standardized. The functionality is exposed in a way that makes sense. So to add, modify, and remove functionality is very simple.

As an example, letís say you have an SMTP mail system. With Open Platform as a service, you can change that one component, not touching anything else and hit the ground running, test it, and cut it over almost instantly.

To go back to the same reasons you would make functions for a modular approach, now you can change out car parts. Keep your car going and put in a new air filter or carburetor, but you donít have to change your whole engine.

I think the fact that most of the time and effort and money is spent after the code has been created the first time is often overlooked when people are coming up with development environments and looking at the total cost of software development.

Scott: When Iíve got these different components, like mail systems and Java code, in nuts and bolts terms, when Iím using your stuff, what am I seeing? It doesnít sound like Iím seeing an API, it sounds like what Iím interacting with is more of a development environment or something that lets me put a user interface together that calls out to all of these disparate things. Is that about right?

Brian: Thatís a very good general analysis of it. If we were to compare it to something else thatís out there that we know as developers, you could look at it as a very lightweight IDE. It doesnít have the step through and the source code control and all of that stuff, because it doesnít need it, but, it has an object selector and then a property sheet so you can select objects and then you can work on them.

Itís all 100 percent web based, of course, so thereís no software to install. Youíre looking at standard web content and adding objects in an object selector. Youíre selecting them just like you would in most any IDE, but it is lightweight, because it doesnít need all of the advanced functionalities of a full blown IDE.

In addition to the object selector, thereís what would be analogous to property sheets, so youíre selecting objects and youíre setting properties. Thatís what youíre interacting with as the developer or the business user.

Scott: Does that generate a user interface, or does it generate whatís one layer below the user interface, and then I put a PHP interface or something else like that on top of that?

Brian: This is where we focus in on the word ďOpen.Ē It can be anything you want. Letís say that you develop an application, and you tell me what your end product wants to be. Is your end product going to be some business objects? Is your end product going to be some source code? Is your end product going to be an HTML report system or some business intelligence? What do you want to give your end user?

It is just that open, so it doesnít limit you in terms of the output. You define that.

Scott: It makes me think back to the notion that using whatever traditional software methodologies you want, whether itís agile development, waterfall, or whatever, youíre building different modules. Or youíre identifying modules that already exist out on the web and youíre using a tool to plug that stuff together and emit some kind of an application on top of it. The application could be an AJAX-based Web 2.0 application, or it could be sort of a web service that other stuff would talk to programmatically.

It sounds like a lot of what Open Platform as a Service is storing is metadata about how these things should all connect and come together. Thatís an interesting way to tackle the issue.

One other thing I want to dig into, since you are running on top of Amazon, is the notion of elasticity. Thatís one of the reasons that people turn to cloud providers. For example, people might have a website built around sporting events.

The problem space that those people live in is that, when thereís an event, thereís a huge amount of traffic, and when thereís not an event, thereís very little traffic. Because of that usage pattern, they want to potentially scale up and down their capacity very quickly. Today I have three servers, and tomorrow I need 40 servers. I need them for a week and then I can go back to three.

Talk a little bit about Open Platform as a Service from the elasticity angle.

Brian: Again, in trying to come up with the most open system, weíre saying use whatever infrastructure you feel comfortable with. If you want to go and rent out some time on the most robust system available because youíre doing a Superbowl ad, go ahead and do that, and Open Platform as a Service will enable you to pick any underlying infrastructure.

It sounds like your question is in part about whether there is inherent scalability, reliability, and availability in Open Platform as a Service. The answer is yes, because you can run that on whatever infrastructure you choose to run. The cool thing about that is that we donít say it has to run on Amazon. We donít say that it has to be public.

You can run Open Platform as a Service behind your firewall, in your private cloud, or wherever you want. On your public server, on Google, on IBM Blue Cloud, the next rev or what theyíre calling that. When the next new kid on the block comes out with a cool new infrastructure, youíll also be able to run on that.

You can run it wherever you want, on as many servers as you want, because we will provide that code to you if thatís the way that you feel most comfortable doing it. Weíre not saying all of this is open and you can use whatever you want but you have to use this infrastructure. Weíre saying we are open, pure play through and through. Use it however you as the architect choose the actual underlying infrastructure thatís best for you. And it can change.

To go back to the Superbowl example, youíre going to have an unbelievable number of hits for a very short period of time. So maybe you have it in a private cloud to test it, and everything looks good, and just for that day, you want to run it on the different platform. You can go ahead and do that. Just point it to that new underlying infrastructure, and then after the Superbowl or a week later, bring it back inside your private cloud.

Scott: Whereís the best place for people to kind of kick the tires and see it in action? Where do people go next?

Brian: OpenPlatformAsAService.com. Rolls off the tongue, doesnít it?

laughter

Scott: Is there anything else you want to add?

Brian: One more thing that I would add is that weíre now launching the Open Store, which is a marketplace for developers to sell their applications.

Scott: So if theyíre using Open Platform as a Service as a way to develop applications, then the store is where I could go to see what people have developed and consider whether it would meet my needs?

Brian: Thatís right.

Scott: Cool. Thanks for taking the time to talk today.

Brian: Thank you.

Copyrighted © 2006 - 2010 How Software is Built. Powered by Wordpress.
How Software is Built is sponsored by Microsoft Corp.