Considering changing my Vfp Apps as SasS Apps

[stanlyn]

Hi,

I need insight, do's and dont's for implementing some of my vfp apps as SasS apps. To solve the uptime requirement for either the whole app, or just the licensing components, I'm considering Azure. Its uptime is far better that what I can provide.

So how would you implement? For now, I'm moving the licensing stuff to our sql licensing server with encryption. This server will be contacted on startup and give back to the app a go/nogo/trial answer. I'm also making provisions for it to be able to skip a few days in case the internet is down, but then lock it down after xx days with no authentication.

I'm developing it now, so nothing is set in stone. Discussion on anything related would be most appreciated.

Thanks,
Stanley

 

[GriffMG]

I took a desktop VFP application and turned it into a collaborative internet based web application about 10 years ago, and it has been an enormous success. I used the VFP OLEDB component and access that data via classic ASP and mostly vbscript.

We allow users to subscribe to a branded portal and then to as many projects as they need on an annual or monthly basis - we keep complete control of the source and no longer allow 'self hosting' as this makes it very hard to recover monies from customers who go bust, and it also leads to over reliance on customers IT people.

A massive advantage of this approach has been our ability to leverage so much out of the existing application - which we run in the background on the servers to serve up the existing reports.

Another has been scalability, we can rent dedicated servers with a few hours notice usually and can drop them when they are no longer required, the server supplier is responsible for hardware issues and provides replacement servers and hard drives very quickly and works hard if we have a problem - which is almost inevitable from time to time.

So, don't - in my opinion - deliver a product to someone else's server, supply it from your own - that way licencing is easy 'pay or we take it away'.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[stanlyn]

Thanks Griff,

This is what I needed to hear. Was wondering if converting them to be web based is worth the pain. Your words "enormous success" is great news.

So, does your converted app still use a vfp frontend along with a sql backend where you control the data which is hosted on your server.

Was this approach accepted by your customer base?

Was there resistance? If yes, for how long?

So, don't - in my opinion - deliver a product to someone else's server, supply it from your own - that way licencing is easy 'pay or we take it away'.

Yes, this is what I'm leaning toward also. Licensing issues would be over instantly.

Has there been many issue where the data was not available to the customer because of an outage? If so, how do you handle those complaints?

Many of my concerns when starting this thread was the political side this exposes. Will my customers mind if I hold the data.

Can you describe your converted app a little more in detail abouts its components and how it all fits together?

Thanks again,
Stanley

 

[Olaf Doschke]

Of course Griff may speak for himself, I just want to point out:

I used the VFP OLEDB component and access that data via classic ASP and mostly vbscript.

This means no recycling of VFP code, just VFP queries executed via VFP OLEDB and towards VFP data, using VB code to access it and output HTML, as it's a web application. Classic ASP is a legacy approach to the web.

Bye, Olaf.

 

[Mike Lewis]

Plus, ASP is Microsoft-specific, which might or might not be an issue for you.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

What Olaf says is entirely correct.

It is a legacy approach, but one that proved to be a real boon when we implemented - went cash flow positive on 1st day of going live.

There is some recycling of VFP code, firstly the processing for the reports is still done in VFP, but then delivered online as pdf files
(mainly, we do csv and xls as well).

The code that was developed over years to enable creation of the databases and to maintain them - version control of the database structure
is still done by the actual VFP app as well - along with those features that we decide should not be in the user's domain (big things like
global changes stuff like that where a lot of damage can be done in seconds).

A VFP app also handles the backups...

None of the interface code from VFP is presented to the web users though, all generated from scratch...


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

Yes, you can of course recycle some administrative stuff and as the data also stays dbf you can reuse database administration code off site, eg directly on the server, if you actually host on a Windows VM, for example, there are many hosters offering Windows VMs, but there is no client side VFP forms unless you go back offering your VFP EXE as download for client side installation. Then the component to change would need to be the data access towards a web service, but as already said in your other thread that layer within an application is the hardest split you can do.

We once hat active document, which indeed put a VFP form into browsers, but the interface wasn't nice looking. You can get over that, if the functionality is right, but the feature deprecated with VFP8 or 9 and browsers need to support ActiveX for that, there's only IE still doing that, even MS rather deprecates that plug in feature, for example see Edge.

Bye, Olaf.

 

[GriffMG]

No client side VFP forms. No VMs either, we tried that and it really does not work, ended up at one point with 4 VMs for each physical server we have now, that
means for a while we were paying a mortgage on VMs that didn't deliver. Spoke to a guy called Craig, tried a dedicated server - modestly spec'ed - and didn't look
back. The trick is in spreading the load - more than one datacentre - and avoiding the 'big guys', post sales support are just - I can't use the word.

