Platform-as-a-Service veteran Engine Yard is getting on board with the recent trend of multi-language support by acquiring Dublin, Ireland-based PHP PaaS startup Orchestra. Engine Yard has built up a portfolio of more than 2,000 paying customers for its flagship Ruby on Rails platform service, but a recent industry shift toward supporting more than one language and/or framework forced Engine Yard to pull the trigger on the Orchestra deal now.

A level up from Infrastructure as a Service on the oft-cited cloud computing stack, PaaS offerings have become very popular among individual developers within their particular languages. That’s because PaaS lets developers write applications without regard for infrastructure-level concerns such as server count or operating system. However, PaaS has attracted its fair share of critics because, historically at least, offerings have often focused around one language, which left developers using multiple services when they wanted to write applications in multiple languages.

This has begun to change in the past year, however, with myriad multi-language PaaS offerings hitting the market, and with legacy providers (if we can say that in a field only a few years old) continuing to add support for additional languages. Even notoriously single-language platforms such as Heroku (Ruby) and Google App Engine (Python) now support multiple languages and/or frameworks.

For its part, Engine Yard CEO John Dillon told me, the company has been considering such a move at least since he joined three years ago. In fact, he said, the first question he asked when he joined the company was “‘Just Ruby, or more?’.”By his thinking, the company couldn’t fully leverage what it has learned over the past five years by sticking with Ruby on Rails alone; it was unnecessarily limiting itself to a discrete customer base.

Furthermore, Dillon noted, sticking with Ruby on Rails only meant that other PaaS providers “would eventually learn what we spent the last five years learning [about running a PaaS business and] mount a competitive threat.” So, when the company began reworking its core code about 18 months ago, he said, it made sure the code could support multiple cloud providers and programming languages.

However, Dillon is sure to make clear, Engine Yard did not rush into its decision to buy Orchestra and support PHP. It has built such a solid business, he explained, because the company knows Ruby inside and out and can answer pretty much any question a customer might have. When Engine Yard entered into talks with Orchestra last year, Dillon knew he had found a PHP PaaS provider that shared in Engine Yard’s vision of providing deep programming knowledge within its field.

Dillon said that Engine Yard isn’t going to stop with Ruby and PHP, though. Already, he noted, the Engine Yard supports JRuby in a beta-like manner, and, he said “you’re going to see us support Node.js in the not too distant future.” The plan is to add languages one-by-one when the timing is right, he said.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Multi-Language PaaS: Salesforce.com Is Just One Option
• Infrastructure Overview, Q2 2010
• VMware’s Cloudy Ambitions: Can It Repeat Hypervisor Success?

alt=''
border='0'
/>

GigaOM — Tech News, Analysis and Trends

Google has killed its App Engine for Business offering, the enterprise-friendly version of its Platform as a Service that included a partnership with VMware around the Spring Java framework. Part of a bevy of changes to App Engine announced at last month’s Google I/O conference, the news went largely unnoticed in the shadow of major pricing adjustments. But the missteps with App Engine for Business are indicative of the types of challenges Google faces as it attempts to ready its PaaS service to compete with companies like Red Hat and Salesforce.com in luring enterprise developers.

No more App Engine for Business

I spoke with Gregory D’alesandre, senior product manager for Google App Engine, who explained to me Google’s new approach to selling PaaS to businesses. In retrospect, he said, Google might have announced App Engine for Business too early — more than a year ago — before it had a chance to gauge reaction to some of its more-limiting features. The company’s “trusted testers,” it turns out, liked many of the features, but they didn’t like the idea of a separate offering or the fact that App Engine for Business locked down API access from outside the owner’s domain.

So, D’alesandre explained, many of App Engine for Business features have or will be rolled into App Engine proper, which Google actually will take out of “preview” mode later this year and make an official part of its Google Enterprise portfolio. D’alesandre said that SQL support, SSL encryption and full-text search, all parts of the App Engine for Business offering, are top priorities not just for the App Engine team, but for Google overall, and should be ready once the product loses its “preview” status. SQL support, he added, is particularly important because of its appeal to enterprise developers, but it’s a complex process incorporating it into a platform that wasn’t designed with SQL in mind.

App Engine also still will support Spring for developing Java applications, D’alesandre said, and Google is actively working with VMware to figure out the next steps to advance their cloud computing partnership even beyond Spring. Other features of the new, improved App Engine will be a 99.95 percent SLA and additional support options. D’alesandre noted that expanded Python support and some new API improvements are in the works, too.

