Let’s dive in and I’ll explain.

Cloud Stack Evolution & ‘Camps’
Amazon Web Services (AWS) spawned a huge ecosystem of knock-offs, management systems, tools, and vendors. They include, but aren’t limited to:

• AWS API compatible ‘cloud stacks’ including Eucalyptus, Open Nebula, and others
• Cloud management systems for the AWS APIs and services such as RightScale and enStratus
• Cloud services layered on top of AWS services such as Jungle Disk (S3), Heroku (S3, EBS, EC2), and more

Prior, I wouldn’t have called the AWS ecosystem a ‘camp’ per se, but if you read our most recent article on Google’s foray into cloud storage, you know that it seems likely they will provide a 100% compatible version of S3 and EC2 this year. Imagine the impact of Google Compute & Storage with Amazon Web Services compatible APIs. Already the Google Storage API is nearly 100% compatible with S3.

Together, as a block, Amazon and Google could create a de facto duopoly for infrastructure clouds, which isn’t good for anyone. We need competition and more than two major players.

Up against the Amazon camp is VMware. In my article on Amazon vs. VMware last year I highlighted how these two businesses were on a collision course. Nothing has changed and competition is mounting between them. The reason is that telcos and service providers are under increasing threat from Amazon and soon Google. They need viable solutions and VMware is attempting to provide a competitive ecosystem.

The VMware cloud initiative, vCloud, is designed to arm enterprises and service providers to be competitive, but has not quite delivered yet. VMware has had a number of problems providing a full cloud stack. The software, now in beta, is codenamed ‘Redwood’ has had significant delays in getting to market. Their strategy for cloud infrastructure does not appear unified outside of delivering compute virtualization.

VMware, as a business, understands they need to make their customers competitive. They have made a number of strategic open source acquisitions such as SpringSource, RabbitMQ, and Redis. There are also murmurings that they have some special projects inside that are ‘up the stack’ from their virtualization offerings. In total this shows that VMware ‘gets it’ in that they want to create a competitive ecosystem. While each of these is currently a point solution, there is yet to be a coherent story here. Can VMW build a consistent story and strategy around these disparate pieces? Only time will tell…

Besides these two camps, there is a long tail of clouds running various frameworks vying to establish themselves such as Cloud.com’s CloudStack, 3Tera, Hexagrid, Abiquo, OpenNebula, etc. John Treadway recently had posted a roundup describing all of the various cloud stacks out there.

OpenStack is stepping into the ring as a viable third camp. In particular, the OpenStack Storage solution is a clear contender to Amazon S3 & Google Storage. Many service providers and telcos have struggled to find a viable solution using commodity hardware that was price competitive. Suddenly, there is a viable proven solution.

Yet this is only storage. How can it create an effective ‘third camp’ alternative to Amazon and VMware for an entire cloud?

Lock-in, Architecture, Standards and The Truth about Interoperability

Interoperability for infrastructure clouds is poorly understood. Most believe that the problem lies in the on-disk image format (e.g. VMDK vs. VHD vs. qcow) or in the ‘hypervisor’ (although people don’t really unders/tand what this means). The truth is that lock-in has little or nothing to do with disk formats or the hypervisor. Most on-disk image formats are simply representations of block storage (i.e. disk drives). That means converting between a VMware VMDK and a Citrix XenServer/Hyper-V VHD is relatively trivial.

What about booting the converted disk image up on a new hypervisor? Guess what, since most hypervisors now rely on hardware virtualization (HVM) [1] using Intel-VT/AMD-V, that means that by default most will work with unmodified operating systems out of the box. No changes needed. The only downside of this is that usually the resulting performance is poor. This requires new paravirtualization (PV) drivers in the converted image. What does that mean? After converting the image from one format to another, you simply have to install the PV drivers for the correct OS. A process that requires being methodical, but is in no way technically challenging.

