4 ms·

Not interested in serverless platforms that are only invocable by HTTP requests. That's very limiting.

• tgtweak 8y ago
  Would be great if they supported some kind of scheduling engine similar to airflow. Could replace a lot of cron jobs.
  • nodesocket 8y ago
    Would Google Cloud Schedule work (https://cloud.google.com/scheduler/ https://cloud.google.com/scheduler/). You can have the scheduled task make the http request.
  • Godel_unicode 8y ago
    App Engine cron is pretty sweet: https://cloud.google.com/appengine/docs/standard/python3/scheduling-jobs-with-cron-yaml https://cloud.google.com/appengine/docs/standard/python3/sch...
    • tgtweak 8y ago
      Nice, seems like a good workaround for now and a low hanging fruit to wire this up directly.
      • hn_throwaway_99 8y ago
        I use Google Cloud Scheduler, https://cloud.google.com/scheduler/ https://cloud.google.com/scheduler/ , to invoke Cloud Functions (actually Firebase Functions which are really Cloud Functions under the hood). You set up a Firebase function to run on receipt of a message to a pub/sub topic, and then in Cloud Scheduler you schedule a post to that topic.
  • brunoborges 8y ago
    Scheduling is easy on many levels. One could set a CICD job to do that (which is usually free in many cloud vendors). The business value though is in data-based events. Data is inserted/updated/deleted in databases (SQL and NoSQL), event streaming, queues, identity management systems, and so on. Until there is a way for Cloud Run to easily plug its 'functions' to those sort of events, the solution is not ready for real world use cases -- unless of course one is interested in building a whole distributed system architecture around webhooks.
    • tgtweak 8y ago
      I like that idea, say after N inserts to a database/bigquery or N requests to existing service, after a file is posted to storage, or once a VM variable hits a certain trigger, kick off cloud function. Great for mini batching ETLs, log cleanup/parsing, upload possessing, cache invalidation... So many use cases. That flexibility would be great. Hope this is on the radar! Cloud run triggers. Being able to pass the event metadata in would be great too.
• mythz 8y ago
  Why? What's so limiting about calling remote services over HTTP?
  • londons_explore 8y ago
    Http is pretty bad for long running requests (run this code which takes 6 hours), or bidirectional streaming (eg. Video conferencing) Other RPC mechanisms have no trouble with that.
    • mythz 8y ago
      Hooks are a popular approach for implementing notification callbacks for long running requests over HTTP. Bidirectional streaming is irrelevant here, the question is what's so limiting about using HTTP for this use-case? (i.e. by far the most popular protocol used for invoking remote service requests).
      • bitcurious 8y ago
        >Hooks are a popular approach for implementing notification callbacks for long running requests over HTTP. Can you post an example/blog post of this approach?
        • mythz 8y ago
          A good example is GitHub's Web Hooks which is common for notifying GitHub PR's of completed CI results: - https://developer.github.com/webhooks/ https://developer.github.com/webhooks/ There's also a Community WebHook plugin for ServiceStack: - https://github.com/jezzsantos/ServiceStack.Webhooks https://github.com/jezzsantos/ServiceStack.Webhooks
• dominotw 8y ago
  as opposed to ?
  • brokensegue 8y ago
    Some rpc standard presumably
    • SlowRobotAhead 8y ago
      RPC over what? If the discussion isn’t about HTTP, and we can set MQTT aside... what format and layer would the RPC go over?
      • brokensegue 8y ago
        Thrift over tcp?
• meddlepal 8y ago
  Doesn't seem like that needs to be a long term hard contract of the system. It sounds like it only supports HTTP/1.1 right now, but I can see HTTP2 support becoming a thing and that would then enable GRPC.