Two Apps One Process

(andersmurphy.com)

4 points | by andersmurphy 7 hours ago ago

2 comments

  • andersmurphy 7 hours ago ago

    I'm curious what people think about this part: If a deploy is indistinguishable from network blip did the app really go down?

    • adityaathalye 4 hours ago ago

      Cool trick!

      How does this compare with shipping WARs, old-skool?

      How are app operations needs met? e.g.

        A] Availability through restarts:
      
      One for all, all for one restarts feels like the obvious downside. All apps blip if we update any one app. Does the "blip-time" depend on how long the updated app takes to come up again? i.e. If we bundle 10 "apps" this way and the one app takes (say) 0.5 seconds to start successfully, the total blip time would be 5 seconds.

        B] Crash survival
      
      If one app crashes on restart, doesn't everything go down together?

        C] Greedy neighbours
      
      If any one app misbehaves with GC or CPU or Memory, it takes down all other apps. How would one configure resource sharing policy into the JVM?

        D] Alternatives with similar operational properties?
      
      I'm assuming La Méthodologie Anders applies to apps aligned with Indie dev. / Tiny Co. nature. Real business / prod stuff, but not shackled by "Enterprise Needs (TM) (R) (C) All Rights Reserved".

      I feel we have a quadrilemma:

        - “Just use Babashka”
        - La Méthodologie Anders
        - WARs-shipping like it’s 1996 (OK we have Jakarta now, but I still like NGINX Unit with its forever-frozen Servlet 3.1).
        - Babashka till dynamic interpreter limit, and Graal-compiled thereafter on a case-by-case basis.