Where is the lock-in then? If it’s not the hypervisor, what makes moving from one cloud to another so difficult? Simply put, it’s architectural differences. Every cloud chooses to do storage and networking differently.

For example, if you wanted to move a virtual machine from GoGrid to Amazon, converting the GoGrid image to an AMI is not difficult. Unfortunately, GoGrid uses two networks, a ‘frontend’ and a ‘backend’ where your cloud storage system is connected to via the backend network. Every Amazon virtual server has only a single network interface. If your application assumes a separate backend network then what happens when it moves to a cloud without one? Or vice versa? Similar architectural incompatibilities exist between Rackspace Cloud, Savvis, Terremark, Hosting.com, Joyent, and all of the others.

The problem here, to be a bit more succinct, is that we need reference architectures for how infrastructure clouds are built. Amazon is one such reference. VMware’s vCloud is potentially another. Now there could be a truly open option with the gravity to gather community support.

More on The Third Camp

OpenStack’s potential to build a real community and a set of reference architectures drives towards greater standardization and interoperability. Perhaps more important than a cloud storage alternative, is this possibility for a true OpenStack community to form a critical mass such that a similar level of developers contributing to it as Amazon or VMware. Then commercial and alternative offerings, such as Cloud.com, Hexagrid, and OpenNebula can match their APIs and architectures to this set of reference architectures.

Will it happen? It’s hard to say, but the opportunity is there. Rackspace and others are putting serious weight behind this initiative.

What This Means for Telcos and Service Providers

For Telcos and SPs this means an alternative to VMware’s vCloud for commodity service offerings. A way to compete and operate at scale like Amazon and at a similar price point. Standardization through a similar reference architecture means greater compatibility between service provider clouds, which means greater benefit for customers and less lock-in, making them more desirable than the walled gardens.

You don’t want to differentiate on the basic compute, storage, and network offering. You want this to be as standard and interoperable as possible, just like 3G networks, TCP/IP, and similar service provider technologies. By creating a common open platform that everyone uses there is a better opportunity to facilitate wider adoption, create a competitive infrastructure service marketplace where providers work on differentiating in areas where they have an inherent advantage:

• Service and support
• Network & datacenter tie-ins (e.g. MPLS, hosting/co-lo)
• Bundled service offerings
• Differentiated value-added cloud services (VACS)

This is a game that all telcos and service providers understand. They have been playing it for the past 15+ years.

Conclusion

OpenStack, with a strong community behind it, should be an important tool for service providers and large telcos to compete at scale with the Amazon and Googles of this world.

We believe OpenStack and the reference architecture(s) associated with it will allow service providers (SP) to get their undifferentiated cloud offerings up and running early. For this reason, Cloudscaling will put real resources into supporting this effort. Getting basic cloud offerings up early then means providers can focus on support, services, bundling, and differentiated services as soon as possible, while embracing as large a customer base as possible. This is just as they compete on top of basic TCP/IP services today.

[1] Clearly, the market leader, Amazon, does not use HVM. They use PVM, a fully paravirtualized mode of Xen. However, even they seem to understand that HVM is the future. Their latest offering, designed for HPC, which is performance sensitive, uses HVM and supports unmodified operating systems. The reality is that the Intel-VT and AMD-V capabilities on the latest round of processors is incredibly fast and will only get faster. The battle is over. HVM and silicon won in this case.

Lew’s background spans more than 20 years during which he has been instrumental in driving several major  technology changes, including: AI and massively parallel systems, developer adoption of Java, Salesforce.com’s AppExchange,  and most recently, Cloud Computing.    According to Lew, “At Thinking Machines, in the early 1990′s, we were building massively parallel machines using thousands of individual processors.   At Sun, we drove the evolution of the web with Java and networking, often using the tagline, ‘The Network is the Computer’.   In this next phase, it’s becoming clear that the ‘Cloud is the Computer’  and this promises to be just as disruptive.”

