Zynga is often in the news because gaming is hot and Zynga has been, and continues to be, a successful gaming company. What’s different here is the story isn’t about gaming nor is it really about Zynga itself. The San Francisco gaming house with a public valuation of $2.5B was an earlier adopter of cloud computing and they built this massive business that ended up going public on AWS. That’s hardly noteworthy these days. Some absolutely massive companies like Netflix have made that same decision.
What’s different here is back in 2012 press reports covered the Zynga decision to move from an all cloud deployment model to using their own data centers. The move was broadly covered in the industry press with example headlines like Zynga Gives Amazon Cloud the Slip, and Zynga Cloud Case Study: the Journey to a Real Private Cloud. This decision has often been referenced as evidence that returning to on premise when a company achieves very high IT investment scale in the right decision. This never seemed very credible to me but I understand the reporters perspective. A slightly more realistic but still incorrect interpretation is to reference this move as evidence that stable workload could be more economically hosted on premise. These days, there is more data available and it’s fairly easy to show that “being at scale” requires order 10^6 servers, deep investments in server and networking equipment and the software stacks above, and massive investments in the software stack that manages these resources. I’ve taken a run at most of those questions and offered my perspective in the last two talks I have done at re:Invent AWS Innovation at Scale and Why Scale Matters and how the Cloud is Different.
The news of the Zynga move has largely faded as more and more companies commit to the cloud. Yet, I kept watching this case closely because it is an unusual case where a nimble, start-up culture company with deep cloud experience decided to build their own private deployment with as many of the characteristics of the cloud as possible with a goal of being more economic.
This week more news came available when Robert McMillan of the Wall Street Journal wrote For Zynga, A Journey from Cloud to Home — and Back Again. In this article, Zynga is reported to have spent over $100m on a private cloud infrastructure and yet decided to return to the cloud all in. This decision is partly interesting because the previous move was so well publicized but mostly because Zynga has incredible visibility into both the on premise and public cloud world since they have run both at very high scale for several years.
The article quotes Zynga CEO Mark Pincus during the last investors call “There’s a lot of places that are not strategic for us to have scale and we think not appropriate, like running our own data centers. We’re going to let Amazon do that.” The articles continues by saying “The company Wednesday said it would shut its data centers and shift its computing workload back to Amazon, as part of $100 million in spending reductions.”
This announcement is interesting because Zygna has a very large infrastructure investment just as most large enterprises have. And yet, even with that large infrastructure investment, they still elected to move to fully to the cloud. What was an example that challenged cloud economics at the very high end of the scale, has now become an example of a company with a deep understanding of both cloud and on premise deployments at scale, deciding to fully commit to the cloud.
Of course, there is room for argument saying that the Zynga business has been through change and, of course they have seen change. What business hasn’t? In fact that’s part of the point. Cloud deployment make rapid change, scale up, scale down, and redeployments easy. In the Zynga case, they are now more deeply invested in mobile gaming with different compute requirements. A related potential pushback might be to point out that Zynga is under financial pressure. But, again, what business isn’t under financial pressure? In fact, I view the decisions made under business and financial pressure as perhaps the most informative. When a business with massive on premise and cloud deployments and deep skills in both needs to be even more nimble and frugal, the direction they take is particularly interesting.
I admit to a cloud bias but it’s really good to see another substantial company fully commit to cloud computing.
Today it seems there really is only three reasons I can see for any given system to not to be in the cloud:
* Regulatory compliance, such as policy or law that mandates data be stored on premises, or be kept within a specific jurisdiction where cloud services are unavailable
* Software dependencies with specialist, proprietary hardware – anything from audio/video capture handling over SDI/AES, PLC controller management, etc.
* A significant dependency on COTS that simply cannot function on the cloud due to software design that makes it incredibly difficult – for example I can think of one or two database products that are overwhelmingly expensive to run on the could simply due to design.
Realistically if none of these exist problems exist, the only problem left to remain is system architects who continue to design systems as if they were running in collocation or on premises. These are the ones that give the cloud a bad image in companies, naively believing systems can just lift-and-shift and assume everything will get cheaper and/or easier without putting enough thought into the dealing with the different environment.
Tony, you assesment is pretty close to where I would come out as well. Each year, these niche areas get smaller.
Looking at your database example, I don’t know the speciifics of why the examples you are thinking of are expensive to host in the cloud, there are solutions to that one as well. Perhaps the simplist solution is to ignore the problem and proceed anyway on the argument that database, although expensive, is a tiny portion of the overall application stack and, since the stack has to all run in the same location, the advantage of running it in the cloud is sufficient to make the database licensing problems worth living with. Another solution I’ve seen done when unusual equipment or non-cloud friendly licenses are required is to host the offending product in an colo that maintains a direct connection to AWS and is physically near. This gets you nearly in-the-same-datacenter latency, allows the rest of the stack to be hosted in the cloud and still have good access to the non-cloud hosted component.