One thing to remember is that GitHub is not Apache’s main source control solution.  Apache still uses Subversion and as such doesn’t use the same concepts used with Git or GitHub.  For instance, if you were to fork the Flex repository, you could clone it and do all your changes and send over pull requests but the powers that be won’t accept them (as far as I heard, that might change).

The best thing to do would be to clone the repository directly from the Flex project so that you can easily stay up to date with the changes.  Then apply your changes locally and create a patch file by doing git format-patch master --stdout > your_patch_name.patch.

After the patch file has been created, you need to attach it to a Jira ticket (need to register for an account). If one hasn’t been made already, create a new one and be descriptive as to what was done, why it needs to be done and maybe even your thoughts behind it; the more information the better. You should hear from one of the community in the next week or so about the status of your patch.

That’s all there is to it. Now go forth and contribute!

All of this was recorded and can be viewed on UStream.  Video after the break.

When I couldn’t find the information needed online, I figured I would give the ol’ trial and error method a try.  We decided to go with Amazon cloud services because of its proven track record and amazing web management interface.  Then I went about implementing our first server which would run Apache, Git, Jira, Confluence, Nexus and Tomcat; everything we would need to run our business and development.  I also create a MySQL instance using Amazon’s RDS, then wired up up the domain to Amazon’s Route53 (DNS ) and created an Elastic IP assigned to the server for public accessibility.

It was beautiful. In a matter of 3 days, with no prior knowledge about Cloud Computing and some elbow grease, I had manage to setup our infrastructure needed to start coding.  I was so proud of myself.  Then the bill came;  It was several hundred dollars for a month.

Fuck.

Live and learn I guess.  Searching through the extensive documentation  (good job Amazon!), I couldn’t find information on how to lower the costs.  I was given so much information that I felt like I was thrown in the Wild West.  I remember that feeling, overwhelmed by the unmitigated amount of what’s possible; it’s the same feeling I had when I tried to install Linux for the first time (the distro was Debian).  Since I wouldn’t wish that feeling to any developer, I decided to write a small primer to Amazon’s cloud solution in hopes to prevent this serious affliction in other possible newbies.

Foreword

When I was reading up on EC2 and other Amazon services, the notion of Computational Units, Compute Hours and pay what you use is mentioned several times in the documentation.  However, I couldn’t find a simple, no marketing bullshit version of what it actually means; that is, until it was too late.  In my case, the point of confusion was the “pay what you use” part.  Amazon made it sound as if that you only pay when your computer isn’t idle (ie. actually doing some work), but that’s not the case.  The simple truth behind “pay what you use” is that every hour your instance is running you pay the fee per hour (which Amazon rounds up), even if it’s idling.  The way they spin it is with auto-scaling, where if your instance is using a certain amount of CPU cycles, it can create a new instance to offload the work so that you won’t pay for the second instance until it’s actually needed.  Of everything Amazon has done that I find awesome, this is the one thing that irritated me.  Why is it that they simply couldn’t say what they actually meant?  We would of gone with Amazon either way, but a better explanation and some examples of how to implement the architecture would of helped considerably.

More is Better (and Cheaper)

I know that this doesn’t seem to make sense at first, and I told myself the same thing.  How can having more of something costs less?  Don’t ask me how Amazon is doing things, but all I know is that in the AWS world, it’s better to have 5 micro EC2 instances than having 1 large instance.  For example, since an On-Demand Linux Micro instance costs $0.02/hr and an On-Demand Linux Large instance costs $0.34/hr, if you have 5 services which can split up between 5 different Micro instances, it is still more than two thirds reduction in costs.  The added extra to having multiple Micro instances is that it’s easier to manage.  When it comes down to scaling or doing backups, you can be much more granular which reduces your costs even more since you don’t have to deploy more than one service at a time.  If it’s possible, always use Micro instances.

Reserved Instances are Your Friends

Another to cut costs are to do Reserved Instances.  What are those you say?  Simply put, you’re buying an allotment of time on a specific type of server for an specific amount of time (1 year or 3 years).  For a one time initial payment, the hourly cost of your servers are greatly reduced (up to 55%).  Afterwards, everything else is exactly how you would create an On-Demand instance as long as your instance is of the same type of your reserved.

Use EBS Volumes, Shared or Otherwise

When you create an EC2 instance, you have a choice as to what time of instance you want in several ways.  You can get Linux or Windows, different capacities (micro, small, large, x-large, and High-CPU), and Local Store vs. EBS.  Local Store means that when your instance terminates or just reboots, the information on the “hard drive” is completely erased.  When you use EBS, your volumes can be stored (snapshots) to either create new instances with the same data and when you reboot you don’t lose your data.  This is an easy to share similar configurations that aren’t database-driven between instances.

Scaling Your Instances

There are two ways to scale easily, to use Beanstalk with an independent WAR file or use a custom AMI to create a new instance.  Both of these ways are good, but personally I like the id’ea of having everything completely independent in a single, easily to deploy file (WAR or EAR); especially for external services that needs to be deployed.  For internal services, using snapshots are more than fine for manually upgrading the workload, but it’s not adequate for proper scaling deployments for massive amounts of requests.

Separate Security Groups

Trust me when I say this, the more granular you can get everything in AWS, the better.  It will make changing your mind while creating the systems that much easier.  This is true for everything, but especially Security Groups.  These are a simple concept; each instance can be part of a specific group and each group can manage which ports are open or which database (or other services) they can access.  Unless you’re using Amazon’s VPN solution, after an instance is created, you cannot change the security group.

Use System Variables

While I was creating these server instance, I thought to myself on “how do I scale these servers?”  There are several answers to this, but what I was mostly wondering is how you code to make it scalable.  The quick answer is to use system variables.  After you create your instance, you can set some system variables, like the URL for your database which can be used by the code with System.getProperty(‘someProperty’).  Moral of the story is, if you want to be scalable, you have to make your code based upon system variable for malleability.

Databases are Costly

This is probably the most important part of this post; Databases are expensive.  Why?  Well, good databases needs a lot of CPU and memory for it to be responsive enough to the need of large scale web applications.  The good news is that RDS databases from Amazon also go through the same model of having reserved servers to save cash,  but even then, they’re still expensive.  If your application is time critical, I definitely recommend that you use Amazon’s RDS solution, however you also need to think about the latest offering from Amazon’s treasure chest; DynamoDB.  This is a NoSQL database that doesn’t charge you based on memory, CPU or capacity consumption; it works purely on how many requests that are being made.

NoSQL databases are a new way of thinking about web applications which I won’t get into, however I will say that Amazon’s new service will definitely change the game as to the scalability of your next application and the easy of maintenance of said service.  I would recommend every engineer to look at both relational databases and NoSQL database and list the pros and cons; in some instances, you need only one and in some other you need both.  It really depends on the needs of your business.  Either way, DynamoDB is a definite winner in my book for NoSQL.

Conclusion

With all that said,  I am thoroughly impressed with Amazon’s offering.  The only thing lacking is a better user experience around starting out.  Partially because of the fact that it isn’t my domain of expertise, but also that I jumped in without learning how the whole system works in the first place, which I think can be simplified.  Either way, this was a very humbling experience that I will never forget and at the same time, I got to learn how real cloud computing work in the real world.  Amazon is still the proper, cheap(est?) way of doing web services, but it all comes down to knowledge.  My hope is that someone in the same predicament as me gets to see this posting and avoid the issues that I had.

Good luck in your next cloud venture.