Thoughts on building software and startups.

A weekly podcast about cloud native development, AWS, and building distributed systems.


Your Most Important Skill

The rapid pace of technology innovation

"Life moves pretty fast. If you don't stop and look around once in a while, you could miss it." - Ferris Bueller

Ferris was right. It's amazing how fast everything is changing, with technology leading the way. New programming languages, new frameworks, new methodologies, new databases. Cloud-native software. DevOps. DevSecOps. AI, ML, analytics. It can be hard to keep up.

I want to share a personal story that reinforced the importance of continual learning and, in particular, taking ownership of your own growth.

A familar problem with a familiar solution

Recently, I was preparing for an episode of Mobycast, a weekly podcast I co-host with Jon Christensen where we discuss topics related to modern cloud-native software development.

With this new episode, I walk the listener through the steps of separating cloud-based resources into public and private subnets. Public-facing resources get placed on the public subnets. All other resources get placed on private subnets. This is a best practice that reduces the surface area you must protect against Internet-based attacks.

One hurdle of incorporating private subnets into your network design is that you need a way to securely access those resources, which no longer have public Internet access. You no longer can simply SSH into your servers. Other methods must be used.

My typical "go to" solution for accessing private subnets has been to use a Virtual Private Network (VPN) connection. There are various types of VPNs, some of which require hardware, such as AWS Managed VPN, and others which are software-only.

The hardware-assisted solutions are more suited when connecting on-premise locations to the public cloud. A software-only VPN is ideal when you have remote access users and want simplicity at the lowest cost. For the podcast episode, I opted to use a software-only VPN.

With AWS, implementing a software-only VPN has always meant deploying third-party software on an EC2 instance in your VPC. The only question has been what third party software to use? There are numerous options to choose from, ranging from commercial, paid software to free, open source packages.

Wanting to demonstrate an option with the least cost, I evaluated two open source packages: SoftEther and OpenVPN. After some research, it was obvious that OpenVPN has the best support on AWS, making it an easy choice. I took notes as I installed and configured OpenVPN Access Server on an EC2 instance in my VPC. After a couple of hours, I had a secure VPN connection to my private subnets, along with detailed notes for the podcast episode.

That feeling of "Ohhhh nooooo"

While doing some final fact checking in preparation for recording the episode, I was reviewing documentation on the VPN choices available from AWS. Curiously, two choices stood out which I hadn't heard of before: AWS Site-to-Site VPN and AWS Client VPN.

After some reading, I discovered that AWS Managed VPN has become AWS Site-to-Site VPN. It's hard to tell when this change went into effect. Some of the official AWS documentation still refers to Managed VPN as a valid option. Ok, name change and perhaps some additional features. I can deal with that.

But wait... what is "AWS Client VPN"? After a few minutes skimming the docs, I learned that AWS Client VPN is a fully managed service for a software-only VPN solution. Additionally, it has native support for OpenVPN clients. What?!? To say I was surprised by this discovery is an understatement. I had just spent hours standing up my own VPN solution without knowing that AWS offers the equivalent as a fully managed service. How had I missed this?

Turns out, AWS Client VPN is relatively new, launching in December 2018. A mistake on my part was not being vigilant about reading updates on the AWS What's New page. But the biggest mistake by far was my reliance on a familiar pattern in solving a familiar problem.

Kill your darlings

"Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings." ― Stephen King

Even though Mr. King was referring to ruthlessly editing one's prose, I think this quote equally applies to the patterns and practices we hold on to.

Technology is changing so rapidly and it can be quite an investment to learn a new skill or technique. Our knowledge gained is so hard fought that it is only natural to rely on it dearly. It becomes part of our core set of practices and patterns.

But this is the catch-22 of being in the tech industry. We must work hard to keep abreast of changes and advancements, so that we can then use technology effectively. But we must also be willing to "kill our darlings" with the realization that the way we have been doing things may no longer be the best solution.

The most important skill

This is why your most important skill is the ability to learn new things quickly. Gone are the days where learning takes place during your formal education (i.e. attaining a college degree), and then you leave that behind and become a practitioner.

Instead, embrace the new reality that learning is a continual process, with which you will never be done. Be flexible with your opinions, be open to new ideas, stay curious and commit to a growth mindset. In short, own your personal development. No one else will do it for you.

If you don't, after a few years you may find yourself left behind, mired in your own technical debt and out of touch with the rapidly evolving state of technology.

Entrepreneur, technologist and startup junkie. Founded two companies, one with $24M in VC, the other bootstrapped with a SBA loan. Now building startup #3, looking to shake up the podcasting industry.

View Comments