Continuing from my post on the , I thought I’d riff off Marc Andreessen’s famous statement and explain one possible future scenario where all your software belongs to Amazon. There are counter plays to what I’m going to discuss but these would make the post too long and being honest, I’m quite content to watch the executives of software giants flap around like headless chickens whilst their industry disappears. It won’t happen overnight, this process will take about 10–15 years but by the time people realise it’s happening (if it does) then it’s too late. It’s a type of economic change known as punctuated equilibrium but … that’s getting too technical, let us keep it simple. fuss about serverless I’m going to use a map to explain what is going to happen. I’ve quickly cooked one up for a trading system, based upon nothing much at all. It’s however a starting point. Now, I’m going to assume we’re going to build this trading system in AWS Lambda which means all the software components of the map (trading engine, stock portfolio, risk system, recommendation engine and mood system) are built from functions (which may call many other functions) in Lambda. For why you might want to think about doing this, go read the post on the . fuss about serverless Ok, our customer in the above map has a desire to make profitable trades (I told you I cooked it up in five minutes and of course, you can make a better map). Making profitable trades requires us to be able to trade and to know what trades are going to be profitable (you wish!) Now, the to our success, the system which differentiates us from everyone else is our recommendation engine. It takes a feed of trades, and uses a magical mood system to determine what’s worthwhile and profiles this with our risk system. Before you go then let me remind you — this is an example. secret “mood system, sounds like gibberish” In any case, back in 2005 when we had Zimki (the earliest serverless, functional billing environment), I did actually build a mood system in a day or so. It scraped information from flickr and other sources to generate a mood for the world. It was daft, part of an evil plan I had that involved an animatronic monkey and concept art …. let’s not go there. So, we’ve got our hypothetical trading system to which I’ve also added some metrics. I’m now going to turn this map into a flow and add the metrics. From below, the trade feed creates the list of trades and is governed by the number (#) of trades. The trade feed is a Lambda function and so there is a cost to it. Each trade is run through the risk, mood and finally recommendation system — each creating their own functional costs. The recommendation system provides a list of recommended trades (#recommended) which impacts the trading engine and the stock portfolio system. Yes, this is a very basic setup. You can argue with the map / flow diagram as much as you wish. Certainly in most banks then almost every component is treated as something relatively novel as if no other bank manages risks, trading, makes recommendations etc. In fact, from experience they usually have huge numbers of custom built systems all doing the same thing i.e. a single bank can often have a few hundred custom built risk management systems. But let us pretend we’re working for some relatively sane bank. You can see from the above we have a cost for each of the systems such as trade feed = #trades x average cost of the trade feed lambda function. Most banks have no idea what individual functions within their organisation cost, they have no clear way to calculate this but let’s ignore that (along with the duplication and bias i.e. custom building what’s a commodity). We’re sane remember! Now let us suppose that AWS launch some form of Lambda market place i.e. you can create a Lambda function, add it to the API gateway and sell it through the market place. PS I think you’ll find they’ve just done that — Amazon API gateway integrates with API marketplace and Lambda integrates with API gateway. I haven’t had a chance to play but it’ll become clear pretty soon. So, you’re thinking about building the above trading system and you notice that someone else is providing an API which provides a risk system (or maybe components of it). Hmmm, I could use that instead of writing it. Cue gnashing of teeth. You’ll probably get a memo from security about the dangers of using third party code they can’t check and extolling the benefits of open source. The memo will probably come as a pdf sent via office 365 mail without a trace of irony. What they mean is they don’t trust the source. Roll back to 2006 and the various “I wouldn’t trust it with production” that applied to AWS EC2. The fact is, trusted sources will appear over time. For startups, you’ll be more adventurous which is also why you’ll probably end up owning those other companies. The chances are that huge amounts of your trading system (if broken down and you spent more than five minutes on it) could end up being provided as Lambda functions from third parties. I’ve drawn this in the map. Along with stitching it altogether you will probably build something that is genuinely different e.g. the mood system. Of course, some of your development team won’t be happy with building the mood system and combining component services from third parties (despite all the talk about micro services). They will argue they can do a better job of making a trading engine. The beauty of functional billing is you can say — “prove it!”. You have the costs per function call. By the way, if they can do a better job then you probably want to be selling it on the marketplace and making sure you’re paying them enough that they don’t leave. In practice, people get away with the old line of we can do a better job because no-one can actually measure it. Most don’t have cost per function or they think that their function is free because it’s running on their own hardware (p.s. that hardware isn’t really free, neither is the power, the building cost, the platform it’s installed on etc). Any Amazon marketplace around such functions will be a two factor market (consumers and providers) and will have strong network effects. The more companies start consuming the functions, the more providers will want to build functions and the more consumers this will attract. Pretty soon, rather than working for a company where you’re writing your thirtieth consumer authentication service (to go along with the other 29 scattered throughout the place) and copying and pasting the same code or at least what you think is the same code then in this future you’ll just be using a service from the marketplace. That marketplace is your service repository! If you were under the impression that companies used to waste lots of hardware with servers sitting around doing almost nothing (loads of 10% etc) before cloud, just wait until you lift the lid of software development. Ask any software engineer and they’ll find you examples of huge amounts of duplication in a single organisation. By huge, be prepared for 100+ duplication as being a “good” day in any company of decent size. Oh, and before anyone in business starts bashing up software engineers … don’t get me started on the utter lack of strategy, miserable understanding of the landscape, leadership based upon gut feel and meme copying the latest trend in the HBR (Harvard Business Review) that goes on. The future of software development will be lots of Lambda functions consumed from a marketplace, stitched together with some new capability. Waste will be reduced, bias (i.e. custom building something which is already well crafted) will start to disappear and we get all that other good “financial development” stuff the . Hurrah! last post covered However, we’ve barely started yet. This gets a whole lot more interesting. To explain why, I have to introduce you to an old favourite (a decade old ecosystem model) known as innovate — leverage — commoditise. The model is fairly simple, you start off with something novel and new (which is why you need pioneers), as it evolves then you leverage any pattern that is discovered to produce a useful product or library routine (for this you need a different culture, a group of settlers) and eventually the thing will evolve becoming more industrialised (which requires a focus on commoditisation and a different culture known as town planning). However, genesis begets evolution and evolution begets genesis. Your more evolved components enable rapid development of new things on top of them. The more evolved the subsystem, the faster the speed of developing new things. I’ve shown this in the map below. This is one of about thirty common economic patterns, so if someone from business has been taunting you as a software engineer just ask them to name more than five and politely remind them that IT and the business are not different things. Anyway, you can play this game within a company using three different cultures (known as attitudes) and mimic evolution. It’s extremely useful for not only encouraging development of the new but encouraging efficiency whilst not creating two factions at war and a host of other problems. However, it has a serious limitation which is your company only has a limited number of people. What you want to do, is to get everyone else in the world acting as your pioneers. This is actually very simple, you provide the industrialised components as public APIs. This is best explained in a more circular form, using the trading system. Your town planners provide a utility coding platform. A whole bunch of other people and companies outside your organisation (i.e. your ecosystem) start using this to build all sorts of things. You provide a marketplace that enables some of them to sell risk system / trading engines and all manner of functions to others. Within this entire ecosystem, there will also be people building genuinely new and novel stuff. Now, everything consumes your platform and so you also get realtime consumption information from every angle. As I’ve mentioned above, you’ve got a two factor market with all those nice network effects causing the ecosystem to grow rapidly. The bigger the ecosystem then the more economies of scale you get, the more new stuff being built (i.e. others pioneering) and the more consumption data you get from its use. The trick is, you use the consumption data to find interesting patterns (i.e. your own settlers leverage all the consumption data to find what consumers really want) and you use this to build new industrialised components. These components make the entire system even more attractive. By leveraging consumption data you’re giving the ecosystem what it wants, you’ve got increasing efficiencies of scale and your entire ecosystem is also acting as your free research and development department or in my language . The more industrialised components you provide and the higher up the stack you go (EC2, S3, Lambda etc) then the more people you attract. A double whammy of two factor market and ILC — it’s a killer! “a future sensing engine” So when I look at my trading system, then as time goes on then not only will more and more of the components be provided by the AWS marketplace but if AWS is playing an ILC game then many functions will become industrialised components provided by AWS itself. The marketplace will just be future potential AWS components and on top of this, all the novel exciting stuff (which is directly giving early warning to AWS through consumption data) is just future market opportunity. I’ve shown an example of this in the map below. The benefits to consumers i.e. those trying to build stuff will be overwhelming in terms of speed, efficiency and agility. Amazon will itself continue to accelerate in efficiency, customer focus and apparent innovation with the size of the ecosystem which itself will continue to grow rapidly despite the occasional gnashing of teeth as they chew up bits of the software industry. Have no doubt, you can use this model to chew up the entire software industry (or the duplicated mess of bias which calls itself a software industry) and push people to providing either components sold through the marketplace or building actually novel stuff. Now most executives especially in the software industry will react just as they did with cloud in 2006/07 by trotting out the usual layers of inertia to this idea. It’ll never happen! This is not how software works! It’s a relationship business! Security! Prior investment! Our business model is successful! Good luck with that. There are ways to counter this play (there’s a path that involves cloud foundry assuming it moves up the stack and others play well), there are niches to exploit but I don’t want to spoil my own fun and this is going too be so much fun. Also, I’ve got an old bet (2012) for a on Amazon being the first $1 trillion market cap company. cup of tea Anyway, the upshot is … welcome to game of the next decade or so. This will make IaaS look like small fry but don’t worry, there are even bigger games to come. Will AWS win this? Maybe. But rest assured, you’re in for the fight of your life in this space. However, as I said at the beginning — most companies will ignore it until the battle is almost over. At which point Larry will probably pop up and claim that Oracle will own it. It won’t. If you don’t know what a map is — and can . start with chapter 1 I suggest reading some basics of strategy — — This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley, a researcher for the Leading Edge Forum . Originally published at blog.gardeviance.org .

Flow

Amazon

BUNCH

Oracle

Routine

Trace

Thank you Amazon. Boom! Everything in business will change.

Why the Fuss About Serverless?

Too Long; Didn't Read

Amazon is eating the software (which is eating the world)

Amazon is eating the software (which is eating the world)

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A set of principles does not make a strategy

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 1)

A set of principles does not make a strategy

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 1)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps