Showing posts with label AWS. Show all posts
Showing posts with label AWS. Show all posts

Thursday, March 09, 2017

Inspector Sands to Platform Nine and Three Quarters

Last week was not a good one for the platform business. Uber continues to receive bad publicity on multiple fronts, as noted in my post on Uber's Defeat Device and Denial of Service (March 2017). And on Tuesday, a fat-fingered system admin at AWS managed to take out a significant chunk of the largest platform on the planet, seriously degrading online retail in the Northern Virginia (US-EAST-1) Region. According to one estimate, performance at over half of the top internet retailers was hit by 20 percent or more, and some websites were completely down.

What have we learned from this? Yahoo Finance tells us not to worry.
"The good news: Amazon has addressed the issue, and is working to ensure nothing similar happens again. ... Let’s just hope ... that Amazon doesn’t experience any further issues in the near future."

Other commentators are not so optimistic. For Computer Weekly, this incident
"highlights the risk of running critical systems in the public cloud. Even the most sophisticated cloud IT infrastructure is not infallible."

So perhaps one lesson is not to trust platforms. Or at least not to practice wilful blindness when your chosen platform or cloud provider represents a single point of failure.

One of the myths of cloud, according to Aidan Finn,
"is that you get disaster recovery by default from your cloud vendor (such as Microsoft and Amazon). Everything in the cloud is a utility, and every utility has a price. If you want it, you need to pay for it and deploy it, and this includes a scenario in which a data center burns down and you need to recover. If you didn’t design in and deploy a disaster recovery solution, you’re as cooked as the servers in the smoky data center."

Interestingly, Amazon itself was relatively unaffected by Tuesday's problem. This may have been because they split their deployment across multiple geographical zones. However, as Brian Guy points out, there are significant costs involved in multi-region deployment, as well as data protection issues. He also notes that this question is not (yet) addressed by Amazon's architectural guidelines for AWS users, known as the Well-Architected Framework.

Amazon recently added another pillar to the Well-Architected Framework, namely operational excellence. This includes such practices as performing operations with code: in other words, automating operations as much as possible. Did someone say Fat Finger?




Abel Avram, The AWS Well-Architected Framework Adds Operational Excellence (InfoQ, 25 Nov 2016)

Julie Bort, The massive AWS outage hurt 54 of the top 100 internet retailers — but not Amazon (Business Insider, 1 March 2017)

Aidan Finn, How to Avoid an AWS-Style Outage in Azure (Petri, 6 March 2017)

Brian Guy, Analysis: Rethinking cloud architecture after the outage of Amazon Web Services (GeekWire, 5 March 2017)

Daniel Howley, Why you should still trust Amazon Web Services even though it took down the internet (Yahoo Finance, 6 March 2017)

Chris Mellor, Tuesday's AWS S3-izure exposes Amazon-sized internet bottleneck (The Register, 1 March 2017)

Shaun Nichols, Amazon S3-izure cause: Half the web vanished because an AWS bod fat-fingered a command (The Register, 2 March 2017)

Cliff Saran, AWS outage shows vulnerability of cloud disaster recovery (Computer Weekly, 6 March 2017)

Thursday, May 10, 2012

Does everyone (except Google) have a platform strategy?

#bizarch The obvious ones - Apple, Amazon, Microsoft

General comments

"The new market disruption is the migration of a large number of demanding customers away from phones-as-voice-products to phones-as-computing-products. The low-end disruption is the migration of a large number of less demanding customers from branded phones to unbranded, commodity phones. ... The new market disruption is evidenced by the shift of fortunes to Apple and Samsung and away from every other device maker." Horace Dediu, The phone market in 2012: a tale of two disruptions (May 2012)
"Apple is the most valuable company in technology (and indeed in the world) because it integrates hardware, software and services. It’s the first, and only, company to do all these three well in service of jobs that the vast majority of consumers want done." Horace Dediu, Which is best: hardware, software or services? (May 2012)


Disney

Back in 2006, people like Hagel thought that Steve Jobs didn't understand platforms. Maybe he didn't then, but he certainly caught up later. 

eBay


Elsevier


Nike


Nokia


Walmart


and finally Google

Steve Yegge compares Google with Amazon: Google has a lot of things in its favour, but its platform strategy is not one of them. See my comment Google as a Platform (NOT) (Oct 2011) 
  • "Page and his management team have mandated that all Googlers focus on seven business areas, and that they don’t look to expand Google’s reach beyond these core initiatives." Farhad Manjoo, Google's Grand Plan (Slate, March 2012)
  • "Page's emphasis on streamlining Google's product line has made the company's thousands of employees focused on how -- and if -- a tool adequately fulfills users' needs." Bianca Bosker, Google's Future (Huffington Post, March 2012)
 That's not a platform strategy, that's a traditional product portfolio strategy!

