Certainly, a good part of A.W.S. software is open source,
which means it could be used elsewhere, and companies
like Microsoft and Google also have big clouds. But
neither of them, nor IBM, which also wants the cloud
business, created more than 500 new features and services
last year, as A.W.S. did.
Not sure about the precision of that number, but the speed and agility of AWS compared to MSFT/GOOG/IBM is astonishing. I still don't quite understand how they do it.
Why maintain and improve your existing services when you can get credit for launching a new shiny thing? Steve Yegge called out this tendency in his (in)famous platforms rant [1]:
They prioritize launching early over everything else, including retention
and engineering discipline and a bunch of other stuff that turns out to
matter in the long run. So even though it's given them some competitive
advantages in the marketplace, it's created enough other problems to make it
something less than a slam-dunk.
Amazon's "speed and agility" comes at the cost of not updating anything, ever. If you want new functionality, you'll have to integrate a new service.
One way Amazon adds so many features, though it won’t talk
much about this, is to contract key elements from other
companies. QuickSight, the data analysis tool announced on
Wednesday as a competitor to IBM’s Cognos, uses technology A.W.S.
hired from a start-up called Zoomdata, according to people
familiar with the technology. They asked not to be named in order
to maintain professional relationships.
My interpretation is that those companies are stodgey. It's always one or two guys trying to be in charge of the whole circus instead of having 5 rings going on. Google and Microsoft also have lengthy, old school review processes for performance, security, etc and lots of gatekeepers. Amazon plays more loose. Not sure about IBM, I thought they just outsource stuff and make jeopardy robots.
Pessimistically, I believe they achieve such speed by strictly limiting the amount time they put into polish and bugfixes for the products they've already created.
After all, it works for their platform, what more could someone want?
AWS IMO is insanely great at cutting the price of established web services. This is more than enough to carry them for the next 5-10 years. What will be interesting is how they deal with what comes afterwards...
I think it's more or less "Throw a few billion dollars at the problem; continue doing so for years." (My over-under for the size of the AWS team would be, oh, 2,500 engineers.)
Amazon has by far the best dev leads. Some of them are guys who worked on the Common Lisp standards in the 80s, some are 22 yo Bring Your Own JS framework hippies. But the management manages to select for lead roles the very best devs internally and mighty capable ppl externally.
My guess is Google/MSFT is doing a lot of putting out fires since their offerings are newer than AWS, and they're not getting as much usage (which makes bugs appear earlier). That's been my understanding as to why Dropbox hasn't changed all that much -- they've just been making sure scaling works. But can teams of 10 at MSFT/GOOG really not put out new desirable product with any decent timeframe? They have enough staff members.
I think with Google, it is really unclear whether the org. as a whole really believed in their Cloud products. They really don't take selling to the biggest users very seriously. Self-service has been fine for Google's low-margin businesses in the past, but its not clear that they've made any effort to invest in the ecosystem of other vendors the way Amazon has. If the IaaS vendor is low-cost/commodity, then most companies will be swayed by the size and competence of the ecosystem as a form of 'insurance'.
Now that Alphabet is the parent company, maybe this part of google can be taken more seriously. They are very capable of succeeding, but they don't really understand B2B/Enteprise and really never have.
Speaking as an ex-googler, I think a disturbing amount of Google is dedicated to pointless blind-allocated me-too attempts to kick sand in the face of its competitors.
Of course, I also think they could work wonders on their horrible attrition rate by ending blind allocation for middle to senior talent, so I'm clearly out of my mind.
Google is legendary for its inability to have medium-/high-touch relationships with customers. Unfortunately. I've always thought their products were pretty high quality.
microsoft azure has added the same amount of new features during the past year as well (600+ features). the new services like machine learning, data factory, data lakes, sql data warehouse, and powerbi are amazingly powerful. the only problem is people seem to ignore them in the conversation of cloud computing.
This discussion of Amazon's agility meshes well with Steve Yegge's famous rant on Google and Amazon. He attributes Amazon's success to their focus on designing all their software as a service, and actually credits this strategy as the very reason that AWS came to be in the first place.
Yegge sez: "a platform-less product will always be replaced by an equivalent platform-ized product."
I guess that's true. If I had to defend that statement, I'd try to argue that a platform, especially an open platform, will be tested, poked, prodded, evaluated, evolved and maybe even documented by many more developers than some monolithic piece of software in some closed code base.
In this context, lock-in is a function of the size of the AWS user's engineering team, and I don't think the NYT Author thoroughly understands this aspect of the problem. It wouldn't be infeasible to, say, move from S3 to OpenStack Swift, but that project is much more feasible for either a large team or a small team with very little data. Similarly, one could use say RabbitMQ instead of AWS SQS, but that takes a bit of effort. The availability of Docker images (and, eventually, k8s- or Swarm-orchestrated cloud apps) helps here too. While AWS might have proprietary APIs, the semantics of those APIs (e.g. 'enqueue this blob') don't entail very much proprietary magic.
not really, everything i've used so far is pretty interoperable with whatever. The exception I guess would be their metaservices that do logging and auditing of AWS services, but the SDK is pretty developed to let you shove, say, S3 into whatever you want.
I'm open to be corrected on this but I don't think it's good to confuse "our different offerings have lots of interoperable synergy" with "it's fucking impossible to migrate off this"
Personally, I don't think lock-in means "it's fucking impossible to migrate off this". It just means it will be sufficiently painful that it is a strong deterrent. A service can be great and still come with a lot of lock-in; it's just another trade-off to consider.
I think AWS and similiar cloud providers have a tough challenge for the long term.
The big question is how cheap will computing get, and how will the demand of that computing increase over time? If prices continue to decrease rapidly, it becomes very difficult to maintain large revenue growth, even with unit-volume increases.
In 20 years, how cheap will core services like S3 and ec2 be, and how will AWS' revenue on those services compare to today?
They are also developing a lot of AWS software that probably won't decrease in price over time. For example, over the past 30 years database hardware has decreased dramatically in price, but Oracle software licenses have not. AWS has a lot of services that are some combination of complex software and hardware components.
Hardware hasn't really decreased that much not if you count what services you want to run these days on it compared to 10-20-30 years ago.
If you just run a simple web-application sure it's much much cheaper today than it was in 2000, but as technology evolved that isn't enough for big business today, if you look at companies that still build their own servers then unless they have unlimited space the servers these days tend to be much more expensive and exotic hardware is more and more common (it's not that uncommon to see SQL/BI servers with quite expensive compute/GPU's these days, 5 years ago it was all those "IOPS accelerators" or "specialized" SSD's, in 5 years it will be something else).
As far as looking at the price of S3 or EC2 in 20 years that's completely irrelevant because those services for the most part will be irrelevant in 20 years, yes their might have their own counterparts but it's not like you will still use the same services, just look at how drastically the way you build and deploy applications has changed in 10 years.
I think it's a mistake to only look at margins. We should also look at economies of scale. In the future, as margins get lower, it is compensated by more customers. Also, whenever margins get lower, successful businesses tend to provide additional value and charge for it. It is already happening in cloud services. Few years ago, it was fully IaaS and now it's moving towards more PaaS. Who knows what will come next? I can already see so many things that could be done better, and that's just me.
I started using uBlock's default-deny setting 2 weeks ago (it rejects all requests to secondary domains unless the domain is explicitly allowed). It's amazing to see how many websites use AWS or amazon ads these days.
It is really strange to think about how the average consumer views Amazon as an online retailer, but that is really only half the picture. As the end of the article states:
>Maybe someday A.W.S. will be the company that also happens to own an online retailer.
I actually don't see how AWS and Amazon remain together in the long term. They seem like two totally different businesses with different goals, long term prospects, etc.
Because the concept that a company has to have everything align with a "core business" is a relatively new, and incredibly stupid concept. The business of business is making money, not being in a specific industry. Nokia has made paper, rubber products, wires, capacitors, robots, computers, phones and networking equipment. Samsung has an even more broad array of products, as do most Korean, Japanese, and Chinese conglomerates. The idea of a "core business" is a relatively recent invention of western business which mistakenly argued that a company could only do one thing well as though a company and a person were the same thing. Dow, GE, P&G, Johnson Family Enterprises, and Berkshire Hathaway would all disagree.
Jeff Bezos sees Amazon as the GE for the next 100 years. He has a long view that left American corporate culture in the late 1970s. Japanese corporate culture takes the long view, they have business plans that look out across decades, rather than quarters. Bezos is making amazon a very wide company, because it's harder to fail as a wide company than it is a deep company. Now, in some ways Amazon IS a deep company, with Amazon products delivered through their supply chain, marketed by their website running on their platform, and a rich media ecosystem on Amazon consumer devices. However it will survive damage to one of those sectors because of the breadth of the company.
The idea of cor businesses and splitting up companies that do "to much" is rooted in the quarterly corporate culture, which sacrifices the future of the company in exchange fore shareholder (and executive) rewards today. Business stagnant? Split it up into aligned companies for a quick stock boost. Did you actually create anything new or useful, or change the way the businesses operate? No, but it looks good on paper.
Agree that American business culture is too short-sighted.
The question is size is far from decided, though. Though these Japanese firms may survive long-term, they often aren't good stewards of shareholder capital as measured by return on equity (ROE) and other financial metrics. But it does seem that conglomerates are making a comeback, with Alphabet, Amazon, and the perennial favorite Berkshire, whose own CEO has said their size is starting to present problems. Definitely an interesting question.
I completely agree that the Japanese might not be the best model, but as usual, I feel the truth lies in a third path. Not quarterly, not 50 years, but maybe look for a path for the company to survive the next 10-20 years, and always be willing to change. "Plans are worthless, planning is priceless."
There is some relation there, though. The obviously use their own infrastructure to run Amazon, which has significant scaling/infrastructure requirement. Initially, of course, AWS was the "space capacity" at Amazon, now their total capacity vastly exceeds what their store needs.
I think though that Amazon will probably remain more of a conglomerate, rather than divesting any parts of its business. Instead, it seems to add more and more brands, services, etc. In the long this will probably be good for them, since they'll be able to effectively integrate the experience of customers across all brands/services/etc.
Amazon actually has/had a variety of groups aiming to be the "operating system" of other businesses - AWS, 3rd party fulfillment and sales, B2B marketplace, amazon stores(closed), etc.
So not sure there's a mismatch problem. Also i wonder - how can Amazon tie all those B2B units into a larger whole ?
1. Its really expensive: about 5 times as expensive as dedicated servers.
2. Not reliable: they will shoot down servers any time they like. You will need to make sure you have redundancies in place and pay for them.
3. Lock-in: their services (beyond EC2) come with a set of proprietary APIs that your app will depend on. This creates a lock in.
4. Still need DevOps: so you pay a lot, get locked-in and still need to put everything together by yourself and make sure it runs reliably? Yep, you still need devops/admins which at the end is probably the biggest cost of your operation.
So, here are my suggestions:
You have a low-volume and don't mind a lock in: use a dedicated mobile/web cloud ala Firebase/Parse/etc or go with a true PaaS solution like AppEngine/Heroku.
If you have a big volume: you will need to bite the bullet, hire some devops and setup+maintain your own dedicated servers. You will at the end pay much less for servers compared to AWS, have full control over hem and have no lock-in.
