David Jilk Interview

Sep 8 2011

David Jilk, Founder of Standing Cloud, shares how they make various cloud environments interoperable by standardizing common tasks. David talks about finding the balance between making common things easy without making uncommon things impossible.

Links referenced in the show:

Standing Cloud

The music in the show, Have Mercy — Big Walter Horton, was provided by Mevio’s Music Alley.

Transcription

DJ: Hi. I’m Dave Jilk. I’m CEO and founder of Standing Cloud.
Ryan 00:00:24

Something that I thought was really neat. I played with the test drive with Standing Cloud; I had, like, a Drupal instance up in, like, three minutes. And I just thought it was cool the way it just seemed like everything just works. I mean, I didn’t get, you know, around to really looking at it, you know, deeply; see if I would have to configure something, like, if I wanted to move one of my Drupal installs over to it, but it sure seemed like everything just went seamlessly.
Dave 00:00:47

Yeah. Well, we’ve tried to make Standing Cloud easy to use; that’s kind of one of the objectives of the system. And one of the things that we do, for example, is that we keep a running inventory of servers on each cloud service that we support that are pre-configured with the technology stack that they’re going to need. For example, you know, a Rails stack or a PHP LAMP stack. So we keep those running and we pay for them and, of course, we only need to keep running the derivative of the activity, right? So if, essentially, if people come to our site and deploy an application like you did on a test drive, we fire up a new server in the background. It’s interesting how many problems that solves, actually, with Infrastructure as a Service because the most problematic time is when you spin up a new server on those clouds; that’s actually a weak point. And so by buffering, essentially, the servers that we deploy we make them much more likely to succeed and it’s a lot faster. So, yeah. So that part is very nice. And furthermore, the whole point of our approach is what 451 Group is calling Auto-Ops. In other words, we view at least some developers as preferring not to get into system administration at all if they don’t have to. And so we automate a lot of the things that you might want to do. That said, unlike some Platforms as a Service, and I think there are different categories of platform involving, some platforms do not give you access to Root or even to system administration if you need it, which can be limiting. And we’ve heard that it’s pretty limiting in some cases and so we give you access to that and have a way that you can do that so that you can conform to our portability standards so that it remains easy to deploy, easy to redeploy, easy to move to a different server, move to a different cloud service at any time. So we both do things to retain that as well as give you some standards that you can conform to if you do dig into that level of system administration.
Ryan 00:02:40

That’s really cool. That solves, I mean, a big problem that was in the news recently, right? Like, when Amazon went down sure, they have the AMIs and you can go ahead and re-provision, kind of, servers in their ecosystem. But what you’re saying is, you know, with the portable nature of what you do people could have even just bounced out of Amazon temporarily or for the duration after that point if Amazon goes down.
Dave 00:03:06

Yes. Exactly. I mean, we had no problems with customers or our own systems when Amazon went down because our system actually, kind of, automatically moved things from one service to another if need be. And furthermore, very importantly, just like any good best practice of backups, we keep our best practices off of the cloud where your application is running. So no matter where your application is running, your backups are on a different service so that you’re not locked in there. Otherwise, you’re going back to the days of GoDaddy, you know, where you kind of just have to wait until they fix it. And so, you know, you don’t keep the backup tapes in the data center, right?
RP: Right. It’s funny because it felt like that.
Dave 00:03:45

Yeah. Sure it did. And, you know, Amazon made a big deal about their availability zones and their different data centers and how you can come up in another place and I blogged about this at the time, well before the outage. But the idea of one company having different data centers and availability zones does not solve the problem. There are so many issues that relate to a single company and their systems and the way they work together. And, you know, we’ve seen this with Google, we’ve seen this with Amazon, and many other companies where any problem in one place has effects somewhere else. So you really need to be able to second-source. Now there’s many ways to do that, right? This is the advantage of systems like Chef and Puppet, right, where you can deploy your application automatically. Of course you still have to have the backup data and the ability to bring the data up somewhere else too. So these are bigger problems, especially as the data gets large. But with Standing Cloud and the kind of applications that we deploy, which is not any arbitrary application but rather n-tier traditional business-type applications, we make it easy to do that without having to do the system administration.
Ryan 00:04:51

Yeah. I like that approach; it seems different. It seems like you’re almost somewhere in the middle. Like, Amazon is, you know, the sky’s the limit as far as, like, what you can kind of tweak there, but then on the other side you’ve got something (well, I guess it’s built on top of Amazon) like Heroku, where it’s just a turnkey, deploy your app, but it’s very, very hands-off. It seems like you’re somewhere in the middle where someone could really easily deploy to you and at that point if they need to get in there and tweak things just to make it specifically correct for them they can. Now you have guidelines that they would have to stick to to keep all your portability good bits going, but that said, it’s still just an instance so they can go ahead and just tweak until their heart’s content.
Dave 00:05:37