Cloudscaling CEO, Randy Bias, and Lew Tucker both share a long-term interest in the design and architecture of large, scalable systems.  As former VP Technology Strategy of GoGrid, Randy was responsible for building out one of the most complete infrastructure services in the cloud.  As CTO of Cloud Computing for Sun Microsystems, Lew was responsible for the architecture and API for Sun Cloud.

Lew’s joining the advisory board continues to build up the Cloudscaling team’s unique set of resources.  “If you want to build significant clouds, you have to have the right team.” said Randy Bias.  We’re the only cloud engineering services team I know of that can point to not one, but many, large scale cloud environments they have built.”

About Cloudscaling

Cloudscaling is the leading cloud computing engineering services firm. We provide strategy, design and implementation to build cutting edge clouds. Located in San Francisco, the company was founded by experts who have built some of the largest public and private clouds operating today. Visit cloudscaling.com to read the blog and follow the team on twitter.com/cloudscaling.

Contact:
Pat Sharp
pat@cloudscaling.com
725 Cool Springs Blvd., Ste. 600
Franklin, TN
USA
Ph: +1 (615) 732-6192

###

Infrastructure History & Standards
Like railways, the telephone system, or any other kind of infrastructure that supports business today, IT is quickly commoditizing and turning from a competitive advantage into a cost of doing business.  Cloud computing is an accelerator in this process.  As I’ve asserted before, the ‘cloud’ is less about technology or where the resources reside and more about a fundamental change in the way that we use and understand IT infrastructure.

I like to think of ‘cloud’ as a group ‘A-HA!’ moment, much like the one that happened with other foundational infrastructure changes.  Early in the advent of railroads, trains, track gauges, switching equipment was all custom and had little or no interoperability.  Eventually it became apparent that standards would allow greater aggregate value to all involved.  Nicholas Carr nails it in his book Does IT Matter?:

As was true with railroads and electricity and highways, it is only by becoming a shared and standardized infrastructure that IT will be able to deliver its greatest economic and social benefits, raising productivity and living standards and serving as a platform for a range of new and desirable consumer goods and services.  History reveals that IT needs to become ordinary—needs to lose its strategic importance as a differentiator of companies—if it is to fulfill its potential.

The primary point being here that market demands will essentially force standardization, one way or another.  Of course, we would all like to see open standards, but even de facto standards will work.  This is what’s at stake in this battle.

The Contenders & Their Market Positions
It’s interesting how two such different businesses can suddenly see themselves at odds, but with a multi-billion dollar future market in cloud computing at stake, it’s not surprising that we may see all kinds of players emerge.  Looking at the relative market cap (AMZN @ 36.5B and VMW @ 15.5B) and stock performance of the two tells one story:

VMW vs. AMZN

Digging into this a bit more we can see that the story is a lot bigger than a simple tale of revenues, especially as it relates to enterprise businesses.

Amazon
Amazon (AMZN), as a whole, is roughly 3x in employees and 10x the size of VMware (VMW) in revenue.  The vast majority of this revenue comes from Amazon’s online retail business, which is consumer focused, while VMware is almost exclusively focused on large enterprise customers[2].  More telling are the recent 10-Q reports of both companies.

Amazon, unfortunately, does not provide the revenue numbers for Amazon Web Services (AWS) as part of their reports.  It is bundled into an ‘Other’ line, which includes a number of Amazon revenue streams.  Their most recent 10-Q reports the North American revenue for ‘Other’ as 217M for the 6 months ending June 30th, 2009.  I’m going to go out on a limb and suggest that AWS revenues are half of this number, but it’s certainly a wild guess.  Assuming that’s the case, the AWS business is a 200M annual business and undoubtedly growing rapidly.  It is very difficult to know what percentage of that revenue is large enterprise customers, but I feel safe concluding it can’t be more than 25-35% total.  My conclusion is based on the fact that enterprises are slow to adopt and that most of their current use cases are almost certainly non-production ones like batch processing.

