From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D0F207F919 for ; Thu, 19 May 2016 11:29:20 +0200 (CEST) IronPort-PHdr: 9a23:akR+TBJF2GxMfe9tE9mcpTZWNBhigK39O0sv0rFitYgULP7xwZ3uMQTl6Ol3ixeRBMOAu6MC0LCd6v2ocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC3oLsjavrptX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4DLDQBfHw2YGTmUH2k5NHhLZ7AC8VZf8rgP1s+N83G+ROsigHp4uXjH39aZ7RRPAiC4fLy89/XnLi8c2i7hU80HpnAB234OBONLdD/F5ZK6IOIpCHWc= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=rixed@happyleptic.org; spf=None smtp.mailfrom=rixed@happyleptic.org; spf=None smtp.helo=postmaster@pim.happyleptic.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rixed@happyleptic.org) identity=pra; client-ip=5.135.156.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rixed@happyleptic.org"; x-sender="rixed@happyleptic.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rixed@happyleptic.org) identity=mailfrom; client-ip=5.135.156.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rixed@happyleptic.org"; x-sender="rixed@happyleptic.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@pim.happyleptic.org) identity=helo; client-ip=5.135.156.187; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rixed@happyleptic.org"; x-sender="postmaster@pim.happyleptic.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7DwC9hj1X/7uchwVdgzdsvHCGEQIIgSs8EAEBAQEBAQEBZCeCLYIWAQEEOj8QCyElDwVJJ4gfAcNgAQEBAQEBBAEBAQEBAQEginKEJnyCSIIuAQSYMY4WjySPSTcrg2+HNYE9AQEB X-IPAS-Result: A0A7DwC9hj1X/7uchwVdgzdsvHCGEQIIgSs8EAEBAQEBAQEBZCeCLYIWAQEEOj8QCyElDwVJJ4gfAcNgAQEBAQEBBAEBAQEBAQEginKEJnyCSIIuAQSYMY4WjySPSTcrg2+HNYE9AQEB X-IronPort-AV: E=Sophos;i="5.26,334,1459807200"; d="scan'208";a="218872807" Received: from pim.happyleptic.org ([5.135.156.187]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 19 May 2016 11:29:13 +0200 Received: from pim.happyleptic.org ([5.135.156.187]) by pim.happyleptic.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1b3KGW-0005WO-Hi; Thu, 19 May 2016 11:29:12 +0200 Date: Thu, 19 May 2016 11:29:11 +0200 From: rixed@happyleptic.org To: Chet Murthy Cc: caml-list Message-ID: <20160519092911.GA19519@pim.happyleptic.org> References: <20160518134349.GA10232@pim.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Caml-list] RPC for OCaml? Hi! I'm not very opinionated as far as which brick should be used but for the fact that I'd like the low level bricks to be interchangeable (transport, serialization, RPC). I'm more opinionated about the bigger picture, which I think is more specificaly were we (community and industry) are missing something, probably because of how large infrastructure is build (ie incrementaly from a small one). We commonly consider RPC, monitoring, load balancing, authentication and service discovery as independant things, but whenever a company has to build a large infra from scratch they tends to prefer to integrate (at least some of) the above, for this "economy of scale" in complexity brings many benefits: - proxyless routing - proxyless load balancing - seamless authentication - seamless quota - instrumentation of all RPC for free - consequently, no need for independant network monitoring - consequently, reliable detection of problems and reliable system to route around or drain the faulty nodes/clusters - uniform behavior across the whole infrastructure inducing ease to diagnosing issues and predict behavior - any improvement of the infrastructure benefits every services Compare with the industry "standard" consisting of throwing some unrelated services together and spending an enormous amount of time interconnecting them together with little visibility. I do not care about speed so much as to consider C++ or RDMA, but more about reliability and type safety. That's why I'm envisaging this for OCaml/MirageOs, interacting with other "legacy" stuff only at the perimeter. In this ideal world or strongly typed microservices, stub compilers or IDL would be superfluous, for you want the authoritative types to be defined in OCaml rather than in, say, protobuf (esp. version 3 which weaken types even more to pander to the json crowd, or so I like to imagine). But then it would make it much harder to interface with the outer world, as you rightfully described. The only way to reconcile those conflicting views, it seems, would be to use some IDL that's as strongly typed as OCaml, supporting various underlying serializers, and that would compile additional runtime type checks for weaker serializer and for softer languages. Isn't that why piqi was invented? (By the way piqi supports proto2 and OCaml).