17 ms·

Serverless first is a mistake. It should be "serverless where it's distinct advantages are actually useful" which is way less common than people think. Also ge

• foffoofof 3y ago
  Is jvm pg and k8s boring enough? K8s is overkill. Jvm is heavy. Pg is fine but relational dbs generally suck.
  • beckingz 3y ago
    elaborate on how relational databases suck?
    • vbezhenar 3y ago
      They're not web scale. https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
    • foffoofof 3y ago
      Try streaming updates to a query without polling…which is essentially all web apps. It’s fundamentally the wrong approach and people don’t realize. The relational model is good for analytics. Think about how often you need to know the internals or you have to debug perf by trying to get a black box to do what you want. Devs should be a layer deeper.
  • sanderjd 3y ago
    What is better than relational dbs (and for what purposes)? I've been learning k8s fundamentals recently after using borg for a long time and then awhile kind of just poking at k8s trying to use it without learning it. Honestly I think it seems like about as simple as a solution to a broad set of real common problems could plausibly be.
    • foffoofof 3y ago
      Relational dbs are based on relational model. It’s a giant black box of magic. And it’s magic is based on a bunch of constraints to make the relational algebra work. It’s really quite flawed for modern web apps.
      • sanderjd 3y ago
        It ... really isn't a black box of magic? It's a transparent box of - as your comment points out - implementing a particular mathematical model. You're gonna need to give me some more on why it's "quite flawed for modern web apps". I may even agree with you, but it's tough to know from what you've written so far.
        • foffoofof 3y ago
          > isn't a black box of magic Referring mostly to the query planner - you have no control over it, and you have to dive deep to figure out why it's making certain plans, and how it collects statistics to make these calls. Plus the planner essentially gives up at 6+ joins. > quite flawed for modern web apps Try listening to updates on a query.
• Jasper_ 3y ago
  Hearing K8s described as "boring" made me chuckle.
  • NickBusey 3y ago
    It’s just yaml. It’s pretty boring.
• sfvisser 3y ago
  Really strong language without any backing arguments whatsoever. You can’t just pick some random tech and decide this is boring tech so it’s good and so the other is bad and has always been. This type of comment is so incredibly meaningless and infuriating. Please explain why you are saying what you’re saying so at least we can learn from it.
  • mjr00 3y ago
    I do think specifying JVM/PG/k8s in that comment was a mistake. Boring tech will be different for different people and companies. Boring tech doesn't just mean it's time-tested and battle-hardened, it means you have deep knowledge across the company because you've used it for so long. I'm in a Python shop, so Python is my boring default tech stack choice. If I introduced C++ into our tech stack, it would be not-boring tech for us, despite C++ not being a cutting edge language. k8s is funny to call "boring tech" because it's notoriously complex. But if your company has set up dozens of k8s clusters and has a bunch of k8s experts on staff, it can be considered "boring tech." It's all relative.
    • jpgvm 3y ago
      Yeah probably. I should have specified "sufficiently boring tech stack of choice".
      • dylan604 3y ago
        or append "for example"
  • jpgvm 3y ago
    Serverless actual pros: "infinite" (meaning wallet level) scalability. Integrated deployment tooling usually. Integrated ingress usually. Those last 2 really don't matter though as neither problem is that difficult if you know what you are doing. They both would have been a huge selling point in a world where k8s doesn't exist. Alas it does and thus mostly moot. The first however is a big deal as managing very bursty loads on k8s can actually be a bit of a challenge. This is doubly true when you are using some sort of queue and don't have good queue scaling metrics for whatever reason. Serverless lets you cop out of managing that by using infinite concurrency. Ok so now cons of serverless: Turns all your code into spaghetti, this is probably the biggest one. Cold boot performance is highly varible and generally worsens with added function complexity but this depends on tech choice. Infinite concurrency is a bit of a curse. Want to use that MySQL DB that contains all your business critical data? Better use some MySQL Serverless proxy nonsense because unbounded connections isn't fun. Lock-in is awful, migration story is awful. Amount of Infrastructure as Code overhead, ala Terraform, CloudFormation, whatever else floats your boat to support serverless is insane. The sheer number of objects that need to defined, kept in sync etc is just bonkers. Not to mention if you have multiple services setup like this it's all boilerplate you either need to abstract or carry around. Hides serious programming deficiencies like memory leaks because context is thrown away after servicing request. Unpredictable runtime makes observability more complicated, probably forcing you into poor decisions as a result, i.e prom push gateway. Runtime/execution time limits mean people trying to do all-serverless end up doing horrible things to accomplish long-running tasks. All of the above leads to increasing pressure to make poor architectural decisions to work around limitations of the runtime. I could probably go on but that is a reasonable set for you. EDIT: Actually I forgot the worst con. The cost. The $/CPU/RAM cost of Serverless is beyond bonkers. When I was pricing up Cloud Functions vs Spot instances on GKE I think I came to the conclusion Cloud Functions are about 300x as expensive. If your code can run on serverless it can probably run on Spot instances which you can just add to your GKE deployment using another node pool and only schedule things that can handle nodes going away within 60s there and instantly reap 300x cost savings. This is because Serverless is sold at a massive premium to CPU list prices and Spot is sold at like ~30-40% of list prices depending on machine type (for those curious when I last checked T2D was the best for price/performance for highly single thread performance dependent workloads, ala Node.js)
