Cloud is dead. Long live the cloud!

Posted on By Mark Wilson

I’ve seen a few articles recently that talking about how organisations are moving workloads out of the cloud and back to their own datacentres. Sometimes they are little more than clickbait. But there is a really important discussion to be had here. So I thought I’d lift the lid on this topic and have a look at what I think is really going on.

The promise of the cloud

Cloud is great for many things. On-demand access to vast amounts of computing and storage resource, on a pay as you go basis. Brilliant. No need to invest in capital. Just pay for what you use.

Except that’s not how all businesses work. At least not for all application workloads and data sets.

Possibly the most famous of these “we found cloud expensive and moved back on-prem” articles is David Heinemeier Hansson (@DHH)’s why we’re leaving the cloud post for 37 Signals, written in 2022. In that post, DHH says that renting someone else’s computers didn’t work for his business. He describes 37 Signals as a “medium-sized business with stable growth”. But, I’m willing to bet that most of the readers of this post are not running SaaS applications in AWS for a global audience of B2B and B2C customers. Some will be, but most of my clients are not.

In fact, in his video on kicking cloud to the curb [sic], David Linthicum (@DavidLinthicum) flags that SaaS providers will scale in a repeated pattern, whereas enterprise [and SME] workloads scale differently. Cloud still has a place for most organisations. DHH’s follow-up post (the Big Cloud Exit FAQ) is worth a read too. Just remember that most business don’t follow the profile of 37 Signals. And that 37 Signals are still using co-lo facilities (because building new datacentres in 2024 is a very brave move, unless you are a hyperscaler).

But you’re not 37 Signals

In 2024, I would seriously question why anyone is running their own office productivity tools (email, IM, intranet, etc.) on-premises. There are many services that can do this for you on a per-person-per-month basis. And they will have better up-time than you ever did, despite what your former email administrator tells you. Those jokes about “Microsoft 364” whenever there’s a blip in the matrix… how much more did you spend on storage to make sure that you got to even 99.5% availability in your Exchange servers?

But let’s move on past the “low hanging fruit” that can relatively easily be replaced by SaaS. Let’s have a look at all those other applications that actually run your business: the finance system; the case management system; the modern data platform; the reporting and analytics; the years and years of accumulated unstructured file data that no-one knows what is needed and what is not. (“The business”* says “that it’s up to IT to sort out”. IT says “we don’t know what you need”. No-one agrees to the blanket retention policies, just in case that file deleted after 3, 7, 10 years is really important.)

What I’ve seen happen, time and time again, is that almost everything is moved to the cloud. I say almost, because the cloud discovery process often turns up evidence of virtual machines that were created, are no longer used, but are left running. This happens because on-premises infrastructure is seen as “paid for”. There is no cost to leaving things running. Except there is – not just in wasted processor cycles and storage, but in the size of the infrastructure that’s required.

Lifting and shifting without transformation

There are many motivations for cloud migrations but the most common I see is because the datacentre is closing. Maybe it’s the end of an outsource, maybe the site is being sold for redevelopment. But it’s nearly always “we must exit by” a particular date. No time to transform – just transition. We’ll sort it out later. Except “later” never comes. The project to move to the cloud is completed. The team is stood down. The partners are disengaged. “Phase 2” to transform the estate doesn’t have a strong enough business case** and things stay the same.

And then the cloud bills come in. They look a bit steep – especially for IaaS. You’re using more storage than you expected, and those VMs are a little pricey. Some “optimisation” is done to adjust VM sizes. Reserved Instances and other benefits are used to reduce the monthly charge.

Watch the costs rise

A year later, the prices rise. Inflation. Exchange rate variance vs. the $ or the € (depending on your provider’s base currency). That’s OK, it was always expected. Wasn’t it? Another round of “optimisation” happens. A couple of applications are no longer used, replaced by SaaS. Some VMs are switched off.

Rinse and repeat. Rinse and repeat.

A few years on, but you’ve still not transformed. Those resources that you “lifted and shifted” to the cloud are, like the old adage, the same computers running in someone else’s data centre.

The CFO looks at the cloud bill and says “how much?!”. It looks astronomical compared with industry norms. They bring in a new Head of IT and tell them that they have to reduce the cloud spend. “We’ll move back on-premises – where it used to cost less”, they agree.

But it’s still the same systems. With the same technical debt. And now it needs power, and water, and expensive servers and storage and… you see where we are going.

Refactor or modernise

Cloud is not a cycle, like in-source/out-source. It’s a business model. And, like all business models you need to tune the way they are used to make best use of them. N-tier applications running on VMs in IaaS will generally not be cost-effective. Look at how to move the presentation tier to web services. Can the application be re-factored? Could the database run in PaaS too? Often the challenge is ISV support. But it’s 2024. If your vendor doesn’t have native support for Azure or AWS, maybe it’s time to find a different vendor.

And if you’re moving to the cloud to save money, maybe it’s time to look again at your business case.

Use the cloud for innovation, not to save money

Cloud can save money. But only after the workloads are transformed. And only then with continual optimisation. The trick is to make the effort you put into transformation cost less than the savings you return through efficiencies. We can do this on-prem too, but it normally involves capital spend. And that’s another major advantage of the cloud. Once you’re there you can use it to try out new products and services, without a major investment. All that AI innovation that’s happening right now. You can try it out in the cloud, for relatively little effort. Now imagine you needed an investment case for the infrastructure to develop new AI models in house? Cloud gave you agility and flexibility.

And don’t forget about efficiency

