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.
This I feel is the ideal way in many many cases. Only separate out components if the additional cost of service communication (when moving the component away from a monolith) is less than the benefits of scaling/separate repo/etc.
I'm personally a fan of the mono-microlith (or whatever people call it), where you compartmentalize the monolith so that it's a just a flag of what "micro-services" are enabled on each instance. Easy to scale down on a dev machine (one process) and easy to scale out, the local procedure calls just become remote procedure calls (over HTTPS or whatever).
Yeah I think there are fundamental challenges with microservices that are very hard to address unless you're someone like Google and you can invent BigTable and Zanzibar. It used to be you needed to move processing into app code and out of the database because they were hard and expensive to scale, but that's not true anymore.
The nice part is that we're no longer at the beginning of this journey. BigTable and Zanzibar already have open source equivalents: HBase/Cassandra-likes (hard to pin BigTable to just one thing) and SpiceDB. As these projects mature, they only become easier for folks to adopt into their architectures and get all the same benefits.
Yeah but if you choose something like BigQuery you really don't need microservices, and thus you probably don't need a distributed auth solution either.
Sounds like a correction from going all-in on microservices back to a more normal/natural, on-demand scalable architecture. Honestly a lot of architectures are selected based on hype instead of if it's the right solution. And a big reason for that is hiring and artificially creating excitement for developers, because let's face it, most software development is boring.
Speaking of boring development, I took a programming aptitude test at the first company I worked for many years ago. If you got a good score you could stop doing boring tasks like data entry or tape backups and learn to write programs instead. The exam room was pretty crowded as that sounded much more fun.
The guy giving the test saw it as his duty to tamp down our excessive enthusiasm. After explaining how the test worked he then told us how a recent study showed that programming was the 10th most boring job in the US. He went on at some length. This was back in the days of COBOL running on mainframes so there was probably something in what he said. At the time I supposed he was trying to provide consolation if you got a bad score. Be that as it may, the "stat" stuck with me for the rest of my life.
I mean, I'm talking from a b2b and an on-prem/world of many differently capable clouds, so I'm most likely a dinosaur anyway. We have established code bases for domains.
We've been looking at lambdas or FaaS for quite a few things and... we kind of always end up with weighing loads of operational effort versus just sticking a method into a throwaway controller on the existing systems. Is it somewhat ugly? Probably. Does it reuse the code people maintain for that domain anway? Very much so. Would you need a dependency or duplicate maintenance of that model code between the FaaS code and the monolith anyway? Most likely.
All in all, we mostly have teams utilizing Pactbroker to work out their APIs usually, deploying decently chunky systems in containers and being happy with it.
The one thing we really do on-demand compute like this is some model refinement. Because here a tiny service can trigger the consumption of rather awesome resources for a short while.
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 :(
Sadly, yes. Several years ago, started a new job at a "serverless" company. There was a ton of lambdas with massive code duplication everywhere. Nothing could be run locally. I'd see people actually editing code through the AWS console. On top of that, the performance was terrible.
The whole thing could've run on a single low end VM and used RDS for the database. Using a more standard framework, it would've been cheaper, faster, and easier to maintain.
All of my past projects where we implemented these cloud paradigms, didn't need them. There were better options to extract performance and improve scale than going all-in for cloud based migrations.
sure, that OS patch was auto updated, but that vuln in our deps that showed up over the weekend did suck in our time.
We lost productivity, the cloud credits ran out and so did our good folks.
I think it solves a very specific set of problems that most people probably don't have.
For example, if scaling various parts of your application independently is a hard requirement, you're going to want to follow some set of these practices. Otherwise you're probably not going to see any practical benefits relative to the additional complexity.
I inherited a project that was a collection of Lambdas set up with the Serverless framework - there are Lambdas that proxy HTTP requests to other Lambdas plus Lambdas sending messages via SNS to other Lambdas.
Tracing/debugging is difficult, and in many cases something seemingly straight-forward is more complex than it needs to be.
Currently used at my current company. It is a nightmare in terms of development. OTOH it is a nice feeling not needing to worry about servers suddenly going down or some sql query tanking prod, which Id say is the only upside
Have been working with serverless for quite a while now and I love it. It's been really good for our specific set of clients who already have extremely large user bases but zero digital tools. Being able to slowly transition into a digital version of their previously manual product without incurring any substantial infrastructure costs during the transition is extremely valuable to them.
However, Serverless has its flaws. I wrote a post a while back where I talk about the current landscape. It's a bit out of date, but if there's interest I might update it and post it here.
I had to work on an architecture like this for a company that had no business employing such an architecture. It sucked, but in attempting to help people on team "this is good" communicate with team "this is insane, terrible, illegal even?" I ended up probably growing more than anyone on either team.
When life hands you executives with zero accountability, make lemonade I suppose.
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.
This is such an insanely short-sighted and downright ignorant statement to make. Not everyone is working with highly abstracted "web applications". If your entire infrastructure doesn't think of anything lower than HTTP, sure. But the industry is so much larger and there are so many reasons to care about the actual hardware your code runs on.
Code runs on computers, and cloud is just a single word for "someone else's computer". Great, you've outsourced hardware provisioning, maybe even OS patches - that's smart, this is not your core business, just like toilet plumbing isn't. But you still need to hire someone to carry a pager, and when the plumbing fails, that person needs to understand what exactly went wrong - sometimes at 3AM on a Sunday. Engineering and operations is not just layering abstractions, we've had Lisp 60 years ago and yet it didn't solve everything.
I think the future is some BEAM-like VM abstraction for cloud environments. I worked at a 100% AWS serverless place and the current tooling is terrible. Now I'm working in Elixir and it offers so many of the tools I wish I had when working there.
Some infrastructure decisions need to be made by app developers.
For example, anybody with hard security environments (finance, healthcare, defence) needs to make sure that some services aren’t available on the public internet but are capable of communicating with internal services.
This kind of networking requirement is essentially tied to the application layer - only application development organisations can know whether e.g the service to check why a user is banned should be on the public internet.
Such a decision could be expressed by app developers using infrastructure as code, UI toggles or physical buttons in a DC - but it has to be their decision.
Similar logic applies to DNS, data isolation, backup policies, caching strategies and much more.
Serverless is fine. I always find that people try to shoehorn everything into something trendy for no reason.
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.
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.
Pulumi is fantastic, just wish it was more popular honestly. That and how you have to handle async stuff with it feels kinda weird in the era of async await in JS.
But it's wild, our tech stack at the company I'm working at is Typescript all the way down. Frontend, Backend, Infrastructure is all typescript. Our team loves it. We also use serverless. Given the perspective in this thread I'm expecting downvotes but we love that too.
I think serverless is just like everything else. If you implement it poorly it can be slow, expensive, and pointless. If you implement it well it can be cheap, fast, and keep your team lean.
> Given the perspective in this thread I'm expecting downvotes but we love that too.
It's a sad commentary that this is the case on HN. People using down votes as lazy disagreements against an opinion they don't like is fundamentally anti hacker IMHO.
I know what you mean but it’s been quite fine for me. With AWS, you have a JMS compliant message router in SQS, and SNS is okay, just might need an adapter to the message schema. I don’t like some of their limitations that are foreign to me when integrating over Artemis, Pulsar or Rabbit, and Kafka. Lambdas are just runtime system containers, you can use Spring Cloud Functions or any of the myriad of compatible approaches. RDS is but a scaled HA Postgres or MySQL service. Redis, DynamoDB, MKS, Keyspaces, and so on, can all be hosted on-premises. Not really a lock-in.
> I don't think that's the way most people are going anyway
Unfortunately some are. And not only that, but also full steam ahead on a 100% locked-in, read _all_ the AWS (serverless)services, AWS-only stack. I speak from unfortunate experience.
Yup me too. Just got out of working at a B2B SaaS that was 100% AWS serverless - Lambda, S3, dynamoDB and all that.
I worked there for 3 years! When I started 3 years ago - the owners touted the benefits of all of it. And I agree its not all totally bad. There are some valid use cases for small enterprise projects.
BUT after 3 years it was really starting to wear me down. The codebase just kept growing, there were so many lambdas to keep track of. It was so hard to test and observe the system in production. Sure you can address some of these pitfalls by creating your own tools that wrap AWS API calls but it never ends. It doesn't make your life easier, you still have to write a bunch of extra glue code because a lot of the tooling for these serverless platforms is terrible and left up to frameworks to solve.
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.
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.
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.
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.
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.
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.
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.
"Is there any reason why there's a "server" or "serverless servers"?"
Yes, you can not run compute processes without compute. A server is where that compute happens. Serverless is a concept that your function will run on "some" compute, that you don't have to manage. It does, however, require compute. So running that function on your mobile device, a server, a fridge, all within the realms of possible. You still, in the end, need compute to execute the code.
Decentralized compute (running on your devices or someone else's) is what serverless is (only, it's wrapped behind a service offering so it's not completely decentralized).
Whatever it is, just drop it and use computers that can execute some high level languages like JavaScript to perform directly useful actions like storing information in embedded DB like SQLite, reading information, transforming information, transmitting information and displaying information - stuff that can be done with huge performance even on 5 years old mobile phones.
So all that "serverless" stuff is basically that but its using traditional server software behind the scenes to provide maintenance free interfaces to do all the things I mentioned. Another aspect is that the client devices may connect to server resources and directly manipulate data without an intermediary code on the "server" and you still don't need specialised hardware to handle it, its handled cryptographically using algorithms that any computer can run.
The problem with it is that its proprietary non portable software that locks you in. Instead of that, you can run the exact same software on every computer(in the datacenter, at the company building, in the hands of people etc). Bottlenecks occur in certain situations, so you don't store all your clients information on every machine and the problem is solved. You run the same platform everywhere but each machine operates with an algorithm suitable for its role.
Modern consumer computers are beasts, they are capable of processing huge amount of data. Its common for handheld devices to load megabytes of of JavaScript, compile it, render graphics with it, handle inputs and send data tens of times per second to multiple servers as the user is interacting with it. I don't believe that a device capable of doing that will have hard time storing and fetching from an SQL database with a few thousand rows.
You just described one tier of the n-tier architecture. Yes, modern compute devices are fast. However, those devices that produce that data have to send that data… somewhere back to the company that cares about it. In your model, they would just write it to the company’s database? All 1Billion of them? C’mon. Even if you had a decentralized network capable - you don’t have a compute device in the world capable of handling that amount of traffic. Even if each device processed a chunk, and you had an efficient network to coordinate execution operations, you still need to get that data to its “caller” which would bombard it with interface calls exceeding its sockets.
So I appreciate the lively discussion on how modern consumer hardware is awesome, it’s only on the edge of a vastly bigger compute structure.
Fun fact, most companies don't have 1 Billion customers. Most don't even have 1000. They can have large data due to the subjects they may work on but that data tends to be accessed sparsely(i.e. a SaaS that provides KYC products to 10 regional banks).
Google, Netflix and the few other exceptions probably should stick with the traditional stuff for now but there's a huge number of companies that just don't need those hugely scalable systems and sacrifice flexibility and/or spend resources on problems they don't have.
Central sever architecture is dominate because it’s easy. I can buy an IP address within a a data center and it will be routable. The lack of IPv4 addresses made giving every client on the internet an unique IP cost prohibitive for ISPs so we created NAT. The majority of clients who only connect to hosts are behind at least one NAT making them very difficult to address uniquely. The client must initiate a connection for an entry in NAT table to be added and allow for outside entry into the network. Further, more devices are mobile or on very dynamic IP systems that cause them to hop among many different IP address throughout the day or even hour. Trying to establish a connection to devices that have no static IP address is a problem that has no real elegant solutions but always defers to some known authority - the central server.
If we were to solve, once and for all, this ad-hoc, client-client connection system, P2P communication does require trust that many applications simply cannot tolerate. Game servers exist to validate client input, register actions, and distribute them to the players in the game, banking apps verify you are who you are and allow the movement or viewing of money, etc.
I don’t see a future where we fully leave the world of central servers behind but I do see one where we value P2P more and create public routing systems that enable this more freely.
The network architecture is a valid concern but IPv6 is a thing and AFAIK it solves a lot of the problems. With the scarcity of IPv4 addresses, and the ubiquity of the connected devices the push appears to be finally here as hosting providers are ramping up the costs for IPv4.
Besides, even if the client-server architecture is to remain, I expect to see significant simplifications on the algorithm deployments. By that, I mean server apps becoming easy to run and manage as WhatsApp on iPhone.
No more complexities related on running python and all its libraries on Linux on some datacenter. Instead, it should be possible to have an app that just runs and takes care of some high level code that is possibly generated by AI.
For example, maybe in near future we will be able to tell some LLM to create an app that does something useful for us(i.e. track orders on Shopyfy and send personalised questionnaire about the delivery) and deploy it to anywhere(own server at home, Amazon, DO etc.) and never think about the complexities of deployment and only deal with the value added part of the process.
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.
I agree. My team has been building systems integrations for years, and it's figuring out what the customers want, and dealing with bad, inconsistent data accumulated over decades that makes life hard. Moving these boring microservices that handle this data from on-prem to the cloud wouldn't solve any of our problems. Most of our customer-facing services also run with on-prem VM instances just fine.
