There is no cloud, we should talk about your premises.

You are reading this right, there is no such thing as "clouds" or "server-less" in IT. The overuse of those buzzwords is hurting the true definition of what "cloud" means: elasticity and scalability of computers. Everything else is just marketing.

Yes, you can create services that abstract as much as you want the server in your on-premises clusters. That does not make the apps you host server-less. It just really means that you have no clue how your app is deployed, where it is deployed, and how safe your code really is - Ok, maybe the last bit there is a bit extreme, we do have ISO standards that needs to be followed for a company to be a trusted cloud provider, but let that sink in for a moment.

How many times have you asked where your AWS Lambda runs? How many times have you checked if your Azure function runs the most efficient hardware for your runtime? How much CPU and Memory are you truly using for your application? Could this be running into some sort of small on-premises appliance that you own and only have to pay now for the maintenance, power, and hardware?

While it might seem like an unfair comparison - given that you "should not have to worry about your 'Managed' services in the 'Cloud'" - I challenge you to truly think about it. Think about the last time you had to worry about that service you run in Microsoft's, Amazon's or Google's computers. Because that is what it truly means: you are using someone else's computers. You might not be worrying about which CPU or how much memory it is running, but you are definitely worrying about your bill at the end of the month.

Do you understand exactly h0w much it is going to cost you if your apps run forever because you wrote a bug in your app services? Do you know how much overhead you are adding to your services because you are abstracting away in a "server-less" mask? Do you know how much of your service could just run in a small 10 year old mini PC with an i5 CPU and just 4 GB RAM?

Now that you've got your attention, let me tell you a story:

There once was this corporation, built in the .com era. They needed to serve their customers with reliable and fast responsive apps - include web apps when thinking of apps. They fast realized that just running that windows machine in the basement and exposing their apps through IIS would not do anymore, and they needed something more reliable; which led them to purchase a nice little server for them to run their service in a LAMP server.

Business boomed and that machine could no longer ensure they were always available, so they've splurged for a few more machines and needed to better automate what they had with better tooling. That's when they've purchased VMWare and started managing their virtual machines to replicate images and ensure the configurations of what they had were repeatable and reliable. With that out of the way, they could rely more and more on the redundancy of their servers and start applying updates faster to their applications.

Once their applications were working better and faster, they needed to ensure their servers were always kept up-to-date with their dependencies. That's when their team implemented a configuration management tool to check and update their packages and notify whenever something went wrong. Things were getting more complex and abstracted, but more powerful as well. Processes were defined to ensure things would work as intended, and tools were available to simplify one's life while delving into this crazy world. But things worked. They had expertise in-house to keep their services updated and running. They understood how things worked on a deep level. Their investment would live long in their datacentres and their engineers in form of hardware, hard work, scars and learning experiences.

Then, this same corporation saw this magical thing getting traction: "The Cloud". It seemed magical. No servers to manage, no downtime to worry, no engineers that needed sleep. All needed was to write your code, push it somewhere, and leave it to do its thing. This corporation then decided it was the best option for them and pressed forward to do the move. Learned everything they could, chose a partner "Cloud Provider" and started moving their services.

The path was treacherous, full of surprises. Moving to the cloud was proving to be more complicated than anticipated. Virtual machines were not as simple to spin up and down with their own images as they had expected. Server-less services came with so many caveats that their services needed to be re-written in new ways. Secrets that once were hidden away in obscurity were now being thrown around without much plan.

Here is the thing about "Cloud". It's a shared environment with the entire world. Most services nowadays offer a way or another to peer your network with some sort of gateway or dedicated route, but even then it is not so simple. Some services require for you to connect to the backbone of "public" services that rely solely upon authentication; which can be fine if you had something similar on-premises, but completely different and daunting if you were expecting your services to be behind your network.

The "conservative" 2 year migration process was barely halfway through at the 3 year mark, making the turnover and shut-down of the on-premises hardware more difficult. The now re-write of the new applications to use "Cloud-Native" tech needed to be rushed to get it over the fence or just "lift-and-shifted" into VMs that were similar to their previous environment. Alas, they were "in the Clouds".

Now they had a partner that would take care of their platform abstractions and the company could focus on what truly mattered: their business logic. That was until they had to account for the new policies, security postures, and new adventures to figure out how to properly deliver and make sure their apps were available to their customers. They were way too similar to what they used to have in their on-premises environments: still relying on Load Balancers, firewalls, Virtual Machines and upgrading their apps using some of their homegrown software for configuration management still. They figured it could be an opportunity to adopt the latest and greatest tools to solve their issues:

Terraform for their infrastructure management, using Terraform Cloud for ease of management of their workspaces. Azure Entra ID for their identity management and permissions management. Ansible for managing their VM configuration and things started to feel similar to what they had.

Now they needed to apply policies, ensure all permissions were set as required. Properly tag resources to ensure all the accounting would work as expected. But while they were at it, something weird started to happen. The benefits of the APIs from the platform provided to them seemed to be quite similar to their previously implemented solutions, but it was harder to scale and control. Cost was much higher than expected to ensure the services were geographically replicated and private; something that was an afterthought when everything was part of your own infrastructure.

The engineers that were not necessary anymore due to the migration to the Cloud environment were now scarce due to the organization changes, and it was harder to troubleshoot what was going on due to the lack of control of the back-end.

Over time engineers had to be hired or trained to be prepared to the new technologies and to ensure things would be working as expected. But even then, server-less somehow was not working as fast or as cheap as promised. Not because it could not be, but because it was expensive to make it work as necessary to cover the business needs of a corporation with the complexities they had. To ensure not all engineers or developers had to deal with that, specialized modules in terraform, CLI, Ansible and even a new portal to implement the new logic necessary to handle everything.

If all of this sounds familiar, do not panic. In well over 15 years of experience: this is the norm.

For the sake of simplicity, let's stop the story time there - if we can call all of that remotely simple.

If you are familiar with any corporation that runs their own IT, most pieces of this should be quite familiar. But you should also be able to see the similarities of the flow. The processes. The Platforms. This is where you should truly focus on.

Regardless where you run your environments, regardless of how you process your data. You are still running processes, and those still running on computers. Because you are running on computers and you have your processes to support, you must understand where your needs truly lie to implement your business logic. Once you understand that, it's a matter of creating the organizational structure and define your process-based structure. In the same way we are used to creating APIs and defining contracts between applications, we should define contracts between your teams to facilitate interaction.

And so I come back to tell you: There is no "Cloud", and you should not take cloud or any other platforms as the true solution for your organization. Those are just tools that can help facilitate the creation of those contracts. By no means you should offload the creation of your contracts to those tools. You should think about your platform and what it means to support it. There is no getting around it.

There are no 'silver bullets'. You can use cloud, you can use on-premises, you can use paper and pen. Just ensure your processes make sense and deliver a platform that works for your organization. If there is one thing y0u must take out of all of this is: do not let your platform be defined by the tool. Shape the tools to your platform.

At FancyWhale, we make our business by ensuring our customers can have their own platforms. Be that through Kubernetes, Azure, AWS, Virtual Machines, RaspiberryPIs, whatever it is that makes sense to your organization.