Matt Tanase Interview

May 19 2011
Download

Matt Tanase, founder of DevStructure and Slicehost, talks with me about all things servers. He shares his experience at Slicehost and being acquired by Rackspace. Then, we talk about his new company that is focused on reverse engineering servers to make deployment more manageable.

Links referenced in the show:

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

Transcription

  1. Matt 00:00:24

    Hi. My name is Matt Tanase. I’m the co-founder of a company called DevStructure and we have an open-source tool called "blueprint" that is used to reverse engineer servers. And previously, I was a co-founder of a company called Slicehost that was acquired by Rackspace and served as the foundation for Rackspace cloud servers.

  2. RP: That is a heck of a resume fodder there. I use Rackspace servers for my stuff. So that’s basically your architecture underneath there making that work, right?

  3. Matt 00:00:58

    It was up until a few years ago. Rackspace is actually very involved with a really cool project called OpenStack, which is an open-source cloud back-end. I don’t know if that’s the official terminology, but it’s basically a more evolved, better designed version of probably what we were initially doing with Slicehost, you know. And it’s in conjunction with a group out of NASA that was working on some of the same problems. And what Rackspace did, and I think was a very smart move, is they went ahead and open-sourced all of that and have really built a vibrant community around OpenStack and have a lot of people contributing to make it better. And that will very soon be probably powering most of the Rackspace cloud’s efforts. And it’s led by a gentleman named Jim Curry that was one of the lead Rackspace people on our acquisition.

  4. RP: You kind of jump started them on the project.

  5. Matt 00:01:51

    Yeah. Certainly, yeah. I mean, all the Slicehost stuff is still in production and running a portion of the Rackspace cloud. And, you know, they’re just evolving beyond it. It’s been, you know, a lot of that code is a few years old at this point so it certainly makes sense for them to kind of be gathering up all the lessons that they’ve learned being one of the two biggest cloud providers around and trying to make it better.

  6. Ryan 00:02:14

    It was interesting a few years ago when I moved over to this server. It was when kind of both were under the Rackspace umbrella: Slicehost and Rackspace servers. And it was a hard choice to make for me because despite Rackspace’s, you know, fanatical service, right, all that I could hear was how amazing your team was at helping developers get up and running with their servers.

  7. Matt 00:02:42

    Well, that’s good to hear. I mean, it’s something that we always prioritize. We billed ourselves as the hosting company that was built for developers. And I think it was a good fit for Rackspace because they had built their company on fanatical customer support. So both of our pedigrees were built around making sure that our customers were happy.

  8. Ryan 00:03:03

    It was interesting that you both seemed to be really competing in a very similar way. And even after both products were under the same umbrella, they were so very similar, right? I guess it wasn’t a big surprise to a lot of people that eventually the brands got consolidated.

  9. Matt 00:03:19

    No. And I kind of talked about it before in some other forums. It certainly makes sense while it sucks for a lot of the Slicehost users and, unfortunately, probably our oldest and most loyal users are the ones that are going to feel the most pain. But it’s way better for everyone involved, both Rackspace and the customers, if everything is under one umbrella because that’s where all their resources are going and that’s where they can have the most support people and the best architecture and the best infrastructure behind it. It’s just that the pain is going to be the transition onto that and away from the legacy Slicehost stuff.

  10. RP: I assume you’re probably more interested in talking about DevStructure at this point, right?

  11. Matt 00:04:06

    You know, I mean, I certainly understand why people are interested about Slicehost. And it, you know, I still like to talk about it so it doesn’t really matter to me. I just don’t want it to seem like a big sales job or something, you know?

  12. RP: Don’t be afraid to talk about it because it’s a really neat product.

  13. MT: Plus it’s open-source so I guess I shouldn’t feel that bad, you know?

  14. Ryan 00:04:20

    Right. That too. I think the problem that you solve is a really interesting one because even I’m, you know, a graphic designer but I do run my own servers for different little projects and things; poorly, I might add. But I definitely know, like, this problem area where sometimes you play with a server and then you want another one. And I don’t remember what I -- it’s working fine now.

  15. MT: Right.

  16. RP: My stack is precariously balanced and everything seems to be okay. I’m a little nervous to do a new one.

  17. Matt 00:04:48

    That’s a dirty little secret of the hosting company is that, you know, you lock people in because people get something set up and they make an investment in the terms of time and effort and the energy required to get a production server up and running and functional. And then they pretty much don’t want to touch it, which is why, you know, to kind of tie it in, a lot of Slicehost customers are upset is because they’ve had stuff there and functioning and working for five years, basically, and they don’t want to move, you know?

  18. RP: If only there was some sort of tool that could help them migrate their servers.

  19. Matt 00:05:25

    It is so ironic. That’s the -- I read that in a comment. Someone’s like, “I cannot believe the irony of what Matt did next is that, potentially, a lot of ex-Slicehosters are going to use that tool to move to another server.” And I’m like, “Yeah.” I can’t say that’s how I drew it all up.

  20. Ryan 00:05:44

    Well, you definitely have, like, a certain area that you seem to be interested in, right? I mean you went straight from, you know, hosting offering to, you know, people that host themselves; a solution for that group, right? It’s definitely, you seem to be drawn in a certain direction.

  21. Matt 00:06:00

    Yeah. I mean I’m interested in the cloud space just because I do really feel like we’re in the beginning of a lot of changes. And, you know, I hate the buzzwords and I hate the sales that’s all going on, but it’s all part of, you know, a massive amount of change that’s taking place in the way that we write and run our applications and the things that we can do with those applications. So it’s really exciting to me and I really like building tools in and around that space. And I like writing software for other developers because I think it’s an audience that you can really not only get some good feedback from very quickly, but also are willing to pay for things that make their life easier and are also willing to tell their friends about your product if it’s good. So, you know, to me it’s a good group to try and win over.

  22. RP: Generally, you only hear someone complain about their hosting offering.

  23. MT: Right.

  24. RP: And I would, oftentimes, either to me or just over here, like, you know, at Refresh or something, people asking about hosting. And it was always, “You’ve got to go with Slicehost. It’s amazing how they treat you and it’s just -- it’s exactly the solution that I want.” It’s amazing. It’s easy to jump straight to, “It was the right tool,” but I think there’s probably something else, right? Because there’s a lot of good software out there that just doesn’t get that kind of response from people.

  25. Matt 00:07:28

    When we started Slicehost, it’s not an exaggeration to say that the hosting landscape really truly sucked. Everyone was using the same back-end software, so all the shared hosts were all using the same piece of crap billing and server management software. And all of the dedicated hosts were also using the same billing and a lot of canned Websites. It was an awful process and I remember having to get a server and, you know, fax in. Now this is in 2006 or late 2005, having to fax in a copy of my driver’s license and my credit card and it literally taking about 36 hours to get a server up from a seemingly reputable and preferred dedicated host. And then on top of that it was $220 a month, or whatever it was. And I just remember thinking, “This is so screwed up and these things suck so bad,” and, you know, in combination with my struggles at trying to find a hosting company and my experience with Rails and, you know, really just falling in love with the framework and how easy it was to do things, and just probably our main advantage, for lack of a better term, was almost ignorance, you know. We didn’t know how to build a hosting company, we didn’t know how to run it, we didn’t know all the challenges. We just looked at the current landscape and thought, “This really sucks. I’m pretty sure we can do something better.” And I think, without question, we did. You know, I’m not saying that Slicehost was the best or anything but, without question, I think we were at the leading edge of companies along with Amazon that kind of jolted the hosting space and made everybody else catch up and, you know, not be stagnant.

  26. Ryan 00:09:22

    Also you had that kind of magic some companies get. I was talking to somebody and they were having problems. And they were like, “Yeah, but I mean these guys are great. We’ll have it fixed in no time.” I was like, “What?” It was such a weird thing to hear someone say. I don’t know if you had, like, a period of downtime or if it was a specific problem to them though. But it was just such an odd response to hear someone say. “They’ll have me back up and running in no time. I know it.”

  27. Matt 00:09:46

    Yeah. I mean, the only thing I can say is that we really have a tremendous amount of respect for our users and we very, without question, we were very much like our users. You know, we expected the same things. I think we’re all logical, understanding, professional people. And if you tell people the truth and you work hard and you keep them updated and you actually explain what’s going wrong, that gets you a long way, you know. We’ve all been in a situation where server’s gone down or something’s not working. And if you just keep saying, “Oh, we’re going to fix it soon,” or, “We’re working on it,” that doesn’t mean anything. But if you say to the 20 people affected, “Here’s what’s going on. We have four drives in that server that are using RAID 10 and one of the drives failed, which is fine, but then a second drive started to fail. But it hasn’t really failed, but it is resyncing so everything’s going really slow. And we’ve got a new drive in there that’s also resyncing so for the next, you know, eight hours things are going to be a little touch and go in terms of your IO, but after that everything’ll be fine.” I mean, how can you argue with something like that? I mean, if someone gives you a technical explanation and our customers were technical people. So they understand and they appreciated that honesty. And I just think that got us a really long way in terms of building loyalty.

  28. Ryan 00:11:17

    So bouncing back from the Slicehost acquisition into this server configuration thing; do you think there was a sense of unfinished business? Because they do seem interestingly related, right?

  29. Matt 00:11:32

    Honestly, not at all. My business partner, Richard Crowley, we met through when I was working at Slicehost. He was one of our early customers and had gone to school in St. Louis, which is where we were based out of. And I met up with him in San Francisco. And after I left Rackspace, we kept in touch and, you know, had lunch and dinner a couple of times. And Richard is very much an alpha developer in the sense that not only is he a great programmer, but he’s an excellent system administrator too. And just knows the right way to build an application and build a server and has very passionate views about the way things should be done. And coming from Slicehost, you know, I saw the way that a lot of our customers used the service and how they built and managed projects. And I think we kind of had some overlapping ideas that there was a lot of pain in the process and that we could make it easier for people to get started and do things over and over and over again. So there were some seeds from Slicehost, but really it was just made from some lessons that I’d learned there and some observations I had made from our user base and Richard, from his time as an engineer at OpenDNS and Yahoo. So when we came together, our initial iteration was really just to make the development lifecycle, the development-production lifecycle I should say, much easier. So how you were writing your applications locally while in development mode should be the same way that they’re running in production mode: that was our premise. So it’s evolved from that but, you know, that was kind of just on its own; didn’t really have anything to do with Slicehost.

  30. RP: Just a very convenient coincidence.

  31. Matt 00:13:24

    Yeah. Like I said, it is kind of scary that a lot of people might use the tool to migrate away from Slicehost as they pointed out in some of the forums and comments on the story.

  32. Ryan 00:13:35

    It’s probably worth going into just real quick to catch everybody up; what is, like, Puppet and Chef and why should they care, in case they’ve never heard of these before?

  33. Matt 00:13:44

    Sure. So Puppet and Chef are the two main tools in what is known as the Configuration Management Space. And both of those tools use a DSL or configuration language that allows you to describe and explain and instruct how a group of servers should be brought up, bootstrapped, provisioned, and configured. So, you know, when we spin up an instance at Rackspace or a server in our datacenter or a server (an EC2 instance at Amazon), they’re basically completely clean, bare images that have none of the data or the configuration we want on them. And when you start to deal with even 2 or 3 or 10 or 50 or 100 servers, you realize very quickly that that is not feasible to be configuring all of those by hand. And similarly, it’s not feasible to be configuring all of those from the same base image because sometimes servers have overlapping components but very different roles and very different configurations. So you can choose a tool like Puppet or Chef to say, “Bring up this server in this role and ensure that these software packages are installed and that these users with these permissions are on the system and that these SSH keys are installed and that these firewall rules are in place.” And moreover, once you have a big running infrastructure, so again that you have 10 or 20 or 100 servers, a month or two down the road you say, “Uh oh, I need to make a change to all of my database servers or all of my application servers,” instead of logging into all of those servers and making a change, you just make that change in your Puppet or Chef server and all of those changes are then automatically propagated to all of the servers in that role. So they’re phoning home, basically, to Configuration Management Server saying, “Has anything changed?, “Do I need to do anything different?” So it’s basically a centralized way to control and manage a bunch of servers.

  34. Ryan 00:15:59

    Well that seems very, very useful. Yeah. I mean, if people haven’t heard about that, they should probably look into it if they’re using what? More than one server or more than zero?

  35. Matt 00:16:08

    I think anyone should consider it with any new project that they start. And the reason I say that is that, you know, we all start projects and most of the time they start and they’re very simple, but they evolve into more complex and bigger problems. And if you start form the very beginning, and hopefully our tool makes it easier for you to do that, then when it does start to grow and evolve and become more complex, it’s very easy; you already have a grasp on that. Whereas if you’re trying to retrofit after it’s gotten outside of your control, that’s when you really feel the pain and that’s when problems start to happen. So if you do it from the very beginning, it’s easy and it’s something you don’t have to think about. And if you don’t need it, you don’t need it. But when you do need it, it’s way worth that little investment that you made to do it right from the start.

  36. RP: Yeah. That’s the real dangers of complexity is when you’re not expecting them, right?

  37. Matt 00:17:10

    Absolutely, you know. We, I mean, we never start off and say, “I hope that in six months this simple single-server application is grown into an eight-server mess that is precariously strung together and I’m waiting for my pager to go off in the middle of the night,” you know? We never want that to happen, it just kind of happens. So if you do it the right way from the beginning, hopefully you never reach that point that you kind of have the reigns and are in control the entire time.

  38. Ryan 00:17:38

    It makes sense. And I really like the part because one of the things that they’ve never made since with me was I was never doing the same thing on a regular basis so automation didn’t really make sense. But I liked how, you know, for the most part, it seems like you can take a lot of the guesswork out, right? Because it’s just a little bit more premeditated in setting things up instead of kind of fixing a problem kind of ad hoc down the way. But I really like how, it seems to me like what DevStructure is is as you kind of find the way to the right answer then you can go ahead and just take that snapshot and move just your config files around. You know, because that’s the problem with a lot of the cloud offerings it seems like is you can’t really move from, you know, Amazon to Rackspace. And really, with Rackspace, you can’t configure it outside of Rackspace and then somehow easily put it in there, which has been, I don’t know, a little frustrating for me, right? It seems like with all these virtual computers, you know, I run, you know, a virtual box on my computer and I set up, like, a dev environment. That’s so far removed from what should be almost the exact same process of the cloud solution that I’m working on, right?

  39. Matt 00:18:48

    Right. Yeah, I mean, I feel like, in a way, you’re kind of our ideal customer for DevStructure and blueprint, or “user,” I should say. I feel like we’re in this transition period where it’s going to take longer than I think anyone would’ve thought, but for the most part, we were all used to working with servers. And, you know, tools like Slicehost and AWS and Rackspace cloud servers, that’s evolved our notion of servers. They’ve now become kind of this flexible set of resources that we can get more than we thought we could faster than we need to and we don’t have to spend a bunch of money to do it. So it kind of becomes this pool of resources we can draw from. But, you know, the other step in that evolution is that people are starting to think of servers as these temporal things that can fail and crash and, you know, be spun up and spun down and, basically, just almost a dumb component of our application architecture. You know, the servers are becoming like, basically, the dumbest pieces. And a tool like Puppet and Chef, it requires a lot of an investment to really utilize how powerful they are. They’re extremely powerful and they can really, I think, propel you into that next stage of thinking in application design and development where you start to do things like that; like spinning up servers at will and bringing up test environments for, you know, four hours of really hammering away on a new release and then spinning it down. And, you know, just for lack of a better word just really doing some, like, alpha development stuff. Alpha, not in the testing sense but in the power-user sense. And what we feel is that we would like to make a way to allow people to get started in the configuration management world but still be able to do it from using tools that they’re familiar with, which we’ve all bootstrapped and configured a server from the command line, you know, using tools like apt-get or yum and editing configuration files and downloading and compiling source. Probably everyone listening to this podcast has done that. But not all of us want to go in and learn a new scripting language or learn a new DSL that’s required to get going with Puppet or Chef. So what blueprint tries to do is to give you a very easy way to export an existing server configuration so that you can either reuse it on another server. So for instance, if you did want to move from Slicehost to some other server and you’ve had a server that’s been running for a few years, you could use blueprint to figure out everything that’s been installed on that server, all of the packages, all of the added software that you downloaded and installed, all of the configuration files that you’ve modified by hand or via your software, and then it puts that into a little JSON file that you could then use to reconfigure a new server the same way or convert it into a Puppet manifest or a Chef configuration file so that you could kind of get started using one of those tools. Because they’re very powerful tools and I really truly believe that everyone will be using that sort of software in the future, but there is kind of a steep learning curve.

  40. Ryan 00:22:33

    Yeah. My approach so far is very trial and error. It’s very, like, I work with Drupal a lot. So if I’ll try to be spinning up new box first it’s okay, so I’ve hit all the requirements, right? And then I’ll hit the site and white screen; not enough PHP memory. Like, you just learn the tells of, “I forgot that one detail.”

  41. MT: Right.

  42. RP: So the idea of it, you know, it’s kind of all being handled for you. It just seems great.

  43. Matt 00:23:01

    I mean that’s what we try and do; we try to make life easier for developers. And I think you said it best. I mean, my theory on this, on configuration management, has been probably I was going to go with the standard 80/20 rule, but I think it’s probably even more than that. I think 90% of developers and administrators know they should be using a tool like that, but unless you felt the pain of having to spin up, you know, tens or dozens of instances and reconfigure them or unless you’re handed an ultimatum that says, “Our infrastructure really, really needs to be flexible and dynamic,” you probably haven’t invested the time into learning one of those tools because they’re hard to learn and we have other stuff to do. You know, personally, I’d rather spend that time making my application better or becoming a better software developer. So what we’re really hoping to do is to make it easy enough that all the people like yourself that know they should be using some sort of config management tool, that our tools can make it so easy that they get started from the very beginning of an application lifecycle using it so that they never reach that pain point; everything’s already in place for them.

  44. RP: More and more, whenever I talk to anyone, and it’s both on designers and developers side, they’re becoming so much generalists that, you know, even a lot of designers are at least dabbling with their own sysadmin stuff, at least, you know, on some level, right?

  45. MT: Right.

  46. RP: Because, you know, budgets are tight or whatever. I guess I do talk to a lot of people who are startups, right? So everybody has to wear many hats. And anything that comes anywhere close to bleeding into your ground, you’re probably going to have to assume that responsibility at some point anyway.

  47. Matt 00:24:42

    Absolutely. I mean, I think the key word is that any startup, virtually any startup, you’re not going to have the resources where you have a dedicated system administration or DevOps team or somebody to handle your back-end, somebody to write your application, and then someone to make it pretty. You know, so design, development, and DevOps are the Holy Grail or the Holy Trinity of a good application. And I think you nailed it, I mean, not to say I think it’s virtually impossible for someone to be good at all three. I think the more likely scenarios are you have people that are really, really top notch at one thing or maybe two things, but for all three it’s just really hard. But you do have to know a little bit of everything, you know. I mean, can you imagine being a top notch programmer and a designer but not being able to spin up instances on AWS or Rackspace and get them going? I mean, you wouldn’t get very far.

  48. Ryan 00:25:42

    Yeah. And it would just be incredibly frustrating. Especially, you know, either if you’re in a startup or if you do consulting work, I mean, you’re really at a loss at that point.

  49. Matt 00:25:50

    Right. And the same way, can you imagine being a, you know, a system administrator that doesn’t know a little bit of coding, you know? And not being able to write a little Perl or Ruby or Python or whatever to make your life a little bit easier. I mean, everyone’s roles are overlapping and the people that are really truly the best I think understand the whole application stack from top to bottom. You know, the one that I, I mean, I think designing is really, truly a talent, but I know tons of people that can draw a pretty interface or say to you, “This isn’t good in terms of usability,” but there are very few that can actually say, “I’m going to take, you know, the Rails application or the Django application or the Java application that you wrote and then I’m actually going to do the graphics and the CSS and the HTML and the JavaScript and I’m going to make it look good.” And, you know, that’s, again, that’s half-developer/half-designer. So what we’re trying to do is maybe make that the DevOps and system administration piece a little bit easier for all of the software developers because you really can’t write an application anymore without thinking about the underlying infrastructure and the components that are going into it. You know, we always used to write apps that had a Web server and a database server and, basically, that was it. And now we all have applications that use multiple databases and maybe even weird databases like some of the NoSQL type stuff. And maybe we have some Web servers and maybe we have load-balance servers and maybe we have queuing servers and we have all these different components and we’re, you know, we’re pulling big files from some sort of cloud storage place and we’re doing some caching for speed and, I mean, we all kind of have to at least be aware of some of the architectural options that are available to us, if not be able to design them from the ground up. And that’s hard so we’re trying to make it easier.

  50. Ryan 00:27:49

    Yeah. I always think of if you give a mouse a cookie, whenever I’m starting a project because, like, well, so I’m the designer and then I’ll do the, well, you know, that means you have to understand the, you know, the front-end development part. Well, yeah, but you kind of end up having at least bleed a little bit. And then, all of a sudden, like, the whole thing is just like, you kind of have your hands or at least opinions about the whole thing before the project’s done.

  51. MT: Right.

  52. RP: It’s so hard to stay isolated. So, yeah. Tools like this that make it just that much more accessible for people. I mean, it’s great to have an expert, but you could just make it a little bit more accessible to people that are willing to put forth more effort. Kind of meet them in the middle with a tool like this.

  53. Matt 00:28:30

    Yeah. Definitely. And, you know, I think the other thing is part of this is where the original idea from DevStructure came from is that when you’re working with a small team and you’re kind of divvying up responsibilities -- maybe I’m the back-end guy or I’m the sysadmin guy and I say,“ Okay. Here’s what our application’s going to do and these are the components that are going to go with it.” I can use a tool like blueprint to say, “Here you go, Ryan. Just install this on your virtual server and, you know, configure that virtual server in just a matter of minutes, exactly the way our production environment is going to look. So then you can run the application locally in an environment that is very similar to your production environment.” And when I say that’s kind of where the original idea for DevStructure came from, you know, in its first iteration last year, our premise was that the way we’re writing applications right now is kind of broken in that a lot of people are using Mac laptops or whatever type laptops and deploying to a Linux or a Windows back-end. And what we were trying to solve was a way to eliminate a lot of that duplicate work where you try and configure your laptop to be just like your production environment. But of course you can’t really do that because you don’t want to trash your laptop with a bunch of junk that you don’t need running on it that’s eating up RAM and disk space and just cluttering your machine. And then you’d have to do everything over again in production and it was never quite the same way. So we were trying to reduce that duplication and tell people to do their development in an environment that mimics what their final production environment’s going to be.

  54. Ryan 00:30:19

    There’s nothing more frustrating than having that dependency that you didn’t realize you had and then trying to find it when you go into production. Like, that’s just one of the worst feelings in the world. “Like, it worked on my box.”

  55. Matt 00:30:31

    Or, you know, you think you’re basically there, you’re done, and you hit return and you get an error. And then you hit return, you get another error. And, you know, each time you’re fixing the error, you’re installing something else, you’re tweaking something. And then, you know, you realize you’ve wasted another 90 minutes on 27 different errors and you’re like, “I was nowhere close to being done,” you know?

  56. Ryan 00:30:50

    Yeah. That’s, I think, one of the things that came to my mind when I first was reading the blurb about DevStructure was, you know, generally, my workflow is find some blog posts about how to set up the perfect whatever server, right, and then kind of follow through. But there’s usually more information in the errata of those than there is in the original post because there’s a typo on this step. And then, like, basically, a lot of these installation steps are very brittle. And if there’s one flaw early on then you have, like, all kinds of problems, you know, with dependencies and stuff.

  57. Matt 00:31:25

    Certainly. You know, and I think the other thing is there are a handful of people that are, you know, again, your really your alpha devs that are designing the application stacks that most of us are using. And I think we’d like to make a tool that makes it very easy for someone to say, “This is the right way to do things and, you know, 80% of you should be doing it this way. Certainly, some of you will fall outside of these lines that I’ve colored, but most of you should be using a stack very similar to this. Here it is. You don’t have to worry about reading a 20-page install and copying and pasting and editing, configuration model.” I mean, that’s dumb; that’s a waste of time. And that’s what, you know, personally, I know I was doing as recently as a couple of years ago, you know. You were trying to figure out how to build and configure a particular stack and you’d google around on the Internet and you’d find two or three different tutorials and you’d kind of read all three of them and be hopping around. And, you know, you’d waste a whole day doing something like that. And we’d really like to make it easy for someone to say, “This is a really top-notch PHP stack or Django stack or Rails stack. Here’s a blueprint and you can spin up a virtual machine using VMware or VirtualBox or whatever or you could spin up a cloud server or EC2 instance and blueprint install that and everything is ready to go in just a minute or two.”

  58. RP: Have you seen any sort of community sprouting up that kind of shares their blueprint? Is that what the terminology is: a blueprint?

  59. Matt 00:32:58

    Yeah. So, initially, that’s what the first iteration of DevStructure was really all about and it was a monthly-pay product and it was closed-source and we had a few hundred people using it, but just not enough people were using it. People weren’t sharing blueprints; that was kind of one of our original visions was that people would be able to share those blueprints and, you know, basically contribute back. Much like we do with GitHub now and open-source code, we wanted to kind of open-source your infrastructure and it just didn’t take off. I mean, that’s as blunt as I can be. So, you know, we gave it a few months. I mean, we launched in, I guess, September of last year. And, you know, by December, I think, we could tell that it just wasn’t catching on. So we tried another iteration of DevStructure, which could kind of be referred to as version two and it was much more decentralized. We did the blueprint sharing, but you didn’t have to come to our Website and it was free. But again, I think our mistake was it was just too complicated and too hard to get started. So we went back to the drawing board and we said, “Well, we don’t want to give up on this because the feedback we have gotten has been very good and we really think we have some good stuff here. So let’s strip away all the other junk that we’ve put into DevStructure and what do we think is the most valuable thing we have?” And that was this tool that my business partner, Richard Crowley, had original written in C and we called it blueprint. And blueprint, we like to say, reverse-engineers a server. So, as I said before, it works backwards to figure out what you’ve done to a server. So what he did was we said, “Well, let’s just make a command line version of blueprint that anyone can use and we’ll open-source it.” So he then converted it to Python from C, hoping to kind of jumpstart the community a little bit, we put it out there, and really got some good publicity, which was basically lucky. And I think probably one of the most important things, GitHub named us, like, the open-source project of the week and that basically lit a fire under it. So we went from, you know, just a couple of hundred people, maybe kind of dabbling with it to several hundred now that are using it and, you know, we’ve got tons of people giving us feedback and telling us about bugs. And, you know, very quickly we went from just supporting Debian servers to now we support Red Hat and Debian servers and things that were installed using apt-get or yum. And that was basically community-driven. Like, the Red Hat people were like, “This looks awesome. How can we help?” And, you know, they gave us lists of files and plus the tools to use. And we thought that would be, like, a month-long addition in terms of man-hours and trying to figure out how to work on Red Hat stuff. And I think we got it done in about a week once we really got some great feedback. And, yeah. Things are going pretty well now. So blueprint is open-source and we’re trying to build, basically, a hosted Puppet service for people that would like to use their blueprints with configuration management but not have to worry about configuring Puppet and having another server that runs it and investing that time. We’d like to just make it easier for people to get started with it.

  60. RP: Oh, interesting. That’s pretty cool.

  61. Matt 00:36:27

    Yeah. So, you know, it’ll be aimed at people like ourselves that are running smaller companies and have smaller projects as opposed to, like, you know, OpsCode has a hosted chef service, but when you look at the pricing, it’s really geared at people that have a lot of servers and it’s not cheap. And we’d like to kind of offer something that’s geared for, you know, most of our peers and our colleagues who are doing maybe small-scale consulting work and small-scale design work and maybe have a startup going on the side or full-time. But just have somewhere between, you know, one and ten servers maybe. So something like Chef or Puppet might be cost-prohibitive, not only in terms of money but in terms of just the time required to learn it and maintain it and keep it updated. We just like it say, “Yeah, we’ll take care of it, you just use blueprint, and on top of that it’ll cost you way less than even having a server would each month.”

  62. Ryan 00:37:25

    That’s interesting. I guess it just goes to speak to where my head is, but when I read about, you know, Puppet or Chef and then also blueprint, immediately what I was thinking of was, you know, like, small consulting shops that kind of do not the same thing, but similar enough things over and over again.

  63. MT: Yeah. Absolutely.

  64. RP: Like, I wouldn’t have even have thought about, you know, like, the large-scale deployment side of things.

  65. Matt 00:37:51

    Right. You know, and that’s the world that I came from too before I started Slicehost was I was doing just contract, consulting, and development work. And you nailed it; you do the same thing over and over again with some slight modifications and tweaks for each customer and project. And the startups that are funded and, you know, are spinning up dozens or maybe even hundreds of instances a week and in production are running 40 or 50 servers, it makes sense for them to say to a guy, “Your job is to become a DevOps expert and learn Puppet or Chef, tell us which one we should use, and manage our infrastructure.” Somebody like that, they’d be irresponsible if they weren’t using a tool like that. But for the rest of us, it doesn’t make sense. So we’re really hoping to kind of capture maybe the smaller end of the market and the people that are doing the same thing over and over again, but are smart enough to know that they should be leveraging these tools because they do make your life easier.

  66. RP: Thanks a lot. I appreciate you taking the time to speak with me today.

  67. MT: Absolutely. Thanks, Ryan.