Ask HN: Who is working on services?
9 comments
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/
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/
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.
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.
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...
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.)
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...
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.)
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.
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.
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.
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.
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.
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.
Do you mean fabric8/openshift/kubernetes+docker images ?
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)