Koding vm cloud development

Richard Gaskin ambassador at fourthworld.com
Fri Jan 31 11:40:41 EST 2014


stephen barncard wrote:

 > jbv wrote:
 >> My remark is probably OT, but I'm still reluctant in putting my
 >> clients' data in the cloud, and prefer to keep them on our own
 >> servers... Just curious : what is your approach to the problem
 >> all of you guys ?
 >
 > I would trust somebody like Amazon more than my own security team.
 >
 > But I think I would rather wait until we hear from Richard Gaskin.

Thank you for the kind words, Stephen, but I usually just do whatever 
Pierre suggests. :)

JBV: is the client data a LiveCode project, or something else?

There's a wide range of options for both, with tons of cloud stuff 
available for free.

For team management of LiveCode projects I have a system in progress I 
mentioned here an embarrassingly long time ago, back then I was 
referring to it as RevCloud:
<http://lists.runrev.com/pipermail/use-livecode/2010-June/142386.html>

It turns out that the backend for that has been useful in other 
scenarios, from student records to custom CMS solutions. So the upside 
is that those client projects have moved the platform along well, but 
the downside is that they've kept me too busy to complete the front-end 
for the original scenario, LiveCode project management.  Hopefully time 
will free up later this year to finish that.

But it's not too hard to ad hoc your way into a simple solution to get a 
specific job done. With what I used to call RevCloud I spent a lot of 
time making a custom data store because I have other needs for it down 
the road that will have some unusually tight memory and CPU limits I 
need to accommodate.  But if instead you take a saner path and use MySQL 
or even SQLite you can snap together something useful in a few days.

And if your needs are more general there are tools like OwnCloud where 
you can build custom cloud solutions while still leveraging lots of 
excellent work from really smart devs.

For security, maybe I'm lax but I feel that if SSL certs are good enough 
for banking and medical records they're more than sufficient for any 
industrial espionage that might be a risk with client projects. :)

And libURL makes it easy to use both custom and shared certs, the latter 
being a fairly cheap option with most hosting companies.

There are other aspects to security beyond encrypting the data stream, 
and Stephen is wise to suggest letting others who specialize in that 
handle as much as you can offload to them.

But like everything else in computing (and perhaps all of life), it's 
all about tradeoffs.  With cloud solutions the tradeoffs often involve 
cost, flexibility, security, and more.  You can choose a solution that 
optimizes for two or more, but not likely all.

If flexibility is critical and the nature of the client data doesn't 
involve nuclear secrets, you may be pleasantly surprised how nice it is 
to work with Ubuntu Server on a VPS, or even on a small box in your 
office if you connection will allow it.

Right out of the box Ubuntu's firewall is locked down pretty tight (in 
the default configuration it doesn't even allow SSH until you turn it 
on).  And if you take the five minutes needed to set up a shared key for 
password-free login, it's not only more secure but oh so convenient to 
access.

On any server your auth.log will show hundreds of attempt to break in 
every day, and when you're just getting started it can be pretty 
alarming.  But with my fairly stock Ubuntu/LAMP/LiveCode test system 
here in my office, on a fixed IP and outside my hardware firewall where 
it's easy for bots to find, so far no attempts have been successful.

I'm not a security expert, and if a system is critical it's probably a 
good idea to hire one, even if you use an outside vendor for your cloud 
services.  Penetration testing services are often well worth the 
investment when the stakes are high.

There are many potential points of failure in online systems, from 
injection attacks (relatively easy to avoid with modest effort) to 
buffer overruns (to which I'm told LiveCode is almost entirely immune), 
and more.

Many of these risks are inherent to the app you're building, even when 
you're configuring something off-the-shelf, so even with an external 
service like Amazon we can't get lax about security.

But on balance, everything is hackable and most of our work doesn't 
involve nuclear secrets.  Take reasonable precautions, remain willing to 
learn, and stay on top of updates to all aspects of the system, and 
chances are your system will survive at least as well as Target's. :)

And if you just want to share files, I've been enjoying Ubuntu One with 
its native clients for OS X, Windows, iOS, Android, and of course Linux 
- here's some tips on setting it up for folder sharing:
<http://www.howtogeek.com/117064/how-to-share-files-online-with-ubuntu-one/>

Ubuntu One offers 5GB for free, and if you decide to explore it you can 
sign up with this link and you and I both will get an additional free 
500 MB:
<https://one.ubuntu.com/referrals/referee/3401205/>

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys





More information about the use-livecode mailing list