If this is true, Amazon’s AWS business for enterprise is unlikely to be more than 70M annually.  This is a very impressive number given that Amazon is not traditionally an enterprise-focused business.  We should give them credit where credit is due.  By all accounts Amazon has generally had a large number of challenges shifting from it’s consumer, one-size-fits-all, business model, which is certainly a put-off for large enterprise customers.

VMware
In comparison, VMW’s recent 10-Q report shows a healthy 926M in revenues for the 6 months ending June 30th, 2009.  VMware’s license revenues dropped pretty significantly from the year before, but annual support licenses made up for it.  Most of this is certainly attributable to the current economic climate and their enterprise customer base.  Given that VMware’s customer base is largely enterprise customers, they are a roughly 2B dollar enterprise business.  About half of which is new license sales.

VMware has a long track record of providing tremendous value to enterprise customers, but by most reports, the penetration of virtualization inside the enterprise is still less than 20%.  This is due to a variety of factors, but anecdotally, it appears that virtualization and server consolidation suffers from many of the traditional issues that plague IT initiatives within the enterprise.  McKinsey’s cloud report predicted that enterprises, with tremendous effort, could reach virtualization rates of 38%.

Unless perhaps cloud computing, as an operational model change, can completely change the way that IT delivers it’s services.

AMZN vs. VMW in the Enterprise
So, while at a glance, Amazon is a bigger business, inside the enterprise VMware is actually a 10x bigger business with relatively low penetration of it’s technology and a lot of room to grow.

Now the 100B dollar question: Will enterprise business move outside to public clouds like Amazon OR use VMware and internal private clouds to change the way that IT does business?

It’s anyone’s guess how this will play out in the long term, but in the short term, we’re likely to see both routes taken.  While predicting the long term is outside the scope of this posting, I think the short to medium term fight (“ROUND ONE!”) that will directly impact how this plays out is cloud computing standards.

The Standards Collision
It’s clear from history that standards combined with infrastructure technology create a transformative opportunity.  While cloud computing has enjoyed some serious traction, we’re still early on and standards have not evolved yet.  Amazon and VMware, as standards competitors, are a bit like having two different railroad track gauges.  You won’t be able to run the same kind of trains on both sets of track gauge or connect railways based on either together.  Standards matter and making sure we have the same gauge rails everywhere is incredibly important to the rapid adoption of cloud computing[3].

At VMworld, VMware announced vCloud Express including the vCloud API.  The vCloud API was released under a very open license.  One that even allows building a cloud with alternative non-VMware hypervisors that provides this API.  As I mentioned at the time, it seems to me that this is going to drive de facto cloud computing standards.  In fact, VMware’s announcement included five new clouds supporting the standard and one very important cloud management vendor (RightScale).  In one fell swoop, VMware provided a standard across five clouds and one vendor.  This is certainly just the beginning.  Without a doubt many more will adopt the vCloud API.  Perhaps most telling of all is that VMware’s own cloud infrastructure product isn’t even shipping yet.  Once it ships, it will most certainly work with existing VMware products like vSphere and every new enterprise vCloud-based installation will have the same vCloud API.

But what about Amazon’s AWS APIs? Could those be a standard too?  They could be, but Amazon has been deliberately vague about the license for it’s cloud APIs.  Although certain vendors support AWS APIs, like EUCALYPTUS and OpenNebula, it has not been clear what their legal status is.  This is also why AWS competitors like GoGrid and RackSpace chose to develop their own APIs, when clearly supporting AWS-compatible APIs would have been more desirable.  Will Amazon license their APIs under an open license in response to VMware?  I think the answer is obvious.  Amazon Web Services must open license their cloud APIs or it will be one of the biggest mistakes they have made to date[4].  Clearly, they will make the standard Amazon play and only do the absolute minimum necessary, which likely means an open license on EC2 (Elastic Computing Cloud).

