If you have been following my blog post in the past several years, you probably have noticed that I'm a huge advocate of the public cloud.
The tech world is evolving, and every couple of years, it seems that everybody is trying to chase the latest technology hype.
In this blog post, I will try to share some history from the past decade, with my personal opinions about technology trends.
The cloud era
To be clear, the world of IT did not begin with the public cloud.
For many years, organizations used to build their own data centers, purchased physical hardware (with around 5 years of warranty), switched to virtualization (mostly by VMWare in the early 2000s, followed by Microsoft trying to compete, not very successful with their Hyper-V technology), and later on, organizations began experimenting with public cloud services.
AWS introduced its first services back in 2006 (in GA). GCP introduced its first services in 2008 (in GA), and Microsoft introduced its first services, under their previous name Windows Azure and now Microsoft Azure, in 2010 (in GA).
Some personal disclaimer – I was introduced to the public cloud several years later (by the end of 2015). Back then, I could not understand the whole rush around the cloud – to me, it looked like an evolution of the on-prem virtualization, but as a managed service. It took me around a year to learn more about what it actually means the public cloud, and how it is much more than "somebody else's data center"…
At the beginning of the cloud era (sometimes around 2010), the U.S. Federal government presented the term "Cloud First", and for many years later, organizations all around the world mistakenly considered it as "Cloud is the only alternative". It was never meant to have everything migrated to the public cloud – it only meant that if organization is currently considering where to deploy/develop the next workload, or should we consider SaaS over on-prem application, we should consider all alternatives, and only if the public cloud is the better option (in terms of cost, maintainability, latency, regulatory, etc.), choose the public cloud alternative.
In the first couple of years of the public cloud, we were able to consume IaaS services, similar to what we had on-prem (such as compute, network, storage, database), and many organizations could see much of a difference between the public cloud and any typical hosting provider (again, mostly IaaS, and some PaaS).
The cloud providers were not mature enough, not enterprise-ready, still suffered from outages, did not have global presence (i.e., data residency, localization, etc.), and their support teams (professional services, solution architects, engineers, etc.) were still learning how to provide adequate services to their customers (some are still learning till today…)
As with any new technology, organizations rushed into the public cloud without proper design, ignoring the cost factor, and for many of them, the move looked like a bad decision.
As technology evolved, sometimes around 2013, containers, and later on Kubernetes, became a popular way to package and deploy modern applications, and today it is very common for developers to be able to write code, create a container image from their IDE, push it to a container registry, and through CI/CD pipeline, deploy a full production scale application.
Kubernetes has become the de facto standard for container orchestration, and all major cloud providers have their own managed Kubernetes services – some are partially managed (such as Amazon EKS, Azure AKS, Google GKE, etc.) and some a fully managed, so customers do not have to deal with the deployment and maintenance of worker nodes (such as AWS Fargate on EKS, Azure AKS Automatic, or Google GKE Autopilot).
Later on (around 2014), we were introduced to functions as a way to run individual pieces of code in response to events without managing any servers, allowing automatic scaling.
As with containers and Kubernetes, the same with functions; the hyperscale cloud providers have managed functions as a service (such as AWS Lambda, Azure Functions, and Google Cloud Run Functions).
Sometimes around 2023, I heard for the first time about "Cloud Repatriation" (I even published a blog post called How to Avoid Cloud Repatriation).
I can still hear the discussion of whether or not moving to the public cloud was the right decision or not.
Personally, I believe it all begins with having strategy, and really understand the benefits of the public cloud supporting the business, design modern workloads to benefit from the public cloud capabilities (instead of the "Lift & Shift" strategy), integrate cost as part of any architecture decision, and always question yourself – is my workload still running optimized, or shell I re-evaluate my past decisions (while understanding the cost and effort to make a change).
For many years, there has been a discussion about whether the security in the public cloud is better or not, compared to on-prem solutions.
I recall in 2016 that even though customer could encrypt data at rest in most (but not all) IaaS/PaaS services (something challenging on-prem), but most cloud providers did not offer the ability of customer to control the encryption keys generation process (the main difference between CSP managed keys and customer managed keys), which raise a lot of concerns among cybersecurity experts, about who can access the organization's data, while it is stored in cloud services.
Today, after many years of experience, I can confirm that the physical location of the data does not say much about the ability of organizations to control their data.
It is rare to find a cloud service that does not enforce proper authorization (from the infrastructure level to API calls), enforce encryption both in transit and at rest (with auto-rotated keys capability), audit trail enabled by default (at least for "admin" activities), and most services can now integrate with CSPM (Cloud security posture management) services, cloud-native SIEM solutions, and other solutions enabling organizations to have visibility over their cloud environments.
The introduction of automation, mostly Infrastructure as Code and Policy as Code, enabled organizations to have much faster deployment time, in a standard and secure way.
Yes, we used to have "admin scripts" using Bash or PowerShell for deploying infrastructure on-prem, but it was not that standard, and not that common. Unless your organization has hundreds or even thousands of servers, you have not put much effort into automation.
Today, mature organizations are taking "everything as code" to the next level, creating CI/CD pipelines to deploy everything they can – from infrastructure (VMs, containers, functions, network, storage, etc.), code (from IDE till production), up to training of AI/ML models, and the public cloud is the natural place for such automation.
The AI era
AI/ML services have been with us for many years – from IBM Watson (around 2011), Siri (2011), Alexa (2014), NVIDIA CUDA (2010), Google TPU (2015), and more.
If we are looking at the cloud providers' offerings, AI/ML services have been with us for quite some time:
- Amazon SageMaker, an end-to-end machine learning platform designed to build, train, and deploy ML models at scale, has been officially available since 2017 (see: https://aws.amazon.com/blogs/aws/sagemaker/)
- Azure Machine Learning, a cloud-based machine learning platform focused on supporting the entire ML lifecycle, has been officially available since 2018 (see: https://azure.microsoft.com/en-us/blog/azure-machine-learning-service-a-look-under-the-hood/)
- Google Vertex AI (formally Google ML services), a unified machine learning development platform supporting all phases from data preparation and model training, has been officially available since 2021 (see: https://cloud.google.com/blog/products/ai-machine-learning/google-cloud-launches-vertex-ai-unified-platform-for-mlops)
The explosion of this market began around 2022 with OpenAI GPT3.5 and the early generative AI solutions (such as DALL-E and Midjourney).
From that moment on, the entire industry (led by analysts) ran amok, and everyone just had to use gen-AI capabilities. Venture capital began throwing billions of dollars all over the place on any company (from small startups to large vendors) that was able to show a proof of concept on anything related to AI or gen-AI.
From Chatbots and image generation, we now have an explosion of AI coding assistance:
As the AI coding assistance became more popular, a new trend has emerged – “vibe coding”. In theory, anyone, without any previous background in development, could ask the coding assistant to write code (such as “develop me a game”).
In practicality, vibe coding is suitable for brainstorming, proof of concept, or perhaps MVP. It is not production scale, and it introduces a lot of security vulnerabilities, such as weak input validation, hardcoded credentials, insecure third-party libraries, improper authentication, etc.
Examples of vibe coding tools:
If we are looking at the Stack Overflow 2025 developer survey, we can see that 84% of respondents are using AI tools as part of their development process; however, only 3% actually trust the accuracy of AI tools.
To understand the hype around generative AI, let us dig into the numbers that the hyperscale providers are putting into the maintenance of software and hardware:
- AWS is expected to spend around $100 billion in 2025, with the vast majority allocated to AI and ML infrastructure to meet soaring demand for cloud AI services.
- Microsoft announced plans to invest about $80 billion in AI-focused data centers in fiscal year 2025, supporting cloud and AI workloads, including collaboration with OpenAI.
- Google increased its capex projection to about $85 billion for 2025, with a major emphasis on building AI/ML infrastructure, including new data centers and upgrades to support Vertex AI and Gemini models.
- OpenAI is projected to spend approximately $13 billion on Microsoft-controlled data centers in 2025, with estimates that its infrastructure spending could reach as much as $20 billion by 2027, and up to $40 billion per year starting in 2028.
- Investors throw another $13B on the Anthropic cash bonfire.
If the huge investment in AI is not enough, there is also environmental impact, by the fact that hyperscale providers need to build large data centers (or expand existing ones), purchase expensive hardware (mostly based on NVIDIA GPUs), invest in power and cooling, and you have got a huge impact on the environment, as you can read in some references below:
- How AI use impacts the environment and what you can do about it
- How big is the environmental impact of AI in 2025
- Environmental Impact of AI: Balancing Innovation with Sustainability
- Generative AI’s environmental impact
If we are looking from a C-level point of view, a high percentage of AI projects fail due to Misalignment of AI and business processes, lack of real planning, poor change management, unrealistic expectations, underfunding, and overemphasis on technology over business impact, as you can read below:
- An MIT report that 95% of AI pilots fail spooked investors. But it’s the reason why those pilots failed that should make the C-suite anxious
- Why 95% of Corporate AI Projects Fail: Lessons from MIT’s 2025 Study
- AI project failure rates are on the rise: report
I am not suggesting AI is doomed, but so far, we have not seen any game-changer (other than chatbots and perhaps AI coding assistance), and I do hope to see enterprises finding a way to produce revenue from AI solutions.
Where do we go from here?
Andy Jassy, Amazon CEO, was quoted as saying: "Remember 85% to 90% of global IT spend is still on-premises". I don't know if those numbers are accurate or not, but even if most workloads are still maintained on-prem, we should ask ourselves why.
Assuming organizations put efforts (in budget, time, and personnel) to re-architect or build from scratch cloud-native applications, I believe the most suitable place for modern applications is in the public cloud.
I am sure organizations will still have many stable legacy applications, not designed to run optimally in the public cloud, based on legacy or dedicated hardware (such as a Mainframe), require extremely low network latency, or simply forced to be kept on-prem due to regulation or data sensitivity.
As long as those applications still produce value to the business, they should be kept on-prem, or perhaps re-architected to hybrid solutions, until eventually the organization can decommission them.
Not everything can run optimally in the public cloud, and without proper design, without understanding business, regulatory, or even service constraints, and by neglecting to embed cost as part of any architecture decision, an organization will find public cloud solutions as expensive or inefficient.
The same thing is relevant for AI workloads. AI does not come to solve every problem an organization may have.
Organizations should strategically look for solving real problems through the use of AI, encourage technical teams to experiment with the technology, and understand which data is used to train AI models (remember data privacy…).
Personally, I believe that using AI technology and building generative AI applications on-prem is good for small-scale or as a mid-term solution.
The cost of dedicated hardware is getting higher and higher, and although you may find a variety of models in Hugging Face, only a few of the most advanced LLMs can be deployed on-prem, to name a few:
The most popular LLMs are only available (as of writing this blog post) in the public cloud:
Summary
The on-prem data center isn't going away in the near future and will probably be replaced with co-location or hosting facilities maintained by data center experts, or hybrid solutions (on-prem and the public cloud).
Right now, the hyperscale cloud providers are hearing the voice of their customers about the high cost of public cloud services (such as egress data fees, cost of GPUs, etc.), and at the moment, we haven't seen any major shift in public cloud costs. Eventually, the CSPs will realize that to keep their revenue, they need to lower their service cost dramatically, and at that point, most organizations will see the public cloud as the most suitable and cost-efficient way to run their business (as long as they don't have regulatory constraints).
In terms of the evolution of job roles, I believe the industry needs more multidisciplinary experts with knowledge in multiple public cloud infrastructures, automation, and smart use of AI tools.
Personally, I believe VMWare experts will remain in demand as long as organizations keep paying license to Broadcom, but eventually, VMWare experts will be like the Mainframe experts 30 years ago – they will remain in demand until they become obsolete, as the dinosaurs.
I do hope to see AI solving real problems for both enterprises and home consumers, and move forward from a proof-of-concept stage (burning a lot of money) to a place where AI makes human lives better.
Disclaimer: I am not an analyst, and everything written in this blog post is either based on public reports or on my personal opinion.
AI tools were used to research and edit this article. Graphics are created using AI.
About the author
Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work.
Connect with Eyal on social media: https://linktr.ee/eyalestrin.
The opinions expressed here are his own and do not reflect those of his employer.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.