Too little, too late?

What’s not clear, however, is whether enterprise developers will buy into the new App Engine or whether its existing hundreds of thousands of developers will stick with the platform once the changes finally take effect. The latter group will have to adjust to higher prices than they were paying in the “preview” phase, and the former group — notoriously wary of vendor lock-in — will have to contend with Google’s very specific set of technologies and coding practices. As The Register‘s Cade Metz explained in a recent in-depth look at App Engine, the platform is very proprietary and requires sticking to a defined set of best practices.

D’alesandre isn’t convinced the concerns around limited language support and proprietary technologies are dealbreakers. The way he sees it, owning the App Engine stack from servers up through APIs means Google can easily troubleshoot and optimize will full knowledge of all the components. As for language support, he sees benefit in providing deep sets of features for the languages it does support — Python, Java and Google’s own Go. It’s difficult to argue with his stance regarding languages considering that PaaS is notorious for being single-language-only and only has begun to break those chains recently in the forms of VMware’s Cloud Foundry, DotCloud and Red Hat’s OpenShift . Google actually was ahead of the game by adding Java support relatively early on.

However, even D’alesandre acknowledged that he’s impressed with some of the PaaS offerings that have hit the market lately. If anything, timing might be critical for Google, which will need to get the production-ready App Engine into the market before any of the myriad other PaaS offerings gather too much momentum. I thought App Engine for Business was a formidable competitor when announced, but time and new PaaS launches — including from Amazon Web Services — have dulled its edge.

Software inferiority?

There’s also the issue of Google “outdated” architecture, as so described in a recent blog post by ex-Googler Dhanji Prasanna. He opined that while Google’s data center infrastructure is second to none, its software stack is aging and has become a hindrance in terms of performance and development flexibility. D’alesandre declined to comment specifically on Prasanna’s criticisms, but called him a “good friend” and “absolutely brilliant engineer” who “was looking for something different” than Google’s development culture.

On his personal blog today, IBM’s Savio Rodrigues offered a down-to-earth take on the debate over Google’s software stack. While Prasanna cites Hadoop and MongoDB (among others) as being superior to their Google counterparts MapReduce and MegaStore — a position that very well might be accurate — Rodrigues notes that “[c]ombining individual best of breed software building blocks into a cloud platform as a service environment that offers the functionality of Google App Engine, requires enterprises to do a lot more work than simply using Google App Engine.”

Of course, he added, that Google’s strict adherence to its own code raises a big question: “how your enterprise needs will be prioritized against the needs of internal Google developers.”

We’ll discuss the potential potholes for PaaS at next week’s Structure 2011 event, many of which are exemplified by the questions surrounding Google App Engine. It’s still early enough in the game for Google’s strategy change to pay off, but it will require some serious effort to convince enterprise developers that Google’s approach to PaaS is worth buying into.

Image courtesy of Google.

Related content from GigaOM Pro (subscription req’d):

• Infrastructure Overview, Q2 2010
• How Google Put the Cloud Computing World on Notice
• The Structure 50: The Top 50 Cloud Innovators

alt=''
border='0'
/>

GigaOM — Tech News, Analysis and Trends

by Stuart Chalmers

Electronics Gadgets Will Lift Your Results with Google, Ebay Powerseller

It’s no secret electronics are highly sought, and therefore highly searched, on internet search engines like Google.

The more tech-savvy your customer, the more likely they are to use Google to find the gadgets they need. If you begin selling electronics products, therefore, it stands to reason that your website traffic will increase.

Article reference: Y4S8CGK0

As a consequence, the more products you sell, the more hits you’ll get on Google. And the more hits you get, the more potential customers are obviously perusing your wares, which will lead to increased sales. So increasing your product line is definitely a good thing.

You can organize the text on your website or webpage to enable a higher ranking on Google – when those key words are searched, the higher ranking you have the closer to the top of the search list you will be.

Google Search Engine Optimization

Placing keywords relating to your products throughout the text of your website is vital. The correct keywords to use are usually the product names, or the names or services you provide, or the names of activities your product is intended for.

Brainstorming a good, appropriate list of keywords and placing them throughout your website content will get you on the right track to upping your optimization.

Avoid Poorly-Written Content

If your content is badly-written, never updated, or is not relevant for what you want it to be found for, then your site is neither user-friendly or search engine friendly.