When AWS opens the EC2 API it will open the floodgates for folks like EUCALYPTUS, OpenNebula, DynamicOps, VMops, and other cloud vendors, effectively allowing them to compete against vCloud in the enterprise.

In effect, we’ll have two major competing cloud standards: the vCloud API and the EC2 API.

What Happens When Worlds Collide?
So, we have VMware moving into Amazon’s ‘public’ cloud territory by enabling AWS competitors, while Amazon is extremely likely to reciprocate by enabling VMware competitors for internal ‘private’ clouds.  Given that both external public and internal private clouds will see significant growth over the medium term and that there is tremendous value from joining external and internal clouds via standards, the writing is on the wall.

A standard has to win or, at least, dominate.  While Amazon is the 800lb gorilla in the public cloud computing space, VMware has a massive lead in the enterprise.  It really depends on where you think the enterprise is going to go.  Will they put more money into transforming the way IT works via internal clouds or begin to move to external clouds right away?

My bet is that enterprises are going to go for internal clouds before external clouds, at least for the majority of their sensitive and mission critical workloads.  If that’s the case then vCloud looks like a good bet and Amazon looks like they could eventually be playing second fiddle as the #1 player in the #2 market.

Spectrum of Cloud Computing Providers

There will soon be two major paths for cloud computing providers: commodity and premium.  If you read my series, Cloud Futures, you’ll know that I broke down cloud service providers into three major categories: service clouds, consumer clouds (previously ‘commodity’)[1], and focused clouds. In retrospect I realize now that there are possibly four, not three major categories. The missing category is premium enterprise clouds. Previously I had lumped these under focused clouds, but I now realize that, in fact, there are likely to be so many of these that they deserve their own category. I’ll go even further and suggest that in terms of markets targeted, there will really only be two ends of a spectrum: enterprise and non-enterprise.

Most clouds will fit towards one of this spectrum or the other. In essence, you’re targeting small businesses (startups, SaaS providers, and SMBs) or you are targeting larger businesses (SME or Fortune 2000). The former are extremely cost conscious while the latter may have a number of other equally important drivers, such as security (e.g. VPN access), high availability (HA), SLAs, application portability without modification[2] and similar. Clearly large enterprises will consume services at both ends of the spectrum, but they will have many use cases (mostly ‘production’) that can only be serviced by a premium service running VMware’s forthcoming vCloud product.

This means we will have a large bifurcation in the cloud computing space with two very different kinds of solutions. Clouds will either target commodity customers or premium customers.  Very few clouds will actually fit in the middle of this spectrum initially, although I expect providers on both sides will grow towards the middle.  In quite a few cases (AT&T and Rackspace come to mind) cloud providers will build two offerings at both ends of the spectrum, but we haven’t seen this quite yet.

Premium vs. Commodity

Ultimately, commodity clouds will be forced via pricing pressure to continue to drive down capital expenses and operating costs.  As we can already see in the public cloud space, providers have largely standardized on the Xen open source hypervisor.  This is the de facto standard because it is free.  In contrast, premium enterprise clouds will necessarily spend more on their infrastructure to provide advanced features like HA.  Their pricing will reflect this, but it also means they will use VMware’s products and hence have unique opportunities for integrating with internal clouds at large enterprises (more on this below).

This table summarizes the differences.

Enterprise Clouds Are Already Here

If you were paying close attention this year, you’ll have noticed that both Savvis and Terremark are working on or have delivered enterprise cloud offerings.  There are many  more on the way.  These providers are delivering VMware-based platforms specifically for enterprise customers and pricing reflects that[3].  Terremark even labels itself ‘The Enterprise Cloud’.  I had hoped to release a full review of Terremark, but due to time constraints haven’t been able to complete it.  If you click on the screenshot to the right it will take you to a set of Flickr photos that are an extensive tour of the Terremark Enterprise Cloud product.

What’s most interesting about this is that two major players have entered into this space and at the same time VMware’s vCloud is unreleased.  Nor are there any other shrink-wrapped software packages for building a cloud based on VMware.

