Just out of interest, and maybe for future reference, I did a little bit of research on the major topics of industry hype over the past couple of decades, to look at how much difference they made and which have quietly disappeared. I wanted to find out what happened to the buzzwords nobody talks about anymore (IoT?) and remind myself of things I had forgotten...
🛑Mostly disappeared. 🟡 Some impact, but not for everyone. ✅ Widespread, normalised. ⏳Still an active topic with potential. (2026)
Certainly, services and microservices are now completely normal. The idea is of course to separate concerns within a software system, so that its constituent services can be developed and deployed independently and in parallel, talking to each other through simple APIs. One service doesn't care if another service's implementation changes, as long as the interface stays the same, so there's more flexibility and less risk. This is in contrast to huge, monolithic applications where everything happens in one big, spaghetti code project, where change is risky and complicated.
Services can still be done badly - you don't want to break up the software into too many chunks that are too small, as that just means more separate things to keep track of, maintain and deploy, i.e. more faff. There is an optimal middle ground that people sometimes overshoot, hence the common complaints about microservices that have gone too 'micro'.
Nevertheless, SOA was clearly very positive, very widespread and was completely normalised a while ago.
Clearly 'agile' has been totally normalised, but that doesn't mean it's universally well understood and well executed. (In fact, there is still a lot to do there.) But, it's fair to say the hype and novelty is over. The question is whether someone can do it well, not whether they've heard of it.
Part of the problem is the choice of terminology, which doesn't lend itself to nuance or progression. Nobody will say that they are 'not agile', as that sounds bad. Every project would claim to be 'agile', but most could also be more 'agile' or could be a different kind of 'agile'. The conversation needs to move past the buzzword into topics like team size and composition, iteration frequency, planning versus experimentation, process flexibility, etc.
Within the topic of 'agile' software development, there are a few subtopics that had or have their own hype: XP, scrum, kanban, lean. I think it's important to remember that these are just templates that might help a project to become more agile than it was before, in certain circumstances, but they are not necessarily end goals. You might use scrum to help a waterfall team learn new, agile behaviours, but you'll probably want to move on from scrum at some point. Scrum is not the epitome of 'agile', it's just one way of starting an agility journey.
Instead of focusing on process frameworks, I find it more helpful to refer back to the original agile manifesto and agile principles. There is still a timeless truth to those things.
DevOps turned out to be a huge topic with enormous consequences, which the industry is still working through. Changes have come in waves, starting with making ops and dev one team. New ideas and new tooling have allowed more aspects of work to be automated and abstracted, i.e. more of the work belonging to the broad software project system has been coded and source-controlled to become part of the software system itself. DevOps doesn't just make the old work faster and less error-prone, however. It makes our roles, projects and products substantially different from before. It feels a bit strange to say that such a long-lived buzzword still has relevance, but I think we have to, for a few reasons:
Still catching up: From experience, it's clear that many organisations still have enormous potential gains ahead of them, if they simply do more DevOps stuff, better. That's a polite way of saying there are many who are far behind, wasting a lot of time and money. The opportunities to make better products faster, while cutting costs and risks, can be staggering. A lot of DevOpsy practices that would give you top DORA scores today were already possible many years ago (maybe 10, not sure about 20), but don't seem to be fully leveraged yet outside of modern tech companies and a smattering of good tech consultancies. And the capabilities available to us only continue to expand...
Still growing and maturing: New capabilities continue to emerge, which fall under the broad umbrella of DevOps. Cloud providers and tooling providers keep enhancing their offerings. New open-source standards and tools, like OpenTelemetry, continue to mature. A greenfield project in 2026 would probably have a very different and more powerful toolset than a project 5 or 10 years ago, even if the broad aims (like workflow automation, IaC and observability) are basically the same. An obvious game-changer of the mid-2020s is that AI agents can join our automated workflows and perhaps change our workflows considerably, chipping away at remaining manual toil. If we're developing or configuring software to do previously manual work for us (which we clearly are with AI) then that sounds a lot like DevOps.
Shrinking barriers: Up until the mid-2020s, the problem has been that DevOps asks dev teams to do quite a lot of new, unfamiliar engineering beyond the core application code and trust that a big initial effort will pay off. Teams invest too little, or just do it a bit wrong, racking up tech debt and missing out on the benefits. AI, however, can help teams to catch up on aspects of DevOps they've neglected, putting the topic back on the table. Deficiencies in a team's project machine might have seemed too daunting to tackle, before AI got good, either because of the learning hurdle or the time cost. Now, there's little excuse to put off a tedious refactor, or a big push on unit test coverage, or a suite of clever system dashboards. An LLM's assistance makes those things much more feasible.
When will it end? It's hard to say. DevOps was/is a cultural shift, so perhaps it could end if another huge cultural shift were to undermine and replace it, but that doesn't feel very likely. For now, it feels like DevOps is a one-off lesson that we needed to learn and won't ever unlearn (like learning the earth isn't flat).
Perhaps it is more likely to end with normalisation (a bit like 'agile', although that's debatable), once it seems the vast majority of the industry is on board. Then, DevOps will just be how the industry works, not how it should work. The following kinds of statements would need to be completely normal, not special:
We almost never touch prod directly, it looks after itself. But we look at it all the time to understand our product and its usage, to inform our business and engineering decisions.
At the point that a change gets merged, we're very confident it's ready for prod. We reliably catch regression well before that point.
We can and do deploy to prod quickly, at any time, and it's not a big deal. It's easy and safe.
So, bugs almost never reach prod, but, when they do, they are very short-lived. We just quickly fix, roll back or toggle feature flags with no drama.
Our system stays secure by itself, regardless of who's on holiday. Patching, key rotation - these kinds of things are all automated or cloud-managed, so risk is minimal.
This term referred to the trend for websites to become more interactive for users, but there wasn't unanimous agreement. MySpace, Facebook and YouTube would be examples of 'Web 2.0', because users were creating their own content, rather than reading static sites. Apparently, some people dismissed this definition of 'Web 2.0', as there was already user participation on the web before that and the advances that the label represents might have been more of a smooth evolution rather than a revolution. Usage of the term must have fizzled out by the time I joined the industry in the early 2010s, as it never came up in conversation.
Clearly, cloud hosting quickly became the default choice (some time before 2020 in my experience), unless an organisation had a very good reason to run an on-prem server.
Some obvious benefits are flexibility, scaling and low barriers to productionising an idea. It's super efficient for a cloud provider to do a load of hard, complicated stuff once and for the rest of us to use their service, as opposed to every software team in the world dealing with the effort and risk of self-hosting.
Some organisations do still need on-prem hosting, such as for niche security reasons, so there is still a market for tooling that supports that.
I wouldn't underestimate the importance of 'big data' in certain sectors. Clearly, there is a lot of 'big data' work happening and tools like DataBricks and Snowflake are widely known about. However, it remains quite a specialist area that most software delivery teams don't often need to deal with, because their data just isn't that big! Even if a dev team's product contributes its data to an organisation's 'big data' repository, there's probably a specialist team managing and analysing it. Application developers need to know that 'big data' is there, but for many it's just not a big part of their daily life.
There was always a bit of a problem with the terminology - how big is 'big'? As of 2026, I have been on one project that might have been considered 'big data', but it's tricky to define.
Also, the hype seems a little excessive in retrospect. I remember it being the number one topic at work for a while and developers being encouraged to retrain, but, looking back, most project work continued unaffected. The same couldn't be said of 'agile', 'DevOps' or 'cloud', for example.
Even when we're not working on 'big data', we might interact with others who are, so it's useful to know some of the terminology:
A data warehouse contains data from various sources, structured and optimised for analysis and reporting. E.g. Snowflake. The term 'data warehouse' already existed in the 90s, long before the 'big data' hype, but obviously tooling is different now.
A data lake is a big, cheap repository of varied data that might be less structured. E.g. AWS S3. This is an early 2010s term.
A data lakehouse is a hybrid, which is meant to be cheap and scalable like a data lake, but with more of the usefulness of a data warehouse. e.g. DataBricks. This is a late 2010s term.
ETL = 'Extract, Transform, Load'. This is the traditional approach for taking data from one data repository (e.g. an application database), restructuring it (e.g. tailoring for analysis and reporting) and loading it into a different data repository (e.g. a data warehouse).
ELT = 'Extract, Load, Transform'. This is a more modern approach, in which the data is obviously loaded to the destination before it is transformed. One advantage is that you can leverage whatever powerful processing capabilities you already have in the destination server, rather than needing a separate processing server earlier in the chain. Also, you can keep both your raw and processed data in the destination repository, in case you want to reprocess it again for any reason (like if your transformation process had a bug), which might not be so easy with a traditional ETL.
Stream vs batch processing: Batch processing involves scheduled or on-demand jobs that process 'batches' of data, whereas 'stream' processing involves continuous, real-time processing of data. Kafka is an example of stream processing tool. Where I've seen it in use, it essentially watched a DB for any changes. Any change resulted in a message on a queue (a topic). Something could subscribe to the topics and ingest the data updates in real time. Streaming has advantages, including less lag time and a more consistent computational load, as opposed to batch jobs that create inevitable lag and spikes in load. Batch jobs could still be a viable option, however, perhaps for on-demand (rather than continuous) tasks or cases where lag and load are not really a concern.
The 'internet of things' refers to the expansion of physical devices connected to the internet. The hype extended beyond the tech industry into public discourse, but the real impact on the general public was less than one might have assumed at the time.
The idea of having one's kettle and dishwasher connected to the internet is now somewhat ridiculed, with good reason. You need to be in the room with these things to use them anyway, so remote operation is irrelevant. Internet connectivity mainly enabled gimmicky features that we're probably happier without - there's enough noise in our lives already. Also, why spend more money when the dumb, offline device already does the job? Of course there are a few useful and popular exceptions, like smart energy meters and doorbell cameras. However, most of us seem to have decided that life is easier when most of our household possessions are simple and offline. I hardly see anyone using a smart speaker to turn on their lights or to give commands to their tumble dryer. Most Alexas probably live in drawers now.
The biggest practical uses of 'IoT' are in business and industry, rather than the home consumer market. For example, it is great for tracking fleets of vehicles, shipping containers and other assets. As mentioned, smart meters are useful in the utilities industry, noting that many houses now have solar panels pushing excess power back into the grid, so there's more to monitor at the consumer end than just plain usage. Healthcare is a big sector for IoT - monitoring devices, implants, etc.
So, the industry impact is there, but it's fair to say it's niche, with much more work happening outside of IoT than within it. Perhaps IoT has come to have a narrower definition than it deserves and perhaps that's down to the smartphone (and to a lesser extent the smartwatch). Our multi-purpose phones replaced the need for so many physical 'things'. The impressive amount of hardware that already exists in all of our pockets (GPS, microphone, camera, speaker, thermometer, NFC, biometrics, etc, etc...) gives us huge scope for developing a range of clever, internet-connected products, without even needing to consider bringing additional hardware into play.
We don't really think of smartphones as 'IoT', because they are just normal, general-purpose platforms for our software, along with tablets, laptops and desktops. We feel like 'IoT' devices should be specialised, not general-purpose. Even smart TVs don't really get described as IoT anymore, as they have become Android tablets with very big screens. That leaves 'IoT' representing the overlap between strong use cases for internet connectivity and things that our computers/phones/watches can't do. Things that fall into that overlap just seem to be vastly outnumbered by things that fall outside of it.
Strong case for internet connectivity; Phone can do:
Communications, entertainment, navigation, photography, banking, retail, gaming, productivity, news, health tracking, ...
Strong case for internet connectivity; Phone cannot do (useful 'IoT'):
Doorbell.
Weak case for internet connectivity; Phone cannot do:
Everything else.
This facetious illustration is not intended to be entirely accurate or exhaustive!
Also 'Web3' (not the same as Web 3.0).
...
Docker, Kubernetes.
...
'Serverless' refers to cloud services that let you deploy and run functionality, without needing to worry about the server behind it. Of course, there is still a server, but you never see it or configure it. It's like renting an Airbnb, where utilities are all included and everything just works, as opposed to owning a house where everything is your responsibility. Of course, some will prefer to have flexibility and control, rather than pay for someone else to manage everything.
Some common examples of 'serverless' services, which I have used, include AWS Lambda functions, Step Functions (State Machines) and Aurora DB. With these, you have the option not to think at all about operating systems, scaling, patching and so on, because these things are either hidden from you, or have a default mode that should work just fine. Sometimes you have some optional controls (like concurrency config for Lambdas), but you're pulling and trusting some very simple levers without needing to worry about the mechanisms underneath.
The efficiency benefits are obvious. The cloud provider develops the complicated, but reusable components (like queues, scalable function runners, data stores) then the rest of us just join them up like Lego and add our custom logic. Yes, we pay for the privilege, but generally only by usage. If nothing calls your Lambda function, then there's nothing to pay, because there's no running server with your name on it. In contrast, if you own a physical server or rent a virtual one (e.g. EC2) then you're paying its bills whenever it's turned on, which it has to be, just in case it needs to serve a request.
There are downsides to serverless, like cross-provider portability. If you build functionality out of AWS serverless building blocks, then you're pretty tied to AWS hosting. Running in a local dev environment or a CI pipeline environment can be tricky, requiring extra tools (LocalStack, MiniStack) that emulate the cloud platform. If you try to move to another provider, you'll have to redesign around their own serverless building blocks. If you want to move to a plain server, you might have quite a lot of development to do, to fill in the gaps where the magic serverless functionality was.
Containerisation is a good answer to the portability problem, although it's likely to be a step up in complexity from the pure serverless options. You can run your containers anywhere, including on a server or your own machine, so containerisation is not 'serverless' by default. But, cloud providers do offer serverless hosting options for your containers (e.g. Fargate), so you can still get some serverless benefits if you want them.
Side note: Serverless is a particularly interesting subtopic of DevOps, because it neatly demonstrates how application and platform now overlap, as do the roles of application development and platform engineering. Pre-DevOps, if a developer wanted to write some asynch queuing functionality, for example, they would do it all within their application code and the ops person in the server room wouldn't need to know much about it, as long as they gave the server enough RAM. Nowadays, developing that same functionality involves a bit less custom code and some very important configuration of the cloud platform's functional behaviour (timeouts, retries, failure handling, etc.). The config and the code are not two separate jobs - both define application functionality and neither has any value or testability in isolation, so they are one job for one engineer. The cloud platform has become part of the functional application, so the application developer has, in a way, become a platform engineer.
No explanation is required here and there is no doubt that the impact is wide and deep, although the exact extent is still unclear. It will be interesting to see how long the sense of 'hype' will last - we're capable of normalising amazing, transformative things very quickly sometimes, like the smartphone. The concept of general-purpose AI assistants is already pretty normalised in 2026. We've got over the initial excitement and we're talking more about the practicalities of serious, operational use of agents.
We can't make many predictions when things are changing so quickly, except that costs will need to go up at some point, as big AI does have quite a lot of debt (estimates up to $3 trillion).
This is like DevOps for machine learning models and large language models that are used operationally. If a company has a production use case for ML or LLMs, then they need to engineer the mechanisms through which the models are developed, tested, deployed, scaled, monitored, etc, the same as DevOps for a conventional software system.