Posted on

Creating my own VPN on Linode with Algo VPN

For a few years I have been using a commercial VPN service for my personal use. It gave me the capability to tunnel to a slew of countries around the globe, and provides apps on my Mac and my phone.  It balanced my privacy and easy-of-use needs, as most commercial VPN’s do these days.

However, as with most paid services that are easy to use, you give up a certain amount of control or an ability to fine-tune (or just play around). In this case, one aspect I could control is the IP address of the server I’m tunneling through. Another aspect out of my reach is the level at which the commercial VPN hides information about the ones using it. Being naturally curious anyway and with some free time, I undertook figuring out how to setup my own VPN on Linode, where I already host my server for my website and other projects.

After some research I settled on Algo VPN, which seemed to achieve formidable tech community acceptance from both it’s ease of install and robustness. And for connecting VPN clients, there are configuration instructions available for tunneling via Linux, Windows, Mac OS, iOS, and Android. In my case I primarily use Linux, Mac OS and Android, so I was set.

The Linode

I selected creating a Linode Nano, which is their smallest box: a 1024 GB memory instance with 1 CPU and 25 GB of disk…. more than adequate for Algo VPN. At $5/month, it is roughly consistent with the cost of my existing VPN. For this instance it allows 1 TB total transfer each month (in and out), but for my own testing this was fine, as I’m not planning to stream movies though it.

As a note, DO NOT TRY to use any of your existing server instances which is used for other purposes, such as hosting websites. Algo VPN will change core network settings and probably mess up your server.

I installed Ubuntu 18.04 LTS (the current long term support version available at the time of writing) on the instance, and performed all the package updates to bring it current.

VPN Installation

The command line instructions included with Algo VPN were as easy as they had been reviewed by others. It will walk you through a series of questions, and then perform it’s install. I won’t go through the how-to here since other people already have elsewhere, but suffice to say it, in an hour or so, I had it up.

With software that easy to setup, I was eerily skeptical if it would actually work though when I connected.

And…it did!

For my Mac, one of the files that is produced out of the installation is useable directly in Mac OS to configure the VPN. Within a minute I had my tunnel established.

For Android, there is an open client app you can download, and import another configuration file created during Algo installation, within another few minutes my phone was connected.

None of these instructions, as easy as they are, will be EASY for the mass market type of VPN customer. But in terms of what I’ve dealt with in the past, and that I’m well accustomed to manual configuration of most anything, it was a breeze.

Testing

Of course I began by visiting specific sites that will tell you how your VPN is looking from the outside. As I hoped they reported seeing my Linode instance’s IP address correctly, and not my computer’s IP. I ran a DNS leak test as well (e.g. DNSLeakTest, DoILeak, Whoer), and the DNS requests going through the tunnel did not give away my true location.

Both services did point out an issue with WebRTC in Chrome giving away my computer’s IP, but that’s a Chrome issue and only via web browsing in that browser, which is something I need to look into. WebRTC cannot be disabled (at least easily) in Chrome from leaking this information.

On Linode, I can see my traffic going through the VPN on the various graphs provided for my instance… something that appeases the engineer in me. Nothing really more to say about it.

A big benefit here is that, as often as I want, I can quickly spin up other Linodes which clone this configuration, all of which have different IP addresses.

I’m still evaluating this little experiment, but at least I can say that Algo VPN is what it’s cracked up to be.

Posted on

Product Management at a Software Development Shop

I lead product management and solution architecture at a software development company here in Austin, Texas. When I started a few years ago, product management as a practice did not exist at this company…and there were problems that the founder anticipated product could solve for our clients.

Fast forward a few years, and I’ve been considering: How is Product Management at a dev shop different than at a company that develops its own software products?

Cross-Domain Expertise

At most companies, Product Management tends to focus within the bounds of the company’s vertical, such as education or healthcare. At our dev shop, we partner with companies from a gamut of verticals to design and develop their products. Given our clients know their respective verticals and by extension their customers infinitely better that I, what value can I bring?

