I've seen the exact opposite - many projects are going back towards monolithic structures and then decoupling a minority of components that need to horizontally scale.
Has anybody actually tried to program as these serverless / microservices articles propose ? Having a collection of lambdas orchestrated by infrastructure as code ? I have and the result has always been a complete nightmare… I’m starting to think I’m not actually an idiot doing it wrong, but that I’m being sold snake oil by cloud companies and ex-programmers who now make money writing books and powerpoints for conferences :(
The future has to be something more like code-on-cloud. Infrastructure should be so abstracted and effortless that development is mainly creating and editing core logic into a web-based development environment. Only the heaviest/purest technology companies and hosting companies (Google, Meta, Microsoft, TikTok) should get down to the level of worrying about the next level down.
Serverless is fine. I always find that people try to shoehorn everything into something trendy for no reason.<p>Like I use serverless for a handful of async tasks that can run in background. Common things like image resizing, processing data to make metadata tags or something, or some things that I would have originally used Kafka for. With serverless especially if I’m already on aws for example I have access to the whole ecosystem. Once something completes it can just write data to some store. Done. I don’t need to lose my sanity fixing Kafka event failures and other bs.<p>Core logic goes into monoliths or services. Anything that can be offloaded that’s an atomic operation goes to serverless from either mono or service.
Not on board with this, other than the advantages that solutions like Pulumi have over 2nd gen IaC tooling like TF.
Pulumi is far more extensible and composable than anything else I've seen out there.
This article puts together a lot of real things that exist and confuses what is actually happening. The new technologies aren't replacing the old ones. They are supplementing them. Not only that, but the author is apparently confused about a lot of the pieces.<p>I'll take just the Infrastructure as Code section since I know the most about it. First it says Infrastructure as Code was a bunch of DSLs like Ansible, Chef, and Puppet. No, those were the second wave of "Configuration Management". Some folks might include them in "Infrastructure as Code", but I wouldn't. They are tools to manage configuration of traditional servers. They have some IaC capabilities, but they are very limited and not really the core of what these tools provide.<p>Terraform and CloudFormation are the real exemplars of "Infrastructure as Code". They take a declarative, relatively static approach to defining infrastructure. That's honestly fine for most cases. But I'd lump the AWS CDK and Pulumi in here too. They aren't something new, they just bring the ability to use more traditional languages to the game. But they don't fundamentally provide more flexibility than traditional TF or CF, because they are still bound to the static plan/apply cycle.<p>I'd not heard of "Composition as Code" until reading this article. But to the extent its meaning is clear from this context, the author isn't making any sense. The author says CaC allows developers to use "finer grained" infrastructure specification than IaC, but if anything, that's the opposite of what they do. By abstracting things into broader chunks of multiple pieces of infrastructure, they are by definition working with "coarser grained" infrastructure.<p>Anyway, as folks here point out, the movement towards highly specific components rather than actual code for building cloud-hosted services just trades one set of problems (scaling; dealing with VMs; having sysadmins) for another (business logic spread out over dozens of individual "components"; impossibility of rapid testing and troubleshooting; requires massive supporting observability infrastructure to make sense of).
IMHO the future should be one where there is no difference between computers and the service providers simply provide always on, always connected devices.<p>Is there any reason why there's a "server" or "serverless servers"? Why everything isn't just apps talking to each other? I think no, there's no real hard reason but just its how evolved as the early on the connectivity and device power was drastically different for devices that users had and devices that were needed to process data and stay on forever.<p>At this day, a JavaScript code can be the engine on a desktop machine, on a mobile app, on HTML client page and on a backend server. Actually, with WASM and some other tools any language can do the same. Its even possible for everything to run in a browser that is available on every platform and all that running in decent speeds because our computers are all supercomputers and the significantly different high performance computing is happening on GPUs.
I’m instantly skeptical about any web tech that promotes performance, scalability, or cloud cost optimization. Those are absolutely not the pain points for 99% of developers.