Google today announced version 1 of its Go language, or Go 1 for short.

Downloadable at the Go website, the open source Go has been positioned as a general-purpose language suitable for uses ranging from application development to systems programming and offering such features as garbage collection and concurrency. It also is intended to be easy to program.

Go 1 is the first release supporting binary distributions, which are available in Linux, FreeBSD, Mac OS X, and Windows. The language also integrates with Google's App Engine cloud platform.

"The driving motivation for Go 1 is stability for its users. People who write Go 1 programs can be confident that those programs will continue to compile and run without change, in many environments, on a time scale of years. Similarly, authors who write books about Go 1 can be sure that their examples and explanations will be helpful to readers today and into the future," according to a post from Go team member Andrew Gerrand on the Go language blog.

Google also is striving for forward compatibility; version 1 is a representation of Go as it is used today and is not a major redesign, Gerrand said. But it introduces changes such as new types for Unicode characters and errors. The package hierarchy has been rearranged to group related items together.

"In its planning, we focused on cleaning up problems and inconsistencies and improving portability. There had long been many changes to Go that we had designed and prototyped but not released because they were backward-incompatible. Go 1 incorporates these changes, which provide significant improvements to the language and libraries but sometimes introduce incompatibilities for old programs. Fortunately, the go fix tool can automate much of the work needed to bring programs up to the Go 1 standard," Gerrand said.

The Go tool suite is being structured around the go command, which is a program for fetching, building, installing, and maintaining Go code. This command eliminates the need for Makefiles to write Go code. Go 1 also triggers a new release of Google App Engine SDK.

In envisioning Go, Google has sought to address what it sees as a need for faster software development and accommodating multicore chips. Go is intended to enable compiling of large programs in a few seconds on a single computer and provide a model for software construction making dependency analysis easy.

What is it with data-transfer cloud computing performance? Some people think cloud services provide great performance, and some think they don't perform well at all. The reality is that both beliefs are true, depending on how you use cloud services and the cloud providers themselves.

There are a few basic, core patterns that define data-transfer performance:

Enterprise to cloud

Mobile to cloud

Cloud to cloud

Enterprise-to-cloud seems to be where the problems exist. Information is transferred, typically over the open Internet, from servers in the enterprise to public cloud computing providers. If you've ever checked out the speed difference in downloading data from a remote website versus an intranet site, you already know what the issues are in this arena. As a rule, try to avoid transfer of large chunks of data from the enterprise to the public cloud computing provider.

Mobile-to-cloud is not that big of a deal in the larger scheme. Businesses don't like to store data on mobile devices (smartphones, tablets, netbooks, and so on), and they pretty much leave most of the data in the cloud. Only data required for an operation is typically transferred to the mobile device. Thus, data-transfer performance is usually not an issue. Come to think of it, it's not a bad model to replicate when using cloud systems in any pattern.

Finally, cloud-to-cloud can be either intracloud (such as within Amazon Web Services) or intercloud transfer of data (such as between AWS and Rackspace). Intracloud data-transfer performance is directly related to the size of the pipe within the cloud service, as well as to performance-enhancing services such as cache services that might be in use. Typically, intracloud data transfer is between tenants, virtual machines, or applications and data stores. The approaches and technology vary greatly, so you should run your own benchmarks to duplicate the scenario you plan to implement. (For more information on an actual benchmarks, check out "Amazon comes out on top in cloud data transfer speed test.")

Intercloud data transfer is even more complex, having to deal with cloud services that may not like each other exchanging data. Moreover, the open Internet is the typical mode of transport, so the same issues arise here as with cloud-to-enterprise. I suspect that cloud providers will get better at this in the future, for the sake of their mutual clients. For now, you need to model, model, model, and test, test, test.

Private cloud company Eucalyptus got a much-needed boost yesterday when public cloud giant Amazon announced it will support interoperability between Amazon Web Services and the startup's own open source platform.

Though the deal with Amazon should help increase Eucalyptus' enterprise appeal, it by no means guarantees the struggling company's success; rather, it ensures that the company will persevere a while longer in the face of competitive pressure -- particularly from rival open source, private cloud upstart OpenStack.