Google’s “spider” feeds on well-written content and is key to high rankings.

However, simply “keyword-stuffing” or using invisible lists of keywords is frowned upon by search engine spiders, and, though such practices may initially aid your rankings with Google, you could potentially be banned. In this case, the quick fix is a quick break.

Use Meta Tags

Meta tags are title tags, keyword tags and description tags. They are not as important as keyword placement or content, but they do help.

Avoid a Badly-Designed Site

Take the time or go to the expense of having a professional design your site.

The clearer the navigation, ease of use, and appearance of your site or page are important. Search engine spiders can actually be blocked from crawling sites that are too clumsily designed.

To get an idea, visit some well-designed sites in your field, and take note of how they’ve done it. Strangely enough, a Google search will tell you the top ones!

Increase The Number Of Items On Your Site And The Frequency In Which You Update

Google spiders are a little like a three year old with Attention Deficit Disorder. They constantly like new different things that change all the time.

As a result your best option as a retailer is to constantly update your inventory and perhaps even increase the number of things you sell.

This is especially where electronics gadgets come in.

The world of electronics gadgets is an ever-expanding one, and there are constantly products to update and new products out on the market that people are looking for.

By finding one or two good wholesale electronics suppliers that have a constantly new range of electronics gadgets and that keep you updated via RSS you are ensuring that you have always fresh content for your site that wont only bring you lots of Google traffic it will bring you lots of sales as well.

What are you waiting for? Get out there now and explore the world of electronics gadgets. You are sure to bring in more sales and higher Google rankings as a result.

Get the latest in electronics gadgets from Chinavasion.com your only source of wholesale electronics online. Just paste this link into your browser: http://www.chinavasion.com/index.php/cName/electronic-gadgets/

Ha! Hold on. Let me walk around a little, calm down. Ummm… so Gene Munster of Piper Jaffray, the guy who was right about the iPad because he wouldn’t shut up about it for most of the last five years, is saying there’s a “70% chance” that Apple will build a search engine. Barring thought that Apple needs to run a search engine like a fish needs to run a bicycle factory, let’s look at what he’s saying (via BusinessInsider)

We believe Apple could utilize data unavailable to Google, data generated by the company’s App Store, to create a mobile centric search engine, which would be a unique offering to Google’s search engine.

An iPhone specific search engine could be a difficult undertaking, but we feel Apple could make a minor acquisition of a search company that has built a web index, like a Cuil, and utilize the index as the base for building its own engine.

We believe the odds of Apple developing a search engine in the next five years are 70%. One hurdle for Apple in developing its own search engine would be generating enough advertiser interest to form a competitive marketplace; however, we believe the rationale for an Apple search product is to protect data rather than generate profit.

While I rarely enjoy point-by-point takedowns, I’m feeling rather frisky on this one. Let’s begin:

1. We believe Apple could utilize data unavailable to Google, data generated by the company’s App Store, to create a mobile centric search engine. – So this would search for popular Apps? Is that a “search engine” or a Genius system for apps. I suspect the latter. Maybe Gene didn’t get the the right term when he checked his Webster’s Dictionary of Computer Terms he bought in college.

2. we feel Apple could make a minor acquisition of a search company that has built a web index, like a Cuil – Remember Cuil? Well no one else does. Apparently someone mentioned Cuil at Munster’s bridge club tournament after reading about it an an old 2008 issue of Fast Company they found in the dentist’s office and it stuck. Someone could have said AltaVista and the same thing could have happened.

3. One hurdle for Apple in developing its own search engine would be generating enough advertiser interest – Because who wouldn’t want to work arm-in-arm a distant, far-from-mainstream search contender dedicated to sifting the ether for data on Hot Tub Time Machine soundboards?

4. we believe the rationale for an Apple search product is to protect data rather than generate profit. – Now this one is rich. Apparently Smith & Wollensky had two-for-one martini night and Munster’s dining partner – the one who probably planted this seed in the first place – apparently partook. “Protect data rather than generate profit” sounds exactly like something Apple would do. After all, they’re in the business of making things better for all of us. If you haven’t visited the Apple Health Centers where they can cure future brain embolisms by bathing you in purple light, you’re missing out. Just don’t take their flu vaccine.

I hate to single anyone out – we all make crazy proclamations, especially when we’re hopped up on Skittles and chocolate milk (not naming names) – but WTF? This is more egregious than usual, friends. Analysts know little more than we do, and that’s not saying much.