VMware’s Dominant Position for Building Internal Clouds

But why VMware?  What’s so important about it?  For those of you who may not be aware, VMware’s enterprise-class hypervisor (ESX) is the de facto standard inside the enterprise, in much the same way the Cisco routers & switches are a standard.  This means that as enterprises move towards building internal clouds (an inevitability), they will be more likely to build clouds based on VMware’s ESX, which they are already comfortable with.

A-ha! Surely there is a startup or major player who has already delivered a software offering that allows enterprises to build their own internal clouds?

No. There is no credible contender to VMware’s crown.  Even though they did not see cloud computing coming, even though they are a large organization and slow to move, there is still not a single credible contender with a released product that manages the VMware ESX hypervisor and allows you to build a real self-service internal cloud.  Nada.  Zip.  Zilch.

There are some prospects like Platform’s ISF[4] that could be contenders, but by the time they are released in the wild, VMware’s vCloud will also be released.  The window of opportunity for making significant inroads into the enterprise is closing quickly[5].  Once VMware’s vCloud is released, who will risk averse IT managers and CIOs in enterprises go to?  A new player or someone already trusted and embedded like VMware?  There is no doubt.  They will largely select vCloud unless VMware fails to execute.

Can VMware Fail to Execute?
Is it possible for VMware to fail to execute in it’s sweet spot?  It’s area of expertise?  Yes.  Is it likely?  No.  If you look at the DNA of the business they already have the kinds of talent necessary for building a strong product in their acquisition of Akimbi, the folks upon whom the VMware Lab Manager product was built.  That team already knows how to build a self-service portal and a large scale VM deployment system including scheduler as these were integral for the lab manager product.

In other words, the writing is on the wall.

The Power of Internal + External Clouds
For many smaller business, moving everything to the cloud will always be a very compelling solution, but for the enterprise it will never be acceptable.  For various reasons (regulatory, political, legal, and others) enterprises must maintain a certain amount of infrastructure.  Also, I’ve heard fairly compelling arguments that large enterprises have sufficient scale to build and operate their own clouds at a cost advantage to external clouds.  Regardless, some capacity will reside outside of the firewall.

The usage of external clouds will largely be dictated by use case and in order for enterprises to derive maximum value from both internal and external clouds they will want a single internal portal that manages both.  They will want minimal friction for internal customers to be able to pick the best cloud for the job/cost.  It will also be important to allow some amount of portability (moving VMs and their workloads across the firewall).

While this doesn’t require a VMware hypervisor on both sides of the firewall, it will be greatly facilitated if that is the case.  Tools written against the vCloud API will likely work with vCloud-based external clouds without modification.  There is simply far too much synergy possible once both internal and external clouds are based on the same cloud platform.

Summary
There will be two paths for clouds: premium & commodity.  Premium clouds will focus on the enterprise and delivering value they are concerned about.  Commodity clouds will largely be forced to compete on pricing and features irrelevant to the enterprise.  VMware’s vCloud will be the dominant player behind the firewall because there is no credible contender.  The synergistic effects of internal & external clouds being based on the same vendor’s software will provide powerful and compelling reasons for enterprises to adopt those external clouds.  Enterprises will use commodity clouds, but mostly for batch processing and non-production workloads that are pricing sensitive.  The bulk of enterprise cloud spending will be on vCloud-based public cloud providers.

192.168.1.1 -> firewall.company.com

firewall.company.com -> 192.168.1.1

This makes it trivial to type URLs into your browser bar. For instance:

http://www.google.com

Behind the scenes DNS looks up the IP address(es) for ‘www.google.com’ and your computer can connect directly.

More importantly, for developers and web operators, it allows source code and configuration files to point to a DNS name rather than an IP address. This is critical when servers may change where they are on the network, which happens more frequently than you imagine. In cloud computing environments it happens quite a lot!