Tuesday, May 01, 2012

Business as a Platform - Amazon

#bizarch Excellent article by @haydn1701 on Why Amazon Succeeds (Forbes, 29 April 2012) via @davegray and @ruthmalan.

Haydn Shaunessy points out the following features of Amazon's strategy.


Understanding ecosystem

Shaunessy starts by defining the notion of ecosystem fairly narrowly, and links it to the information market. "Bezos is not as great as Jobs at playing the information market but he is good." This may well be true, but it misses the point. Jeff Bezos's understanding of ecosystem has always been much more profound than that of any of his peers, and Amazon's ecosystem is a lot broader than zen marketing.

One way of seeing it is that Jobs coerced people to do things that were in his (Apple's) interests, whereas Bezos gives them opportunities to do things in their own interest, from which he benefits in more subtle but perhaps more sustainable ways. But of course there's always another story.

Radical adjacency

The ability to go beyond normal business practice and to seize opportunity in widely adjacent markets.

Business-as-a-platform

Shaunessy identifies a number of characteristics
  • Tearing business away from "the straight jacket of old management theory" - "the outdated idea of core competency" 
  • Providing a new way to scale business
  • Bringing (shared) value to all parties

Technical enablers

Shaunessy identifies two in particular
  • Universal connectors - not merely technical protocols but contractual protocols that radically reduce the transaction costs of using the platform 
  • Cloud computing

Organizational enablers

Shaunessy talks about ability to attract and retain very talented, imaginative resources. I would also add the ability to build these into an effective and innovative company - what I call Organizational Intelligence.


Strategic Outcome

This combination of strategies has allowed Amazon and Apple to develop what Shaunessy calls complex options portfolios. He notes that "the ecosystem is full of businesses that can jump quickly into new opportunity" and argues that this yields the true meaning of shared value.

Friday, October 14, 2011

Google as a Platform (not)

Google vs Amazon (again). @davidsprott reckons Steve Yegge's rant is spot on. Steve Yegge is a software engineer who used to work for Amazon and now works for Google, despite the supposedly accidental publication of a long and opinionated rant (his words) complaining that

'[what] Google doesn't do well is Platforms. We don't understand platforms. We don't "get" platforms.'

(For more context, see Steve Yegge's second thoughts on Google+).

Waddya mean, Google doesn't get platforms? Surely Google is a major player in platform, especially in the so-called Cloud? Dion Hinchcliffe sounded fairly convinced when he was Comparing Amazon's and Google's Platform-as-a-Service (PaaS) Offerings back in April 2008.

"Amazon and Google have strategically built up an extensive set of services over the last few years and have made some very interesting assumptions that will determine who their customers are (consumers, startups, enterprises) and what type of business models can sit on top of them (advertising, subscriptions, cheapest source of outsourced computing resources). ... Google and Amazon have emerged to be the leaders in this space while Microsoft, IBM, and especially Oracle and SAP are either well behind or have unclear plans to enter the PaaS space. Both of these companies formed their DNA around the world of the Web and deeply understand how to leverage the enormous strengths of the Web platform."

So what went wrong? This guy (Yegge) sure knows one thing, says @pardhas, building platforms is not just collecting your products on one plate. For Yegge, platforms is about eating your own dogfood. Not just Amazon, but also Facebook - hey, even Microsoft understands platforms better than Google.

But there is something missing from Steve Yegge's account. He sees the (lack of) platform from an engineering perspective, but what he doesn't talk about is the enterprise/ecosystem perspective.

@davidsprott's tweet ends with the formula "SOA + platforms = competitive advantage".  David and I have written a great deal about ecosystem SOA and ecosystem architecture, and we have long credited Jeff Bezos of Amazon as someone who "gets" ecosystem.

Among other things, "getting ecosystem" means understanding the variety of ways in which the social complexity of collaborations create value for the customer, and therefore how, from the perspective of the supplier, platform architectures can capture indirect value. See Philip Boxer's presentation on supporting social complexity in collaborative enterprises, as well as my presentation on Next Generation Enterprise Architecture, both from the recent Unicom EA Forum in London.

As I pointed out in my recent VPEC-T analysis of Google, Google is adopting a positional strategy - capturing some territory and defending it against its competitors. Amazon and Apple have shifted towards open source competition on their platforms (relational strategy) while Google is still closed-source.

In his post on Tomorrow's Networked Economy, @JDeragon praises Google+ for becoming an integrated portal. Er, wasn't that AOL's strategy? And Yahoo's for that matter? Maybe Google has greater ability to execute this strategy than they did, but it still looks more like yesterday's networked economy. Have you read Kevin Kelly's book?



For Apple's shift from product to platform, see my post on Disney, Pixar, Apple and Jobs from February 2006.

For the shift from positional stategy to relational strategy, see Philip Boxer and Bernie Cohen, Triply Articulated Modelling of the Anticipatory Enterprise and Philip Boxer, Architectures that integrate  differentiated behaviours.

For more on Ecosystem SOA and Ecosystem Architecture, please browse the Ecosystem category on this blog. Here are some further links.

Jeff Bezos Letter to Shareholders (via Geekwire) (April 2011)
Bob Ellinger, Enterprise SOA vs Ecosystem SOA (April 2011)
Vaughan Merlyn, From Enterprise Architecture to Ecosystem Architecture (July 2008)
David Sprott, Introducing Smart Ecosystem Architecture (October 2009)

Monday, July 23, 2007

Scale and Self-Organization

Werner Vogels, CTO of Amazon, knows a thing or two about implementing large-scale distributed SOA. So it's worth taking seriously when he tells us that

"For any truly scalable agile environment, self-organization is essential."

In his post Reading References, he goes on to recommend some papers and books on scalability and self-organization.
My own favourite book on self-organization remains Kevin Kelly's book Out of Control, now available online on KK's website. See also the entry on Self-Organization in Principia Cybernetica.

If we accept that self-organization can be effective for addressing some classes of complex problem, next step is to develop practical methods for engineering self-organizing systems. There are some promising research projects in this area, and there's a conference in Leibzig in September (SOAS 2007). I probably won't have time to attend the conference myself, but I shall look out for the proceedings. I wonder whether Amazon will be represented?

See also Werner Vogels on Scalability (April 2006)

Tuesday, September 14, 2004

Business Geometry

A business or value chain is composed in a geometric structure. (In the past we have often called this structure an architecture, but this word has lots of different and tangential associations for different people.)

In SOA, we design a business or value chain as a network of services. This is a powerful geometrical pattern. But there may be many possible network geometries satisfying a given business requirement, all of which count as satisfying the principles of SOA. For example: hub/spoke or peer/peer.

Business Stack

Another common geometric pattern for SOA is stratification. A business process is composed of services from a set of lower-level services, presented as a platform. A good example of a business platform is the set of retail services offered by Amazon and eBay. Other service providers have built further retail/logistical services on top of the Amazon/eBay platforms.

Each platform is in turn built upon even lower services. At the lower levels, there may be collections of IT-based services, known as ESB. There may also be sociotechnical service platforms, such as call centres.

Thus we have a stratified geometry, in which a person tackling a problem at a given level is presented with a collection of available services, formed into a virtual platform. This can be thought of as a business stack, with one plaform stacked on top of another. Some of the lower layers of the stack may appear to be purely technical services; however a more complete picture should reveal the existence of an IT organization maintaining the platform, in other words a human platform of administrators and programmers supporting the technical platform.

Variable Geometry, Variable Granularity

While the SOA principles may provide some geometrical guidance, and mandate certain geometrical patterns, there is still a design job to determine the geometry. This design job may be easy when the requirement is trivial, but gets harder as the complexity increases.

In many situations, the demand side has more variation than a human designer (or design team) can accommodate. (We characterize this as an asymmetry of demand, which calls for a process of asymmetric design.) We need to start thinking about variable geometry solutions, where the geometry itself can be adapted on-demand.

For example, in the past we have assumed that granularity has to be fixed at design time. But we can conceive of a web service platform that detects patterns of demand-side composition, defines new composite services automatically, describes and publishes these new services in real time, and notifies likely users of the new service, complete with an incentive to switch. We can conceive of a web service platform that analyses the message content of a certain service, and produces a substitute service with a smaller footprint that would satisfy most of the uses in a more elegant way.

Value Landscape

I use the term value landscape to refer to the distribution of cost, benefit and risk across a complex market ecosystem, such as the insurance industry. Technology (including SOA) influences business geometry, not least because it affects transaction costs. The shape of the value landscape changes (has already started to change) as the result of B2B and B2C and BPO. Companies that once occupied safe market positions (the high ground) may find their commercial advantage slipping into the sea, or they may find themselves cut off from their natural markets or supply chains.

See Microsoft Blog Insurance Value Chain

Let's suppose an insurance company has the following strategic aims:
  1. Profitability, short-term viability. To deliver the maximum service value as cost-effectively as possible, using available input services and technologies as efficiently as possible, with minimum costs/risks of change.
  2. Adaptability, medium-term viability. To understand and respond to changing demand for insurance services, and to trends in cost and risk, both internally and across the industry. To develop and deploy new services to exploit new business opportunities and avoid emerging business threats.
  3. Survival, long-term viability. Making sure the core business proposition remains valid, and doesn't get eroded by more agile players. Taking strategic action in relation to structural changes in the insurance industry.
If we are doing business geometry for an insurance company, we need to think about the insurance industry as an ecosystem. We need an AS-IS model of the present ecosystem (largely based on pre-SOA technologies) and a TO-BE model of an idealized ecosystem (based on SOA). We can expect the pre-SOA ecosystem to evolve into some form of SOA ecosystem, although we may not have much idea which of the possible changes is going to happen first. To satisfy all three strategic aims, an insurance company needs to exploit the pre-SOA ecosystem, and prepare for the SOA ecosystem.

Note that this situation may force the insurance company to implement a variable geometry, both in the organizational platform and in the IT platform. Otherwise, it will either have to operate suboptimally for an extended period, or incur significant organization costs and IT costs every time the industry takes another step towards SOA.

Sunday, August 01, 2004

Amazon and Ebay

Amazon, eBay and PayPal are creating platforms for eCommerce.
At CBDI Forum, we have been tracking these developments from time to time. See news commentaries: July 2004, February 2004, February 2004, July 2003. See also Jeff Bezos and Ecosystem Thinking.


Jeffrey McManus of eBay claimed recently that 'we make inefficient markets efficient'. (Source: Aaron Johnson blog.)

In his blog, Jonathan Schwartz (Sun Microsystems) talks about selling computers on eBay, as a web services experiment. Schwartz expects this experiment to provide "unvarnished" pricing information, as well as providing practical experience with a service-oriented supply chain. This seems to support the McManus claim.

However, efficiency often conflicts with adaptability. How wise is it for Sun and other firms to link to the eBay platform? What is the likely ecosystem effect of allowing eCommerce services to be defined and controlled by a small number of like-minded firms?

I've just had a look at the eBay technical documentation. Developers must follow detailed procedures for design, testing and certification, before they are permitted to plug into the live eBay environment. Rightly so no doubt, but this raises questions about service life cycle management and technical change.

In response to the possible difficulties of raw eBay, a number of service providers are now offering DropOff services that provide a simple eBay front-end. These include AuctionDrop, AuctionWagon, QuikDrop and Picture It Sold! and 1StopAuctions. The last of these makes strong and explicit claims about the difficulty of using eBay. (Success here means not just completing the transaction but getting a good price.)
"To successfully sell an item on eBay requires marketing and selling strategies unique to eBay – and learning those strategies can take years to master. 1Stopauctions.com has that unique knowledge to successfully sell your items on eBay. We have been buying and selling on eBay since 1998. Over the years we have found the secrets of launching successful listings to obtain the highest possible price ... and so on ..."
For me, the appearance of these secondary service providers simply confirms that the big issue is business hegemony (power) - the value ladder now belongs to Amazon and eBay, they control the terms on which everyone else is trading.


Lawrence Wilkes, Amazon and eBay Web Services (CBDI Journal, October 2004)

Thursday, February 26, 2004

Jeff Bezos and Ecosystem Thinking

Lots of commentators and blogs have picked up on a recent Business Week story about Amazon (December 22, 2003).

But Amazon has been working towards this for a long time indeed. When I searched the web for Bezos and ecosystem, the first page of hits included a story from June 2000, in which a senior manager at HP acknowledged that he had gotten ecosystem thinking from talking to Jeff Bezos.

Recent developments by Amazon and eBay (as described by David Sprott and Lawrence Wilkes at the CBDi Forum) establish a business service stack for the eCommerce sector.

But this isn't just a clever tactical move. It follows logically from a strategic direction that Amazon has been pursuing for a considerable time. During the dot-Com boom, there was lots of superficial admiration of Amazon, and lots of companies trying to emulate it. But few of them mastered ecosystem thinking, and few of them survived the downturn.

Later note. The conversation with HP also indicated that Bezos already had The Idea of Showrooming.(See my post from July 2017.)




Alan Deutschman, Inside the mind of Jeff Bezos (Fast Company, 1 August 2004)

Steve Hardy, Guidelines from the Book of Bezos (Creative Generalist, 5 August 2004)

Robert D Hof, Reprogramming Amazon (Business Week, 22 December 2003)

David Jastrow, HP Keynote embraces ecosystem thinking (CRN, 15 June 2000)

Lawrence Wilkes, Amazon and eBay Web Services (CBDI Journal, October 2004)


Related posts: Binary Advice (July 2004), Amazon and Ebay (August 2004), Business as a Platform - Amazon (May 2012), The Idea of Showrooming (July 2017)

For more on ecosystem thinking, see my 2001 book on Component-Based Business. Available from Amazon (of course).


reposted 22 September 2025