Lots of problems with the VM re file handling, timing, stuff - had to SLOW stuff down just to make it work.

But individual servers work much, much better - one hardware fail on a VM is enough to bring (say) 4 servers down, if the PSU goes on a dedicated server
you lose that server for an hour and the provider sorts it out.

To be honest, with a bit of HTML, JavaScript and some imagination you can make a 'more modern' interface with a web app. Personally, I always find it a tiny
bit unreliable, my apps that do the reports also scan the server logs and tell me about errors - some are application related (it is after all nearly a million
lines of code, in three different languages - you are bound to get some) but some are truly random, gets, posts, puts and whatnot from people probing and trying
to find weaknesses, using code from old forum templates to try and do something I don't know about - and of course you always need to look out for SQL injections
(which is an imperfect science).



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

Oh, while I am on it, the VFP OLEDB is not bad, most of the time.

When something gets slow, say for example getting 1000 records across a few tables with perhaps a couple of million records and finding attached files
(remember just an example) - now we move the call into a stored procedure (The old VFP app updates and adds SPs to the DBC). This can make something
that took perhaps 3mins take just 3 seconds - because an SP can use your knowledge of the DB, the indexes and the keys to limit the scope of a
search even better than a Rushmore optimisation, and can use a whole lot less memory.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

On the admin stuff, as Olaf says - you can recyle.

But online collaboration introduces a raft of new things. You have to make sure your passwords are really secure. They need to be one-way encrypted.

If someone gets access to your databases, they must not be able to work out what passwords people have used, they will have used them elsewhere and
if they can work out that FRED BLOGGS thinks 'DEEP PURPLE' is good for you, perhaps it's good for his Facebloke account, Asleigh Moddison login etc.

You should not even be able to work it out yourself, or someone working for you will be able to and take them home on a memory stick.




Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

Just spotted these:

Has there been many issue where the data was not available to the customer because of an outage? If so, how do you handle those complaints?

Yup, with the VMs this happened from time to time - once in three months. With the dedicated servers it does happen, rarely, we had a HDD fail
and that took about 3hrs to resolve, we had people who weren't happy - but we explained the problem, the cause and the solution and they were ok.

That is possible if 1 or 2 customers experience an outage out of say 200 or 300 customers.

The most common problem is not in our realm, perhaps someone can tell me a way around it, we rely on DNS services, and sometimes these have been
attacked by third parties - not attacking us, attacking the people we register domains with. This has caused us about 18 hours outage in the last
five years for a number of sites - we use more than one registrant.

Many of my concerns when starting this thread was the political side this exposes. Will my customers mind if I hold the data.

