Week 9 and 10: Security, Scalability

Since I forgot to post on the class last week (or more like, too caught up in work), will do one post on both weeks at the same time.

----

Week 9 was on security. Security as a form of protection for users' data that has been entrusted to you (as simple as a password).

The ultimate test of the lecture contents is what you remember after 1 week. The 2nd half on how IBM is structured to produce security products, I didn't really pay attention. But the first half was rather interesting, especially when a typical loophole after another were revealed in class. I particularly remember the part on SQL and code injection, because that was one of the earliest security lessons on a web service I had. And maybe about password hashing for storage. And this.

I remember the first time I encountered PHP programming was in Year 1, in RH computer club. We were supposed to pick up PHP and MySQL to write a "Supper Ordering System". Of course novice projects weren't implemented, but in the implementation, one of the seniors taught me the concept of MD5 hashing. I was hooked on this simple way of protecting users' passwords, yet not being computationally complex (I still don't understand SSL, encryption keys).

Under some circumstances that are now fuzzy memories, I managed to talk to one senior on database statements. And so he taught me the need to protect against SQL injection, by escaping every string that was provided by the user — possibly using a custom layer to protect every SQL query that goes to the server.

One thing that I always believe when developing apps is that we have to have security in mind right from the start. From the storage layer, user data especially private information should be somehow protected. The best place this can be done is probably at the database interface layer.

I don't know much about securing the communication between the user and the server, but another thing is to protect your data from being tampered without the right credentials, and to prevent leaks of the same data. So the usual implementation I'd come up with is: if you have the correct credentials to access the data, I'll let you push or pull the data. And guess where this goes — database layer.

Of course, authentication and stuff is another tricky issue that needs rather in depth testing to make sure no information can be leaked. I don't know much about this, so let's leave this to the experts to say so?

----

Week 10 was on scalability. Nice, big word. And coming with it are a whole bunch of related terms like, elastic provisioning, high availability, load balancing, duplication, redundancy.

I always had an interest in scalability - of storage. In the past, when I was running a computer with a small hard disk, the numerous external hard disks that came in 40 or 80 GB, ended up being consumed very quickly. That'll probably make any person who backups regularly think "where am I going to put my next backup? a new hard disk? or do I delete some old ones to make space for the newer backups?" And the headache gets bigger when you deal with backups and shared storage across a network that you maintain alone.

Then came along NASes. And WHS (Windows Home Server - I'm a supporter of this OS). After one year of evaluating the costs-benefits of each variant (linux boxes vs headless WHS), I caved in and got a DLink DNS323. What it seemed to tell me is that the storage in this box is going to be scalable. Put in one disk, you get a 500GB NAS. Put in 2 disks, you get redundancy (duplication RAID-1) or speed (RAID-0 or JBOD). Replace disks, you can seamlessly upgrade to larger disks under RAID-1, and to your clients, it's all transparent.

WHS was even better. After WHSv1 got terminated by MS, I got a friend to buy back WHSv1 from the US, and installed it on an older desktop. The best part of WHS over linux NASes like my DNS323 was that my storage was expandable, scalable — across ANY bus type — to create a disk pool. And I didn't have to worry about storage being a limitation anymore as long as I have enough ports (money is still, data must still live in hard disks). When capacity is reached, just get a new disk, and the software automatically balances storage and duplication across the disks using certain heuristics (like associated files are kept on one disk to prevent spin-up & down across many disks or something like that). And still, to the clients, it's all transparent. (Plus I get proper windows server support for shared printers!)

But. The awesome Drive Extender software layer had been terminated as of WHS2011, but its spirit lives on, reinvented in Windows 8 Storage Spaces.

(The joys of a digital hoarder.)

As can be seen, scalability of a home NAS / server has many parallels to a web service that is accessed by many clients. In a storage environment, the resources that are needed are the physical disks, while in a web service, the resources are the app logic and database etc.

But the same concepts apply. Addition of low cost layers to the resource acquisition process: duplication of essential services (redudancy), load balancing & proper routing to the desired resource. All while being transparent to the client (same IP, same HTTP requests).

In any case, it was interesting learning about the scalability issues from a more fundamental software, hardware and efficiency point of view (like swap, RDS i.e. slow clients, and the expensiveness of threads on linux - never knew that!)

----

Noticed I like to relate what I've learnt to past experiences. Interesting.