What is VWire?

Vwire isn't any one thing. The domain vwire.net is one I've used for various projects and learning exercises over the years (Since 2004)

Currently the name servers (One on Linode, one in Azure) for Vwire are authoritative for itself and a few other real world sites/APIs.

You've owned this domain since 2004?

I was <16 when it was first registered. I can't believe it either.

Who are you?

My name is Sean, but there are other aliases that mostly exist on the Internet

Where do you live?

Manchester, NH, USA

Your history in tech?

Warning: Rambling ahead.

Beginnings

My technical history started in a way common for most professional geeks; an unusual interest in computers at a young age. I began using Linux around age 10 (Although these days I'm on Windows for my main machine. WSL and the ability to SSH directly from a Windows terminal is something 2005 me would never have expected to become reality)

I was lucky enough to land a part time support role at a local ISP/phone company in high school. Working for a small company forced me to absorb as much knowledge as possible (Anything from troubleshooting BGP sessions on a Juniper M/MX router to where the trash goes at the end of the workday). Spending significant time in central offices and talking to old-timers gave me a wondeful history lesson in telecom. Why are racks in these offices 23 inches wide? Why is everything -48v? Why is the world going from Ethernet-over-SONET to SONET-over-Ethernet?

Working for several ISPs caused me to develop a deep interest in telecom and network engineering. Especially anything related to inter-AS routing and intra-AS design for ISP-scale networks. Even though I've never directly worked with them, I find mobile networks fascinating. Feed me beer and I'll talk your ear off about LTE/NR deployments and why the modem in your pocket is one of mankinds greatest technical achievements

Network engineering to coding?

I was presented with a well-paying opportunity to write code for a small company. Fast forward a few weeks on Google and StackOverflow, I began to develop an obsession with creating scalable web services (APIs consumed by applications).

The first production API I ever created was was written in C# (.Net 4.5.x?) and hosted in a local datacenter on a Linux machine under Apache with mod_mono. As traffic grew, I spun up a proxy server (Another Linux machine running HAProxy) to handle SSL termination and simple load balancing between any number of mod_mono workers. We were also able to create a pretty neat update script that could take workers offline one at a time, wait for HAProxy to realize they're down, update the code, and put them back online. Good times, complete hack.

Without going into too much detail, this API was eventually moved to Azure. Linux and HAProxy were dropped in favor of a Windows app service and the built-in scale out features that Microsoft offers.

Can you just list what you know?

Lists work better for me, too. Here's a list of what I know about/have experience with in no particular order:

• Routing/switching/anything network-related (And Juniper, Cisco, Extreme Networks hardware)
• Linux/Unix (FreeBSD)
• Active Directory (And to a lesser extend, ADDS)
• .Net Framework & .Net 5/6 using C# (Can do VB, never touched F#)
• WPF, Xamarin (Now part of Microsoft), ASP, Blazor (Both WASM and server)
• Most things Azure, extensive experience with App Services, file storage, AZSQL, AZRedis
• Entity Framework
• Linq gets a dedicated line because it's one of my favorite .Net features.
• Azure Devops. Using pipelines to automate testing and deployment. Experience with deploying build artifacts directly to AZ app service slots
• ServiceStack framework*
• RESTful API design and operation
• Redis**
• MQ design
• Integration with Auth0 and other IDPs. Validation of JWTs on incoming HTTP requests for stateles session and authorization
• Sendgrid*** (Both outbound and inbound message processing through the SG API)
• TSQL. Proficient enough here, able and willing to learn more as needed
• DNS - Specifically using BIND, authoritative and non-authoritative, resolvers for ISP level operation

* ServiceStack Framework

www.servicestack.net

ServiceStack is far and away my favorite framework to compliment .Net. It greatly accelerates the API development process and abstracts away much of the tedious work (Session management, HTTP request interfaces, interfaces for authorization). Also includes fantastic JSON tools and additions to general .Net features.

** Redis

Redis is one of my favorite tools for API operation. Two uses in my experience worth mentioning:

• Session management

  In cases with n<1 instances handling HTTP requests, create a session object for each user as needed. The session object represents the entire context for the user session, including any sensitive strings to access resources (SQL, BLOB storage). Serialize the session, store it in a Redis instance and key it with a JWT (or a shorter hash of a JWT). For each incoming request, take the incoming JWT to query for the session. Return a 200 or 401/403 as needed.

  Tl;dr: Use Redis to allow any HTTP worker to reconnect a request to an existing session.

• Message queueing

  Ideally any web API should return as fast as possible. For requests that will take a long time to complete (Or requests that trigger a process where the requestor doesn't need the state right now), add an internal request to a Redis instance and return an HTTP response immediately.

  "Worker" instances constantly poll the queue for jobs, processing them as they arrive. Clients can be be notified of state using SignalR, HTTP long polling or similar.

  Tl;dr: Use Redis to facilitate super-responsive, asynchronous API endpoints.

*** Sendgrid

Everybody knows you can send email with Sendgrid, but did you know you can receive messages?

Sendgrid can accept incoming messages for any domain and send them to your API. Just create a few MX records and configure a callback target.

A great use case for this is accepting trouble tickets. Accept external updates to trouble tickets by parsing incoming mailbox info. I.e., 270166@support.vwire.net

You sound like a geek. Do you have any non-technical interests to offset that?

Motorcycles (an obsession), biking (An even bigger obsession), skiing, hiking, horses, investing (Stock market & real estate), German beer.

How can I contact you?

Hello (at) vwire dot net

Or if I've emailed you with my personal address, just respond to that!

Can I hire you for something?

Maybe! See the contact section. Shoot me an email, I can answer any questions you have and send you a formal resume if needed.