We have not had a problem with this - the opposite in fact - most of our clients do not have an enormous amount of confidence in their own IT
capability, they have - shall we say - no reason to expect them to have actually done back-ups (because they wouldn't pay for them) or to be able to
cope with a couple of extra GB unexpectedly.

We make it clear that we back up the data, to a different datacentre and we regard the data as theirs not ours, we are not responsible for any of
the content and they can have it back at any time for no cost.

Never been a problem.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[GriffMG]

We have three had legacy customers with our software hosted on their servers.

One is bust, we lost some money, not as much as some employees lost in expenses, nothing like as much as the administrators charged in fees.

One finished the project and we have ceased updating the software and have no reason to assume they are either, we think everyone involved has retired.

The last one is a 'black hole' - pretty sure they used it for a bit, but also sure, because you need the VFP app to update the database, that
the online app is dead - even internally.

These teach us lessons, keep control of your software. Kill it if you do not get paid, a late payer is a non-payer.

You can always revive something that is within your control, at their expense if needs be.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

>No VMs either, we tried that and it really does not work

I see where your thoughts spins off to, but that's not what I had in mind talking about VMs. A Windows VM does not only offer you to host a website, you can also put some VFP code for adminstering the DBFs on site, nothing any client (noth user and client computer) ever get's hand on, the rest of the VM machine just hosts an IIS for a web application, no difference from that to normal website hosting, it's just having more than just FTP access to some webroot folder, you have hands on the whole web server. And that works nice. You can, but shouldn't put the whole VFP desktop app and give users access to the VM, that's like giving them hands on your webserver, no. Going that route Terminal Servers are the better option, but also more expensive and I already said I don't see it as good solution despite of so many doing it. The pro of terminal server rerally just is, you run your old app 1:1. It's more an option for users you can trust, you have contracted, eg employees working in world wide regions.

The thought to not hand out a desktop application simply is driven by the fact less desktops are sold, but end users of business line applications still rather don't drive their business from a tablet. On the go they might do simple things via smartphone, but not major work. Therefore the desktop application still isn't dead. I already said I prefer replication, but that obviously also only holds a good practive, if you don't fear end users fiddling with and causing flawed data with hands on the database. Separating the data from a desktop app into the cloud, yes, I'd also rather put a cloud application up, both application and data. And there a very few options when you want to stay VFP, you should rather do the big step and reimplement then. Use todays internet technologies both for frontend, business logic and data. You can recycle ideas, algorithms, formulas, queries, also data schema, if it's good, but don't force it to ba anything foxpro like or even foxpro itself, or you bind yourself to few options copmbined with something non regular.

Bye, Olaf.

 

[stanlyn]

So the take away from this discussion is,

1. forget about technologies that are Microsoft specific, unless I already use them,
2. forget about depreciated technologies, unless I already have experience with them,
3. use dedicated servers instead of vms,
4. desktops are mostly dead, program for web and mobile,
5. move the data layer away from the desktop and user into the cloud,
6. to implement what has been discussed so far would require a team of programmers as it looks like a need for at least 7-8 skill sets to pull this off. Lets see, VFP, oledb, javascript, html, ?xml?, iis, sql, css, activex, ie, ssl, and possibly visual studio for the front end stuff. And for me, I need to add imaging and scanning with multi-page viewing and printing.
7. start from scratch using modern tools and build it for the web and mobile,

Is all of this realistically doable for a one programmer shop?

I was just trying to leverage my vfp, sql, and iis skills. I really don't want to be learning old depreciated stuff, which probably means I need to cut vfp loose in favor of the new stuff???

My plans was to create a vfp client exe that the client installs and uses with all their data stored on our sql server under our control. It looks like the consensus here is against that and more toward the new iis website stuff, correct??

Am I seeing this correctly? If so, what would our toolkit look like?

Thanks for the discussion,
Stanley

 

[GriffMG]

We do it everyday, we are what the 'mercans call a mom and pop shop. Technical is me, commercial is Danielle.

Activex isn't required, and I use visual studio - the IDE for VFP - to not only maintain my VFP code, but also all the website code.
The only thing the VFP IDE is not so good at is editing the .js files and maybe the .css ones.

The consensus you speak of is a little bit one-dimensional, as only Olaf, Mike and I have replied...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

About your bullet points:

1. In the web the number one server OS is Linux, many things run cross platform, JSP, PHP, even ASP.NET Core now also runs on Linux, but MS is not a bad server system. MS Azure is a main cloud platform aside of Amazon AWS and Googles cloud, and even a classical Windows Server running an ASP.NET web application could work out. In relation to bullet point 4 no web technology would be your goal, but I'll address what you got wrong with that there.

2. OK, yes, your experience with anything makes it a faster alternative than needing to learn new things. If you dust off knowledge about VB, though, I would say the effort to go for VB.NET or C# is quite similar.

3. Surely a dedicated server or even colocation always is faster than VM, a VM can already have big advantages in comparison to the classical hosting web space you get, VMs are not bad in themselves. Any normal account no matter if you get hands on the VM or not, typically runs on a VM. Any decent hoster with an own data center will run VMs on the bare metal, todays servers are mostly only hosts to guest OS VMs, even when you buy dedicated server. The VMs specs count in the same manner as if a server was its own real system. If you really want control about what hardware runs, you may use colocation and bring in your own hardware, but virtualisation also has benefits, eg your VM can move to another host when necessary, hardware crashes and defects don't harm you, as a VM can be started on the next intact host machine. And this is all automatic, your hosters job, not yours. The more you buy, the more hands on you have. AWS allows you to create VMs and run many of them. That's not the problem with VMs.

What not to do with VMs is giving users VM sessions for running a desktop app remotely. It's not what you can do in most cases anyway, you'd not only give access to your app, but your whole hosting system, if you let users login to your VM, but if you theoretically could, running a desktop app each user needs much more RAM than a webserver handling all user requests of many more users. Simply think about what needs to run server side in each scenario. Running a desktop app in a VM everything runs server side, needing the same amount of resources as a LAN client needs. While an app might only need 1% cpu, peak usage is seldom at the same time with other users, a server CPU, even just a VM cpu, can serve
many users, but RAM is a bottle neck, every session will have it's own VFP runtime for example, when you would run your VFP app on a Windows Server VM.

Running a web app, all RAM usage for display, forms, input of data, etc. all run client side, your server just needs fractions of RAM to prepare the HTML it sends out and process the HTML form submission and other http protocol communication in case of attaching a webservice, Rest API, and/or Ajax usage.

But no, VMs are not a no go in themselves, you might use them even without knowing anyway. It's just not the platform the end user should ever see, unless money plays no role to you and you rent big hosting space for each 10 concurrent users or so. It has a big money advantage, you could host your VFP app as usual, no new implementation, but it has running costs and security riscs. You would at least need a hoster offering VMs for this end user scenario without them getting hands on the whole system.

4. I said desktops are dead for home end users, but business app users - at least in my opinion and when I talk about myself - will run a desktop and I count notebooks into this. If you want to serve home end users on tablets , then not only desktop, but also web apps are a no go, then you'd need to go for native apps for Android and iOS or a cross platform app with Xamarin or Cordova and the like, but native apps are still kicking HTML5. Nobody uses a browser on a tablet to use a web app, even if you don't need GPS or device orientation or other native device APIs. The native app is the next desktop thing, but mostly only for software not needing keyboard input. Also not those keyboards with MS surface or Apple iPads. It's ok to work in a train, but not in your office and that will stay. Human hands won't shrink for easier tablet usage and tablets won't grow to not contradict their size for mobility. So a very essential thing I already said above is, business apps with their typical need for keyboard input rather stay desktop. What's bad in my situation is, deciders for budget are not the main users, they may only use a dashboard to display KPIs and other statistics to them and a tablet may be sufficient to them, but their employees enter much more text in many business applications than they and need the best input for that: keyboards. It's still that way and stays that way. Even considering swipe, word suggestions, auto correction on the virtual keyboards of smartphones/tablets, once you learned typing, a real keyboard is your input device of choice. Employees don't attach to a 9" display, they use a 14" notebook at least or larger with multiple displays in a docking station or a classical desktop, maybe not the big tower case anymore, but the size isn't making it a desktop machine. So back to what I said under bullet point 1, desktop may die out, but never in your domain of business apps (I assume you don't talk of game development, do you?), so the sales of desktop vs tablets vs smartphones don't matter much to you/us. Only in the sense of the additional app for on the go features.