Without robust and effective DNS, your web application or cloud-based service will tend to be brittle, prone to outages.

Advanced DNS Primer
I won’t cover how DNS works in detail behind the scenes, but do suggest you check out the comprehensive Wikipedia article on the topic. I will provide you with some details on some of what has changed recently in DNS land that is highly relevant to cloud computing itself and explains why running DNS robustly is not just for anyone.

A major advance in the way that DNS services are deployed is the use of Anycast technology. Simply put, Anycast is a ‘trick’ you can play whereby a host can appear to be in multiple places on the Internet at once. With DNS this trick is performed by doing the following:

1. Deploy your DNS servers in a number of different global locations
2. Configure each DNS server so it looks like all the others (same IPs, etc.)
3. Employ a trick with Border Gateway Protocol (BGP) to route all traffic to all servers

I’m simplifying this a bit, of course, but the result is what matters. Effectively, now when a computer on the Internet does a DNS lookup against any of these hosts they will somewhat auto-magically reach the closest one to them. This makes DNS deployed in this manner very fast and resistant to failures.

This works well for DNS servers, but it’s not the only advanced DNS feature that services like Dynect can provide. In addition to deploying Anycast servers, these DNS services frequently provide:

• Load balancing across multiple locations or cloud providers
• Geographically intelligent traffic management (route customers to ‘closest’ server)
• Deeper reporting data
• APIs for maintaing DNS

Needless to say these are all non-trivial capabilities for your average business to build into their own DNS structure[1].

Dynect and Me
First off, I need to be clear that I am a member of the Dynect customer council and may be a bit biased; however, while most of this review undoubtedly holds true for Dynect, it’s probably somewhat true (at least) for their competitors. You’ll need to try them out for yourself.

I’ve been using Dynect for well over a year now and during that time have experienced zero DNS service outages. There were a couple of speedbumps with API accessibility early on, but even those are long gone now. We used Dynect for the CloudScale Project and were heavy API users. Although the user interface (UI) leaves something to be desired, the API has been outstanding. Generally speaking changes made via the API show up globally across all of their nameservers in a few seconds or less. This is an outstanding response time!  If you’re a cloud provider and want to outsource DNS services I highly recommend using Dynect just because of this.

The UI, while clunky, is usable and there are a number of convenience features for experienced DNS admins like the ability to import a standard DNS zone file. More importantly, the reporting data is excellent allowing you to get detailed usage reports at any level of detail like the following:

The only major downside I encountered with the Dynect service was that the API had not been designed well for concurrency, meaning that if you had multiple processes making updates at the same time with the same credentials they would run over each other. I believe the Dynect folks have either fixed this or a fix is in their current roadmap.

Summing up DNS
Domain Name Service is critical to a well functioning Internet infrastructure or cloud application. Building it yourself is possible for the basics, but achieving the same level of robustness and features of a DNS cloud service is difficult without considerable resources. Many of these DNS services provide good value for your money. I personally recommend Dynect as I have had great experiences with them from a reliability, support, and feature point of view. In the classic equation of build vs. buy, DNS definitely gets a ‘buy’ from me, a long time DNS administrator.

 
[1] If you insist, then start here with RFC3258 ]]> http://www.cloudscaling.com/blog/cloud-computing/dns-as-a-service-dynect-review/feed/ 2 http://www.cloudscaling.com/blog/cloud-computing/gogrid-net-sdk-updated/ http://www.cloudscaling.com/blog/cloud-computing/gogrid-net-sdk-updated/#comments Sat, 02 May 2009 19:53:48 +0000 su http://neotactics.com/blog/?p=196 Continue reading →]]>

Mitch Denny, a member of the GoGrid developer community, stepped up and took over maintenance of the GoGrid .NET SDK.  He’s just released a new version that updates to support the latest GoGrid API features including jobs and pagination.  You can also find Mitch on twitter.

Thanks Mitch!