For this month's Stride Tech Talk, Stride CEO Debbie Madden discussed serverless architecture and other aspects of his current work with David A. Black. David A. Black is an internationally-known developer, author, trainer, speaker, and event organizer. A software engineer at 2U, Inc., he is a Ruby standard library contributor and one of the founders of Ruby Central, Inc., the parent organization of the official international Ruby and Ruby on Rails conferences. David is the author of The Well-Grounded Rubyist (2E, Manning Publications, 2014)
Debbie: You've always been deeply into Ruby and the Ruby world. I understand that your current job doesn't involve Ruby. Has that been a hard adjustment?
There’s more to say about the transition I’m describing, though. It’s not really about this or that language, and certainly not about this or that language feature. It’s about my relationship to programming languages, and specifically to Ruby. Ruby was very popular in Japan in the1990s, and started to trickle out to the West during that decade. But widespread adoption of Ruby outside of Japan didn’t start to happen until Dave Thomas and Andy Hunt wrote the first edition of PROGRAMMING RUBY (the “Pickaxe Book”) in 2000. That’s when I discovered Ruby -- literally by happening upon that book in a bookstore and finding myself entranced.
I was thus a pretty early adopter -- outside of Japan, that is -- and most of the rest of what happened was because I was in the right place at the right time. Publishers were starting to look for Ruby books, and by the end of 2001 I had contributed a couple of chapters to TEACH YOURSELF RUBY IN 21 DAYS. (People make fun of that series, but it was a good book!) And in 2001 we held the first International Ruby Conference, the chief organizers of which were me and Chad Fowler. Chad and Dave Thomas and I subsequently founded Ruby Central, Inc., which we ran for about another ten years, with Rich Kilmer stepping into Dave’s shoes along the way, before turning it over to its current directorship. It still produces RubyConf as well as RailsConf.
Speaking of Rails… Ruby on Rails came along in 2004, and increased exponentially the number of opportunities to make a living programming Ruby. At the time I was a professor in the Communication field, not a full-time developer. But that changed in 2005: I left the university and set out on my own as a programmer and trainer. Meanwhile I got a book contract with Manning Publications, resulting in RUBY FOR RAILS (2006) and eventually leading to THE WELL-GROUNDED RUBYIST (2009; 2E 2014).
Here’s the thing: it is almost impossible that I will ever have a relationship to any technology comparable to my relationship with Ruby, nor a role in any tech community comparable with my role in the Ruby world. Back in the early 2000s I benefitted from a perfect storm of circumstances. The likelihood of that happening again is essentially nil.
Which is fine! For quite a while I’d been feeling over-specialized, so it’s good to turn over new earth, so to speak. And I thoroughly enjoy what I’m doing now. Moreover, it’s not just languages I’m learning: I’m also working with Amazon Web Services (AWS) technologies and finding them utterly absorbing.
Debbie: Which AWS technologies are you using, and what are you doing with them?
David: The main AWS services I’ve been learning and using include Lambda, which allows you to deploy individual functions and endpoints -- it’s fundamentally a microservices platform, though it’s actually more versatile than that -- and ancillary technologies like CloudWatch logs and IAM role management.
I work at 2U, Inc., a company whose business involves partnering with universities to produce very high-quality online graduate degree programs. The team I’m on is the Post Enrollment Technology (PET) team. Our work principally supports other 2U teams who need tools to automate and enhance their jobs.
Here’s an example. New faculty members at our partner universities have to be added to our systems. The steps involved in this include creating accounts for them on the services we use, creating virtual classrooms for them (we use AdobeConnect for the rooms), adding conference lines to those rooms, and several other things. The Faculty Support team had been doing all of this by hand for some time, and it was very time consuming. Imagine copying and pasting phone numbers from one input form to another, and having to change the hyphens and parentheses to match each service’s required input format!
So the PET team wrote a service that automates about as much of this process as can be automated. (A few steps require reaching out to humans.) We use AWS Lambda for that. Our Lambda function gets requests from Salesforce, where most of the actual data and interfaces reside. For each of those requests, it walks through the necessary steps, performing those that it finds unfinished and reporting on any errors or missing data that prevents it from reaching the end of the process. The Salesforce operator gets back a status report -- hopefully one that says the new faculty member is fully onboarded, but in any case one that will help them if there are problems.
AWS Lambda is an example of “serverless” architecture -- a bit of a misnomer, since somewhere in the sky there are servers… but accurate in that we don’t have to administer and monitor a server of our own. It’s a different deployment model: you deploy functions, and those functions get invoked on demand. I’ve found it very interesting to work with.
Debbie: Any writing projects in the works?
David: Nothing book-length. (But maybe some day an AWS book? You never know!) I’ve actually gone back to blogging, after a hiatus of several years. Writing is a big part of my creative work, and it feels good to do it on any scale. And so is teaching. I haven’t done much training over the past few years -- it’s hard to schedule courses with a full-time job -- but I don’t rule out finding a way to do some more of that too. The possibilities are many!