bgror

All About High Availability »

Created at: 09.05.2012 02:22, source: Engine Yard Blog, tagged: Technology Tips & Tricks training

What is a High Availability system? There are multiple opinions/definitions of high availability. Some people refer to it as Disaster Recovery; I refer to it as an implementation to ensure that business systems spend minimal time down from a disaster.

For the purpose of this post, I think we should establish a description of Disaster Recovery and how it relates to High Availability. Disaster recovery includes the processes, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster. There are 7 tiers to disaster recovery; tier 0 is no data loss prevention or basically several single points of failure, while tier 8, which is a fully automated failover system with zero to minimal data loss. Tier 7 and 8 are more in the classification of High Availability. Recognizing that there are plenty of discussions, opinions, and confusion regarding High Availability/Disaster Recovery, I have decided to discuss what I believe is the most logical solution for e-commerce and mission critical cloud applications.

Utilizing cloud technology for applications has grown immensely over the past 3 years. This growth is due to the fact that IT organization (or lack there of) has minimal responsibility, overhead and maintenance. All of this equates to less money spent and larger margins on revenues.

Although this has its upsides, there are many pitfalls associated as well. Some of these are lack of control over infrastructure, lack of knowledge as to what infrastructure is to be utilized and a lack of knowledge about the maintenance of this infrastructure. It is important to remember that cloud infrastructure is subject to outages just as normal infrastructure would be. A virtualized environment is a great way to minimize costs and maximize margins, but it does not prevent against outages. To minimize the lack of control clients have over these systems it is recommended that one invest into an insurance policy that would minimize down time during a man made or natural disaster.

The most logical or practical insurance plan to ensure ones business stays up with minimal down time is to implement a geo redundant High Availability system. A geo redundant system is basically a master/slave system located in two separate geographical locations. This is very similar to what most everyone implements with their local databases, in the event of the master database failing the slave takes over to where the application has minimal to no data loss with minimal application downtime.

Accurately implementing requires that the database replication is constant, in our agile world we also need to ensure that all code is pushed to both locations, the directory structures are replicated at a specific intervals and that all of the policies and procedures are in place to fail over from one geo location to the other geo location with minimal downtime and maximized efficiency. With the lack of control in cloud computing and the definite knowledge that an outage will occur, the logical solution to ensure Application up time and minimal Data loss is to implement a Geo-Redundant High Availability system.

We at Engine Yard recognize the need that clients have in running their applications on the cloud and that downtime equate to loss of revenue and more importantly possible loss of client. We have now implemented this technology and are offering it to clients that need that solid insurance.

Check out Engine Yard Professional Services page to learn more. If you have any questions about services offered for the Engine Yard PaaS, please feel free to contact proservices@engineyard.com.

 

more »

Introducing the New Feature Request Forum »

Created at: 17.01.2012 20:30, source: Engine Yard Blog, tagged: Technology Tips & Tricks training

more »

Introduce a friend to Rails »

Created at: 12.08.2011 02:05, source: Engine Yard Blog, tagged: events training Engine Yard University rails for zombies ruby on rails training WindyCityRails

This post has one purpose. I want you to bring a friend to the Introduction to Ruby on Rails training day on September 16th in Chicago. Code School's Gregg Pollack, of Rails for Zombies fame, is leading this day-long session, and it promises to deliver. Heck, bring two friends. Make sure they're cute.

Enroll Here

Now that we've gotten that out of the way, let's talk more about your cute friend, and why he or she should join us.

In my role as director of training at Engine Yard, I have heard two phrases again and again. The first goes something like this:

"We need to hire Rails programmers, but they are hard to find, and expensive."

The second phrase is the other side of the coin:

"Rails is awesome! I have so many opportunities!"

In the short run this is good news for the Rails guru. The labor curves drawn by your freshman Economics professor illustrate the benefit. An intersection of a low point on the labor supply curve with a high point on the demand curve means a solid income for all of us.

In the long run, and assuming the pressure to deliver web applications remains constant, there are some different economic models to consider. Even without innovation in other languages, a decrease in productivity due to talent acquisition costs will lead to fewer Rails projects over time. Alternatively, an influx of new Ruby on Rails programmers will help meet current and future demand.

To put it simply, if we love Ruby on Rails, which we do, it is in our interest to recruit new blood. It will grow the community, keep things thriving, and give us more warm fuzzies than the GDP of all the OPEC nations combined.

By the way. Gregg's session is followed by the WindyCityRails conference the next day. Does this not have the makings of a serious road trip?

If Rails is your religion, get your PHP and Java followers, and start the pilgrimage to Chicago, a city of great food, awesome pubs, and home to more Nobel Prize laureate Economists than any other city in the world.