Early one we debated this issue and there was some sentiment that no, we should simplify it like a typical closed environment like Force.com. Others argued that, you know, no, you couldn’t limit people in that way because they can’t do anything useful. And there are arguments for each, but in the end we came down on the side of let’s try to make it easy to deploy standard things and possible to do non-standard things. And that’s where we ended up coming out and it seems to work pretty well. You know, the thing is at the end of the day if you have three developers in the room, you have four/five different ways of doing things and so you need to accommodate that. Developers are comfortable with their approach, they like it, they have reasons for it, and you can’t tell them, “No, you can’t do that.” On the other hand, they certainly would like things to be easier. And all the things that they agree with and that are standard, they would like to not have to type those commands and look them up and figure them out every time because it’s not the thing that produces value for a software developer. You know, from a software developer’s perspective configuring the system is not value added. It’s the code and the application code that really adds the value. So automating as much as you can and then letting them in where they need to; that’s the approach we’ve taken.
Ryan 00:06:47

Cool. So for the foreseeable future, do you think this idea of just sensible defaults that are pretty much fair game to override; would you say that’s a good strategy that you see going down the road?
Dave 00:06:58

I do and, again, we’re not the only ones to think about this kind of thing. The library of Chef recipes that’s out there has similar kinds of thoughts in it. And yes, we also see the idea, and the system does not support this today, but we see one direction where we would head is that inside enterprises and larger organizations are within open-source communities that are developing on an application, you might want to have an administrative user be able to set certain defaults. In other words, not just use Standing Cloud’s defaults that can then be changed but change the defaults, if you will. And then developers within that environment get their own set of defaults and have to be explicit about making changes to that. Again, rather than making some sort of obscure change to a configuration file that no one remembers when the person leaves.
RP: It’s interesting to think about in that context, where do you think you see the sweet spot of your target audience? Do you think it’s more, like, smaller shops or bigger shops?
Dave 00:07:57

You know, it has been a variety so far and part of that is reflective of our strategy. You know, we work with cloud providers (Infrastructure as a Service providers). Essentially, what is their application layer? Well, we hope it to be Standing Cloud because most of the other services run only on Amazon or on proprietary infrastructure. And so the customer base depends on the particular provider. Some providers that we’re working with have, you know, a customer base that consists of individual developers, consultants, solution providers, var-type people, which is a strong target audience for Standing Cloud. However, we’re also seeing some of the larger companies we’re working with like OpSource; they have a very enterprise-y target audience and customer base and so we’re providing solutions for them as well. We have a partnership with a company called Nexaweb, for example, that does application modernization for enterprises. And they have both a technology stack and professional services that help you port old PowerBuilder apps to Java. And we’ve set up a system called (the underlying technology for a solution they have) called DevCloud. So this is very enterprise-oriented. It’s, you know, Fortune 500 companies.
Ryan 00:09:08

Cool. Have you noticed that there’s, like, a certain workflow. I guess it would be more of an outreach, not something you’d necessarily see just from checking your server logs, but just thinking about -- so I can deploy really easily, but what about things like setting up in tandem, like, a, you know, like, a test environment, things like that? Is there a way to sort of clone it but leave them separate or is that something that you solve? Or is that kind of outside of the realm and the user would have to kind of figure out how that works for them?
Dave 00:09:36

You know, what’s funny is that the way we do things, that’s just a special case of what we do. In other words, everything in Standing Cloud is all about being able to deploy an identical environment, including identical data if you want. And essentially it falls into the realm of how we do backups. When we backup a server or an application we back up all of the code that has changed relative to a particular locked version and all of the data and any configuration changes that have been made. So we back up all the stuff that’s a delta, essentially, to the original and then -- and, you know, of course, if it’s an application that’s built from scratch the original is a blank. And what we do when we restore a backup is we put that all in in the appropriate way for the server and the cloud service where we’re deploying. And so, for example, if you’re a single-server deployment and you need to upgrade to a larger server that’s just the same operation as if you were moving to a new server or restoring a backup in the case of downtime. So, you know, you get a lot of benefits from standardizing how you handle these situations and so we standardize it that way. So the idea of upgrading to a larger server or, you know, other lifecycle type things, those are all straightforward for us because they’re just a special case of the general thing that we do.
Ryan 00:10:54

Cool. Yeah. I guess coming back to it again thinking -- like, I think the thing that’s really compelling, back to the simplicity of your approach; maybe that’s just the, you know, where my mindset is. You know, as a graphic designer I’m usually just trying to see how do you make a solution a little bit more simpler so people are more likely to use it, but it just seems really interesting. Instead of the edge case of, you know, like you said; the false pursuit of this infinite scale, but this idea of you just making it really easy for standard-type environments, right? Just regular people. Most of the people that I run in contact on a normal basis aren’t dealing with Digg-like traffic, at least not on a regular basis. They’re just trying to get an app started.
Dave 00:11:37

