Kent Langley on why he thinks Ruby is going to be so disruptive and the importance of scalability. Danish: Today we have Kent Langley with us from SolutionSet. So Kent, can you introduce yourself please.
Kent: Hi, yes, my name is Kent Langley. I’m a senior director at SolutionSet here in San Francisco. Thank you guys for having me on today.
Danish: Thank you for joining us. So could you take a little bit of time to talk to us about your background and what made you so passionate about tech?
Kent: Yea, certainly. Well I think, you know, in general I just think I was made this way or born this way. I’m definitely a technology advocate and something of a geek but I kind of have this entrepreneurial itch that I have to scratch or I get a little bit unhappy. Over the past years I’ve been focusing really heavily on cloud computing, I would say starting probably in early 2006 and, sorry there’s a little background noise over there, and today I am working for a company called SolutionSet doing primarily web systems engineering and operations and large scale deployments for our client base. Once things stop working so much, you get a little bit of success and things can go a little sideways and that's kind of one of the areas I specialize in. My passion for tech just--somebody handed me a computer when I was a little kid and my dad bought me a computer before they were a commodity item and it was just love, you know, it was just a good love affair from there.
Danish: Ok. So can you tell us a little bit about SolutionSet and the history behind it?
Kent: Oh, sure. SolutionSet is the 4th largest independent marketing services company in North America. There are 4 divisions--direct, local, data, and digital. I personally work for the digital division, that division was founded in 2003. There are about 110 people, I think, working for this division out of the total of little over 400 that work for SolutionSet, 6 offices, and the developers here are of all flavors. Ruby, of course, PHP, Python, .NET, Java--we have all those and there’s whole teams of systems engineers, user interface experts, project managers, creatives--that do a lot of the beautiful designs that you see on our work and in general we just have people across the board in the marketing but my focus here is primarily on the digital side.
Danish: Ok. So what does--what is your business philosophy? Do you guys use open source products? What does open source mean to you guys?
Kent: Ok. Business philosophy here at SolutionSet is really simple--its relationships and client value creation. Our best clients are the ones that have been with us for a long period of time, we do project after project with them and I think that because we have such focus on client value creation and integrity, that’s what lends itself to that. You know, it makes me happy when we have a client that comes back again and again--I know I’m doing something right so that’s very important to us. So philosophically, I would say relationships and client value creation. When it comes to open source, yes we absolutely support open source and we do it in a pretty big way because I don’t even think what we do would be as possible in a closed source world. We use just about every open source stack you can imagine in here. And, philosophically, open source is about creation of aggregate value, far beyond your individual contribution or company. And I think that’s where it has its best potential, globally, not just here at SolutionSet. But when you create something that can be shared, improved upon, and then used to create business value in turn and that’s a virtual cycle, you know open source does that better than any other systems of code creation that I know of.
Danish: Ok. So I know you were saying earlier that at SolutionSet, you guys do Java, .NET, and PHP so I’m curious how you guys became involved with Ruby and what steps you guys take to implement Ruby in your business.
Kent: So the way SolutionSet has become involved with Ruby over time is number 1 because our clients are asking for it and so we’re going to help do--we’re going to provide what our clients need. Number 2, its because I happen to personally happen to have quite a love for Ruby and used both in--I would say my use primarily in systems engineering and operations but also I’ve done some interesting projects with development partners over the years and I’ve just not found another community like Ruby that has such a momentum and such a huge number of really bright people contributing, you know, constantly, almost as fast as you can think of something, it seems like you can find a gem for it in a week or so and it doesn’t even matter if you tell anybody about it. You just don’t find that anywhere else, at the moment so I got involved with Ruby personally by just wanting a more solid way to automate system configuration and systems--website deployment in particular with Capistrano, a number years ago. Good work by James Buck there originally and that’s how I found myself digging deeper and deeper and deeper into Ruby.
Danish: Very cool. So I know when we talked before about getting you to do the podcast, scalability was really important to you so if you could tell us, what to your mind, is the significance of scalability and what is a scalability architect and why is this role so crucial.
Kent: Sure. So scalability, there are 2 things that are really important to me about scalability and its not always just about technology, its just as much about people and organizations as it is technology so I think the most scalable systems that are ever build were built from scalable organizations, right, that understand how to get things to scale, right. And in most cases and in my world, it tends to be a website. You hear about web-scale everyday and I think that web-scale, what that really means is that if you have an idea these days that;s pretty straight forward, that execution is the key and when you ask what a scalability architect is, its a scalability architect that takes that little step back and takes a look at systems as a whole, not just the tech but the people too and makes sure that you’re not painting yourself into a corner is the analogy I like to use a lot because you need to make sure you have options. And then there’s a common misconception that scalability is expensive or too expensive, prohibitively expensive to even think of and to avoid premature scaling at all costs. Well its kind of--it can be expensive to scale and grow but--and its true you should scale prematurely but its absolutely not true that you shouldn’t think about it. You need to have a plan to grow and I think that’s where scalability architects come into play. I don’t even know, yet, if that’s truly a title that’s common out in the world but I do know that I’m starting to see a lot more trends of people talking about it and I’m please to see that because scalability architect--you don’t get that from a book you get that from experience and you get that from really loving what you do and being able to look at systems as a whole and make sure that as they grow, they have a way to scale. It doesn’t mean they wont fail sometimes. Sometimes they do, but it means you’ll have options when they do.
Danish: Ok. So, I know with scalability a lot of people talk about databases and I read this great post on HackerNews that discussed key differences between few of the no-sequel databases and their pros and cons, so I was curious, which no-sequel databases have peaked your interest the most and why?
Kent: So, definitely read that article as well and there are numerous other out there doing those comparisons now and I’m really pleased. The most important thing they do on those comparisons is they talk about when you should use something and why, not just how it works and what it is. And so I tend to favor articles that have the whens and whys and--there are 2, really, that have caught my attention and not just my attention but my time, meaning that I’m actually actively building and installing and running systems that are using them. I have a tendency to use Redis fairly frequently. I have a tendency to use Riak. I’m doing a project right now for a substantial size customer where we needed something like Riak and there was just nothing else that had distributed data store at its core with scalable reads and writes, you know, meaning you just add another node of things get a little faster. So, the use case for Redis in my case are a little different. I needed about a 60:1 master slave scale out on a large read-heavy application and I needed it to be able to push data out to all of those slaves really, really quickly. Redice was a great fit for that and its simple and easy to implement as well. Developers can pick it up really, really quickly.
Danish: Ok. I’m curious if you’ve dabbled in Mongo at all? That’s kind of my preference a little bit.
Kent: Yup.
Danish: But I know some people don’t like it.
Kent: No, I do like Mongo actually. It would probably be the 3rd one on my list at the moment and the only reason that its 3rd on the list at the moment is because its horizontal scalability tech--what you have to do operationally to scale horizontally with the shard-ed replica set is pretty intense, right? I mean not just anyone can prop that up so it does have a little bit higher operational overhead but in cases--and this does come up for us quite a bit, especially the smaller e-commerce side, in cases where you do have developers and/or a highly relational data store, we found MongoDb to be the best sort of almost like a 1:1 port from traditional relational database world into a document oriented database world so, you know, I’m quite fond of that one as well to be honest with you.
Danish: Ok. So there’s this recent acquisition that I think that went for $212 million for Heroku by Salesforce--has a lot of people talking about the relationship between Ruby, Rails, and enterprise, so I was curious if you could offer any insights that you have into that.
Kent: Yea, I mean, I could tell you what we’re actually seeing, right. Is that, large corporations now, that we are potentially already doing business with in a lot of cases, who even 3 years ago wouldn’t have thought or maybe might have even laughed to me for suggesting that I was going to use Rails to prototype their application or build their application. That’s just not the case anymore, its completely flipped around. They’re asking me now, if I know how to use Rails and if I have developers that can help us deploy Rails and the Heroku acquisition only strengthens the position of any developer or any person out there that wants to suggest Rails as an alternative, right. And I think that for me, that’s what it means more than anything else and I don’t want to say legitimatizes; it was certainly already legitimate but it certainly moves it up market a little bit and makes it a little easier to sell.
Danish: Definitely, that’s for sure. So, I know you stated you guys use Chef for your automation and I know that’s what we use here at Engine Yard. I haven’t really--I wasn’t ever really ever been exposed to anything more than Chef but I know when I did a little research, there’s other ones out there called Sprinkle and the other one’s Rudy. I was curious if you guys ever looked into other ones of it Chef was just--since it seems like its almost the de facto if you guys just decided on that you know opscode has done a really good job with it.
Kent: Yea, you know, as I mentioned earlier, some of my first Ruby was dealing with automation of deployment so Capistrano so I got my hands on essentially a Ruby DSL for deployment very early on so moving to Chef for me was fairly easy and fairly natural and it just made sense. But in my opinion there are probably 2 leading options--there’s Chef and there’s Puppet. I do know Sprinkle, I don’t know Rudy, I would have to look that one up. But Chef for me, because of the--it all comes back to that same thing I said about open source and the same thing I feel about Ruby and the Rails community in general and the quality and passion behind what people are doing. Its all about community, right, and the momentum behind it. Just go search for the recipes. You can find a recipe for almost anything and it’ll give you a great starting point and reach out to the person who wrote it, they will answer you and they’ll be right there and I found that to be really nice. In terms of, not only using it but helping to train my team to use it. You know, there’s a learning curve for all that stuff. When you start talking about indempotent systems, people start to look at you kind of sideways but its certainly--in my world, Chef was the best fit, I’ve used Chef and Puppet and would recommend them equally, depending on which one was the best fit for the organization at hand.
Danish: Why would you say for you guys, Chef seemed to be the better fit? I know like you said, there’s a lot of people that talk about Puppet as well but I’ve noticed a lot more people have been moving to Chef from Puppet if they were using it previously.
Kent: I think that, again, the primary reason is that I’m focused on building a Ruby practice here so the re-usability of the native DSL for the configuration management platform is key. The types of things I want to build, its very quick and easy for me to modify and find recipes that I need or create our own. The fact that I can, you know, again with either one of them you can run your own servers or you can, you know actually I’m not sure--do you know right off the top if there’s a--is there a hosted Puppet service because we do use Opscode Platform and we do like that quite a bit.
Danish: From what I know, I don’t think there is. i know a lot of people tend to harp a lot about how Opscode makes it really easy for having their chef server up for them.
Kent: Yea. So what we did here was we started with the Opscode Platform then we fairly quickly realized that were wanted to run on our own server inside the firewall and Chef made that very, very easy, right. So I was able to get everybody trained up and then when I pull clients in, if they want to take over the Chef repository, right, all they need to do is set up an Opscode Platform and clone the Git repo and then we’re good to go. We’ve done our job and transferred the work. So that’s also important as well.
Kent: Yea. In a consulting--you know we’re in a consulting and services business so many times our clients will want that type of portability.
Danish: Do you feel though, when you kind of transfer I guess, the code base off to people, is it easier for them to understand Chef, you know? Do they ever have trouble using it if they need to change things or if they needed to do anything with it?
Kent: My personal opinion, I think its easier to groc but--and its Ruby so you can go out and find a Ruby developer. Now, Puppet has its own internal DSL however, as of fairly recently, you can also write your manifest in Ruby so I can’t really argue that anymore, right. Its kind of again, it just really comes down to what fits your organization. Chef fits ours.
Danish: Ok. Awesome. Well thanks a lot again for finding some time to talk with us Kent, I really appreciate it.
Kent: Yea definitely. And as I mentioned earlier, I’m very excited about continuing to work with Engine Yard and I think that I love what you guys are doing and what you guys have done over years and years in the community to promote Ruby and Rails and even make it possible for me to build a profitable and successful Rails practice here so thank you, thank you.
Danish: Glad we can help. Thanks a lot Kent.
Kent: You bet, thank you.