To borrow a metaphor from David Linthicum, remember that cloud is a utility. If you leave the heating and lights on at home, you can expect a big bill. It’s no different in the cloud, if you run inefficient infrastructure and applications.

Look at the long-term viability and placement for your services, Make right-sizing decisions based on application workload and datasets. The problem isn’t the cloud – it’s that some people are trying to use it for the wrong things.

* I used this term to be deliberately provocative. I could write a whole separate post on the concept of “the business” vs. “IT”.
** It should have. If properly thought through.

Featured image: author’s own

Do we need another as-a-service to describe functions?

Posted on By Mark Wilson
This content is 7 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week saw quarterly earnings reports for major cloud vendors and this tweet caught my eye:

You see, despite Azure growing by 93%, this suggests that Amazon has the cloud market sewn up. Except I’m not sure they do…

I think it would be interesting to see this separated into infrastructure-, platform- and software-as-a-service (IaaS/PaaS/SaaS). I suggest that would present three very different stories. And I’d expect that Amazon would only really be way out front for IaaS.

My friend and former colleague, Garry Martin (@GarryMartin) questioned the relevance of those “legacy” distinctions but I think they still have value today.

In the early days of what we now recognise as cloud computing, every vendor was applying their own brand of cloud-washing. It still happens today, with vendors claiming to offer IaaS when really they have a hosted service and a traditional delivery model.

Back in 2011, the US National Institute of Standards and Technology (NIST) defined cloud computing, including the service models of IaaS, PaaS and SaaS. Those service models, along with the (also abused) deployment models (public cloud, private cloud, etc.) have served us well but are they really legacy?

I don’t think they are. Six years is a long time in IT, let alone the cloud but I think IaaS, PaaS and SaaS are as relevant today as they were when NIST wrote their definition.

When asked how “serverless” technologies like AWS Lambda, Azure Functions or Google Cloud Functions fit in, I say they’re just PaaS. Done right.

Some people want to add another service model/definition for Function-as-a-Service (FaaS). But why? What value does it add? Functions are just PaaS but we’ve finally evolved to a place where we are moving past the point of caring about what the code runs on and letting the cloud manage that for us. That’s what PaaS has supposed to have been doing for years (after all, should I really need to define a number of instances to run my web application – that all sounds a bit like virtual machines to me…)

To my mind, “serverless” is just the ultimate platform as a service and we really don’t need another service model to describe it.

To quote a haiku from Onsi Fakhouri (@onsijoe):

“Here is my code
Run it in the cloud for me
I don’t care how”

Or, as Simon Wardley (@swardley) “fixed” this Cloud Foundry diagram:

What-as-a-service?

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve written previously about the “cloud stack” of -as-a-service models but I recently saw Microsoft’s Steve Plank (@plankytronixx) give a great description of the differences between on-premise,  infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS).

Of course, this is a Microsoft view of the cloud computing landscape and I’ve had other discussions recently where people have argued the boundaries for IaaS or PaaS and confused things further by adding traditional web hosting services into the mix*.  Even so, I think the Microsoft description is a good starting point and it lines up well with the major cloud services offerings from competitors like Amazon and Google.

Not everyone will be familiar with this so I thought it was worth repeating Steve’s description here:

In an on-premise deployment, the owning organisation is responsible for (and has control over) the entire technology stack.

With infrastructure as a service, the cloud service provider manages the infrastructure elements: network, storage, servers and virtualisation. The consumer of the IaaS service will typically have some control over the configuration (e.g. creation of virtual networks, creating virtual machines and storage) but they are all managed by the cloud service provider.  The consumer does, however, still need to manage everything from the operating system upwards, including applying patches and other software updates.

Platform as a service includes the infrastructure elements, plus operating system, middleware and runtime elements. Consumers provide an application, configuration and data and the cloud service provider will run it, managing all of the IT operations including the creation and removal of resources. The consumer can determine when to scale the application up or out but is not concerned with how those instances are operated.

Software as a service provides a “full-stack” service, delivering application capabilities to the consumer, who only has to be concerned about their data.

Of course, each approach has its advantages and disadvantages:

  • IaaS allows for rapid migrations, as long as the infrastructure being moved to the cloud doesn’t rely on other components that surround it on-premise (even then, there may be opportunities to provide virtual networks and extend the on-premise infrastructure to the cloud). The downside is that many of the management issues persist as a large part of the stack is still managed by the consumer.
  • PaaS allows developers to concentrate on writing and packaging applications, creating a service model and leaving the underlying components to the cloud services provider. The main disadvantage is that the applications are written for a particular platform, so moving an application “between clouds” may require code modification.
  • SaaS can be advantageous because it allows for on-demand subscription-based application use; however consumers need to be sure that their data is not “locked in” and can be migrated to another service if required later.

Some organisations go further – for example, in the White Book of Cloud Adoption, Fujitsu wrote about Data as a Service (DaaS) and Business Process as a Service (BPaaS) – but IaaS, PaaS and SaaS are the commonly used models.  There are also many other considerations around data residency and other issues but they are outside the scope of this post. Hopefully though, it does go some way towards describing clear distinctions between the various -as-a-service models.

* Incidentally, I’d argue that traditional web hosting is not really a cloud service as the application delivery model is only part of the picture. If a web app is just running on a remote server it’s not really conforming with the broadly accepted NIST definition of cloud computing characteristics. There is a fine line though – and many hosting providers only need to make a few changes to their business model to start offering cloud services. I guess that would be an interesting discussion with the likes of Rackspace…