AWS and the Risks of Being a Conglomerate
Tuesday, November 28, 2017
The launch of Amazon Web Services in 2006 was a milestone in technology innovation. AWS was the harbinger of our now cloud-mad world, where doing new projects solely in on-premises datacenters has become kind of quaint. AWS was--and remains--a great achievement.
Any company that can pull off a technological achievement like this must qualify as a technology company, right? Amazon is also a retailer, of course, but even this business is based on the company's unique technical foundation. Given all of this, it's natural to view Amazon as first and foremost a technology firm.
But this isn't correct. In fact, Amazon is a conglomerate, one of the few to appear in recent decades. To understand why this is true, think about all the companies that Amazon competes with. The diagram below shows some of the most important.
In retail, Amazon competes with Walmart, Target, Alibaba, and pretty much every other retailer in the world. In cloud platforms, AWS competes with Microsoft Azure, Google Cloud Platform, and others. Amazon Video competes with Netflix and Hulu and others, while Amazon Devices sells hardware against Apple, Google, Samsung, and more. With the purchase of Whole Foods, Amazon added Safeway, Kroger, Aldi, and other grocers to its roster of competitors, while Amazon Studios competes with Warner Brothers and Columbia and Disney and everybody else who makes filmed entertainment.
And while they're not shown in the diagram, Amazon also competes with more companies in even more industries. Their self-publishing business competes with HarperCollins and Hachette and Macmillan, while Amazon Music competes with Apple and Spotify and Pandora. Amazon has even taken on Etsy with Amazon Handmade, and more are sure to come. In fact, it's hard to think of any other business in history that's chosen to compete in so many diverse markets at once.
Becoming a conglomerate rather than staying within an industry has some well-known challenges. One of them is losing focus: What is Amazon's core competence? Another is brainpower: No matter how good Jeff Bezos is (and he's clearly really good), can he hire and retain top managers who can successfully compete with the top people at every one of Amazon's competitors?
But for AWS in particular, Amazon's role as a broad conglomerate brings some special challenges. AWS is a platform, which means that its success requires other companies to build on it. Yet who's going to build on a platform offered by a company that's also a competitor? AWS is no longer the only cloud platform game in town (as it was when Netflix chose it), so why would any company that competes with Amazon in any area choose to give them money by building on AWS? This simply isn't rational. In fact, I have to believe that if Netflix were starting today, they'd pick somebody other than AWS for just this reason.
These conflicts are already starting to appear. The Wall Street Journal has reported on Walmart's efforts to get its partners to avoid AWS, and as Amazon enters more businesses, we should expect these challenges to increase.
And even if Amazon doesn't compete with a firm today, who's to say what might happen in the future? For example, entering the financial services market could make sense for Amazon, given the firm's incredibly broad customer base. This would immediately make them a competitor for thousands of banks and other financial services firms. Because it's hard to see a logical bound to the markets Amazon might enter, almost any business leader could one day wake up to an announcement that he or she has a new and powerful competitor. If this leader has already chosen to build on AWS, which is itself quite profitable, they're now in the position of giving their new competitor more money to use against them.
Amazon's ability to diversify successfully into so many areas is impressive; Bezos just might be the most successful business leader alive today. But choosing to become a conglomerate has downsides, too. One of them is that some number of potential customers are likely to shy away from AWS just because they don't want to help fund a competitor.
What, Why, and How: Communicating with Different IT Audiences
Wednesday, April 19, 2017
I spent the first several years of my career writing code.
For all of that time, I divided the technology world into two groups:
developers and non-developers. I didn’t have much respect for the second group;
they were mostly IT managers and marketing people, and they weren’t very
technical. Even worse, they didn’t make decisions based solely on which option
provided the best technical solution, an approach I thought was inexplicable.
When I first moved from writing code into writing books and giving
presentations, I held onto this perspective. My audiences were largely
developers, and like me, they knew that technical arguments were all that
mattered. In fact, we agreed that unless you really understood the details of
competing technologies, you could never make good decisions.
But I was wrong. I’ve now spent many years working with both
groups of people, and I’ve learned that the best technology isn’t necessarily the best
choice. Even more important, a deep technical understanding of the options isn’t
necessary to make a good decision. I’ve come to have a great deal of respect
for IT managers and marketing people.
The truth is that different audiences care about different
things. When I’m talking to developers, I still focus on what a technology is and how
it works—this is what developers care about. But when my audience is IT managers
or marketing people or other less technical folks, I briefly describe the what, then move on to why they should care about it. These
people don’t need to know how to use something—the what and the why are far
If you’re trying to communicate with different
IT audiences, you might find it helpful to be clear about this difference. This
is especially true if you’re trying to sell something. Developers rarely sign
checks—they’re not usually the final decision maker—and telling a deeply
technical story to IT managers won’t persuade them. The thing to remember is
this: developers care most about what and how, while IT managers care about what and especially why. Give each audience the information it needs--and only the information it needs--and you’re likely
to be significantly more successful.
Why Microsoft is Serious About Open Source
Monday, October 31, 2016
Open source software has had a huge impact on our industry. Over the last several years, just about every big IT vendor, including Microsoft, has embraced this approach to some degree. Now with Azure, Microsoft is telling us that it doesn't care whether we use open source software or Microsoft's own technologies.
Really? Can they be serious? Has Microsoft embraced open source this completely? The answer is yes, and here's why.
In the traditional software model, vendors made money through selling software licenses, as shown below.
In this approach, the vendor provides software that runs on the customer's premises, and the customer pays the vendor a one-time license fee. While there might also be annual maintenance fees, the bulk of the money the vendor gets is typically from this initial license.
This makes open source software, which typically shrinks or eliminates the license fee, a threat to the vendor's revenue. Steve Balmer famously called open source a cancer. I don't know what was in his mind when he said this, but open source is certainly a cancer on the margins of the traditional license-based software business.
Today, though, this model is being replaced by cloud services. The picture now looks like this.
In this situation, the vendor runs the software, and the customer pays a monthly usage fee. Whether the software that provides a cloud service is open source or proprietary or some combination of the two doesn't typically have much impact on what the customer pays. They're paying for the service rather than licensing the software.
This is why Microsoft is serious about open source in the cloud. Offering open source services, such as Azure's support for Linux, Node.js, and Hadoop, just gives Microsoft more things for customers to use. Because there's no software license revenue to protect, Microsoft need not care about what kind of software it deploys to provide a cloud service.
In other words, offering cloud services using open source software lets Microsoft make more money. And we should always trust Microsoft to do the things that will make them the most money.
In the pre-cloud era, open source was spreading into more and more areas, so much so that it was getting harder and harder for software companies to make money from traditional licenses. With the rise of cloud computing, this problem goes away, since vendors are now charging for usage. Maybe the cloud came along just in time to save the software business from the margin-destroying cancer of open source.
New Whitepapers: The Microsoft Data Platform
Thursday, March 17, 2016
After decades of dullness, data is back in vogue. As part of this, we're seeing an increasingly diverse set of data technologies available. Taken as a group, these technologies can be viewed as a platform for working with data.
I've written a set of three papers describing the Microsoft data platform today. Each paper covers the technologies for working with a specific kind of data--operational, analytical, or streaming--and each one is meant to be readable on its own. They're also meant to hang together as a group, which is why each one starts with the same big-picture diagram of this broad set of technologies. That diagram looks like this:
Each paper describes a particular column in this figure, and all three take a scenario-oriented view--they're not deep technology tutorials. The core audience is IT leaders, but I hope they're useful for anybody looking for a broad survey of what Microsoft offers today for working with data.
The papers, all sponsored by Microsoft, are available here:
SOA Lives! APIs and Microservices
Wednesday, February 17, 2016
A dozen years ago, service-oriented architecture (SOA) was all the rage. The idea of exposing application services in a standard way (which at the time meant via SOAP) was so attractive. Why not remake our software to reflect the then-new agreement on how applications should communicate?
But the SOA bubble burst pretty quickly. It turned out that solving the technical problem of communicating between software wasn't enough to solve the real problems. In particular, organizations had a very hard time agreeing on what services applications should expose, how those services should be versioned, and who should pay for what. Much like the software reuse bubble engendered by the advent of objects, and for many of the same reasons, the enterprise dream of universal integration through SOA didn't work out for most organizations.
Yet today, the descendants of SOA live on. Rather than focus on enterprise integration, each of these descendants picked up on a stream of SOA thought and took it further, eventually finding real success. The two most important of these are:
- API management, where cloud-based services provide a standard mechanism for exposing, managing, and controlling access to software of various kinds. The dominant protocol is now REST, not SOAP, but the idea has gone mainstream through offerings from smaller firms (e.g., Apigee) to big ones (e.g., Microsoft and Amazon). In fact, API management has become so important that CA thinks it's worth running ads in the New York Times to explain the idea to non-technical readers.
- Microservices, where applications are built from self-contained chunks of code that interact via interfaces.. Rather than the grand enterprise integration schemes that drove much of the original SOA hype, microservices are primarily about building a single application. This simplifies communication--you can often dispense with authentication, for example--while still providing a way to create manageable, easily deployable application components. Once again, the big vendors are here, providing technologies such as Microsoft's Service Fabric to support this approach.
When a new technology appears, it's always hard to know how best to use it. When SOAP first showed up, it kicked off the original SOA thrust toward enterprise integration. This was certainly a worthy goal, but over time, it's become evident that API management and microservices are the approaches that actually worked. It's also become apparent that the complexity of SOAP and its fellow travelers wasn't required--a RESTful approach (or with microservices, maybe something simpler) was usually good enough.
The startup that was SOA a dozen years ago has pivoted to become the much more successful API management and microservices of today.
New Whitepaper: Introducing Azure Machine Learning
Wednesday, August 05, 2015
Machine learning has become a big deal. The rise of big data and the massive computing power made possible by cloud computing have made this set of technologies much more useful.
But machine learning isn't especially simple. While the basics are fairly straightforward, they're cloaked in odd terminology, phrases like "training data" and "supervised learning". For data scientists, people with years of specialized training, this isn't a problem. For non-specialists, though, the topic can be off putting.
To perhaps help with this, I've written a Microsoft-sponsored introduction to Azure Machine Learning (ML)
. The paper's subtitle is A Guide for Technical Professionals
, and that's exactly what it is: an introduction to machine learning for ordinary mortals. Azure ML is likely to become a broadly used technology, and so knowing the basics of machine learning is important. The paper's goal is to help you do this, using Azure ML as a concrete example.