How Serverless is Killing the Traditional Backend Role šŸ”„
Leon Martin

Leon Martin @holasoymalva

About: 404 bio not found

Location:
Mexico City
Joined:
Jan 10, 2019

How Serverless is Killing the Traditional Backend Role šŸ”„

Publish Date: Jan 30
74 24

There was a time when backend engineers were the backbone of software development. They built APIs, managed databases, optimized server performance, and designed architectures that could handle millions of users.

But if you’ve been paying attention to how tech has evolved in the past few years, you might have noticed something: serverless is eating the backend world.

And honestly? Traditional backend roles might not survive it.

I’ve seen companies gut their backend teams because they realized they don’t need a dedicated backend engineer for everything anymore. I’ve seen startups launch massive products with just a frontend team and a couple of DevOps folks managing cloud functions.

So what’s happening? Why are backend roles disappearing? And if you’re a backend engineer, what the hell should you do about it? Let’s talk.


How We Got Here: The Rise of Serverless

A few years ago, building a scalable backend meant managing servers. Whether it was on-premises or cloud-based, backend engineers had to worry about:

  • Provisioning and maintaining servers
  • Scaling infrastructure as demand increased
  • Optimizing performance and handling security
  • Managing databases, caching, and networking

Then serverless happened. AWS Lambda, Google Cloud Functions, Azure Functions—these platforms abstracted away servers entirely. Suddenly, you could write a function, deploy it, and let the cloud provider handle everything else.

And companies loved it.

Why?

  • No need to manage infrastructure
  • Auto-scaling built-in
  • Lower costs (you only pay for execution time)
  • Faster time to market

Instead of hiring a team of backend engineers, companies realized they could just plug into a serverless architecture and call it a day.


What’s Disappearing?

With serverless, a lot of traditional backend responsibilities are slowly fading away.

1. Server Management is Gone

No more provisioning EC2 instances, no more tuning nginx configs, no more babysitting Kubernetes clusters (unless you really, really need to).

Serverless platforms abstract all of this. AWS Lambda, Google Cloud Run, and Azure Functions scale automatically based on traffic. The backend engineer who used to monitor and optimize servers? No longer needed.

2. API Development is Changing

Instead of spinning up an Express.js or Django backend, many companies are opting for API Gateway + Lambda functions.

What used to be a monolithic backend team managing an API is now:

  1. A frontend dev defining API routes in API Gateway.
  2. A few cloud functions handling business logic.
  3. A managed database like DynamoDB or Firebase Firestore doing the heavy lifting.

No dedicated backend engineer required.

3. Databases are Becoming ā€œServerlessā€ Too

Managing and optimizing databases used to be a backend engineer’s job. But now? Managed databases like Firebase Firestore, AWS Aurora Serverless, and PlanetScale handle scaling, indexing, and even query optimization automatically.

Backend engineers who spent time tuning SQL queries and designing efficient data schemas? Companies are realizing they don’t need as many of them anymore.

4. Authentication and User Management? Outsourced.

Rolling your own authentication system was a core backend responsibility. But now?

  • Auth0, Firebase Authentication, and AWS Cognito handle user auth seamlessly.
  • Stripe, Plaid, and third-party payment services handle transactions without backend teams needing to implement complex payment flows.

The backend engineer’s role in security, auth, and payments is shrinking fast.


The ā€œNew Backendā€ Looks Different

So does this mean backend engineers are completely dead? Not quite. But the role is changing dramatically.

Instead of managing servers, APIs, and databases from scratch, backend engineers in 2025 need to:

  • Understand cloud-native architectures (AWS, GCP, Azure)
  • Write efficient cloud functions instead of monolithic backends
  • Design event-driven systems (Pub/Sub, AWS EventBridge, Kafka)
  • Integrate third-party services instead of reinventing the wheel

Basically, the backend engineer of the future is part cloud architect, part API integrator, and part problem solver.


The Winners and Losers in a Serverless World

Not everyone benefits from this shift. Some developers will thrive in a serverless ecosystem, while others might find themselves struggling to stay relevant.

Winners: Who Benefits from Serverless?

āœ… Frontend Engineers: Frontend teams can now handle more backend tasks using serverless functions and APIs.

āœ… DevOps & Cloud Engineers: Since infrastructure is more cloud-driven, DevOps engineers are taking over a lot of backend responsibilities.

āœ… Companies & Startups: They can ship faster, scale easier, and spend less on backend engineering teams.

Losers: Who’s in Trouble?

āŒ Traditional Backend Engineers Who Refuse to Adapt: If your expertise is just managing servers or writing monolithic backends, your job market is shrinking.

āŒ Developers Who Ignore Cloud & DevOps: Backend without cloud knowledge? That’s a risky bet in 2025.


Should You Still Become a Backend Developer?

Short answer: Yes, but don’t be the kind of backend developer that’s getting replaced.

The industry still needs backend expertise—but the skills required are shifting. If you want to stay relevant, focus on:

  • Cloud computing (AWS, GCP, Azure)
  • Serverless architectures (Lambda, API Gateway, Firebase, etc.)
  • Infrastructure-as-Code (Terraform, Pulumi)
  • Event-driven architectures (Kafka, SQS, Pub/Sub)
  • Building scalable, maintainable APIs (GraphQL, gRPC, REST best practices)

In other words, you need to become a backend engineer that understands serverless, not one that fights against it.


Adapt or Get Left Behind šŸ”„

Serverless isn’t a trend—it’s the future of backend development. The days of traditional backend engineers managing servers, databases, and monolithic APIs are fading.

If you’re a backend developer, you have two choices:

  1. Adapt to the new reality—learn cloud, serverless, and modern backend architecture.
  2. Ignore the shift and risk becoming obsolete as companies continue downsizing backend teams.

The role of the backend engineer isn’t dead—it’s evolving. The question is, are you evolving with it?

What’s you think? Let’s discuse in the comments.

