In a demonstration of cloud computing’s increasing stature within the world, Washington state freshman state representative Reuven Carlyle involved scrapping a $300 million data center in favor of cloud computing last week. We are deeply troubled by the weakness of the technical and support behind this decision, and fear the state is potentially making a $300 million mistake,” Carlyle said during a letter to Governor Christine Gregoire published on Carlyle’s website. Co-written with Representative Hans Dunshee, the letter was first picked up by Pacific Northwest In a nutshell, the letter involves a halt to a bond sale to fund the project and a review of existing cloud services, like “Google, Microsoft, Amazon or others as many companies and governments do today.” Further, it argues that the trend in outsourcing data and services may be an accomplished fact and far better use of taxpayer dollars. Unfortunately, Carlyle’s letter sometimes reads love it was written by a jingo-happy IT vendor. call center technology
To wit: “How best to efficiently and effectively move faraway from hardware-centric, expensive, proprietary, silos of knowledge trapped in old databases to open, transparent, flexible, accessible, customer-oriented applications available via the Internet?” he asks. (I think we’ve all snoozed through that PowerPoint talk, no?) This is understandable. Carlyle comes fresh from the communications industry, where silos aren't crammed with grain and budgets are fine-tuned with an ax, as against the government, where silos are quite likely crammed with grain and budgets are fed like pate de foie gras geese. Dunshee appears to be a more traditional politician; interestingly, he lists many unions as backers, groups likely to require state construction dollars. It’s unclear why Carlyle and Dunshee believe the new IT infrastructure would attend waste. What’s notable, however, is that cloud is now commonplace enough that an official will throw it out there and hold traditional IT up because of the poorer model.
That’s an extended step in discourse from “cutting edge.”The need for automation in cloud computing JOSE -- one among the common threads within the "Private Clouds -- Why They Matter" session at O'Reilly Open Source Conference (OSCON) on Monday was a general frustration with the extent of automation available to cloud computing users. the necessity discussed by the session participants goes far beyond the power to spin up new server instances within the cloud. It really touched on several concepts: interoperability, workload redistribution, monitoring and scaling. Interoperability is a few frictionless and reliable set of standards to permit users to write down once/run anywhere in order that they can build applications and deploy them internally to Amazon.com, RackSpace or ... you get the image . Interoperability isn't automation, but it dramatically eases the automation process.
Workload redistribution is about having the ability to maneuver an existing process from one cloud to a different during a seamless and comparatively quick set of steps. It relies on interoperability, but it goes beyond that with a group of tools to enable users to maneuver their workloads to the cloud environment that creates the foremost sense for financial, performance or other reasons. Tools are being developed to support this. Cloudkick may be a Y Combinator-funded company with support for Amazon Web Services and Slicehost that's performing on Cloudshift, a multi-cloud migration tool. Another startup which will be performing on something for workload management is CloudSwitch, which claims to maneuver workloads back and forth within the enterprise, as against the concept of a cloudburst, which means a unidirectional flow.
Monitoring and scaling automation for clouds may be a bit more mature, with RightScale leading the pack. IBM and Hewlett-Packard also are adding cloud monitoring to their systems management suites The cloud automation space is probably going to be very interesting for the foreseeable future and supported the comments of OSCON attendees, the demand is real. Open source gains popularity privately cloudsSAN JOSE -- It probably comes as no surprise that the overall cloud computing market is heavily into open source. From Amazon.com's Xen-based cloud infrastructure to the LAMP-stack components in most cloud-based Software as a Service (SaaS) and e-business startups, the general public cloud may be a fertile environment for open source. What could also be less obvious is that the extent to which internal "private" clouds are within the open-source camp.
At a session at O'Reilly Open Source Conference (OSCON) in the week titled "Private Clouds -- Why They Matter," there was a strong discussion regarding internal cloud computing plans. While few of the attendees had large-scale internal clouds in production, several had some operating cloud infrastructure running in-house, and lots of claimed to be actively evaluating the technology. To be fair, a number of the session attendees were from companies like SaaS providers or software developers -- though their comments were clearly directed toward use of cloud technologies for internal applications (rather than their public Web sites). However, there have been several traditional end-users there also.
It quickly became clear that a lot of of those internal private clouds weren't just using open source (Linux, MySQL, etc.); they were built on open source. Eucalyptus was most frequently cited because the base platform for building private clouds, and this was true even when VMware was an organization's primary virtualization environment.
The key takeaways included the following: Internal private cloud deployment is gaining steam. Many traditional internal IT organizations are considering open source (mostly Eucalyptus) to urge them there. John Treadway is an enterprise and Web 2.0 technology veteran, and he has created two companies built on open source technologies running during a cloud infrastructure. Treadway may be a blogger on cloud computing and enterprise technologies and is that the lead local organizer of CloudCamp Boston.
Google App Engine developer discusses distributed architecture challenges you asked Google's App Engine team about the most important challenges facing developers moving to the cloud, working with a nonrelational distributed database architecture would surely be near the highest of the list.I think the toughest thing for developers coming from a standard IT development stack is that they are wont to having a relational model," said Fred Sauer, App Engine developer advocate at Google.
"And thereupon comes the only hardened instance where you would possibly have a database server or a failover. But everything is centralized." In a relational model, even when developers are working during a locally distributed grid, they're usually working with centralized data stores and machines they will tweak to optimize access performance. Not so within the cloud. Sauer said learning the way to develop under a distributed model isn't necessarily harder , the maximum amount because it may be a matter of relearning the way to store and call data. With App Engine, you're talking a few platform that by its very nature is extremely distributed," said Sauer. "Every time your browser makes an invitation , you'll hit a special server or a special a part of the info store." To ease Web application building
In other words, if you fetch 100 rows of knowledge, the requests might leave to a couple of dozen machines, and still more machines might actually return the info . This forces developers to believe the ways they read, write and store data in ways in which suit those patterns, Sauer said. But the distributed model utilized in App Engine can find those rows of knowledge and convey them back all directly, in parallel, instead of in some relational hierarchy.
[Editor's note: Google's view of a distributed nonrelational data model is best exemplified by its MapReduce and Hadoop data implementations. A recently reported Yale computing project seeks to mix characteristics of both Hadoop and electronic database management systems.] Sauer said App Engine was built because Google realized that building Web applications was just too difficult a process. "There was an excessive amount of work that a developer would need to neutralize getting the appliance ... to scale," said Sauer. "The three goals for the App Engine were [it had to be] easy to start out , easy to scale and straightforward to manage." Make mine Python Sauer said three of the favorite languages at Google are Python, Java, and C++. But the Python developers were those who first gravitated toward the App Engine project. One of our biggest challenges was building out a service that would be employed by non-Googlers," said Sauer. "It's one thing to form an indoor tool and another to open up a platform where you've got no control over the appliance code that's being submitted. We had to harden the environment."
The last item a corporation offering a cloud computing development platform wants is for requests coming from one application to hinder the response times of another application. to stop this, App Engine has some limitations. Sauer said developers aren't allowed access to file systems on the cloud machines or to open arbitrary network sockets or requests. In terms of application portability, Sauer said App Engine tends to be more welcoming of native code written in Java than Python. In April, Google App Engine added support for Java to its existing support for Python, which proved to be a well-liked language among the troops because the Mountain View, Calif.-based giant grew. With Google's cloud-based application development platform now hospitable a more mainstream language, many developers are taking a better look. Farewell, proprietary API We made it a first-class goal for application developers to implement their entire application with open standards without the utilization of proprietary APIs [application programming interfaces]," said Sauer.
But things do get complicated for developers wishing to port very complexly, non-standards-based applications from a relational to a distributed model, Sauer said. As a general rule, he said, it's easier to create an application in App Engine and port it into a relational system than the opposite way around. More than 100,000 applications are built on App Engine, Sauer claimed. They include social applications like BuddyPoke and smaller apps that monitor keywords on Developers have built games and little internet sites, while businesses have written applications for internal use. Azure is going to be fashionable .Net developers, but questions remain on application deployments Microsoft in the week released the pricing details and business plan for its cloud computing platform, Azure, developers still had questions on what proportion of their code they might deploy when migrating. Ed Laczynski, chief technology officer at LTech Consulting, said the worth -- 12 cents per hour compute and 15 cents per GB/hour of storage -- seems competitive with offerings from Amazon.com and other competitors. But because Microsoft is to the cloud computing game, he said, one among the tech giant's goals is probably going retaining Microsoft development shops as customers.
The major question Laczynski had is simply what proportion use of native code Microsoft will admit Azure. As it stands today, you cannot use the maximum amount of your existing IP and existing code and port it over," he said. "You need to use their [new] APIs."
Though recent announcements suggested that Microsoft will allow more use of native code than originally anticipated, a move during this direction might be damaging to parts of the company's business. They need to preserve their on-premise software business," said Laczynski. "They make tons of cash with SQL Server on-premise. Are they really getting to be ready to cannibalize that business?" Many developers hope that Microsoft will embrace open Web standards. within the past, Microsoft has sought to influence standards within the spaces it inhabits. during this case, Laczynski said it might be counterproductive. Companies can attempt to force standards," he said. "But the cloud ecosystem is so young that any plan to standardize it beyond open Web standards is futile. The folks that are innovating immediately are all using these open source technologies because they're supported open Web standards."