Wednesday, November 22, 2017
   
Text Size

Amazon EC2 squeezing the profits from SaaS applications?

You need to build a reliable SaaS application from a portfolio of unreliable platform services; the price of which you cannot control. To survive you must ensure you do not lock your application workload into a single utility provider. A workload that you can divide and easily move from one utility to another gives you the believable threat; which you need to build negotiating power with your CPU service providers.

As an SaaS ISV you will not build your own data centre; that most basic of computing services–CPU cycles–will come from utility providers. Amazon’s EC2 cloud computing platform is the current market leader. Microsoft is coming soon; Google and IBM will most likely follow.

Relying on any one CPU service provider, no matter who it is, is a bad idea. There is a real risk that what could turn out to be a monopoly provider will lock you in. Running your SaaS applications will be a major part of your running costs. If your CPU service provider can lock you into their service then there is a high chance prices will rise.

You will have limited pricing power so it will be difficult to pass provider’s price increases on to your own customers; this will squeeze your margins and profits. There is a risk you have a successful SaaS application for your vertical niche, but one you cannot afford to run profitably!

If you allow your CPU utility to lock you in; the future profitability of your business could be in serious doubt.

Utility providers will never be 100% reliable

If your CPU utility is up and running, but your user cannot reach it across the network, then to them your application is down; the technical reason does not matter to them at all. The uptime of your CPU service provider can never fully compensate for everything that could go wrong. You need to incorporate this reality into your business model.

  • Availability Does Matter. Early adopters might put up with beta downtime; the early majority will not. Exploit system availability as a competitive differentiator and build service portability into your core architecture.
  • Unreliability is Guaranteed. CPU services come and go: networking issues, unplanned downtime, even squirrels! There is always something to go wrong, so expect the unexpected and do not rely on any one service always being available.
  • Spread Your Workload. You cannot rely 100% on any one CPU utility. Spread your workload across two or more providers to increase stability and availability. You can better react to unexpected events; even to moving processing from one country to another to avoid unwarranted intrusions.

Build your negotiating power

You will always be a small fish in the big pond of utility customers. As you become more successful, and so need more capacity, you risk that your utility will put you under pricing pressure. You must build your negotiating power by being able to move workloads. If not, you risk losing your margins and a squeeze on your profits.

  • Your Utilities Are Not Free. You want to control any ads that appear in your application; you do not want to have to display ads for who-knows-what from your utility providers. Plan to pay real cash for your CPU services. Effectively managing that cash cost will be a major part of your future business.
  • Create a Believable Threat. As you become more dependent, some utilities may seek to increase your prices. Your only real threat is the ease of moving some or all of your workload with little or no extra effort.
  • Protect Your Margins. Relying on a single utility risks having any profit sucked out of your business through predatory pricing. Plan from day one to be able to move; and show that you mean it by never allowing yourself to rely on a single CPU utility.

Exploit arbitrage opportunities

New utility players will introduce new business models to drive down costs. To take financial advantage of these market developments you must be able to shift your workload easily. Intelligently exploiting future price and service differentials between providers can be a major contributor to your success.

  • Exploit New Players. While Amazon EC2 is the current leader, Microsoft, Google and others are coming soon. You can profit from these changes and drive down costs as new offers become available–but only if you can actually move some of your workload to those new players.
  • Find Off-peak Tariffs. Vertical application demand varies a lot by hour and day. You can exploit this by running some of your workload at CPU utilities in different time zones. Utilities will create off-peak tariffs to keep the level of use high enough to justify their investment.
  • Plan For Agile Sourcing. CPU services will become a significant and growing running expense of your SaaS business. Plan to be eventually able to move slices of your workload between your utilities in real time. Finding the right blend of price, performance and availability will be a core business skill for the future.

Build operating skills

It does not help to have a great SaaS application if you cannot run if profitably! Running on-premise products was not your problem–with SaaS it is. You must invest in building the new operating skills you will need to source services cost-effectively. You will then be able to exploit the utility market as it grows and develops.

  • Build New Operating Skills. Running an application cost-effectively is different from developing it. You must invest time and money to build the operating excellence that you will need to run your application. There are tools that will help, but knowing what you are doing will make all the difference.
  • Decouple Development and Operations. Your developers build the application to consume services; operations must be responsible for sourcing them from your utility providers. Be fanatical about keeping this clear separation of roles.
  • Start as You Mean To Go On. Relying on only one CPU service during start-up and then hoping to add others when necessary will be expensive. It is also likely to fail–provider assumptions have already contaminated your application. Your only chance is to force yourself to work with at least two utilities from day one. It sounds like more work but this is an investment you must make to protect your future.

Having more than one CPU service provider sounds like a good idea, but how sensible is this in the real world?

PaaS on Twitter

Search