4 ms·
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 inv
by asim 4y ago
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 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 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.
- jiggawatts 4y agoA not-so-tiny nitpick: All of the code examples on m3o.com for DB access are a recipe for command injection. They all use a string with "columname == literal" format. That's near the top of all top-10 security don'ts lists..
- asim 4y agoYea we are aware, there's a lexer/parser but ideally we should have some Query op and use prepared statements. I am probably looking for some additional help on that front in the near future.
- hcrean 4y agoCan you point us to the areas that you are looking for help on? If you save us work on looking for them and you might get a PR for your trouble.
- asim 4y agoHey, I have a non-comprehensive list of issues for new services https://github.com/micro/services/issues https://github.com/micro/services/issues but most of the bugs/features are still in my head for other stuff. I think purely on the DB front we need to add a new Query endpoint that's more powerful that will accept a repeated array for Filter options that look like the below. message QueryRequest { repeated Filter filters = 1; } message QueryResponse { repeated Record records = 1; } message Filter { string field = 1; string op = 2; string value = 3; } Something like that. I think otherwise a majority of issues really become clear through use, so those using the services tend to see where the pitfalls are or where they can contribute. It's harder to do that without context and arguably less enjoyable for the person contributing as they're not seeing that change in whatever they're doing.