5. If you want to move from the desktop overall, yes. If you only want to use the browser on the client, then it's a natural thing, too, that the data is server side. It's more what you wanted, you don't want the end user to have the database installed locally, didn't you made that a requirement. I'm totally fond of desktop apps still with just data rerplication, the cloud mainly is the transport of data needing to sync between sites in this scenario, but of course that means a on premise database at the customer per site. You are the one wanting to move to SaaS, that in itself is meaning data is not local, how could it be? The main poiint I stressed out many times is not separating a frontend and backend, if you can. With a webapp you can't keep these two together, by definition the frontend is separated to backend. It's the hardest thing to reimplemnt that, if your VFP desktop application does not already have a client/server architecture. And having DBFs on a file share is not having client/server architecture in itself.

I see a webapp still as nearer to the concept of a remotely running application, as you don't develop a frontend as rich in it's own functionality than a typical VFP form is. The typical VFP form rather is self contained, pulls data at init maybe also while using it, then saving at end of it's use and then finishes. Every interaction on it, very high level workflows are done in form methods. If you want that in the web you mainly need to use JS and that's the most unfortunate language to program with in my experience. JS once was built in 10 days and it's only intention back then was providing some simple client side features, not a desktop form feeling.

With a web app, you rather split a complex Winform into many steps in simpler HTML forms with submits to server at more times than you'd need save/close button usage on a winform. Just seeing you also have textboxesd, comboboxes and grids in HTML controls doesn't make it the same interface. You don't usually have formsets open in parallel, drag&drop from form to form and many more things you can rather easily do in the desktop, besides enabling such things in JS it's not the interface users are used to in browser, a browser canvas is not a desktop, each tab is one form. Users use the browser as multi desktop with maximized forms only. I do, nothing else makes real sense in browser usage. You know the web, you use the internet, don't you? You know it's giving you another experience as desktop apps. How often do you save files or open files from a browser? Very rarely. The whole experience is totally different as the outset differs very much.

6. For native apps: Java for Android, Objective C for iOS, C# for Windows mobile apps or with less needs some cross platform thing like Xamarin (C#,CSS,HTML,JS) or Cordova (JS, HTML, CSS plus API usage).
For web apps: JS, CSS&HTML client side, PHP or Ruby or Python or JSP or ASP/ASP.NET server side, MySQL or MSSQL and sql queries (no more workareas, cursors)
Cloud apps are rather like web apps, you have more API usage, but your end users still sit in browsers, nothing more native.

