Cloud Native Goals

In our earlier posts in this series we described a Cloud Native Strategy as a way to achieve business goals by taking a particular set of actions:

• using IaaS or PaaS
• a microservice(ish) architecture
• containers
• orchestrators.

Now let’s talk about the most common of those business goals: speed, scale and margin.

The Goals of Speed, Scale & Margin

First of all, let’s define what we mean by these objectives in this context. Right now, the most common desire we’re seeing from businesses is for speed. So that’s where we’ll start.

Speed

In the Cloud Native world we’re defining speed as “Time to Value” or TTV - the elapsed clock time between a valid idea being generated and becoming a product or feature that users can see, use and hopefully pay for. But value doesn’t only mean revenue. For some start-ups, value may be user numbers or votes or it might be conversions from free to paid-for. It’s whatever the business chooses to value. We’ve used the phrase clock time to differentiate between a feature that takes 3 person days to deliver but launches tomorrow and a feature that takes 1 person day but launches in 2 months time. The goal we’re talking about here is how to launch sooner rather than how to minimize engineer hours.

Scale

We all know you can deliver a prototype that supports 100 users far more quickly, easily and cheaply than a fully resilient product supporting 100,000. Launching prototypes that don’t scale well is a sensible approach when you don’t yet know if a product or feature has appeal. There’s no point in over-engineering it. However, the point of launching prototypes is to find a product that will eventually need to support those 100,000 users and many more. When this happens your problem becomes scale - how to support more customers in more locations whilst providing the same or a better level of service. Ideally, we don’t want to have to expensively and time-consumingly rewrite products from scratch to handle success.

Margin

It’s very easy to spend money in the cloud. That’s not always a bad thing. Many start-ups and scale-ups rely on the fact that it’s fast and straightforward to acquire more compute resources just by getting out a credit card. That wasn’t an option a decade ago.

However, the time eventually comes when folk want to stop giving AWS, Microsoft or Google a big chunk of their profits. At that point their problem becomes how to maintain existing speed and service levels whilst significantly cutting operational costs.

What Type of Business Are You?

But before we jump into choosing an objective let’s consider that a goal is no use unless it’s addressing a problem you actually have and that different companies in different stages of their development usually have different problems.

Throughout this blog series we’ll be talking about the kinds of business that choose a Cloud Native strategy. Every business is different but to keep things simple we’re going to generalise to three company types that each represent a different set of problems: the start-up, the scale-up and the enterprise.

The Start-up

A “start-up” in this context is any company that’s experimenting with a business model and trying to find the right combination of product, license, customers and channels. A start-up is a business in an exploratory phase - trying and discarding new features and hopefully growing its user base. Avoiding risky up-front capital expenditure is the first issue, but that’s fairly easily resolved by building in the cloud. Next, speed of iteration becomes their problem, trying various models as rapidly as possible to see what works. Scale and margin are not critical problems yet for a start-up. A start-up doesn’t have to be new. Groups within a larger enterprises may act like start-ups when they’re investigating new products and want to learn quickly.

There’s an implication here that the business is able to experiment with their business model. That’s easy for internet products and much harder for hardware or on premise products. For the “speed” aspect of cloud native, we are primarily describing benefits available to companies selling software they can update at will. If you can’t update your end product, continuous integration doesn’t buy you as much although it can still be of use.

The Scale-up

A scale-up is a business that needs to grow fast and have its systems grow alongside it. They have to support more users in more geographic regions on more devices. Suddenly their problem is scale. They want size, resilience and response times. Scale is not just about how many users you can support. You might be able to handle 100X users if you accept falling over a lot but I wouldn’t call that proper scaling. Similarly, if you scale but your system becomes terribly slow that isn’t successful scaling either. A scale-up wants more users, with the same or better SLA and response times and doesn’t want to massively increase the size of their operations and support teams to achieve it.

The Enterprise

Finally, we have the grown-up business - the enterprise. This company may have one or many mature products at scale. They will still be wrestling with speed and scale but margin is also now a concern: how to grow their customer base for existing products while remaining profitable. They no longer want to move quickly or scale by just throwing money at the problem. They are worried about their overall hosting bills and their cost per user. Being big, resilient and fast is no longer enough. They also want to be cost effective.

Where to start?

It’s a good idea to pursue any wide-ranging objective like speed, scale or margin in small steps with clear wins. For example, pursue faster feature delivery for one product first. Then, when you are happy with your progress and delivery, apply what you’ve learned to other products.

It’s a dangerous idea to pursue multiple objectives of Cloud Native simultaneously. It’s too hard. Every Cloud Native journey is different and challenging, it requires focus and commitment. Don’t fight a war on more than one front.

Your objectives don’t have to be extreme. Company A might be happy to decrease their deployment time from 3 months to 3 days. For Company B, their objective will only be achieved when the deployment time is 3 hours or even 3 minutes. Neither Company A or Company B is wrong - as long as they’ve chosen the right target for their own business. When it comes to "define your goal" the operative word is “your”.

So, if you're searching for product fit you are in “start-up” mode and are probably most interested in speed of iteration and feature velocity. If you have a product that needs to support many more users you may be in “scale-up” mode and you’re interested in handling more requests from new locations whilst maintaining availability and response times. Finally if you are now looking to maximize your profitability you are in “enterprise” mode and you’re interested in cutting your hosting and operational costs without losing any of the speed and scalability benefits you’ve already accrued.

OK, that all sounds reasonable! In the next post we are going to start looking at the tools we can use to get there.

Read more about our work in The Cloud Native Attitude.

Image by Scott Lynch [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons.