What are the top tech questions developers are asking in 2025?
Quick answer: in 2025, developer questions cluster around a few themes: which platform-as-a-service to deploy on (Heroku vs Railway vs Render), when to scale horizontally vs vertically, whether an internal developer platform is worth the setup cost for a small team, and how AI tools fit into an existing DevOps workflow without replacing the people running it.
Platform as a service. Heroku gives you a very easy way of deploying your application — you give it a git repository, you've got some special config in there, and it installs it for you and gives you a server address. Happy days, minimal effort on your part. There are a couple of other companies that do a similar thing — Railway and Render. Both look different, both do things slightly differently, and both have simpler payment plans, and as a platform as a service they'll give you the extra add-ons you want — need a database, sure, just add it on, need more CPU, sure, just add it on.
Horizontal vs vertical scaling. Horizontal scaling is where we take the same cookie-cutter process — be it a server, a virtual server, or a container — and stamp out more of them to give us more capacity, so we can go from two servers to four to eight to 32, however many it takes for the workload. Vertical scaling is where we make the resource bigger — give that virtual server more memory or more CPU. There are pros and cons depending on where you are and what layer you're working at — it's quite common for web or proxy servers to scale horizontally, but for database servers it's more common to scale vertically, and of course you can blend the two.
Configuration management. Another tool that lets us personalise the server — say we've got a Python app, we make sure Python is installed, then install a virtual environment and a package manager like pip or poetry to install all the dependencies, install a web server, and once that's done we can get the thing running. This reduces toil and manual work.
Internal developer platforms. As part of my operability, DevOps, and SRE role, I want to present a situation where everything is self-service: the developer says "I want to start a new project," the documentation says "here's a template, off you go." The developer says "I want to deploy it," the documentation says "go to this URL on our portal, click this button, feed in some information, and it will deploy it for you." There's a pipeline behind the portal that builds and tests it for you, so all of that extra cognitive load is taken away, and everything and everybody is just a little bit happier.
This sounds amazing to the developer, but there's a catch — an internal developer platform (IDP) might not be the right solution for your organisation. It could be over-engineering what you already have, it could be too complex, and there are always budget and team-size constraints. IDPs take a lot of effort to get working — I was on a project where it took about 18 months from inception to the first live service. That's something your business might not be able to support. Nine years on, a team joining that service can now pick up their tickets and deploy a fully working service within 3 weeks — pretty impressive, but that's a lot of groundwork to lay first. Once it's up and running, 3 weeks is great, but it relies on a lot of foundation your business might not be ready to invest in. If you've only got a team of two developers, that's a lot of hassle to go through for two people — that doesn't mean you shouldn't use guardrails or CI/CD pipelines, but you don't have to go as far as a full internal developer platform.
Will AI replace you? Probably not. With technology it's always about doing or delivering more with the same resources — we have a food processor at home, and even a klutz like me in the kitchen can make mayonnaise with it, producing something I couldn't make without that technology. AI is the same — it's not about replacing you, it's about augmentation, and focusing on work you wouldn't otherwise get done. On larger teams I've often paired with somebody else, either with the same skill set as me — DevOps pairing — or a different skill set: maybe a tester if we're writing tests, a programmer if we're creating programming guidelines, or someone from the logging team if I'm setting up more alerts. Automation, to me, is the heart of DevOps, SRE, and platform engineering — providing tools and functionality so developers have an easier life. What's the one thing I can do today to make tomorrow easier for everybody else, including myself?
Service industry transformation. We've already got lots of robots in factories doing boring, repetitive, precision work — making a car out of metal is quite simple, but with fabric it's all a bit wobbly and tricky, so there's a service industry transformation coming too. This will disrupt the jobs market like the Industrial Revolution did several hundred years ago. New roles will be created because somebody's got to look after all these robots.
And this is why I'm here — I want to be more useful to you. If you've got any questions about SRE, DevOps, or platform engineering, come along every Wednesday — I run a free Q&A and the link is at tech-answers.club. I'd like to finish with a joke: a developer and a system administrator walk into a bar. The barman says, "What is this, some kind of DevOps joke?" And they reply in unison, "It's not a joke, it's a collaborative deployment," then proceed to spend the next hour arguing about who's going to write the infrastructure code. Maybe not that funny, but jokes and humour are what get me through the day. Until next time, see you at the Q&A sessions every Wednesday over at tech-answers.club.