Eucalyptus' open source IaaS software is designed to give organizations a way to build their own elastic, highly available private clouds that are compliant with AWS clouds. The idea is to accommodate AWS customers who might decide particular workloads would be better run in a more secure, manageable private cloud environment. In practice, Eucalyptus has served mainly to allow projects incubated on Amazon Web Services to be brought in-house. Eucalyptus' goal has been to make that transition seamless, and Amazon clearly sees opportunity in ensuring this interoperability between its public cloud and these private clouds.

Amazon and Eucalyptus have been somewhat vague on the details of the agreement, such as whether Eucalyptus is paying fees for interoperability rights. What's clear is, the two haven't formed any deep, strategic alliance. Amazon won't hand over AWS code or any other intellectual property to Eucalyptusbeyond the AWS APIs, a company spokesperson told The Register. The main benefit to Eucalyptus, then, seems to be the removal of a legal shadow that may have presented a hurdle to potential customers. Eucalyptus now has Amazon's blessing to use Amazon's APIs.

This pat on the head is hugely important to Eucalyptus' survival, but it doesn't give Eucalyptus much in the way of new guns to wield in its battle against OpenStack. Against OpenStack's fast-growing open source ecosystem and open APIs, Eucalyptus still offers a small community and proprietary APIs. It needs more from Amazon than approval, but perhaps Amazon's approval will lead to partnerships with other industry heavyweights.

Meanwhile, OpenStack continues to pose a serious threat to Eucalyptus. Co-created by Rackspace and NASA, the IaaS provider has backing from an impressive list of vendors, including Canonical, Cisco, Citrix, Dell, Intel, and Microsoft. Giants including AT&T, Internap, and Hewlett-Packard have announced or launched public clouds that use the OpenStack software. Moreover, OpenStack is a subsidiary of Rackspace and thus presumably has a tight relationship -- one that goes beyond simply sharing APIs to ensure OpenStack is interoperable with Rackspace's public cloud.

The big winner in all this ultimately could be Amazon. If the agreement with Eucalyptus works out, more customers might be lured to AWS with the knowledge that they would be able to move a workload into a compatible private cloud should the need arise. If Eucalyptus goes under, Amazon still sits pretty atop the heap of unmanaged cloud services, with the option to find other private cloud partners -- or reverse its decision to offer private cloud services itself.

"If you build it, they will come" may be a line from a baseball fantasy, but it describes what really happened in the world of cloud computing. One late summer day in 2006, online bookseller Amazon.com quietly made a portion of its excess data center capacity available to curious developers over the Web. Within hours, hundreds of developers had jumped at the chance to spin up some servers simply by opening their browsers and typing in their credit card numbers. Today, Amazon's Elastic Compute Cloud is the foundation for countless tech startups, and Amazon counts its business customers in the hundreds of thousands.

If you're a CIO with a data center to run, that has to make you think. Assuming you're not ready to entrust your company's crown jewels to the public cloud, couldn't you satisfy IT requests faster internally by borrowing from the Amazon playbook? Standardize on commodity servers and storage. Connect them using a converged IP network infrastructure. Layer on virtualization to support resource pooling, isolated multitenancy, automated provisioning, and dynamic scaling and contraction. Provide a Web front end and workflow engine that allows your "customers" to serve themselves, and bill them each month for what they use.

Unlike Amazon, you don't need to develop your own cloud management software. VMware, Microsoft, the OpenStack open source project, and many others are building cloud-oriented automation and controls on top of today's virtualization platforms. Depending on the number and sophistication of your users, you may not need or want elaborate self-service and chargeback mechanisms. Your on-demand resource pool might exist only to serve other IT groups within the company, as a shared platform for batch processing or short-term projects or to allow your development and test teams to do their thing without burdening server, storage, and network admins.

Ultimately, "private cloud" is just a new name for the same old goals: Consolidate workloads on a shared infrastructure to increase utilization and lower costs, while taking increasing advantage of virtualization to respond more quickly to business needs. Someday, either through proprietary links or open APIs, your private cloud may integrate with one or more public clouds, allowing you to migrate or extend workloads in ways that make business sense. In the meantime, building a fast and flexible private cloud may be the only way to discourage the people you serve -- be they developers, marketing managers, or entire business units -- from taking their projects to Amazon EC2 or some other cloud they can open in their browsers.