7. Yes, I already removed VFP from 6, it makes no sense to continue VFP on the web, native or in the cloud. There is the FoxWeb, FoxIS in foxpro sample, there is ActiveVFP and AFP as classical scripting server side VFP solutions, but they still have the HTML frontend and change or architectural principles and when going that route, don't stay foxpro.

Besides all that you can look at FoxInCloud, that's keeping your VFP app mainly as is. You forget one thought, if you lay weight on your own knowledge, though: What will be after your retirement, will no one inherit your business? Even if your business then simply ends. What do your customers do then?

Bye, Olaf.

 

[stanlyn]

Hi Griff,

I use visual studio - the IDE for VFP - to not only maintain my VFP code

Are you saying you use Visual Studio to maintain your VFP code? If so, how are you doing that? Any whitepapers on how this is done? By using Visual Studio more, the stretch for the web stuff should be easier, I would think.

From what I know, VFP stuff has to be written and maintained with VFP's IDE and the wed stuff is maintained in VS... If you are doing this differently, like doing all your VFP stuff within the VS ide, then I'd like to adopt that as that would give me much more time in VS.

Please clarify,

Thanks, Stanley

 

[GriffMG]

Sorry Stanley

I may have muddled things, VFP was part of visual studio, and I meant I use the VFP IDE to maintain as much of the code as I can - all the .asp vbscript stuff as well as the normal VFP code and forms.

I like the tools like the code references etc. and it does work well. Except for the couple of examples with .js files and .css files, where I probably should associate them with the VFP editor

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

Just one note, SaaS - Software as a Service, is one of those buzz words and cloud marketing terms coined to make a difference or propagate a "pardigm change", while any classical web application not running in a big cloud system, but normally hosted already is providing a software as a service you host for customers with all the key features the SaaS term means, no installation or infrastructure needs on the client side, installation, updates, backups, in short all development and adminsitration is done by the service provider, etc.

One big topic is scaling for more users. If you start serving a small user base but plan to scale for much more users, a cloud solution typically means your whatever technology web application is hosted with VMs in some cloud system, which can spawn a new VM just in time, just when needed for serving a higher load. So in that aspect VMs are a big point of cloud solutions, but the core application development still is with any web technology you can also use without basing on such a scaling concept.

Bye, Olaf.

 

[stanlyn]

Hi Olaf,

#1,

MS is not a bad server system

I know and agree...
#2,

If you dust off knowledge about VB, though, I would say the effort to go for VB.NET or C# is quite similar.

I've never written anything in VB. I have converted some VB code to VFP before and can generally read and follow its logic.

#3,

It's just not the platform the end user should ever see, unless money plays no role to you

So are we back to creating our frontend as a desktop client and only serve user's data from servers in our control?

#4,

Xamarin

I'm looking at that solution and looks very promising, however still plagued with the need to master tooooo many technologies before billable work can be created.

I agree that that bulk of my customers will continue to use desktops for reasons already mentioned. However, the desktop users are wanting to interact and do minor data work on mobiles whereas the mobile app becomes an extension to the desktop apps. Things like data collection and alerts... Many other areas where mobile can improve the experience my app brings to them.

And yes, NO game development.

#5,

You are the one wanting to move to SaaS, that in itself is meaning data is not local, how could it be?

I'm mainly concerned on having control of the data and using Griff's (pay or no-play features). I've had customers owe us lots of money and instead of paying, they quit us and hand over the data and images to our competitors for use in their document imaging system.

I have already finished testing our methods of encrypting the 4 million images and storing them in SQL along with performance data. This will solve this issue, and if the customer decides not to pay, our contract allows us to use their data in our data center. (land, marriage, wills, mortgage, liens, contract and other records) In 2008, we lost 80k due to having all data on-site and in an un-encrypted state. In 2010, we lost another 20k, same scenario. I also know that I can encrypt the files and leave them on disk, however I've decided to make it a bit harder for them to convert should they decide to pay up and still change to the competitor. Look at it as a new revenue source (data conversion) One site can easily have a million images. I've tested my routines on up to about 4 million images, with great performance results.

The whole experience is totally different as the outset differs very much.

It doesn't have to be as I'm seeing more and more browser apps providing identical experiences as found on their desktop counterparts. Take a look at what MS's OWA from years ago and probably Office365 (no experience with it). Getting the look and feel of desktop apps appears to be a priority of many of the tool vendors.

#7,

You forget one thought, if you lay weight on your own knowledge, though: What will be after your retirement, will no one inherit your business? Even if your business then simply ends. What do your customers do then?

What are you saying here? Forget my knowledge and build for the future? or ??? Not clear on what your point is.

Thanks for such an educational class. I've learned a lot here today, and thanks for taking the time to lay it all out there...

Thanks again,
Stanley