Note: If you're interested in attending or hosting an Intro to Rails course (and the Zombies) in your city, get in touch.

Additional Note: Thanks to Obtiva for providing the space for this awesome event!

Yet Another Note: Cover image of May I Bring a Friend was included with permission from Perfection Learning.

more »

The Common Threads Through AntiPatterns »

Created at: 24.05.2011 23:30, source: Engine Yard Blog, tagged: Tips & Tricks training Engine Yard University rails antipatterns training

For a few years, I’ve been developing content and giving talks on the theme of Rails best practices. This work came together under the name Rails AntiPatterns in the form of a book, a recent podcast and webinar, and some upcoming workshops in Boston and San Francisco. Throughout these activities, some common themes have emerged.

• Read up on good OO practices
• Work on real software
• Work with a team that cares about craftsmanship
• Follow the Rails commit feed
• Upgrade to latest Rails quickly

Many Rails AntiPatterns can be avoided by following techniques that have been around for a long time

Last week at RailsConf there were at least three talks that mentioned SOLID prominently, as well as other principles of clean code and object oriented programming techniques. This is great to see. Ruby is a great OO programming language and by following well-proven principles you can keep your code clean and well-factored. I think it’s actually refreshing to realize that what we’re doing here isn’t particularly new or special and that there are proven techniques, learning materials, and important thought leaders we can fall back on to ensure the quality of our code and our applications. There is lots of good stuff out there on principles of object oriented design, refactoring, and clean code, but here is some good reading and watching.

• Clean Code
• This is the post that introduced the grouping of concepts behind SOLID The Principles of OOD
• Here is a video about applying SOLID in Ruby SOLID Object-Oriented Design

Many Rails AntiPatterns stem from unfamiliarity with Ruby on Rails

Being the popular new kid on the block, it was inevitable that Rails receive an influx of developers from other languages and frameworks. Each of these developers brings with them the techniques, both good and bad that they’ve learned from their past experiences working with other tools. This leads to either things being done just plain wrong, such as violations in MVC, or things being more subtly just not the “Rails Way”, such as making certain things, like modeling, overly complex. The two best fixes for this that I’ve found are continued practice with Rails, and working on real software with a team of other developers that care about quality and craftsmanship. Working together, you can help each other identify improvements to your code via lightweight code reviews or Campfire discussions. An extension of this problem is not keeping up with the changes in Rails itself. With each version of Rails new features are added and existing features are refined. If you’re not keeping up with these you’re likely writing more or worse code than you need to. Combat this problem by becoming and staying invested in the framework you use. If at all possible, follow along with the Rails changelog RSS, even if its only something you skim. More importantly, keep your application on the current version of Rails and upgrade as soon as possible after a new version comes out and someone writes an “upgrade gotchas” post for this version. Once you’ve upgraded, make sure you’re refactoring your code to take advantage of new features and syntax changes. There are other important maintenance benefits to this too, so making the business case for the time shouldn’t be difficult. This is particularly relevant with Rails 3.1 coming out soon. If you haven’t upgraded your application to Rails 3 yet, that means you’re going to be two important versions behind once 3.1 is released. Some gem and plugin authors have already started to drop support for Rails 2.x, once 3.1 comes out I think you can expect the number of gems to drop support for Rails 2.x to increase dramatically.

The Rails AntiPatterns Workshop

In the Rails AntiPatterns workshops we’re going to sit down with your real code and we’re going to identify problems and work on fixes as a group. In doing so I expect that we’re going to touch upon these common threads repeatedly, and we’re going to call upon proven object oriented design techniques to help improve our code. The class sizes are small so we’re going to be able to work directly with each other and get some real quality time together. I hope you’ll join me.

more »

Rails AntiPatterns: The Course »

Created at: 16.05.2011 20:25, source: Engine Yard Blog, tagged: events training Engine Yard University rails antipatterns

Next month, Engine Yard University and thoughtbot are launching Rails AntiPatterns training, an instructor led course based on the book by Chad Pytel and Tammer Saleh. The course is for Rails programmers who want to identify, address and discuss some common Rails development pitfalls. It is an advanced class, and assumes at least a few months of Rails programming experience. To get a sense for the course, check out the Rails AntiPatterns Open Session webinar from last week in the embedded video below. While the hour long webinar session was more impromptu than the written course curriculum, the themes are consistent with what you will learn over the course of this two day instructor led training.

Rails Antipatterns - Open Session with Chad Pytel from Engine Yard on Vimeo.

For Rails programmers who want to take their expertise to the next level, please attend Rails AntiPatterns! The Boston session is on June 6th, and the San Francisco session, on June 13th. Signup here. Note: Scholarships and group discounts can be requested at training (at) engineyard (dot) com. We hope to see you next month!  

more »