Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I value your points because they are the same concerns I would have being a CTO of a company. Ultimately vendors don't yet care enough about this problem to invest in it and I think ultimately that's a mistake because while we have standardisation at the Cloud infrastructure layer, we're missing everything above it. The cost of development to an organisation in these services is quite frankly astronomical. You've got hundreds of devs rewriting identical CRUD services or proxy shims to existing SaaS across the entire industry. That's millions in capex just being burned.
In relation to being a CTO of a small startup, yea OSS maintainer risk is tough. You want to use projects that are used by hundreds of companies and actively maintained. In my case, I am the primary maintainer and it's used for a cloud service called M3O - https://m3o.com. I think it will take a while before we're in a place to warrant more buy in but my hope is eventually it'll get there or at the very least people will come to use the APIs serviced by M3O.
On architecture, I mean you're quite literally talking about software "build vs buy" tradeoffs for the entirety of all software you ever write. In this case, do I integrate something else or write it myself. I think that comes down to the same assessment of whether you should offload to some other piece of software versus your own. When it comes to domain specific services this is always tough yet we see the adoption of the likes of Twilio for SMS, Sendgrid for Email and Stripe for Payments so I'd argue we're getting closer to blurring the lines now.
On cost, you can use the hosted offering - https://m3o.com - but at this point the reason I'm sharing the open source services is really because I think that adoption curve to a cloud service takes a lot longer especially with domain specific services. I would argue these services while on the surface appear a commodity, the development time and integration cost of using bespoke independent APIs or services has a much higher cost. Everyone internally ends up writing proxy/shims to SaaS products to try eliminate this risk for themselves. I just think we should standardise a lot of our business logic service consumption.
I also can't really take this seriously. Maybe I'm ignorant of something to the Go ecosystem that makes this relevant, but this seems truly bizarre.
The "answer" microservice says: "Instant answers to any question" / "Ask a question and get an instant answer". Okay? Like, is this a service that I would have to back with my own knowledgebase? In which case this is just a service that accepts questions and serves answers? Why would this need its own service then?
The "address" microservice says: "Lookup UK addresses by postcode. Simply provide a valid postcode and get a full list of addresses". Why is this not called "uk-address" then? Or can it be modified for arbitrary locations? Does it handle when new addresses are created? Can it do validation?
How much demand is there for a "joke" microservice? And I think it shows a lack of professionalism to seed such a microservice with something like this: https://github.com/micro/services/blob/master/joke/examples....
I think the more interesting aspect of this is the framework being used: https://github.com/micro/micro
I haven't dug into it at all yet, but at a glance it looks like it's aiming to do something similar to what Go kit (https://gokit.io/) or Finagle (https://twitter.github.io/finagle/) does, where it gives you a nice abstraction for defining your "service" and then handles all the supplementary aspects (service discovery, serialization, retry/circuit breaker logic, rate limiting, hooks for logging, tracing, and metrics, etc) so you don't have to build those from scratch every time.
I don't know if any of those other frameworks could really be considered very "successful" outside the original organizations they were built for (it seems like the industry has bet more on service meshes and API gateway products), but I'd probably be more inclined to start with one of them than making a new framework.
I spent quite a few years working on a standalone framework called Go Micro which has now been donated to a community - https://github.com/go-micro/go-micro. Ultimately it never really achieved the potential I standardisation I was hoping for e.g something like gRPC.
Micro is more of an all encompassing platform that addresses not just writing code but running, consuming it, securing it. I've been using it in production for 3-4 years now after a lot of pure OSS development. Still as others are saying it may never reach its true potential without the backing of a big vendor.
I think the more interesting aspect of this is the framework being used: https://github.com/micro/micro
I haven't dug into it at all yet, but at a glance it looks like it's aiming to do something similar to what Go kit (https://gokit.io/) or Finagle (https://twitter.github.io/finagle/) does, where it gives you a nice abstraction for defining your "service" and then handles all the supplementary aspects (service discovery, serialization, retry/circuit breaker logic, rate limiting, hooks for logging, tracing, and metrics, etc) so you don't have to build those from scratch every time.
I don't know if any of those other frameworks could really be considered very "successful" outside the original organizations they were built for (it seems like the industry has bet more on service meshes and API gateway products), but I'd probably be more inclined to start with one of them than making a new framework.
I think the more interesting aspect of this is the framework being used: https://github.com/micro/micro
I haven't dug into it at all yet, but at a glance it looks like it's aiming to do something similar to what Go kit (https://gokit.io/) or Finagle (https://twitter.github.io/finagle/) does, where it gives you a nice abstraction for defining your "service" and then handles all the supplementary aspects (service discovery, serialization, retry/circuit breaker logic, rate limiting, hooks for logging, tracing, and metrics, etc) so you don't have to build those from scratch every time.
I don't know if any of those other frameworks could really be considered very "successful" outside the original organizations they were built for (it seems like the industry has bet more on service meshes and API gateway products), but I'd probably be more inclined to start with one of them than making a new framework.
Yea like you're part of this club that has exclusive access to something, you contribute to it, deliver value, see it grow and then it's gone when you leave. It exists within a silo and for the better part of a decade that's really irked me but I haven't quite figured out how to solve for that problem beyond doing it in a shared open source repo and a shared platform. I think I the issue is it's bigger than any one person and you have to find a way to sell thousands of people on the idea. My starting point was code and now I wonder could I have approached this differently? Is there another path in which this would actually succeed? I'm still trying to figure it out and it's driving me crazy. Next I'll be writing a protocol no joke https://github.com/micro/network