Everybody’d like their application to be the most heavily used application in the world and we’d all like to scale up and become Zynga. That is certainly true and we want to have optimism. And I think it’s wise to consider the possibility that your system will grow and possibly even grow rapidly. That said, to the extent that you have to do things that are a big detour to be able to handle that. You know, oftentimes, you know, if you take a lean startup sort of approach you’re probably better off getting something working than you are getting something that scales infinitely but nobody cares about.
RP: Right. Exactly. You’ve just got to launch the thing.
Dave 00:12:12

The promise of Platform as a Service is that if you deploy it there when you’re small it’ll continue to scale and grow with you. The reality is is that if you become Zynga you’re going to have your own, you know, you’re going to have a staff of thousands of people, you know, dealing with all these issues and you’re going to need to optimize so many things and, you know, they even get into issues. Like, most cloud providers other than Amazon don’t even have the scale that they need. And so you get into different sort of issues no matter what. And so I think Platform as a Service is a good approach for most new developers building even Web-scale applications. I think absolutely for business applications. There are actually very few business applications that need to scale beyond a single large server oftentimes. You know, the performance of the application and the language is often so good now. That doesn’t mean that you want to build it so you couldn’t easily move to a horizontal scaling approach. But, again, the reality is that early on you don’t need that. And so the question is can you do it without detouring? And that’s what Platform as a Service is about.
RP: Yeah. It just seems like it’s the kind of situation that can grow, but you really just focus on just getting this thing up and running quickly and painlessly.
Dave 00:13:21

That’s right. And the other thing is that Platform as a Service can create some amount of lock-in and so you want to be careful that if you do scale beyond that and you decide that that platform is no longer for you either because it’s economically not viable anymore or because their systems actually can’t handle what you’re trying to do, then you want to build things in such a way that you’re not completely stuck. And, you know, that’s a continuum as well, right? You can make it so that it’s largely portable but not completely with a pushbutton. Standing Cloud tries to do it in a way that everything is pushbutton, but then, you know, we’ve limited the set of architectures that we support, so. And platforms vary as to how much lock-in they create. As we’ve discussed before, Ryan, you know, Amazon does a lot to make things easier for you, but all those things lock you in quite a bit. Whereas if you build on Heroku and then you want to move to Engine Yard, as long as you’re paying attention it’s probably not that hard.
Ryan 00:14:21

That’s the funny thing about portability, right? Like, you can get your data out, but if you don’t have a somehow congruent system to put it into what good’s that going to do you?
Dave 00:14:33

That’s right. And, you know, not only a congruent system but one that you understand how to get from A to B. You know, you need to be able to make the mapping because they’re never really congruent. So I’ve been a software developer for a long time. Portability is something that is not that bad if you think about it in advance and is horrifically painful if you don’t think about it in advance and that’s the main thing. And by “think about it in advance,” you can build things into your system end solution that make it portable via extraction or you can rely on a system or service that makes portability fundamental.
Ryan 00:15:12

So it’s weird though in platforms that differentiate themselves by kind of abstracting away some of these complexities that if the first thing you have to do to think about the portability of your app is to somehow not use their offerings, right? It seems like you give up some of the benefits if you either have to think about that or, you know, kind of build around that way.
Dave 00:15:37

That’s right. And that’s true of our system as well. In other words, many of the services (the infrastructure services that we support) have features at a lower level that you can’t really access through Standing Cloud because we’ve taken a least common denominator approach to retain that level of portability. Now, you know, there are going to be cases where we need to dig in and support those features and users will then have to realize that that’s creating a non-portable capability or, you know, and this has been our preference is to support it on different providers in a default sort of way using software. So I’ll give you a great example. So we do not use the firewall services of the different cloud providers we support. Instead we install and use the software that comes with the Linux distro to create firewall blocks so that we can completely control it. But we could get in on certain providers and use their firewall and we may yet do that. So these kinds of things, having an alternative mechanism is essential to portability. Otherwise you really have locked yourself in.
Ryan 00:16:40

Oh, that’s interesting. So it’s very much on the ops side, you know, similar to how I would handle new stuff on the front end, right? Like, there’s new HTML5 stuff out there and you use it when you can and when you can’t you just kind of have to patch up, like, a JavaScript alternative for browser support. You’ve got the same thing bouncing your things from server to server. No, it makes a lot of sense.
Dave 00:17:01

