VB6 to microservices: is it even a thing?

VB6: will it ever go away?

Maybe not--the current (June 2017) TIOBE index shows Visual Basic (not VB.NET) at #16 (down from 11th a year ago). Maybe that sounds irrelevant, but consider what it's still ahead of: FORTRAN, MATLAB, and Objective-C.

And our "get the heck off VB6" tool's free trial still gets thousands of downloads every year. And we talk to customers all over the world daily who have hundreds of thousands, even millions of lines of code in VB6.

And I've never met one yet who was just fine leaving it just like it is.

The Visual Basic Upgrade Companion has been around for years to help get VB6 apps upgraded to .NET desktop versions. And it works great. Literally billions of lines of code have been cranked through this proven tool either when it was part of Microsoft Visual Studio or acquired directly from us.

More recently, we introduced WebMAP to move those resulting .NET applications all the way to ASP.NET MVC with HTML clients using KendoUI (for fixed design) or Angular/Bootstrap (for fluid design). This tool has slashed years off development time to move Very Large Commercial Apps to hosted SaaS software models.

As a sidebar to this, based on conversations with prospective customers, it's clear that ISVs with vertical market apps see moving to a web version as critical to their future. Many of these apps--even those from niche market leaders--are still running VB6, captive to a desktop, paid for with a traditional license model. New market entries are appearing on scene as pure SaaS web apps, allowing customers to access data and functionality from a rich variety of devices and locations. Those SaaS entrants are threatening the established market leaders still on desktop-only code.

Some of these ISVs will try to hold on to their leadership positions without moving their code to the web; some will continue to support their desktop versions while launching expensive, lengthy rewrites to get web clients; and some turn to us for a fast efficient "lift and shift" to get the code into a modern web architecture and then start adding new functionality.

What has this got to do with microservices?

Microservices--in case you missed it (and at the current rate of change in the world of tech, you can miss a major trend just by grabbing lunch)--is an approach to decomposing a monolithic web application into discrete components. Some people call it "fine-grained SOA" as opposed to more traditional SOA. But while SOA can live inside a monolithic application, microservices tend to be discrete and autonomous, communicating with other services (typically) via REST or RPC.

If you are writing new code this is a nice complement to Agile, since individual teams can build up these microservices independently, test them independently, etc. Because they are (relatively) small* it's still within possibility for developers to understand the full stack--something arguably not possible with apps encompassing millions of lines of code.

A VB6 to microservices scenario

Let's imagine a commercial VB6 app that manages custom cabinet shops. Like many apps of this vintage, it started as a point solution--creating material take-offs and cut lists for kitchen cabinet parts. Next it added customer order tracking, then shipping, then a services module for cabinet installations, inventory management, and finally cost accounting.

It grew and grew. 

After migrating to HTML5 with WebMAP it's now 800KLOC of ASP.NET/MVC code running in Azure and it would benefit from microservices, as well as simplified DevOps.

Let's start with DevOps. Docker now plays really nicely on Azure--it's no longer just for Linux devotees. Docker makes it easier to go from dev to production without breaking stuff; it makes it simpler to move a deployment from one infrastructure host to another; and it makes scaling up and down pretty quick.

So we're going to put our ASP.NET app into a Docker container on Azure. Done.

Next we want to start the microservices ball rolling. Let's start with a goal to expose the customer order object as a microservice. Right now it's difficult for our sales team to take orders at a customer site so a cute little app that could run on a tablet would be awesome.

Orders are a sales function so we sit down with some of our reps to understand their story. Most of it is pretty predictable: they'll need product info to show customers, pricing, availability, shipping info. It's easy to get feature creep: what about customers who are late with a current invoice? Do we want that flagged by the order app? That would mean interfacing with the AR subsystem. No, let's keep it simple. Finance can manage that with some basic back-end processes; no need to build it into the microservice.

Further, why have the orders app talk to the products object? Why not just use the company website which has all our products with descriptions and pictures? Good idea; now the microservice is getting truly "micro."

From this point on it's pretty simple. Once we have our API services built, we define a simple RESTful endpoint and then code up some JavaScript and HTML for the front end. For our cabinet shop we don't need real time data access, so order transactions can simply be queued up on the backend to be reviewed and approved via simple business rule processes. For example, an order can trigger a simple email notification to Finance to approve any necessary credit extensions; likewise it could create a Zapier action to update a scheduling board to reserve resources.

Pros and Cons

Ok, let's be frank. We didn't NEED to do it this way--the existing monolithic app could be used to do all this stuff. And the microservices add complexity, albeit different complexity than what the monolithic app is saddled with.

However. Once the order microservice is built, you could chop out the order piece from the main app--just point users to the new mobile ordering app. So the monolithic app shrinks a bit in size and complexity and the order component gets more autonomous and easier to test and maintain.

That's the promise of microservices. And while that might seem like quite a stretch from where you are if you're still booting the VB6 IDE to maintain your existing code, remember the old saying: A journey of 1000 miles starts with lacing up your hiking boots.

VB6 and microservices may seem to inhabit different universes, but instead they are on a continum. Like how the Mercury program led to SpaceX. 

*How small? Some people think they should be as little as 10 lines of code. I think not.