• Tainnor 3y ago
  I don't care for serverless, but your suggestion that the only right way to build software is by using the JVM, and the only right way to use the JVM is to use Spring or Quarkus is... puzzling to say the least. I might as well say that you should run everything on PHP. I guess that's boring too?
  • jpgvm 3y ago
    You can sub JVM for something else but you should probably stick with PG and k8s. What I am saying is the highest quality tools are still the best and will remain that way. As other things come and go they absorb the best ideas from the new stuff without losing what makes them good. Sometimes the new stuff survives (Node/TS/Go/Rust) sometimes it doesn't (Clojure, Scala, arguably Ruby), some we are waiting to find out. But betting on JVM and .NET has been winning strategy from a technical perspective for a long time now. Also worth mentioning no, PHP probably doesn't work here because it's not "general purpose" enough IMO. JVM can handle almost any workload shape, the main one it doesn't do well in is memory constrained environments (though it's possible if you really want to). PHP, Node/TS, Python, Ruby all suffer from being single threaded so can't take advantage of properly large machines without a ton of extra complexity and you pay a high memory overhead for most of those strategies. Go is OK, I hate writing it but it can do all the things so if that floats your boat go for it. Rust is also perfectly fine, I just find it is actually pretty slow to write because changing requirements often mean changing structure which can be harder to manage in Rust vs Java/Kotlin/C#. Anyways, wasn't meant to be a thing about languages. Just pick a good runtime or AoT lang of choice, write everything in it, stick to conventional frameworks, choose PostgreSQL, run the lot on k8s. That is the core takeaway.
    • foffoofof 3y ago
      Agreed re: jvm and .net. It’s easy to imagine a resurgence in the future.
      • re-thc 3y ago
        Java by all accounts and if jvm include Kotlin is 1 of the most widely used. Do you still want a resurgence? :)
• erulabs 3y ago
  The amount of complexity created in the desperate attempt to avoid learning k8s APIs has at this point, dramatically out complexified k8s itself.
  • politelemon 3y ago
    The quadratic function that represents the hand waving away of k8s complexities causes a stack overflow exception.
    • deleted 3y ago
      [deleted]
  • Arbortheus 3y ago
    I see the anti-K8S sentiment so much on hackernews. Sure, there’s a time and a place for K8S, but I see a lot of point-blank objection to it for often weak reasons.
    • nova22033 3y ago
      It's bloated Often this translate to "It has features I PERSONALLY don't need or understand"
      • jpgvm 3y ago
        I generally find people that don't like k8s don't understand it or more commonly even the reasons why it exists. If your job hasn't been to write Cloudformation/Terraform/Pulumi/Chef/Puppet/Salt/Ansible/Capistrano/Packer for a living, you might not appreciate it. As someone that has been around the block I think k8s is the best thing since sliced bread.
