I was quite happy and satisfied for being able to attend a talk about a demo/intro about Amazon's cloud-as-a-service solution, the Amazon Web Services. Apart from acquire more technical knowledge, it sort of gave some options to prevent too much cost on set-up of a server for public-viewable production use.
I don't want to bother talking and putting more details on what's the technical differences and the pros and cons of AWS from traditional in-house or other cloud-hosting providers since there is really no absolute truth or "standard" that can explain this in concrete sense. But one thing that I'm actually keen is on their "free tier usage" for new AWS account holders.
Well, on a marketing standpoint, the "free tier usage" is their proof-of-concept or demo-to-purchase to reel in customers and use their offered service... which is all true perhaps. But for tech-enterpreneurs who are looking for ways to deploy their apps or products over the net and be accessible to their target customers, I could really say that AWS should be there on the potential list for achieving it.
The "free tier usage" from what I understand is good for 12 months upon sign-up of a new AWS account... which for the record requires you to provide a credit card. But despite of that uneasiness for people that are not entirely comfortable of letting someone save your credit card credentials... it is a gamble worthwhile. The main agenda at the end of the day is to try out if the 1-year free trial service that AWS offer can meet the requirements of your start-up tech project. In turn, it will make you actually move forward to realization of launching your start-up project into production.
Everyone would like to spend (too much) money on a start-up that has to prove its value, and releasing it to the public market is the driver or decision-block on determining a winning formula or just another rubbish in the bin. Of course, when it does become a huge hit upon release to the public, you would likely need to think of scaling the capacity and performance. In AWS, you can scale your set-up as convenient as you can, and as their saying goes "pay for what you only use".
For more info on this matter, I suggest you to read their program details at Amazon's own website at this link.
Monday, April 30, 2012
I encountered a weird behavior from my recent projects that were related to some setup of gateway servers, for both Linux-based (Debian) and BSD-based (FreeBSD) systems... wherein there is an issue when adding static gateway routes that does not match or fall within the defined subnet network configured on a network interface.
To give a better detail or explanation of this predicament of mine, below is a sample network configuration scenario...
- Network IP address subnet is 10.10.1.0/24, so that's basically 10.10.1.X correct?
- Gateway IP address is... let's say 10.50.1.27...
Clearly on the scenario given, the IP address of the gateway is outside of the network subnet defined for a network interface. Here in the Philippines, this is a common case for leased-line internet connections coming from telco providers.
From previous engagements, I don't have a problem hard-coding this on either the interfaces config file or in the rc.conf... but in the recent turn of events and experience, it seems that the latest linux kernels and BSD builds have incorporated a sort-of mechanism that prohibits this kind of configuration to be enabled and up upon start-up of the operating system. I've experienced this issue with a Debian Squeeze server and a FreeBSD version 8 I think (am not really a BSD proficient guy, just the basic UNIX made me survive).
The setup still works with this kind of interface configuration, but upon boot-up, you have to manual place the static routes (using "route" command) for it to recognize and see the gateway IP you want it to use.
My initial solutions involved adding static routes on the interfaces config or on the rc.conf files.
post-up route add -net 10.50.1.27 netmask 255.255.255.255 dev eth0
post-up route add default gw 10.50.1.27
post-down route add 10.50.1.27 netmask 255.255.255.255 dev eth0
post-down route add default gw 10.50.1.27
Sadly though, my attempts in fixing the BSD-based system ended up in failure. As for the Linux machine, well I have yet to fully test it out since the project suddenly reached the end without further testing.
Hope this rather weird post of mine helped to shed some light to their problem and looking for an answer.