Lately there’s been a lot of fuss about serverless. But what the hell does serverless even mean? Let’s see if I can provide a brief explanation.
The last two years at work, I’ve been gradually moving our on-premise infrastructure up into “the cloud” (AWS and DO mainly). At this point, about 85% of all the company’s infrastructure is now in “the cloud”. Which brings us to AWS Lambda and serverless. How the hell could something be serverless? Well what they really mean is that you don’t have to worry about the server. You write some code and the code will be triggered to run and you don’t have to provision a server, install the dependencies, etc. Sounds cool, right? Yes. And more importantly to the company, it can help save a lot of money.
There’s a few things that I could transition to AWS Lambda. Until recently though, Lambda didn’t support Python 3.x and that meant it wasn’t something that I wanted to deal with. But that has changed now and Lambda supports Python 3.6. So in the next month or so, I’ll be playing around with it and hopefully can migrate some stuff over and save the company some more money. Should be a fun side project.
I’m often working on little personal projects alongside the projects for work. Personal projects though, gives me a chance to try new things, experiment, learn new techs, etc. I’m also much less careful so end up doing really stupid things (in hindsight). So I thought it’ll be nice to share some of those… adventures. Keep in mind, I’m no pro… so if you know of better ways of doing something, let me know in the comments!
Working on a trouble ticket system the other day, calling it Tick-IT ha! Get it????? From experience, whenever I write projects that uses a database I always end up adding new features that require modifications to the table schema. The changes usually involves one of two options: 1) adding a new table that shares a key with the existing tables in the best case 2) requiring the adding of a new column which means migrating all existing data in the table into a temporary table, deleting the original, then creating the new table, moving the data from the temp table to the newly created one. A total pain in the fucking ass.
In an attempt to be smart, I decided that I would only have 3 columns in the tickets table which holds all ticket information: ID (unique ticket ID), ticket number, and ticket data (JSON blob that stores all other information on the ticket). Brilliant right? Need to add new fields? Just add to the JSON object! Nope… See, the problem that I didn’t think about was the JSON data isn’t searchable using SQL. It would require a full text search. So… Not so smart after all.
Disclaimer: I wrote all this on my phone while “shopping”. Please excuse any misspellings or grammar problems.
It’s a new year and a new start for the server that runs ronniechung.com. The process took far FAR longer than I originally expected. This was because I was learning while doing. So what changed?
First off, ronniechung.com no longer runs on bare bones. What I mean is that the server that hosts the site is now a VM. The physical server is the VM host, it runs Debian. The hypervisor as you can probably guess is KVM. The VM that runs the site is running Ubuntu still because I didn’t want any distro changes to affect my scripts, custom web apps, etc. The process of getting all this setup was actually easier than expected. Only took a few days to get it all configured and ready for deployment.
What really took a long time was getting the VM setup. I wanted to learn configuration management using either Puppet or Ansible. Puppet was the obvious choice being that it was so popular, but as I quickly learned it wasn’t the right solution for me. The time spent learning Puppet though (about a week) was worth it for sure. The biggest problem with learning something new while attempting to apply it to a “production” system at the same time is you’re almost guaranteed to make mistakes or do things that aren’t exactly “best practices” first time through. And that’s exactly what happened.
A few days ago, everything was set and all tests were passing. I switched the DNS back thinking it was time to bring things back to normal. I was wrong… First I wanted Ansible to handle everything including restoring files (like the pics of the beautiful ladies ;)). While writing the playbook for that, I decided to update everything to follow “best practices” which I learned the same day. Finally late into New Year’s Eve, I had everything updated and finished. Ran one more test to make sure I didn’t accidentally screw something up (I did) before going to sleep. Checked in the morning and well, I made a couple mistakes in regards to restoring of files. Simple fixes but still annoying.
As you can see today though, everything is fully operational and all managed by Ansible. Best part is if I ever needed to rebuild its just a few steps and less than 30 mins to do. There’s still a couple things to do, I don’t have VM backups setup yet for instance, but all the major work is finished. Quite happy with the setup right now but if you know me you’ll know I like to keep changing things. I get bored real easy 🙂
Did a photo shoot with the lovely Roxxana on Monday. It was a pretty simple shoot, some head shots, some full body. Had a good time and got some good images which I will be posting in the coming week. For now though, here are some behind the scenes pictures.