• afandian 3y ago
  I’m building something with Spring Boot, Kotlin, Postgres and containers, with a small team. It’s far from boring, it’s the most fun I’ve had in ages.
  • jpgvm 3y ago
    Yeah I very much prefer Kotlin now. It's Boring Tech but at the same time pleasant because of it's high expressivity and tooling. Also I find it way easier to convince people coming from a dynamic language background to try it out vs Java which they find less approachable. Which is ironic as Kotlin is by far the more complicated language vs Java.
    • re-thc 3y ago
      > Also I find it way easier to convince people coming from a dynamic language background to try it out vs Java which they find less approachable. It's just a sad fact of Kotlin is not Java. There are lots of people out there that just hate on Java as a hype train.
      • jpgvm 3y ago
        Yeah it's sad. Java is really really good these days.
  • switch007 3y ago
    Spring is fun until you need to do anything mildly complex and then you tear your hair out trying to find the right documentation. You have to navigate myriad of sub projects. They really really need to sort out the SEO. It’s atrocious. The only way to learn Spring is to read the latest manuals of every subproject you think you might need, cover to cover. Even then you might not figure out what awkward collection of beans you need to override the magic Spring does.
    • jpgvm 3y ago
      I found Spring to have a little bit of an understandability cliff. Coming from Guice though once I understood the container and had a feel for the general patterns it was easy. I think if you try to use it without understanding the magic you can probably get pretty far but you will always feel lost when things don't work just like the example. Understanding how all the runtime wiring works at the DI/IoC layer generally makes it pretty easy to work out what is going on though.
• opmelogy 3y ago
  > All the points noted in the slides etc just come from poor engineering leadership. i.e decisions/choices, etc. Hindsight is 20/20. It's easy to make these claims after the fact. In the moment it's far more complex and the decisions made at the time take in a lot of factors. Oversimplifying things and placing blame on a tiny thing doesn't push the discussion and learnings forward. Lambda came out in late 2014 and Step Functions came out in late 2016. It's entirely likely that this team was an early adopter of the tech. Internally a lot of these AWS technologies have a roadmap that sound like they will solve a lot of your issues but those roadmaps get tossed fairly regularly as priorities shift at the product level and AWS-wide level. We won't be able to get the info on what went on here (likely the team that improved things doesn't even know due to turn over). But watering it down to be "poor engineering leadership" is off the mark and way too simplistic.
  • jpgvm 3y ago
    I wasn't talking about the Prime Video case, I was talking about the slides in Adrians blog post which compare Serverless with traditional development. IMO if you are facing those problems it has to be poor leadership, there is no excuse for why you shouldn't be able to make effective decisions if you know what you are doing.
