I would say that we did thin 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…

• How Open Platform as a Service fits into the development process and the industry as a whole
• Building an open software architecture for loosely coupled components and environments
• Developer interaction with Open Platform as a Service
• Dealing with elastic resource demands

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.

Bookmark this: