
Ask HN: Who is working on services? - tylerdiaz
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&#x27;ve seen some great SASS products like Auth0&#x2F;Algolia&#x2F;Pusher&#x2F;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&#x27;t that solution cover a bigger surface area for devs? (who may use other languages)
======
onli
Doesn't that happen very often, that people work on such services?

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).

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.

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.

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.

 _Edit:_ 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.

[0]: [https://portier.github.io/](https://portier.github.io/)

~~~
tylerdiaz
It's possible service development is happening very often, just not in the dev
circles I spend time in. (web based startups)

Regarding writing interfaces for the service, that's fine too. It's just an
easier way to integrate with a service. But there's a big difference between
writing a service interface and a library that implements the service's
functionality.

We do have plenty of open source services (e.g: Zookeeper, Redis, Kubernetes),
but few product level like Stripe/Auth0. Yet there's a lot of duplicated
effort in things like writing ecommerce/forum/blog/geolocation/social
software. I wonder why we don't have more of these.

------
pavlov
Libraries offer tight integration with the language. A generic service that
provides a HTTP API doesn't.

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.

Back in 1990, there was an industry standard called CORBA that attempted to
turn libraries into services:
[https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...](https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture)

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.)

~~~
mcless
During the time I worked for Amazon, the entire Amazon infrastructure was
written as services. It indeed felt like a bucket of cold water in my first
month at Amazon, especially after having worked in software products company
for 10 years prior to that.

But gradually, I got used to the services based architecture, where something
as simple as presenting a login page would lead to dozens of REST API calls
back and forth between various backend services.

I am not saying that one approach is better than another. I would have to
dedicate a separate comment to discuss that. All I am saying is that
developing an entire software system composed purely of generic services with
HTTP based REST APIs indeed exist and are very successful in very successful
companies.

~~~
pavlov
Absolutely. At Amazon's scale, the justification is there. Things are
different for invididual developers and small teams where the mesh of services
will be maintained by the same people anyway.

------
mdekkers
_What are some of the problems keeping that from happening?_

Here's one: Money.

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.

------
herbst
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'

------
warren46
Open standards are such, but in a heterogeneous software landscape one will
always have challenges integrating vendor specific implementations of such and
such services.

------
artpar
Do you mean fabric8/openshift/kubernetes+docker images ?