Working across so many domains, it turns out I have the unique perspective of seeing customer pains addressed over and over through products and their features. Over time, I’ve been able to distill out common successes (and failures) of the solutions, turning that experience into product guidance for every new client. Even knowledge of existing open-source and OTS (off the shelf) solutions used in one vertical prompts consideration for reuse or exploration within another vertical for possible solutions.

In short, I have become a consultant to our clients, lending those common solutions as we think through the desired features together, ensuring the task of reinventing a wheel isn’t undertaken, or at least without sufficient warning.

PM Maturity: Everyone is Different

Successful product managers must know their customers and business. In my case, every one of my clients should have at least one person who plays this role, even if not officially titled product manager. This is where things can get tricky, as not every client employs experienced or trained product managers.

As the product management counterpart for each client, I meet them where they are today, each at their own level of product management maturity. I’ve become well-versed in asking the right questions to distill out:

  • how well they understand the problems that need to be solved for their customer and business
  • the requirements that have been validated by their customers, and thus,
  • where they are making assumptions

Organizations with mature product management have this worked out, but others may need quite a bit of hand-holding through multiple conversations. It is in no one’s best interest to build the wrong features, or build the right features at the wrong time. As we figure out the roadmap, often my job is to think through and push back on proposed features to ensure the client is planning features that their customers want while fulfilling their business goals.

Solution Architecture

Quite a bit of my role overlaps into solution architecture, which is where my broad technology background and software dev experience tends to pay off. As I meet our clients during pre-sales and after the project commences, it’s helpful to know where the gotchas are fairly quickly, navigating the conversation to investigate further.

Example: the client wants to build a car, and desires the following features: wheels, windshield, steering, engine, radio, seats, and hover capability. It’s helpful to be able to state immediately that all but the last are fairly standard, but the final one requires orders of magnitude more time & resources. At this point, we can dive into that feature requirement and see if it’s truly necessary, or see if the root problem can be addressed in another less taxing way.

In addition, as the product management counterpart to our client, I have think through the features they will need for a successful release, including anticipating the back-office administrative roles and features which most clients rarely anticipate. Thinking ahead to how the client, given their own business processes + sales & marketing plans, will need to engage with the product post-deployment, cannot be underestimated. Surprised clients, in this scenario, is not a good thing.

Finally, as I alluded to earlier, when I interview clients to understand their business goals and customer problems, I naturally consider solutions I’ve already seen…whether partial-solutions as OTS software, or software products that exist in other domains. I often break down the customer problem and consider solution made up of OTS and custom components, all of which can be investigated by our design and development teams as a potential path for implementation. It’s a starting point for the internal conversations, and gets everyone thinking about development costs, cost of ownership, performance, integrations, and the like.

Client-Facing, by Nature

If there ever was a role that is client-facing, it’s product management at a dev shop. While traditional product management is encouraged to spend time with customers, there is hardly a day that goes by when I’m not speaking with a potential or current client.

Being genuine, friendly, professional, likable, transparent, and an excellent written and oral communicator are all required for this role. Most of our clients first engage with our dev shop via product management, and therefore we are the first impression. Then, collaborating with our internal UX design and software development teams before in pre-sales, as well as during the project, is imperative.

Suffice to say, in product management, it helps to be a people-person, and no less so at a dev shop.

Managing Process

Every software company must have some software development process to create products. Because dev shops are typically managing numerous projects across one or more clients, they live and die by process.

At our dev shop, we practice our own flavor of Agile Scrum. Clients hire us to develop software for them, and for many, this relieves them from building their own UX design and software development teams, and associated methodology. This also means many clients have no idea what “Agile” or “Scrum” is, and may themselves be accustomed to a traditional waterfall mindset of project execution. Training clients about the benefits and drawbacks of Agile is often required initially and throughout the project. This is a big difference between dev shops and traditional software companies, where the latter is presumed have all bought-in on a methodology.

In addition, the three pillars of a project (time, budget, scope) become quite literal when working with clients. If any or all of the three pillars were tied down contractually, product management must manage this with the client, and decide how to handle inevitable changes that occur during the project jeopardize success.

Posted on

The traveling salesman, Steiner trees, and bubbles

