John you absolutely CAN run a Tomcat app on an Apache deployment in an Azure VM. But then you have to manage the Apache server. and if you create an AMI of Starter.com on AWS you cannot just re-deploy that AMI into Azure VMs. You have to do as the MSFT documentation says -
create a virtual machine that has a JDK already installed.remotely log in to your virtual machine.install a Java application server on your virtual machine.create an endpoint for your virtual machine.open a port in the firewall for your application server.
This is the point about the tradeoff being management of a server stack. The same applies to MySQL instances - you have to instantiate and manage the server.
So you can move your app to various instances but you are creating new VMs as you go. That's not really smooth migration.
as you point out, the only way you can do this is by avoiding any of the Service based APIs. This does give you migrability but it also imposes a fairly high NIH opEx cost. For example because we opted to deeply integrate with Azure - since MSFT is about as likely to go away as Amazon or Google - my SQL management consists of a weekly autoscheduled set of scripts being run to update the internal table statistics and checking the security logs for any attack threats and to make sure we are still well within our autoscale parameters. This takes all of 5 minutes
my backup is automatic geo-distributed to the other side of the country into an offline store (to minimize hack attacks). So my net OpEx costs for managing my database are much lower than yours I suspect.
And I absolutely agree with you that this balance between OpEx, future roadmaps, and portability and ITS associated costs is very much the role of the CTO.
My approach is different than yours. I have seen wave after wave of technology sweep by - and platform independence has always come at both a functional, development, and opEx cost that I have rarely seen justified vs the cost savings of integrating with a major platform. The best examples of this I can give you is the number of folks who did very well by betting on Windows and then iPhones, vs those trying to build to "write once run anywhere" code bases..
But that's a CTO's judgement call. And our jobs and our bonuses and our compensation ride on this. I have nothing against OSS - we use it where it saves us money - but I personally avoid the fear of Vendor Lockin. Its only been an issue when your vendor is highly custom, when its as broad a platform as Facebook - its actually rather costly NOT to leverage the connectivity.
This is also where Enterprise Architecture principles come into play (something I've written more than half a dozen whitepapers on). The key to EA is to look at both your Business Goals and roadmaps and the technology implementations and roadmaps that are being used to act on those business goals and roadmaps. And to proactively identify where future divergences might occur and to plan for them.
But its important to include in that, the costs of what that divergence might impose vs. the costs you incur currently by preparing for an unknown set of divergences that may never happen
![[C]oFoundersLab](/img/logo/blue_cropped.png){kind=logo}
