Following yesterdays post about Amazon you could call what is happening at Zappos ‘Amazon’s AWS (or big established system) disadvantage’. For over 2 years Zappos, which got aquired by Amazon in 2009, is frozen in time now, as reported in this portrait at New Republic:
Zappos’s customer-facing web site has been basically frozen for the last few years while the company migrates its backend systems to Amazon’s platforms, a multiyear project known as Supercloud.
And in more detail:
THE MIGRATION of Zappos’s entire IT infrastructure to Amazon—which means figuring out a way to move an extraordinarily complex set of custom software programs that power a billion-dollar-a-year e-commerce site over to an entirely new environment—continues. The difficulty of this effort is almost unfathomable. Imagine taking a million square pegs and attempting to insert them into a million round holes, except you don’t even know if all the holes exist, or where the holes might be located, and you have to negotiate access to the holes with dozens of different teams of hostile software engineers. The project has consumed Zappos’s tech department for more than two years, and during that time, the Zappos site has been almost completely static. That means no improvements or innovations and only minimal bug fixes.
(Highlights by me.)
Amazon is not alone on this. Google is well known for demanding of aquired services to migrate to its own homegrown backend system; which has led to similarly frozen services. This makes sense on a level. You want and need every service you offer to be on your technology stack for technical as well as organisational reasons.
But the price for this might be high and maybe even to high in some places. Being dormant for two years in todays market is an eternity.
This has implications beyond just the one frozen service. Founders of startups looking for exit options might look closely at stories like this and if they are indeed builders they might not find it attractive to stand still for a long time with everything consumer-facing while coordinating tedious migration work.1
To make it short your backend might be efficient, it might even be the best in the world, but that still doesn’t mean you have to have running everything you own on it. There is more than one dimension to this.
As startups grow ever faster and M&A is becoming more important for internet giants like Amazon, it might have to rethink its stance on migrating aquired services to its backend systems at least on a case to case basis.
Side note: With Zappos and Amazon the argument for migration might make far more sense than in other instances given how close both are on the operations side of things. But the case remains that two years in todays market is far to long to concentrate on just backend migration.
- This does not mean Amazon would because of this not get to buy a hypothetical hesitant startup for the right price. But that is the point: The right price increases if Amazon itself is perceived as a place there you can not evolve as company and with your product as fast as you may want to. Even more problematic: This way you are losing the product people you just aquired as fast as possible. ↩