Exactly. Now the thing is is that if you do something that has no software kind of even kludgey alternative then you really can’t go anywhere else. But the way to handle those situations as a developer is to isolate them. In other words, if you’ve got a well-defined list of the no-nos that you did, that’s not so bad because you can just go down the list and deal with them when you move. Or I’m a believer that you don’t have to do most of those things. I think developers do get themselves into hot water by configuring things in a custom sort of way because that’s not really their area of expertise and they just wanted to get it to work. And so our view is that probably your application, if it’s user-facing, does not need to get into a lot of system configuration issues. There’s the occasional one, but the hope is that unless it is a very hardcore, Web-scale, complex system with many different roles and components that don’t fit into a typical n-tier architecture, unless you’re doing that then probably working with standard practices is your best bet as a developer.
Ryan 00:18:09

Well, it seems like it would be great to have, you know, you mentioned this list of kind of what works here and ways to configure the files. I think that could be extremely useful for people too. Just thinking about, like, if I bounce from, like, more of a Red Hat-centric server over to, like, a Debian-based system I don’t even know where to keep my config files and that’s a pretty basic, you know, startup thing. And now I need to look up, you know, because they -- it’s just the conventions of the platform. I mean, that’s just talking about the server itself not even, like, all the extra richness that you might have. It seems nice to have, like, this almost, like, this common language that you offer where people don’t have to worry about that.
Dave 00:18:48

That’s right. And we’ve done that for two reasons, just to explain it a little more fully. We treat it as an abstraction layer of configuration. So we keep, regardless of the cloud service and the distro that we’re dealing with, we keep files in a consistent location and we tweak the, kind of, source files to look in the right places so that if a top-notch system administrator were to look at the way we did things they would say, “Oh, okay. I understand. That makes sense.” You know, it might or might not have been the way they did it, but they understand how we did it. So it’s an abstraction layer that’s sensible and logical. It’s not a, kind of, complex invention. It’s not a bunch of binary magic. It’s just system administration done in an organized way. And that abstraction layer allows you then, as a developer, again, like you said, to know where everything is if you do want to make changes and that’s half the battle is finding some of those things. You still will need to, you know, know what you’re doing. To change Apache configurations you have to understand Apache configuration structures and files and you have to understand that there’s a context to everything that you do in the things that have previously been defined. So it’s never easy, but at least having them in the same place isolates what you have done special. You know, if you write a piece of software that runs, you know, let’s just say -- go back to the days that I was writing a lot of code. You know, if you’re writing in C++ and you want something that runs on Windows and Linux and Mac and, you know, maybe anywhere else then you’re going to have some switch statements; that special case, the things that you need to do. Like your forward slash versus your backwards slash and just things like that, right? So each situation is going to need to have special cases. We’ve tried to organize those all in a way that the developer can manage configurations if they want to. Again, part of the point is you shouldn’t have to in most cases, but if that’s the kind of thing you want to get into there’s a way to do it that makes it so that you retain portability and don’t get locked in.
Ryan 00:20:50

Well, speaking for myself I think a lot of times if there’s a solution where I can’t dig in there and tweak things if I have to I will maybe shy away from that to begin with. However, deep down, plan A is not getting in there and tweaking all of those things, right?
Dave 00:21:09

Yeah. Again, like I said earlier, the value added for the developer is the code and the user-facing code and features and capabilities of the application; not the way that the system is configured because the end user couldn’t care less about what your Apache configuration looks like. They want it to be secure, they want it to be fast, they want it to do the thing they’re trying to do, and that’s all they care about. So if we can (we, Standing Cloud) or, you know, again, there are other ways to do this. If we can standardize these practices so that you don’t have to think about it that’s way better because now you can spend your time writing code that adds features and not looking up Linux commands and wondering what this option does and whether it’s the option you need to get the system to kind of work properly.
RP: Ultimately it’s just about letting the developers get out there and build the thing that they’re interested in, right?
Dave 00:21:59

Right. And the thing is of course there are always situations that are exceptional for one reason or another. And so that’s why this combination of automating everything we can and giving them the ability to change it if they have to and in a way that doesn’t conflict with portability and mobility of the app (not in the phone sense but in the moving it around sense). If they can do that then they’ve got mostly the best of both worlds.
Ryan 00:22:28

StandingCloud.com. People can really simply kick the tires. I’m really impressed with how easy that is. And yeah, they should definitely check that out if they’re getting ready to deploy something new or, you know, just looking for a new way to do it, right?
Dave 00:22:42

That’s right. And again, you know, we have a library of 100 different applications and technology stacks. You know, if you’re a person who customizes applications (open-source applications) then it’s a really great and easy way to get started. If you’re working with a development stack and want to just start building an application from scratch the system handles that as well. And either kind of developer or anything in between is definitely something that we’re targeting.
RP: Great. Well, thanks a lot for your time, Dave.
DJ: Thank you, Ryan.