Be forewarned: Of course no solution here, but rather a train of thought I want to jot down…if not for your consideration, then for me to pick up later. Also, this post mentions soap film, not bubbles. But who doesn’t like bubbles? Same generally can’t be said for soap film.

The Traveling Salesmen Problem is a hard problem. In fact, it’s NP-hard. Here’s a description (thanks, Wikipedia!):

The Traveling Salesman Problem describes a salesman who must travel between N cities. The order in which he does so is something he does not care about, as long as he visits each one during his trip, and finishes where he was at first. Each city is connected to other close by cities, or nodes, by airplanes, or by road or railway. Each of those links between the cities has one or more weights (or the cost) attached. The cost describes how “difficult” it is to traverse this edge on the graph, and may be given, for example, by the cost of an airplane ticket or train ticket, or perhaps by the length of the edge, or time required to complete the traversal. The salesman wants to keep both the travel costs, as well as the distance he travels as low as possible.

The salesmen needs to find a single loop to hit every city, and our objective is to find the least cost to make that loop. Let’s assume that cost is the distance: the salesman wants to get home as fast as possible.

OK, put that on ice for a moment and switch gears.

Another problem that also involves graphs is the Steiner Tree Problem, which is a little different. While you can still consider many cities as with the above problem, in this case we’re talking about road planning. How do you connect all the cities with the minimum distance of road pavement? In more general terms, what is the minimum length of edges that include all fixed points in the graph?

I was first introduced to Steiner Trees via this wonderful video by the good folks at Numberphile:

What astounded me is that we can “use nature” by exploiting an inherent property: get to the lowest energy state possible. Whether its water rolling down a hill to find bottom, or lightening finding the optimum path to reach ground, nature generally looks for the easiest path to get to the lowest possible energy state. In this particular scenario, the soap film expends as little energy as possible to maintain itself. The area of the film for a segment varies with the total length between the pegs. Nature wants to minimize its film area, so in doing so it also finds the minimum length solution for us. (The end of the video showed a local minimum, which by adding some energy, yielded the global minimum. Clever!)

The ultimate supercomputer

No calculations, no algorithms, no processing. Intrinsically, nature behaves like an infinitely-scaled parallel processor, evaluating all possible paths simultaneously in an attempt to find the lowest possible energy state that maintains itself. In my mind, this behavior is analogous to quantum computers where all states are evaluated simultaneously (for the purists, greatly simplified).

Via this exercise in the physical world, nature solved a mathematical problem by finding the shortest distance between a set of points. Can nature also similarly identify the shortest loop through a set of points for our friend, the traveling salesman?

Comparing the problems

The Traveling Salesman problem has the following properties (where I equate the edge cost to the distance between cities):

  1. Requirement to create a loop (in contrast to Steiner Trees, which have no such requirement), and therefore a traversal order is implied.
  2. Each city has precisely two edges connected to it (where Steiner Trees have at least one).
  3. All available paths and their associated distances between cities are fixed (whereas the paths between nodes in Steiner Trees are undefined from the start, and the paths with associated distances are solved for).
  4. The number of cities cannot be changed (whereas Steiner Trees can increase the number of nodes by adding Steiner Points if it reduces the total distance).

As I see it, the primary difference is that Steiner Trees solve for the minimum total distance to connect all nodes, versus the Traveling Salesman problem must solve for the minimum loop distance by identifying a traversal order.

Another way to contrast is that Steiner Trees are unordered because a traversal order isn’t part of the solution, and the Traveling Salesmen problem is ordered because you must find the right loop through all nodes.

Naturally…

Is there a natural phenomena, similar to the soap film exercise that would provide a solution to a given Traveling Salesmen problem?

I’ve been pondering this for the past few days, and I think the problem’s complexity lies in the ordering. Unlike Steiner Trees where nature “solves” for minimum distance by finding the lowest energy at an instant, here it would need to solve for the minimum distance over every ordered permutation of nodes. That implies iterations and time dependency, which reminds us of why this is NP-hard.

If we find a natural phenomena where things are traversed in a specific order which happens to be the optimal distance, we have a chance. At the moment, nothing comes to mind.