[HN Gopher] Post-Serverless Era Trends
___________________________________________________________________
Post-Serverless Era Trends
Author : bibryam
Score : 38 points
Date : 2024-01-22 19:26 UTC (3 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| andrewstuart wrote:
| Serverless - there's the strongest cloud lock in right there.
| willsmith72 wrote:
| Eh you can still use a lot of the regular frameworks and
| libraries on top of serverless, and then easily switch between
| cloud and on prem.
|
| I wouldn't go all in in a stack which only worked for example
| on lambda, but I don't think that's the way most people are
| going anyway
| emestifs wrote:
| > 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.
| mikhmha wrote:
| 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.
| jmaker wrote:
| 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.
| xnx wrote:
| 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.
| packetlost wrote:
| 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.
| rollcat wrote:
| 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.
| mikhmha wrote:
| 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.
| mrtksn wrote:
| 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.
| reactordev wrote:
| "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).
| mrtksn wrote:
| Compute? Never heard of it.
|
| 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.
| samtho wrote:
| 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.
| mrtksn wrote:
| 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.
| teknopurge wrote:
| 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.
| spacephysics wrote:
| 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.
|
| Cost also includes the orchestration and such
| sn0wf1re wrote:
| 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).
| tetha wrote:
| 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.
| camgunz wrote:
| 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.
| jzelinskie wrote:
| 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.
| camgunz wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| gatvol wrote:
| 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.
| willio58 wrote:
| 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.
| mind-blight wrote:
| What Typescript infrastructure code are you using? I'm
| looking for alternatives to TF, so if love to know what's
| working for people
| freedomben wrote:
| This is very much a meta comment, but:
|
| > 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.
| fvdessen wrote:
| 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 :(
| netghost wrote:
| 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.
| gofreddygo wrote:
| 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.
| jamesfinlayson wrote:
| 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.
| teaearlgraycold wrote:
| 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.
| ardaoweo wrote:
| 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.
| skywhopper wrote:
| 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).
| lgkk wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-22 23:02 UTC)