Comments 24 total

  • mehmet akar
    mehmet akarJan 31, 2025

    Happy to see more serverless geeks!

  • Andrey Rusev
    Andrey RusevJan 31, 2025

    I'd say there's definitely a kind of a shift (thanks to hyperscalers). I usually describe it as libraries are evolving into online services.

    Say, if years ago you'd look at libs as pieces of functionality that you can combine - now you have more and more ways of combining entire services instead. Anyway, it's a long story, won't go deeper in this comment.

    Specifically about cloud functions though - yes, they are pretty good especially when you are starting something new - very quick to develop and deploy. But I usually recommend watching them a bit more closely - one day you will grow to a level of demand (requests) that's worth handling in a more 'tightly packed' way. That's when you might prefer building your own backends and spin them in containers or something...

    • Andrey Rusev
      Andrey RusevJan 31, 2025

      A bit like - the moment you get 24/7 demand for a CPU core - get a CPU core and fill it with work...

  • david duymelinck
    david duymelinckJan 31, 2025

    Software development is always changing.
    But who says backend developers can't change? And haven't changed already.

    I have seen websites change from static to dynamic. With dynamic meaning adding a database to the server the webserver runs on. Now with cloud platforms servers are running in network clusters.

    If you think serverless is the thing that is the silver bullet, you buy into the hype. And that is never a good thing.
    I see serverless as an extra tool that has its place in the development environment.

    It seems that you don't understand all the decisions that go into backend development. And you start from a limited tool to pile on more work to positions that have their own speciality.
    Devops in my opinion is an operations job, instead of configuring servers manually now it can be done with code. Devops don't touch application code, if they don't need to.

    It is not that when someone specialises in one aspect of software development, that they forget all the other parts. For a backend developers that is impossible because that position is in the middle of frontend and operations.

    I'm more worried for you, than for backend developers.

    • Brian Lewis
      Brian LewisFeb 5, 2025

      You already called yourself out. Dynamic sites have been around since the 90's and static sites have been they hype. Serverless has been around over a decade strong. The article is straight facts. Backend engineering is being replaced by AI first and right now. The real problem is terrible front-end that skirts backend dedication and foresight.

      • david duymelinck
        david duymelinckFeb 6, 2025

        Dynamic sites have been around since the 90's and static sites have been they hype

        With static sites I'm not referring to the jamstack version, if that is the hype you mention.
        Things like geocities where dynamic, otherwise there was no way people could add their own content. I knew there where java applets that brought dynamic parts. I knew asp, without the .net, but it was expensive to host a server. And then came php, and things got cheap enough to build your own dynamic website experiments.

        Serverless has been around over a decade strong.

        I'm not saying it is a bad thing. It isn't the only way forward.

        Backend engineering is being replaced by AI

        The post does not mention AI as the cause of the diminishing backend role.

        AI at this time can't do reasoning. You can't feed it an idea and expect it to come up with a codebase on its own.
        You have to spell it out with all the context you can provide, before it comes close. And then you have to verify if that is what you wanted.
        Even in an AI world developers matter.

        The real problem is terrible front-end that skirts backend dedication and foresight

        I'm not sure if you are ranting about frontend development or AI?
        And it also feels like you are contradicting yourself. Because first you agree with the article, but here you agree with the sentiment of my comment.

  • keyr Syntax
    keyr SyntaxJan 31, 2025

    You tried to touch many points about serverless architecture but you forgot very critical disadvantage of serverless which is cost. Do you know how costly it becomes when your serverless usage increases? I don't think you have full picture of what you are talking about.

    • Thillai Sathasivam
      Thillai SathasivamFeb 1, 2025

      It's great point. If you have more users concurrently requesting, serverless cost is going to be very high!!!!

    • VEMAREDDY SHRISHVESH REDDY 22115161
      VEMAREDDY SHRISHVESH REDDY 22115161Feb 1, 2025

      My company opted out of serverless architectures because of its increasing costs

      • keyr Syntax
        keyr SyntaxFeb 1, 2025

        Good decision by your company. The traditional backend is so cheap and reliable as well.

  • uratmangun
    uratmangunFeb 1, 2025

    serverless basically adhere to this motto of ship fast break things, while traditional more like cheaper but complicated, but i do love the traditional one

  • Kevin Naidoo
    Kevin NaidooFeb 1, 2025

    I love fiddling with servers 😊 but I also use serverless tech wherever it makes sense to do so.

    The tech world is big enough to specialize in whatever you want to, so long as there is a good enough demand for that skill. With the amount of Linux servers out there in the wild, there are plenty of jobs. If you work hard enough and keep improving your skill set, there will always be opportunities.

    There is no "my way is the right way". This is the problem with the internet in recent years, the fanboyism.

    I do agree with "Adapt or Get Left Behind"; from day one as a software engineer you have to understand that tech changes often, the underlying engineering not so much but the APIs, tooling, and frameworks do. You must keep up, you don't have to know everything, pick a specialization and just aim for mastery.

    If the tech you picked dies off, you know how to learn, so just learn the next thing. Not that hard.

  • Juan Camilo Vega Nieto
    Juan Camilo Vega NietoFeb 1, 2025

    There are some tools that tries got the best of both worlds (classic vs cloud), such as knative for build "lambda" functions whiteout too much costs.

  • john fivekiller
    john fivekillerFeb 1, 2025

    One problem with your argument, isn't all these serverless platforms essential back ends? Which means a backed developer created your "backend". The problem isn't backend jobs/code is disappearing it's the jobs and code are shifting, so you don't see them in your world but the world is a bigger place than you think.

  • Ravin Rau
    Ravin RauFeb 1, 2025

    Good writeup, but I think the emphasis on serverless might be slightly overrated here. I think it is worth considering the broader shift in what it means to be a software engineer today. The industry isn’t just changing tools; it is redefining the role of engineers themselves.

    Modern engineers are increasingly valued as problem solvers first and coders second. The explosion of abstractions (like serverless, low-code platforms, and managed services) means engineers no longer need to obsess over infrastructure minutiae or syntax quirks. Instead, they’re tasked with asking: How do I solve this business problem most effectively?

    This requires a mindset shift:

    1. Trade-off analysis: Should we prioritize speed-to-market (e.g., serverless, PaaS) or long-term cost control (e.g., self-hosted solutions)?
    2. Process optimization: Engineers now design systems to eliminate bottlenecks,automating CI/CD pipelines, adopting infrastructure-as-code, or leveraging serverless for event-driven scaling. Efficiency isn’t just about code performance; it is about the entire development lifecycle.
    3. Cross-disciplinary thinking: Today’s engineers often bridge gaps between frontend, backend, DevOps, and even product/business goals. The ā€œall-rounderā€ engineer isn’t a jack-of-all-trades, they are a systems thinker who connects technical decisions to outcomes.
    4. The real challenge isn’t choosing serverless vs. containers vs. monoliths, it is understanding which tool (or combination) solves the problem efficiently while balancing technical debt, scalability, and business context. This is why engineers today spend less time memorizing documentation and more time architecting solutions that align with why a product needs to exist, not just how to build it.

    Serverless is a tool, not a philosophy. The true evolution is engineers becoming strategic decision-makers who optimize for value, not just lines of code.

  • om pharate
    om pharateFeb 1, 2025

    But what about WebSockets?

  • christopinka
    christopinkaFeb 1, 2025

    No mention of a clear path or suggestions of how to learn these skills in a way that is relevant to companies hiring for them in an attempt to migrate to cloud soa.

  • Jayesh Kale
    Jayesh KaleFeb 4, 2025

    Do you think serverless is the silver bullet. As number of users grow sleeveless cost shoot up as well, as opposed traditional system. Heck even most of companies won't even migrated fully to cloud.

  • steve
    steveFeb 5, 2025

    Interesting. I find the reverse. Front end jobs are being demoted in salary by nearly half and competition for the role is steeper due to everyone and their dog learning basic React. Never mind that they lack html semantics, accessibility, mobile responsive structure, patient dogwork in performance optimising, smooth animation, transitions, good ui experience.

    Yes the environment has changed but I think its a combination of austerity and the advent of ai to answer questions and fill in the knowledge gaps.

    Regarding companies just using lambda and heaven forbid dynamodb in a small scale, have you seen the cost for running that and the benchmarks? Having spent the last 4 months playing with AWS exlusively I can confidently say its just a different skill, much like azure and gcp.

    The benchmarks I've read online and cumulative cost under loas all steer more positively towards ec2 and ecs over complete lambda serverless architecture. Also it compartmentalises the dependencies for any migration away from depending on AWS, should their pricing model or company fail to be fair.

  • Chi Huynh
    Chi HuynhFeb 5, 2025

    Serverless or managed services = you are paying for the convenience.

    It’s just a tool. Not your silver bullet.

  • Ankit Sood
    Ankit SoodFeb 5, 2025

    Who has build those 'serverless' services?
    Guess??
    Backend engineers

  • Maniraj Madishetty
    Maniraj MadishettyFeb 6, 2025

    You missed comparing cost factor at scale. Also let's say if you have to work at these tech giants,underlying infra would still be kubernetes.

  • nasoma
    nasomaFeb 7, 2025

    With serveless you must wake up at midnight to check your email, just to confirm you dont have a bill that looks like you were training a model.

  • nicholas-eden
    nicholas-edenMay 12, 2025

    This is a load of nonsense. Serverless is just a different deployment structure, it doesn't replace the need for developers to build out business logic on the backend. In my experience, serverless requires vastly more care and planning due to the complexities of managing smaller "serverless" servers. When your lambdas need to talk to each other you need to worry about backwards compatibility a lot more than when you just deployed a full server. When you make an update to any shared library, such as within auth or primary business models, you need to take pains to update a lot more repos/packages than when you have a set of services with their own domains. The list goes on, lambdas just have a lot more growing pains built into them due to how they force you to structure your system.

Add comment