• sanderjd 3y ago
  Doesn't JVM here result in some amount of "dicking around" with respect to which JVM language to use? Or do you mean that it doesn't matter, as long as it's all JVM? Or do you mean to just pick java? One thing I've seen in my experience generally buying this "standardize on boring tech" take, is that it's really common these days for a company to be doing some amount of "serious" data science work, and most people seem to really want to do that in python, and it also seems to benefit pretty significantly from some kind of OLAP database system. So adding those things onto your "boring" stack becomes JVM+psql+k8s+python+snowflake/databricks/duckdb(?). But I agree with your real point about serverless.
  • jpgvm 3y ago
    Generally speaking your data-science stuff wouldn't fit into the serverless bucket anyway though. Also generally Python is just used for terminal processing in the Big Data world, all the pieces in between are JVM anyway.
    • disgruntledphd2 3y ago
      Yeah, I mean if you're already a JVM shop then you could probably run Spark yourself (which can be painful) and use SparkSQL to dump to Python (maybe on databricks, though I'm not a massive fan) and do your fancy ML stuff there. Alternatively, you could just use a read-only PG replica and Python here, which would suffice for most DS needs (unless your core product is DS related or you have huuuuuggggggggeeee data (which you probably don't)).
      • jpgvm 3y ago
        Yeah that is fair too. Most people have tiny data. Then there is places I have worked... where 10TB qualified as small data that you "just query with Presto" and where more exotic things were needed for actually interacting with the "big data". All relative in the end.
        • disgruntledphd2 3y ago
• romanhn 3y ago
  As someone who went with Lambda for my current project, I don't agree with this take at all. In fact, it's as boring of an implementation as you can imagine - a single "fat function" developed in .NET serving the entire web application. Can be easily transplanted onto any other hosting paradigm, but Lambda is incredibly cheap (free at my current usage) and incredibly scalable should I hit some inflection point. Learning K8s would have been quite an overkill.
  • fallat 3y ago
    k8s is not as hard as its advertised
    • ghaff 3y ago
      One of my recent conclusions is that it's not so much that Kubernetes on its own is so very complicated; it's that if someone tries to glue their own container platform together from Kubernetes plus another dozen or so cloud-native projects and integrate the whole thing, it can get wickedly complex very quickly.
      • derefr 3y ago
        Right — Kubernetes was evolved in the context of being a Google Cloud service, and despite now having other deployments, still is mostly architected around the assumption that your Kubernetes cluster is surrounded by a featureful IaaS platform providing things like managed load balancers, VM auto-scaling pools, iSCSI volumes on a dedicated SAN network, non-throughput-bottlenecked object storage (and a container image repo on top of that!), a centralized logs and metrics sink, etc. A k8s cluster expects these like a computer expects a bootable storage device. If you're using a managed Kubernetes (in GCP, or AWS, or Azure, etc) then the owner of the platform presumably has all this stuff going on somewhere (whether they expose it to you or not), and so is solving all these problems for you. But if you're not using managed Kubernetes — i.e. if you're ever typing `k3s deploy` or whatever equivalent — then you'd better realize that you're signing up to either also deploy and manage your own bare-metal OpenStack deployment for your k8s cluster to plug into; or to tediously glue together a grab-bag of services from your hosting provider + third-parties to achieve the same effects. (And this is why Google's "Anthos" is an interesting offering to many enterprises: rather than running your own on-prem k8s cluster implying the need to own+manage on-prem supporting infra, you can instead have a GCP project that has all the managed supporting infra, and maybe some hosted k8s clusters; and then your on-prem k8s nodes can just think of themselves as part of that GCP project, relying on the same cloud infra that the hosted clusters are relying on — while still being on-prem nodes, and so still having data security guarantees, low-latency links to your other on-prem systems, etc.)
• xg15 3y ago
  > Serverless first is a mistake. It should be "serverless where it's distinct advantages are actually useful" which is way less common than people think. Wouldn't that approach take away the remaining advantages of Serverless while still leaving you with the cost? My understanding was that Serverless is supposed to free you from the burden of maintaining a complete software stack, including configuring the db, server, application runtime etc and just focus on the business logic - a bit like one of the old "sharehost"/LAMPP setups from a few decades ago. If that is true, then you'd be well-advised to either go all-in and structure your entire application as lambda functions, or don't use functions at all and go with a "traditional" kubernetes deployment. As both strategies come with considerable complexity cost, combining them would give you the cost of both. I think you'd want to avoid that if possible.
  • jpgvm 3y ago
    Somewhat. I think if I was to ever use serverless for something it would be in concert with a traditional setup so in a way yes, you pay 2x the deployment complexity because now you are orchestrating 2 environments. However if you have a usecase that is absolutely a perfect fit for serverless i.e incredibly bursty, unpredicable, very short runtime. To the point it would be to the detriment of other services hosted on the same infrastructure i.e would need say an isolated cluster anyway then yeah, serverless could be a cost worth paying.
  • vbezhenar 3y ago
    Main issue of lambda and similar offerings is that you're pretty much bound to the cloud. Kubernetes is much more open standard. It's much easier to move to other cloud or self-host. It's more about insurance and keeping other options. Managed Kubernetes, managed databases are a thing and you should use them if you can. Just don't depend on cloud-specific stuff too much.
• waboremo 3y ago
  Actually your comment is a great demonstration of poor engineering leadership. You've already decided on an outcome and are shifting the narrative to adhere to this outcome. The labelling of JVM + K8 as boring, to posture why it's automatically superior to "serverless integration crap" is exactly the sort of thing poor engineering leadership does to avoid having the sort of difficult conversations necessary. There's no metrics involved, no studies, no prototypes, no financial assessments, none of that it's purely based on emotion. You can envision the same exact thing happening (but to the preference of serverless) on the Prime Video team.
  • jpgvm 3y ago
    It's not emotion. I make money from porting people off of poor technical choices onto solid ones. It comes from experience working with all these various systems. I have used (at large scale) GAE, Google Cloud Functions and Lambda, before that I also used all the previous "serverless-like" things including Beanstalk (anyone else even remember that?), Heroku and bunch of other PaaS things for various stuff. It's all come and gone. To me serverless is just the latest in a long line of things that I get paid to replace with things that actually solve the problem and doesn't turn into a ball of spaghetti that no one is able to modify anymore.
    • Spivak 3y ago
      Seconded, just got done with one of these. Literally 1200 separate lambdas, step functions, hundreds of kinesis streams, and sqs topics plus a smattering of ecs fargate tasks for when invariably something takes longer than the max lambda time. And oh god all the stupid supporting infrastructure to build layers. There primary app was Rails, you know what replaced all of it? Running the synchronous tasks on the app servers themselves, the async ones on Sidekiq and changing the max instances on the two ASGs. The only downside has been not being able to meme about how we're web scale anymore.
      • jpgvm 3y ago
        Not being able to make jokes about how fast it is to serve requests from /dev/zero must be absolutely killing your team. However, great job. Once they get to that scale of objects it becomes really hard to clean it up - especially if most the people that wrote them have already left the company for example. Curious if you ended up also saving money in the process?
• jimbob45 3y ago
  How are you going to throw away the competitive advantage of serverless first if you’re a startup? You’re just asking to lose to whichever of your competition that goes serverless first. However, if you’re a massive company like Amazon working on a less-than-cutting edge project, you certainly have the resources to avoid serverless up front to avoid rewrite costs down the line.
  • glutamate 3y ago
    LOL. Competitive advantage comes from understanding user needs, great UX, and a smooth running sales machine. No-one cares that you built with technology X, whatever that is. There is no silver bullet.
    • namaria 3y ago
      While I agree with the conclusion, competitive advantage is by definition very relative. It might be what you say, if you're producing some sort of saas offering. But it might be something completely different as well.
• jonfromsf 3y ago
  What is PG?
  • jpgvm 3y ago
    PostgreSQL
• hn_throwaway_99 3y ago
  Your comment highlights that you really don't understand what "serverless" is. We run a monolith running on App Engine "NodeJS Flexible". All of our code is basically a single Node monolith, and under the covers many of GCP's newer serverless options (like Cloud Run and Cloud Functions V2) run on the same infrastructure -it's basically just containers, and they even offer versions that let you simply deploy any Docker containerized app. But compared to the maintenance burden I've seen with other similarly sized startups that use k8s, we just spend way, way less time on infrastructure management. On a related note, this kind of language, "The only world where I can make a good case for serverless for small teams is if you have said poor leadership and serverless helps you escape their poor decision making." which is basically "if you don't agree with me you're an idiot", says a lot more about the speaker than the speakers usually realize, and it's a huge, giant red flag.
  • jpgvm 3y ago
    Yeah I am familiar with those (Cloud Run, Fargate et al) and they are much less egregious than Lambda and Cloud Functions. As for if they qualify as Serverless though I don't know, it seems poorly defined. How about I clarify that my stance mostly relates to Functions as a Service so it's clear that while I wouldn't choose Cloud Run over GKE that is hugely different to FaaS.
    • maccard 3y ago
      I think Cloud Run, Fargate and Azure Container Apps all fall more into the category of "platform-as-a-service" rather than "function-as-a-service", in the same way that EKS or GKE could be categorised as a PAAS. EDIT: I also think they're _excellent_ to use for development. The migration from ECS + Fargate to EKS + EC2 is not a difficult migration from the application side, and can be done relatively piecemeal, in my experience.
• GuB-42 3y ago
  JVM+PG+k8s is absolutely not "boring tech" to me. LAMP, this is boring tech. You can switch Apache for Nginx, and MySQL for another SQL database, but that's the idea. People still develop in PHP today, and performance-wise, assuming you follow standard good development practices, and good servers, it can take a lot. If it was good enough to get Facebook started, it is most likely good enough for you, and the situation has much improved since the early days of Facebook, a lot of it thanks to Facebook itself, and also better hardware. PHP security is not as terrible as it once was too. At work we have a couple of Spring projects, and I don't think I have hated a tech stack more than that. If you to illustrate the "action at a distance" anti-pattern, look no further. I'm sure most Spring web apps could be implement in PHP for a fraction of the size, both in terms of application code and memory. I don't do k8s, so I have no real opinion except that it looks like overkill in many cases. As for Postgres, nothing against it, it is a very good SQL database, though my opinion is that you should limit yourself to basic SQL as much as you can, so that you are not dependent on a particular database.
  • cutler 3y ago
    I don't get how a Spring app rewritten in PHP, assuming a framework is used, reduces code significantly given that PHP5+ is a dynamically-typed Java clone with the same mind-numbing boilerplate.
• MuffinFlavored 3y ago
  > Boring Tech stack of JVM + PG + k8s. We live in a new time where k8s is "boring" and grouped in as such.
  • jpgvm 3y ago
    For infra folk that lived through the "before time" it certainly is and damn is it refreshing that it's become boring at most places. :)
• websap 3y ago
  Serverless first is a great way to start building your business. As long as you don’t have strict latency requirements. You focus on your business, while the infrastructure requirements are handled for you. The point of engineering is to deliver the best solution and the right cost. Cost needs to be evaluated on multiple dimensions - actual dollars, time required to build, time required to maintain. Nothing stops you from using Postgres with Lambda. AWS has done a bunch of work to make this possible. I would recommend, creating the correct layer of separation in your code, so that when the times comes to migrate from Lambda or other serverless functions to Fargate, cloudrun, or even containers run on VMs managed by K8S, you have to make minimal changes to get up and running.
• emodendroket 3y ago
  I can't help but laugh at this when I think of how easy it is to imagine the exact same tenor in a post dismissing Kubernetes as newfangled, overcomplicated garbage.
  • jpgvm 3y ago
    Yeah there probably were people that wrote those. Not me though, I had been through the whole wringer before k8s so I knew what it was when I saw it. I was working on a competitor to k8s at the time though so my knowledge of the subject matter definitely influenced my opinion of it. I thought it was unstable though, largely due to dependency on etcd which was also unstable at the time. Thankfully that got sorted out though.
• ChicagoDave 3y ago
  Wow what an emotional and biased take. Architecture isn’t like Lord of the Rings where one ring rules them all. What if the dev team doesn’t know Java? Are you suggesting they be forced to learn it? What if the company has 20 applications with complex interactions? Are you suggesting they all be baked into k8s and then have someone manage containers full-time? What if no one in the company understands containers? I’ve been at this for 40 years and will tell you there is no common architecture environment. There can be any mix of business logic, services, data storage, containers, events, queues, redundancy, reports, analytics, external systems, 3rd party black boxes, skill sets and levels, budget, tech stack, and leadership. Trying to pigeonhole any architecture into that mix is the very definition of amateur.
  • jjtheblunt 3y ago
    > Trying to pigeonhole any architecture into that mix is the very definition of amateur. I’ve also been at this 40 years and what you ended with is worded unnecessarily crass, in that folks of course learn perspective over time.
    • ChicagoDave 3y ago
      I think I was matching the same tone as the previous comment.
• richardw 3y ago
  Stop with the confident silver bullets. There are effective teams using every stack out there, including serverless. The professional chooses the right tool for the job and team. This is an instance of one change between options that happened to blow in the direction you like, but there are good options at all points of the continuum. I've used most languages in on-prem and distributed settings, from app to web app to micro services to serverless to single DB's of all kinds to distributed everything, in all clouds, and all have their place and time and team. Sometimes I'd arrive with a perfectly confident view and then learn that actually there is another truth. Sometimes a 50-page stored procedure is perfect. Microservices is awesome in the right context, monolith in the right context, just stop with the simple answers because you have a particular lens that works for you. What a single lens does really well is that it removes options and that makes you faster at how you solve most problems. Good for you, simplicity is excellent. But don't diss professionals and their leaders who have made choices and then adjust them based on the data.
  • jpgvm 3y ago
    There is a big difference between learning the nuances of engineering as you go and re-adjusting your viewpoint vs bandwagoning on a new tool because it's cool even though you can't tie any of it's advantages back to your problem statement. That isn't making a choice and adjusting based on the data, that is just shoddy engineering. It should have been obvious to anyone at a cursory glance that not only did serverless not offer anything to this application it would be actively detrimental. Simple napkin math of data rate of a 1080p video stream should have made that immediately clear. Just because you can use something to get a task done doesn't make it a good choice. I can still write pretty decent Perl. It gets the job done and for some protocols that haven't changed in a long time like LDAP the existing CPAN libraries are still some of the best. But that isn't the right choice is it? I don't think it's defensible to argue that we should build thing sub-standardly just to give people more choice. That is like arguing that real engineers should have more freedom in choice in how they design bridges. No one would agree with that. We get away with it because our bridges are much cheaper to replace and noone dies if they break or have to be rewritten because they rotted too much to run anymore. Right now as it stands arguments for serverless aren't technical in nature. They are a best an appeal to "the traditional way is slow" or some notion of "infinite scalability", the first of which isn't true at all and the latter doesn't matter for anyone that is arguing in favor of serverless. Also even if it was "faster" (I don't agree but lets postulate) that probably wouldn't make it a good decision either unless it was proportionally faster vs it's costs (not just dollar costs, architecture, complexity of managed objects, etc). Which I highly doubt would be the case. As you can see from a technical POV it's just very very hard to rationalise a position for serverless > Boring Tech. For me it would take too much mental gymnastics. I was perhaps a little strong but my points are solid. If it was good it would have proven advantages by now. K8s adoption curve vs serverless adoption curve tells the real story of quality IMO, especially given how much bigger of a move it was to k8s from what preceeded it.
• throwawa23432 3y ago
  I'm confused by your language since you can do "serverless" or "FaaS" or "cloudfunctions" on k8s.
• deleted 3y ago
  [deleted]
• winrid 3y ago
  When I talked to people at Amazon it sounded like there was a huge push to dogfeed Lambda. The guy was almost worshipping it in the interview and appalled that I wasn't interested in it. :)
• scarface74 3y ago
  “I don’t think you need unnecessary complexity. You should use Kubernetes” There is a certain lack of self awareness. What exactly do you think that serverless is besides spinning up VMs on demand where you don’t have to maintain the orchestration?
  • jpgvm 3y ago
    I personally find k8s to be much simpler to use. Both are complex internally, k8s does a better job of preventing that complexity from leaking IMO. You need to know roughly the same amount of things to use both. On k8s to deploy something simple you will need: 1. A deployment to actually run your app. 2. A service describe how to talk to your app. 3. An ingress to route requests to the service. On Lambda w/API Gateway: 1. Lambda Function 2. IAM Role 3. API Gateway objects (Deployment, RestApi, Stage) More if you expand out the policies and API gateway objects. These become -really- burdensome if you are using IaC like Pulumi or Terraform. In practice using k8s these days is essentially managed also, ale GKE/EKS/AKS so the real differences are down to: 1. API, the FaaS etc ones are proprietary, k8s is standardized. 2. Runtime environment and execution limits, varies by FaaS, k8s has none. 3. Access to durable storage, FaaS only object/HTTP based storage, you can attach EBS-like to your k8s containers. 4. Architecture incentives. FaaS highly incentivises microservices, k8s isn't really opinionated. FaaS is more like cgi-bin on steroids, k8s is daemons on a box but with fancy management. 5. Scaling. FaaS scale "infinitely", k8s scales depending on settings of cluster autoscaler. So generally you get as good or better from k8s, the API complexity is about the same except now it's standard no lock-in, no enforced runtime limits, you have durable containers so you can attach a debugger, etc. Hopefully this shows a bit why I think k8s is at least as simple as serverless if not more simple.
    • scarface74 3y ago
      Anyone who says that they aren’t “locked-in” hasn’t done a large migration and dealt with both the technical and organizational complexity of any large migration. I’ve been involved with organizations that just literally wanted to do a “lift and shift” of 100s of VMs and databases. They were definitely didn’t have any “vendor lock in”. Guess how long it took? Guess how much regression testing it took and planning?
• optimuspaul 3y ago
  I disagree very much. I don't think any blanket statement like that makes sense. I recently started building a service and need to keep costs down. Serverless is perfect for it. My service has low to moderate traffic, costs pennies to run on AWS Lambda and MongoDB Atlas. If I had gone the boring route of JVM + PG + k8s, putting aside the time it would take to defamiliarize myself with anything on the JVM, the cost to run this service would have been in the hundreds of dollars a month vs the pennies. Interestingly the most expensive part of my current setup is the NAT Router on my VPC. With JVM + PG + k8s it would have been PG or K8S depending on where I ran PG. I do agree that there is a misconception with containers taking longer than server less. I don't think either takes longer considering the current tooling available. Seems like you got burned on Serverless at some point, I'm sorry that happened, but for many people and teams it is a productivity multiplier and can be a big cost cutting solution.
  • re-thc 3y ago
    > the cost to run this service would have been in the hundreds of dollars a month vs the pennies And maybe this again proves the initial comment's point. > I do agree that there is a misconception with containers taking longer than server less. I don't think either takes longer considering the current tooling available. And (the misconception) that it costs more. > AWS Lambda and MongoDB Atlas If you take a managed database with a free tier and compare it there are similarly managed databases (SQL) based with a free tier. Not really fair to say PG will cost more. This also comes down to the world is not just AWS. k8s is cheap in a lot of places and definitely not hundreds a month.
• quickthrower2 3y ago
  Serverless first is probably not a mistake in general. But we may have a different definition? For me Serverless means no need to administer a server (in the sense of "an operating system"). So baremetal, vps, = serverful And lambdas, app engines, firebase, ... = serverless There is a space where you are deploying a monolith app, and letting the cloud provider do the scaling, server management, environment management. But at any time you could run that same app happily on a server. I think starting off there is not a mistake. I think k8s is an advanced move. You can start off with the cloud built-in container management solution, then move to k8s later if you really need it.
  • jpgvm 3y ago
    yeah, I think I should have said something along the lines "Functions as a Service first is a mistake" but whatever, I didn't think people would focus so much on what they consider serverless is. IMO managed container runtimes are PaaS, are both FaaS and PaaS serverless? Who knows, we don't seem to have hard definitions but in my mind PaaS predates serverless becoming a fashionable word so I associate with FaaS and FaaS-like things only.
    • quickthrower2 3y ago
      Safest to say the exact thing (or list of things) I reckon! Technically "serverless" should mean "no server" which means "no process fielding network requests" i.e. "unable to accept inbound network requests" - so some kind of batch processing system, or scheduled lambdas :-)
• r3trohack3r 3y ago
  I’m going to have to disagree with this. There are different shades of serverless, and you don’t start at an R620 plugged into a colo rack. You grow into it OR start with a large enough problem to demand it. You start with GitHub pages or Cloudflare pages where all you have is CSS, HTML, and JS served from the equivalent of a global CDN that you didn’t have to build for essentially free. For a mom and pop shop, how many times are they going to have to contact you over the next 20 years for a piece of software doing its job running on GitHub pages? Practically zero, unless it’s a feature request. Can’t say the same for a Linux box plugged into the wall under your desk or an R620 at the colo downtown. Then you graduate to sprinkling a little bit of persistent state in. When you need a little bit of persistent state for a small mom and pop, deciding to vet colo vendors and signing that shop up to be responsible for sysadmining an R620 with a Linux kernel is irresponsible. You find a serverless vendor for your DB layer (like the Firebase of yore) or a set of CRUD handlers written on infra that fully manages the language runtime, operating system, kernel, and infra for your customer (like Cloudflare workers). How many times is the customer going to need to contact you over the next 20 years for your Cloudflare worker? Probably only a handful. Odds are, significantly less than an R620 plugged into a server rack at the colo downtown. If you outgrow this, you probably are starting to look at VMs or colo. Serverless is real. It’s not lambda. It’s pervasive. It’s provides substantial value in ongoing maintenance and engineering costs if you pick the right vendor. And a majority of the market demands it as a starting point. An engineer is expensive and most customers aren’t in a position to practice the craft themselves. The best service we can provide is to minimize their dependence on our field.
  • danielheath 3y ago
    > How many times is the customer going to need to contact you over the next 20 years for your Cloudflare worker? Probably only a handful. Odds are, significantly less than an R620 plugged into a server rack at the colo downtown. This has nothing to do with "serverless". Heroku did the same thing well before serverless was available. Keeping a simple app running on heroku over the past 15 years has required about 3 hours admin total since I set it up (moving from an old stack to a newer one).
    • 3y ago
• siliconc0w 3y ago
  +1 that k8s really isn't that much more challenging configuration syntax than most 'serverless' solutions (which is a bit different than FaaS as in the article). The difficulty with k8s is (w/ a managed solution) generally the cost of running the control plane though most IaaS will 'give' you a zonal one for free to encourage more spend because inevitably you don't just need one, but ideally one per environment per app/product maybe even per engineer if you want eng to be able to stand up their own 'full' environments of beefier apps w/ lots of components and dependencies.
• mannyv 3y ago
  IMO serverless is incredibly useful when latency isn't important. Backend stuff, metrics, analytics, APIs, etc should be serverless. It allows you to scale incredibly easily at basically 0 cost. For everything else, you have to test and examine the use cases and performance requirements. In general if there's a UI that's doing work it shouldn't be serverless. Work = latency = bad.