While we’ve been evaluating AWS at Gorlet one of our primary objectives has been to be able to rapidly scale capacity. In the course of our research we ran across RightScale which provides a Cloud Management Platform. Their platform is designed to provide automation, control and flexibility in managing a ‘system’ instead of servers.

Essentially, RightScale provides the following:

Cloud-Ready ServerTemplates – RightScale uses a template system instead of the AMI system used by AWS. By maintaining parameters instead of images there is less room for error and a time savings in configuring and deploying instances.

Automation and Orchestration – RightScale provides the ability to auto-scale, monitor and remediate instances.

Choice and Portability – RightScale provides the ability to deploy a wide variety of configurations on a wide variety of cloud providers, not just AWS.

Again, the two additional areas of evaluation are cost and support. In this case, the costs are reasonable, but like AWS the area of concern is support. With the Bronze support package, max initial response time is 24 hours and Gold provides 1 hour emergency response and 4 hour max initial response time.

Free Standard Premium Corporate Enterprise
Bronze Support Silver Support Gold Support Platinum Support
FREE
Single User
$500/mo
Initial fee: $2,500
$1,000/mo
Initial fee: $4,000
Call for Pricing Call for Pricing

Yet, for our purposes, we are continuing to evaluate the use of AWS to provide the functionality we’re looking for through the use of Auto Scaling, Amazon CloudWatch and Elastic Load Balancers.

AWS Auto Scaling allows you to scale your Amazon EC2 capacity automatically up or down according to defined conditions, increasing instances seamlessly during demand spikes to maintain performance, and decreases automatically during demand lulls to minimize costs. Auto Scaling is enabled and implemented by Amazon CloudWatch. This is great for us as we can very closely define when during the day we will have high-usage, particularly when used with CloudWatch.

This can then be used in conjunction with Elastic Load Balancing, which automatically distributes incoming traffic across multiple instances, provides the ability to achieve fault tolerance and provides load balancing in response to incoming application traffic. Elastic Load Balancing also detects unhealthy instances within a pool and automatically reroutes traffic to healthy instances until the unhealthy instances have been restored. New, healthy instances can then be launched automatically to ensure continued performance.

In essence, this provides everything we’re looking for, monitoring, scaling capability and fault-tolerance for a relatively small cost, about $30/month (plus data fees) for detailed, 1 minute interval monitoring and the Elastic Load Balancer usage. Certainly not as simple simple as RightScale, but with some solid upfront work and testing we believe that we can achieve the same functionality at a reasonable cost. At our current size and business situation, this functionality and cost combination is hard to beat.

.NET – Strengths and Weaknesses

September 18th, 2009

The biggest strengths of .NET are its widespread use and ease of finding skilled developers and admin, primarily due to the fact that so many companies already run Windows based servers.  While it has wide adoption in Windows based organizations, this platform is not as frequently seen in startups which start from a clean slate and are more cost conscious.

Let’s look at some key components for a comparison:

Open Source – No

Object Oriented – Yes

Compiled Code – Yes

Scripted Language – No

Licensing Cost – Expensive licensing costs

Platforms – Windows

Hardware Costs – Mid-range costs

Staffing – Easy to find qualified admin staff

External Hosting – Available, but more expensive than PHP

Security – Getting better

Performance – The better the hardware the better the performance

Scalability – Can be difficult

Admin – Easy

Available Frameworks – One standardized framework.

Compatibility – Mid-range.  New releases sometimes break functionality.

Site Monitoring

September 9th, 2008

Reactive Monitoring

To expeditiously address any problems that your web site might encounter, most companies establish some platform and process for site monitoring.  Normally, the monitors are set to identify problems when they occur with one of the most common areas below and are set to automatically notify the individual(s) who can quickly rectify the problem.

* HTTP: Web Server
* POP3: Email Server
* SMTP: Outgoing Email Server
* FTP: File Transfer Protocol
* SSL: Secure Socket Layer
* DNS: Domain Name Server
* Custom TCP Ports
* Ping
* Web Page Content

To run a reliable site, these monitors must be in place.  In addition a documented plan for reacting to the event notification along with an automated escalation procedure must also be established.  I refer to this as reactive monitoring and this type of monitoring is quite common.

Proactive Monitoring

While having the ability to react to problems is extremely important, it is also just as important to attempt to prevent problems from arising in the first place.  That’s why I advocate establishing a much more extensive and comprehensive set of monitors that can help you identify potential problems, and correct them, before they become apparent to the end-user.  This list can become quite extensive.  It is probably a good idea that the more traffic and transactions that your site handles the more monitors that you should establish.  Again, the attempt here is to identify certain thresholds that when reached indicate that if action is not taken there is the potential for problems at some point in the future.  Examples include:

* CPU usage
* Disk space usage, both physical and virtual, both database and front-end server
* Various application services, above and beyond those discussed above
* Bandwidth usage, if you are bandwidth constrained
* Disk utilization to measure physical disk performance constraints
* Tempdb space
* Environmental factors, particularly temperature

These are proactive monitors and are part of an overall strategy to achieve the highest site availability and reliability that you can.

Performance Monitoring

The third type of monitoring that is used is Performance Monitoring.  With performance monitoring you usually contract with a vendor that has a number of geographically dispersed monitoring sites that specifically measure the response time of requests to your servers.  In addition to providing information that can identify performance problems, even when everything is actually running, this service can also identify problems that specific geographic areas may currently be having in accessing your site.  If the performance issues are latency related this information may lead you to incorporate a strategy which mitigates the problems for users in the affected areas.
Historical or Baseline Comparison Monitoring

This is not really a separate type of monitoring, but a means to store data values obtained during proactive monitoring so that the data points can be graphed to show historical trends.  Having this ability can help identify the trends of such things as CPU and disk space usage so that hardware upgrades can be made in advance of when they are needed and emergency upgrades avoided, which is never a good thing.

Usually, site monitoring is an afterthought.  As an afterthought only the basics are initially implemented.  However, it is important to develop a comprehensive monitoring strategy that incorporates reactive, proactive, performance and historical monitoring.