With the widespread adoption of containers as an easy way to develop and deploy applications, should we be thinking of open-source solutions to system problems in terms of services instead of language-specific libraries? What are some of the problems keeping that from happening?<p>I've seen some great SASS products like Auth0/Algolia/Pusher/Stream. But if instead of working on Devise (Ruby auth), someone worked on an open source version of Auth0 that can be run as a service, couldn't that solution cover a bigger surface area for devs? (who may use other languages)
Doesn't that happen very often, that people work on such services?<p>I'm part of a small team that works on portier[0], which is what one could see as open source alternative to Auth0 (it's not the same thing, and it is more inspired by Mozilla Persona, but close enough). It's a service, as we run a broker online for everyone who wants using it, and the whole concept is having self-hostable brokers that handle the login of users (via email or Openid).<p>But: While that broker has a proper and simple API one can use to use the service with every language, it is still so much easier to just include a library/module that does that for you. Interpreting the jwt, fetching the jwk to check the signature, packing the request to the broker properly. We currently have one for Python, node, php and ruby/sinatra. They are not all at the same level, the one for sinatra does almost all the work for you, while the the python library is more a set of helpers.<p>And I don't think that's something weird we're doing, look at services like stripe or superfeedr, they all have language specific libraries to make calling their web part easier.<p>So what I'm saying: If you run a service that targets devs you might still end up writing language-specific libraries. And I don' think there is much keeping language-agnostic services from happening, as there are a lot of them.<p><i>Edit:</i> Though open source there is less, right. I think that's a mixture of the skills you need (having a proper server online and programming the software, not every team can both), the popularity of self-hosting in that community, and that it might cost money to run the online service.<p>[0]: <a href="https://portier.github.io/" rel="nofollow">https://portier.github.io/</a>
Libraries offer tight integration with the language. A generic service that provides a HTTP API doesn't.<p>If you are currently using a library that operates synchronously on in-memory objects and offers an idiomatic API in the language of your choice, switching to a web service may feel like a bucket of cold water because suddenly you're dealing with an async-only interface that sits behind a slow socket and requires serializing everything to a lowest common denominator API. It's a huge tradeoff that requires serious justification.<p>Back in 1990, there was an industry standard called CORBA that attempted to turn libraries into services:
<a href="https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture" rel="nofollow">https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...</a><p>There's a reason why we're not using any CORBA-based software. (Well, the GNOME desktop was based on it for some time, but they gave up eventually.)
<i>What are some of the problems keeping that from happening?</i><p>Here's one: Money.<p>A service will cost me (more) money. A library I can deploy on already-existing infrastructure. Keeping in mind that "Cloud" is 3x to 6x more expensive over running in house, this is a significant drawback.
The thing about containers is that they tend to make everything more complicated and resource hungry. Devise is a very good example for 'it Barely could be easier at this point'
Open standards are such, but in a heterogeneous software landscape one will always have challenges integrating vendor specific implementations of such and such services.