June 22, 2015
I’ve been helping software teams accelerate and succeed with DevOps and Amazon Web Services for a few months now (See Phoenix DevOps), and one of the more rewarding parts of the job is getting to observe how multiple different companies operate.
I’ve seen high-performing teams in companies that are about to IPO, software teams in Fortune 100 companies, startups of about 10 engineers, and software-based companies of no engineers at all! It’s been incredibly enlightening for me to learn about how people organize themselves to get sh*t done.
One of the other cool things about my line of work is that it’s right when companies are about to scale to the next level that they call me. So, for the most part, the companies I interact with, are successful startups on the verge of fast growth.
Now here’s the interesting pattern I see. I have yet to work with a single software team that doesn’t suffer some level of “embarrassment” about the state of their codebase, the “amateur” methods they used to get the job done, the duct tape they used here, or the total-makeshift-not-scalable solution they used there. It’s a really…unexpected combination: a business whose growth rate and product-market fit looks awesome, and whose product is filled with shortcomings.
June 18, 2015
I wrote a simple tool that makes it easy to create an AMI of your EC2 instance, and then to delete all AMI’s older than X days/hours/minutes with a single command. Check it out at https://github.com/josh-padnick/ec2-snapper.
This works especially well for backing up WordPress blogs hosted on a single instance in AWS.
There are many ways to do backups in AWS. One of them is creating an Amazon Machine Image (AMI) of your EC2 Instance so that you have a moment-in-time backup which you can use to launch a new EC2 instance in minutes.
It’s not the world’s most robust backup method. First, in order to guarantee that your file system is consistent at the moment of your snapshot, you have to agree to reboot your instance. Second, if you’re backing up data where even a few minutes of data loss is a big deal, this solution isn’t for you.
But sometimes it’s actually the best solution.
March 16, 2015
I published a 12,000+ word guide in January on AirPair.com on building scalable apps on Amazon Web Services. I’ve been a longtime Hacker News reader so it was gratifying to see the article get 500+ upvotes on Hacker News! It also attracted about 30,000 readers in the first 24 hours of publication.
Part 2 of the article is brewing right now, mostly in the form of gaining the real-world experience necessary to write a thorough and helpful guide.
Read the Article on AirPair.com
Update/December 25, 2016 : AirPair.com has been down for a few days now, so if you’d like a copy of the article just email me and I’ll send you a PDF.
Regarding Part 2, I have all the knowledge and experience to write it, but I’ve been busy getting our new “DevOps as a Service” company Gruntwork up and running. I’d like to make it a Q1-2017 goal to publish Part 2, and will report back here once I’ve formally committed to that. Thank you for all your interest!
Update/January 6, 2017: Looks like AirPair is back online, so you can view the article there now!
January 24, 2015
This past weekend, I volunteered at a clinic in Puerto Peñasco, Mexico (better known to Americans as “Rocky Point”). The clinic was makeshift, conducted in a church in a local neighborhood. It was completely free to the residents and funded with donations.
The surrounding residents would be considered low income by American standards, but I sat on many pre-visit interviews with them and most of them don’t think of themselves as struggling. They’re really just living their lives.
The locals have differences in their lives that I simply haven’t experienced. In my makeshift Spanish, I learned that one woman, Guadalupe, had been waiting at the free clinic for about 8 hours, not knowing when she would be seen.
November 9, 2014
Yesterday I volunteered at CodeDay Phoenix as a mentor. The goal of the event was to take young kids (mostly middle school and early high school) and give them an opportunity to code something in 24 hours.
As a mentor, my job was to “walk around and help where I could.”
The first group I walked up to was creating a tool to help you come up with something to do for the day. The idea was that it would take your current location, your preference on whether you wanted to eat, play, build, or socialize for that day, look up some locations in a local database and then make a suggested schedule. It was actually kind of a cool concept!
October 18, 2014
I gave two presentations at Desert Code Camp 2014.2 earlier today. The first was an intro to EmberJS.
Ember is known for its steep initial learning curve and it was an interesting challenge trying to pack in so many concepts in 60 minutes. I had a great time preparing for, and giving the talk.
My second presentation at Desert Code Camp 2014.2 was on Amazon Web Services.
It was exciting to see standing room only during the talk! My main concern was keeping it interesting. The natural temptation for this kind of presentation is to do a “documentation summary” but that risks afflicting the audience with severe boredom. So I used a lot of visuals and everyday analogies in explaining AWS.
I spoke both about the big picture, and then went into detail on two of the most popular AWS services, EC2 and S3. I also briefly described VPC, IAM, RDS, DynamoDB, Glacier, and SES. I received numerous positive comments on the talk, so I’m pleased post the slides below.
October 4, 2014
Recently I celebrated my 10th year at Omedix, the company I started when I was 24 years old. At 34, it is a little hard to imagine I’ve done anything for 10 years!
The milestone has made me reflect on some of the early decisions I made when I first got started. There were many really good decisions, but there were plenty of bad ones, too. And of course when you’re in your early 20’s you have that perfect combination of extreme confidence and supreme ignorance. Sometimes that can be a good thing, and sometimes it can be as bad as it sounds.
September 10, 2014
This is my review of my first couple of weeks with Ally Bank, and why I ultimately decided to stay with stodgy, old Chase.
When I was 16 years old, I went with my Mom to a local Bank One branch to open my own personal checking account. Bank One eventually got acquired by Chase, and so I’ve effectively been a Chase customer for more than half my life!
But it’s been a love-hate relationship. On the positive side, it seems that no matter where in the United States I am, I’m always less than 3 miles from a Chase branch, so it’s definitely convenient. I also don’t worry about Chase failing so it seems like a safe place to keep my family’s money. Their iPhone app is actually pretty good, especially the ability to remotely deposit checks.
But on the downside, I often get a “big bank” feel from them, mostly owing to the fact that I don’t really have a personal relationship with anyone there. I find I’m usually just engaging the “Chase Infrastructure” rather than contacting a specific person I know.
August 7, 2014
Earlier today, I met a friend for breakfast who’s an outstanding professional UX designer. I was curious about something:
“How do you balance the need to give people a user interface they’re familiar with and can do something with right away, against the opportunity to innovate and do new things that may take more time to learn?”
He gave a beautiful analogy in response.
“Consider the violin. It has one of the most difficult user interfaces in the world to use. But if you’re willing to put in the thousands of hours of practice, you can make such beautiful music with it. There has to be that trade off. If we demand of our users a steep learning curve, they had better be able to produce some beautiful music.”
I like that idea because I’ve met many designers who get so mesmerized by the idea of doing something new and amazing that they lose sight of the fact that “the tradeoff” has to make sense.