9 ms·

Real World Micro Services

189 points by asim 4y ago

dang 4y ago
https://github.com/micro/services https://github.com/micro/services
lbriner 4y ago
I love the idea and I also agree that there is so much duplicated effort but the difficulty of making the "one service to rule them all" is that there is pressure for it to be all things to all people, at which point, it becomes harder to use for a simple use-case. Take the crypto microservice. Someone says, e.g. "I notice that it doesn't support Argon2". If it doesn't, I can't use it, I would need to write my own library. Arguments ensue about you don't need Argon2 or "why not contribute the change to the library?". Maybe the maintainer doesn't want to accept the PR because they don't think the library needs it or they are not sure that the quality is high enough to accept. The library gets forked internally and the fork takes on a life of its own. I don't want to be negative but my experience is that people have a certain way of doing things and unless these services do it in that way, people won't live them. There are other ways in which they wouldn't be able to be reused like if people don't know how to build/deploy Go or they are only looking for something simple but the fully featured libraries are too hard to understand. Maybe having something is better than nothing but I think the saying is something like, "in trying to be all things to all people, you end up being nothing to any of them". I really hope I am wrong though because the amount of duplicate work in the world depresses me as an engineer!
erwinh 4y ago
The main thing I would say is more and especially legacy companies should have clear open source policies & IP strategy to enable employees to quickly assess if they can build their work openly.
- asim 4y ago
  Even if they did we have no standardisation. I truly wish we had Android for Cloud. An open source operating system and framework that then let people publish software that worked seamlessly on it. I don't think docker and kubernetes went far enough.
  - robertlagrant 4y ago
    We do have Android for Cloud. It's called any cloud provider. You can build for that provider and it will work.
    - asim 4y ago
      Cloud providers right now look more like the PalmPilot's and Blackberry's of the world did.
      - robertlagrant 4y ago
        I don't know. Maybe? Depends on what you mean.
seibelj 4y ago
Who is operating the micro service? What are the rate limits? Are there status pages? Who made the code? How secure is it? Can it scale? Or are we supposed to clone all the repos and host ourselves? Do they all have the same deployment cicds? A grouping of open source repos is useful. But there is a reason why I pay companies for “freely available” services when I have my own revenue on the line.
- asim 4y ago
  Right now I'm just sharing a set of open source services. A hosted offering exists as an API platform called M3O as mentioned in the post. Ideally just as infrastructure is now shared as cloud services maybe the same would occur here but not always a feasible starting point.
ivan_gammel 4y ago
This is a noble idea that unfortunately will not work. As a CTO of another small startup, I have no incentive to reuse those services for a number of reasons: 1. Trust. I need a strong vendor or community behind third party code which will issue security updates, have transparent roadmap that I understand and agree with and good paid licensing and support business model. It’s a high bar, but having some control over supply chain is important. 2. Architecture. Domain-specific services that integrate with some APIs are middleware: either I have to build some other middleware to integrate them with loose coupling, or I have to accept their integration contracts as a basis for my solution architecture. Both don’t look good to me. 3. Cost. If the problem is generic enough, why I should take only the code but spend money on DevOps to deploy it? No-code SaaS today is great and it’s all-in-one, being cost-efficient simply because it eliminates expensive internal maintenance effort. And it’s commodity today, there are often many alternatives for some problems, so vendor lock-in isn’t as scary as it was before.
- 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.
thraxil 4y ago
I think the more interesting aspect of this is the framework being used: https://github.com/micro/micro 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/ https://gokit.io/) or Finagle (https://twitter.github.io/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.
- asim 4y ago
  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 https://github.com/go-micro/go-micro. Ultimately it never really achieved the potential 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.
superfist 4y ago
After quick look on code it looks to me more like nano services than micro services and nano services are basically antipattern. I would never host that and expect most of this functionality to be library/package to programing language I use for my projects.
- asim 4y ago
  There are some services that are still singular endpoint you're right e.g SMS. But the goal is to address immediate need and expand on requirements beyond it. No one using SMS has asked for more yet. Other things are more full fledged e.g a db service that provides a http interface on top of postgres, or the user service with email verification and the app service that does hosting on top of Google cloud run.
  - superfist 4y ago
    It is not about number of endpoints - libraries also have multiple "endpoints" and some are used and some are not. It is about reasonable code packaging. Most of those "micro" service just wrap some single purpose libraries and expose them as REST endpoints. That is way they are more like nano services and not micro services. This lead to modern version of "dependency hell" but much more complex becasue now we have to deal with whole class of potential network problems.
    - asim 4y ago
      Can you point to the ones you're talking about? A lot of the services are actually not that, they're offering simplified API and RPC access to data that's siloed elsewhere or systems that are quite complex to manage. There's some stuff we wrote for fun because writing arduously complex code can be tedious and I enjoy playing around with random things but I wouldn't waste a lot of my time wrapping libraries. OK so an "id" service is a bit like, maybe we don't need that to be an API call but let's say you do and you do want unique IDs distributed across many nodes, that was actually a hard problem solved by stuff like Snowflake [1] and distributed node management like zookeeper. https://en.wikipedia.org/wiki/Snowflake_ID https://en.wikipedia.org/wiki/Snowflake_ID
asim 4y ago
Hey, maintainer here. Happy to answer questions. I know some people are skeptical of such an idea working outside of an existing organisation or without large vendor support but had to take a shot nonetheless. These are built and hosted for an API platform called M3O so actively in use 24/7.
- jmartrican 4y ago
  I like the idea and the website. I also like how you were able to stick to this project for the past 7 years. Who is your provider for SMS? Can we add our own APIs to M3O?
  - asim 4y ago
    The SMS provider is currently Twilio. You can contribute services to the micro/services repo and they will be hosted on M3O. I welcome a sort of collaborative approach to that. We used to enable each user to have a *.m3o.dev subdomain to host their own but that product grew too slowly, so shifted focus entirely to serving through this one pipeline.
Traubenfuchs 4y ago
What‘s with the masochistic drive of software developers to open source their code and assist in the commoditization of their craft? Why is this not seen in any other profession? I kindly ask you to stop and keep your code proprietary and hidden, for the sake and salary of the average software engineer.
- asim 4y ago
  I don't know what other people's motivation is but for me after experiencing life at Google and elsewhere I really understood that to build anything at scale takes a multi-year effort building on the foundations already set. Google and Amazon don't get to be where they are by rewriting the entire stack every 2 years, yet as developers that's what we effectively have to do every time we leave a company. Only the large incumbents truly benefit from this compounding value and services development model. The rest of us just have to keep rewriting stuff from scratch and hope for opportunities to work at places with great technology. Personally I feel like if we can open source building blocks that become the foundations for our development then we can build more interesting things on top e.g you're not going to build redis, postgres, etc again, but what are the things we build on top of them? We have a lot of open source infrastructure but not much in higher level categories. One day we'll get there, but it takes multiple people trying time and time again before we get there.
  - Traubenfuchs 4y ago
    > but what are the things we build on top of them? Countless other software developers and me build those things. If what I am currently building becomes available for free, as usable open source, I might lose my job. The company that let me go can increase their revenue and reduce their costs. You gain nothing, maybe some clout and fame. Open source is harmful to the average developer. After years of this, we'd just be happy to reinvent StringUtils, EmailValidator and FileUtils classes every few years and take home our decent salaries.
    - asim 4y ago
      So I'll start by saying, I've spent the past 7 years working predominantly on open source, 4 of those years were bootstrapped and the majority of stuff I've written is basically given away for free. I fully understand what that does to my own earning potential but at the same time as a developer at every single company I ever worked at, I came to rely on open source for quite literally everything I built. Whether it was linux, apache, nginx, docker or asterisk or whatever else. Our entire industry is built on the foundations of open source and without it we end up in these silos where only the incumbents thrive, that's how we end up with platform centralisation and inevitably struggle to break free with no alternatives. I think now is the time for us to start moving beyond just open source infrastructure and into open source services. Yes as developers that means the things we write will change, yes some of us will have to reskill and learn new things but that's also just how evolution works in engineering. Whether its code or whether its cars, we, the current generation will be displaced by automation and large scale solutions.
pan69 4y ago
Real world micro services without tests?
- asim 4y ago
  Testing in production https://m3o.com https://m3o.com
  - michaelmcmillan 4y ago
    That's not nearly enough.
    - asim 4y ago
      Probably not but users tell me when something isn't working. I spent my entire career in this sort of development model where 80% was good enough, put it into production and then moved on. When something breaks, fix it, when something is really complex test it, when the logic is critical mock it.
      - robertlagrant 4y ago
        This is likely to be a core issue for most people. In reality it isn't "if it breaks, fix it", it's "if we notice it breaks, and we can remember what it should do, we can probably fix it". Tests allow you to spot when you break things, and also encode what they should do.
        adrianmsmith 4y ago
        Tests also cost money to write and to maintain. It's a tradeoff. Personally I like to work at places where the tradeoff falls in favour of writing tests. But I understand there are some businesses that just don't have a lot of money and where the cost of things breaking isn't that high, and then the right decision might be to skip tests. And one might argue if the customers don't notice it's broken, does it really matter?
torbrowser 4y ago
weego 4y ago
One of the biggest issues we face in the industry is the lack of reusability in software Disagree with this core premise. The biggest problems we face are that every developer is coached into believing everything they make needs to be unicorn scale and quality, that everything they build should conform to impractical levels of scrutiny and long-termism and that it is unavoidable for even basic development needs to have incredibly high levels of complexity in code / build / release tooling. Microservices are just the latest weapon in furthering this agenda for the good of a tiny minority of people who value indulging their time and business costs in esoteric software philosophy goals.
- asim 4y ago
  Not sure how to approach that comment really, I don't think it matters if the pattern used is microservices or not, the basic premise that we're still way far off reusability of software that's basically identical across thousands of orgs stands. Most devs are rebuilding identical software stacks to serve a very small different business layer product. There's probably 80% of software that we could open source as reusable building blocks. Do they need to be microservices? No, but if the logic was in libraries and we had to reimplement per language it would be really a waste of time. Could we package this in some other way? Someone please show me that solution because I'll stop talking about microservices and go use that. Ultimately from what I've seen at companies like Amazon, Google, etc is reusability is about services development exposed as APIs with common libraries, frameworks and platforms for that development/deployment, itself, that's it. Its not buzzwordy, but microservices encapsulates that model. Amazon/Google, etc are just hundreds of small teams all using a shared model of development, so the argument that you don't need microservices at small scale is not the issue here, it's that we outside of orgs don't have this level of reuse that they do, so we waste most of our time spinning our wheels building the same software, where as if we had a set of reusable building blocks or APIs on top of cloud infrastructure, we could actually then go solve even more interesting ideas rather than it being something only possible at massive orgs.
  - throw827474737 4y ago
    But then I look e.g. at your weather microservice, and see again a (configurable, but still expecting some already standardized format) wrapper around an existing API that once more mingles the data all around? Sorry, but really not getting what this is achieving/solving?
lifeisstillgood 4y ago
I have had these exact same thoughts - and have half-built attempts all over. (I'm not convinced APIs running in Go are the way everyone will want this - I get the argument but I suspect this is the way language ecosystems will evolve) But this is looking far more polished - excellent. I am inspired. Good luck !
jakuboboza 4y ago
This feels very not-reusable to me. Guys has an idea that protocol buffers are the way to go. Cool but in many cases you really want to put a queue in front of things like email sending etc. And if you make email microservice that can't handle attachment it again isnt reusable. I would be more in favour of having option to point every service at a rabbitmq queue to listen on and have a format of message that containes the delivery report queue to use when email is sent to notify rest of the system. And here we come to conclusion, everyone has his own idea. This is who it is hard to make really good reusable micro services unless each of them becomes not so micro. Nice that people try but i'm still in the camp of building from lego bricks provided in libs and creating my own microservices in a way I see them interconnect fit for given project. It might be protobuf, http or qeueue systems.
- Cthulhu_ 4y ago
  That's the vibe I was getting; these all feel like focused libraries, but using these in an application architecture feels like you would have a distributed monolith. You need resilient task queues to turn it into a 'proper' microservices architecture, which is honestly a much more challenging task than encapsulating concerns like sending emails or geocoding. The other thing, as another commenter pointed out, is that these are nanoservices; I find it really difficult to imagine a situation where you would ever need 10x of one service for 1x of another, for example. It's a litmus test for microservices: do they have to scale independently. A lot of these just interface with an external service doing the heavy lifting, so the performance requirements for each of these is low; little to no value in running them on separate, independently scalable VMs.
rjrodger 4y ago
Microservices are about reusability - at the "business logic" level. This framework and its services gets that exactly right. All the network stuff is fine and dandy but first you need to build actual features, which is where intentionally reusable microservices like these really shine.
robertlagrant 4y ago
> GitHub made a major revolutionary change for developers, enabling all of us to reuse libraries, and code through reuse rather than writing everything from scratch This doesn't seem at all accurate.
- jeltz 4y ago
  Yeah, PEAR, CPAN, Maven and Ruby Gems all predate GitHub. And even before those there were other ways to share code. The author must be very young. CPAN is from 1995.
  - robertlagrant 4y ago
    Also DLLs, all of the Debian ecosystem, etc etc. So much incredible stuff (and DLLs too) that still exists, and powers most of what we build now.
  - asim 4y ago
    Born in 84. I have been a user of all the above. The reason I mentioned GitHub to this level is truly in 2009 onwards it unlocked sharing of code at a level I had not seen before. It really did eclipse the reuse of software to what came prior and a lot of that has to do with the associated social network and network affects. They in a way game-ified software for a new generation. And it's not that we didn't share software before, just not to this degree and that's because every decade we rebuild the same ideas for a new generation that then 10-100x what came before. So something will come after GitHub as well. But today that's what we have and that really changed software for a generation.
    - robertlagrant 4y ago
      I think Stack Overflow achieved the gamification and sharing of ideas much more than Github, and package managers such as NPM unlocked more and more reuse. Github has had some big benefits, but I think you're exaggerating quite a bit. Mercurial, SourceForge, etc etc were already around doing quite a lot of what early Github did, and while it's true that lots of projects transitioned from them to Github (it looked nicer, it was free and it was Git), it wasn't the sea change that some of the other platforms have brought.
nicolas_lorenzi 4y ago
I reassure you, we have the same observation in the field of hardware. A lack of agility coupled with an inability to reuse code from embedded/edge project to another. We have also chosen microservices to apply it to the embedded domain with our open-source project Luos, but there is still a long way to go.
skywhopper 4y ago
> GitHub made a major revolutionary change for > developers, enabling all of us to reuse libraries, > and code through reuse rather than writing > everything from scratch Uhhh, pardon me? We were sharing code, even packaged libs, long before GitHub or even Git.
hrdwdmrbl 4y ago
Wow! Incredible work. Is this the work of a single person?
- asim 4y ago
  It is the work of a number of people over a few years. Some of those people have now moved on but what's left is their contribution.
numlock86 4y ago
It took me a while to realize if this is satire or an actual effort.
- thatnerdyguy 4y ago
  Me too. However, I'm also not all that familiar with the Go ecosystem. Maybe they don't have the concept of libraries?
  - asim 4y ago
    Done the library thing https://github.com/go-micro/go-micro https://github.com/go-micro/go-micro
- asim 4y ago
  It's real code https://github.com/micro/services https://github.com/micro/services It runs on software that's also real https://github.com/micro/micro https://github.com/micro/micro It's hosted on a cloud platform with real customers https://m3o.com https://m3o.com
- mynameisash 4y ago
  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.json#L21-L22 https://github.com/micro/services/blob/master/joke/examples....
jmartrican 4y ago
I applaud Asim's effort. I can't wait to try some of these APIs out. One of the APIs is for SMS. Any idea which provider is being used for these SMSs? Also, I see some similarities with Rapid API. Another API sharing platform. It would be cool if other devs can add their own APIs to Micro's platform to make some extra loot.
- jimmyswimmy 4y ago
  Looks like twilio
edfletcher_t137 4y ago
So... a whole new set of "reusable" components that must be vetted & audited? Why should these be trusted? Why should these be adopted and integrated into a team's ecosystem instead of their own work? I have a hard time seeing the true utility of this collection.
cultofmetatron 4y ago
a monolithic app with genservers is a better cost/efficiency ratio for getting to profitability.
bastawhiz 4y ago
I guess it depends on what "real world" means here. These are all things that people would want in the real world, but this collection isn't built for the real world. Am I really going to build my business around a cache service with no meaningful operational documentation? I mean I guess if I need to also get NFTs and Islamic prayer times, this is a compelling package. But really: much of this is either a) stuff that should be a library, even in a microservice ecosystem or b) could just be a static file (like the list of holidays).
no_circuit 4y ago
The related value is likely a service catalog and the common transports, not the services themselves, and that ship has sailed already with things like Kong Service Hub or the Swagger / OpenAPI spec [1]. A lot of people will likely not want to wait behind the open-source standardization effort on how to extend the service definitions for an API like email sending or file reading, e.g., does the file ACL go in the generic metadata map [2]? There probably could be value for service definitions and a proxy that allow you to directly access a proprietary API but with a transport of your choice like gRPC which only happen to offer REST/JSON. But trying to come up with a standard API without collaboration among the largest of industry players will likely go virtually unused. [1] https://en.wikipedia.org/wiki/Swagger_(software) https://en.wikipedia.org/wiki/Swagger_(software) [2] https://github.com/m3o/m3o/blob/fb7eb42512e4c7db49ab03da0b471bbe67fcf74a/services/file/proto/file.proto#L27 https://github.com/m3o/m3o/blob/fb7eb42512e4c7db49ab03da0b47...
perrygeo 4y ago
My perspective is that code reuse is a problem when "business logic" gets fused together with implementation details. When you evaluate bringing code into your project as a dependency, the primary blocker is all the operational assumptions and baggage that comes with the core functionality. For instance, the assumption that everyone wants to use an HTTP request for every little query and deploy, maintain, and debug dozens of live services. Don't buy into the microservices thing? Then you can't reuse this code.
kokizzu2 4y ago
no need to create a service for things that can be just a library '__')
lakomen 4y ago
Microservices without events are useless. I'm tired of repeating myself and I'm tired of the buzz hype. All this is, is putting you at a disadvantage, vs just a package that isn't hosted on its own. I'm tired of seeing wrong theorems applied and sold as something good when in reality its bad. Why this makes the top page of HN is beyond me
- acjohnson55 4y ago
  You seem exasperated, but it's not clear what point you're making. If you're saying that these utilities would be better off as libraries, what you get hosting them is language independence. With extremely light runtimes, the cost of RPCing to access some logic isn't that much greater than a library call. For things that aren't performance critical, the overhead might be fine.
- mstafa 4y ago
  > Microservices without events are useless why?
mbrodersen 4y ago
A colleague of mine is currently working on a 20+ years old micro services system. It has more than 50 services that are all super busy sending messages to each other in a wonderfully chaotic jaw dropping WTF way. While solving really simple business problems. It is without a doubt the most complex and badly designed software I have ever experienced or read about in my 30+ years career. I am predicting that 10 or 20 years from now developers unlucky enough to have to take over micro services systems created today will curse the developers who today are inexperienced enough to think micro services is a good idea.
ofrzeta 4y ago
I think it's a good direction to provide standardized services for running multiple containers as a cloud application. The current state is: get some "legacy" (old school unix) server, pack it into a container (with some ugly shell hackery, albeit in a Dockerfile or Kubernetes manifest), provide configuration through environment variables or rewrite the old-school .conf files through more shell hackery. All state management of those servers is done through more shell hackery (select statements or nc for databases; nc or wget for http services; touch a random dotfile after a certain state is reached).

189 points by asim 4y ago

dang 4y ago

https://github.com/micro/services https://github.com/micro/services

I love the idea and I also agree that there is so much duplicated effort but the difficulty of making the "one service to rule them all" is that there is pressure for it to be all things to all people, at which point, it becomes harder to use for a simple use-case. Take the crypto microservice. Someone says, e.g. "I notice that it doesn't support Argon2". If it doesn't, I can't use it, I would need to write my own library. Arguments ensue about you don't need Argon2 or "why not contribute the change to the library?". Maybe the maintainer doesn't want to accept the PR because they don't think the library needs it or they are not sure that the quality is high enough to accept. The library gets forked internally and the fork takes on a life of its own. I don't want to be negative but my experience is that people have a certain way of doing things and unless these services do it in that way, people won't live them. There are other ways in which they wouldn't be able to be reused like if people don't know how to build/deploy Go or they are only looking for something simple but the fully featured libraries are too hard to understand. Maybe having something is better than nothing but I think the saying is something like, "in trying to be all things to all people, you end up being nothing to any of them". I really hope I am wrong though because the amount of duplicate work in the world depresses me as an engineer!

erwinh 4y ago

The main thing I would say is more and especially legacy companies should have clear open source policies & IP strategy to enable employees to quickly assess if they can build their work openly.

asim 4y ago
Even if they did we have no standardisation. I truly wish we had Android for Cloud. An open source operating system and framework that then let people publish software that worked seamlessly on it. I don't think docker and kubernetes went far enough.
- robertlagrant 4y ago
  We do have Android for Cloud. It's called any cloud provider. You can build for that provider and it will work.
  - asim 4y ago
    Cloud providers right now look more like the PalmPilot's and Blackberry's of the world did.
    - robertlagrant 4y ago
      I don't know. Maybe? Depends on what you mean.

seibelj 4y ago

Who is operating the micro service? What are the rate limits? Are there status pages? Who made the code? How secure is it? Can it scale? Or are we supposed to clone all the repos and host ourselves? Do they all have the same deployment cicds? A grouping of open source repos is useful. But there is a reason why I pay companies for “freely available” services when I have my own revenue on the line.

asim 4y ago
Right now I'm just sharing a set of open source services. A hosted offering exists as an API platform called M3O as mentioned in the post. Ideally just as infrastructure is now shared as cloud services maybe the same would occur here but not always a feasible starting point.

ivan_gammel 4y ago

This is a noble idea that unfortunately will not work. As a CTO of another small startup, I have no incentive to reuse those services for a number of reasons: 1. Trust. I need a strong vendor or community behind third party code which will issue security updates, have transparent roadmap that I understand and agree with and good paid licensing and support business model. It’s a high bar, but having some control over supply chain is important. 2. Architecture. Domain-specific services that integrate with some APIs are middleware: either I have to build some other middleware to integrate them with loose coupling, or I have to accept their integration contracts as a basis for my solution architecture. Both don’t look good to me. 3. Cost. If the problem is generic enough, why I should take only the code but spend money on DevOps to deploy it? No-code SaaS today is great and it’s all-in-one, being cost-efficient simply because it eliminates expensive internal maintenance effort. And it’s commodity today, there are often many alternatives for some problems, so vendor lock-in isn’t as scary as it was before.

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.

thraxil 4y ago

I think the more interesting aspect of this is the framework being used: https://github.com/micro/micro 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/ https://gokit.io/) or Finagle (https://twitter.github.io/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.

asim 4y ago
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 https://github.com/go-micro/go-micro. Ultimately it never really achieved the potential 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.

superfist 4y ago

After quick look on code it looks to me more like nano services than micro services and nano services are basically antipattern. I would never host that and expect most of this functionality to be library/package to programing language I use for my projects.

asim 4y ago
There are some services that are still singular endpoint you're right e.g SMS. But the goal is to address immediate need and expand on requirements beyond it. No one using SMS has asked for more yet. Other things are more full fledged e.g a db service that provides a http interface on top of postgres, or the user service with email verification and the app service that does hosting on top of Google cloud run.
- superfist 4y ago
  It is not about number of endpoints - libraries also have multiple "endpoints" and some are used and some are not. It is about reasonable code packaging. Most of those "micro" service just wrap some single purpose libraries and expose them as REST endpoints. That is way they are more like nano services and not micro services. This lead to modern version of "dependency hell" but much more complex becasue now we have to deal with whole class of potential network problems.
  - asim 4y ago
    Can you point to the ones you're talking about? A lot of the services are actually not that, they're offering simplified API and RPC access to data that's siloed elsewhere or systems that are quite complex to manage. There's some stuff we wrote for fun because writing arduously complex code can be tedious and I enjoy playing around with random things but I wouldn't waste a lot of my time wrapping libraries. OK so an "id" service is a bit like, maybe we don't need that to be an API call but let's say you do and you do want unique IDs distributed across many nodes, that was actually a hard problem solved by stuff like Snowflake [1] and distributed node management like zookeeper. https://en.wikipedia.org/wiki/Snowflake_ID https://en.wikipedia.org/wiki/Snowflake_ID

asim 4y ago

Hey, maintainer here. Happy to answer questions. I know some people are skeptical of such an idea working outside of an existing organisation or without large vendor support but had to take a shot nonetheless. These are built and hosted for an API platform called M3O so actively in use 24/7.

jmartrican 4y ago
I like the idea and the website. I also like how you were able to stick to this project for the past 7 years. Who is your provider for SMS? Can we add our own APIs to M3O?
- asim 4y ago
  The SMS provider is currently Twilio. You can contribute services to the micro/services repo and they will be hosted on M3O. I welcome a sort of collaborative approach to that. We used to enable each user to have a *.m3o.dev subdomain to host their own but that product grew too slowly, so shifted focus entirely to serving through this one pipeline.

Traubenfuchs 4y ago

What‘s with the masochistic drive of software developers to open source their code and assist in the commoditization of their craft? Why is this not seen in any other profession? I kindly ask you to stop and keep your code proprietary and hidden, for the sake and salary of the average software engineer.

asim 4y ago
I don't know what other people's motivation is but for me after experiencing life at Google and elsewhere I really understood that to build anything at scale takes a multi-year effort building on the foundations already set. Google and Amazon don't get to be where they are by rewriting the entire stack every 2 years, yet as developers that's what we effectively have to do every time we leave a company. Only the large incumbents truly benefit from this compounding value and services development model. The rest of us just have to keep rewriting stuff from scratch and hope for opportunities to work at places with great technology. Personally I feel like if we can open source building blocks that become the foundations for our development then we can build more interesting things on top e.g you're not going to build redis, postgres, etc again, but what are the things we build on top of them? We have a lot of open source infrastructure but not much in higher level categories. One day we'll get there, but it takes multiple people trying time and time again before we get there.
- Traubenfuchs 4y ago
  > but what are the things we build on top of them? Countless other software developers and me build those things. If what I am currently building becomes available for free, as usable open source, I might lose my job. The company that let me go can increase their revenue and reduce their costs. You gain nothing, maybe some clout and fame. Open source is harmful to the average developer. After years of this, we'd just be happy to reinvent StringUtils, EmailValidator and FileUtils classes every few years and take home our decent salaries.
  - asim 4y ago
    So I'll start by saying, I've spent the past 7 years working predominantly on open source, 4 of those years were bootstrapped and the majority of stuff I've written is basically given away for free. I fully understand what that does to my own earning potential but at the same time as a developer at every single company I ever worked at, I came to rely on open source for quite literally everything I built. Whether it was linux, apache, nginx, docker or asterisk or whatever else. Our entire industry is built on the foundations of open source and without it we end up in these silos where only the incumbents thrive, that's how we end up with platform centralisation and inevitably struggle to break free with no alternatives. I think now is the time for us to start moving beyond just open source infrastructure and into open source services. Yes as developers that means the things we write will change, yes some of us will have to reskill and learn new things but that's also just how evolution works in engineering. Whether its code or whether its cars, we, the current generation will be displaced by automation and large scale solutions.

pan69 4y ago

Real world micro services without tests?

asim 4y ago
Testing in production https://m3o.com https://m3o.com
- michaelmcmillan 4y ago
  That's not nearly enough.
  - asim 4y ago
    Probably not but users tell me when something isn't working. I spent my entire career in this sort of development model where 80% was good enough, put it into production and then moved on. When something breaks, fix it, when something is really complex test it, when the logic is critical mock it.
    - robertlagrant 4y ago
      This is likely to be a core issue for most people. In reality it isn't "if it breaks, fix it", it's "if we notice it breaks, and we can remember what it should do, we can probably fix it". Tests allow you to spot when you break things, and also encode what they should do.
      - adrianmsmith 4y ago
        Tests also cost money to write and to maintain. It's a tradeoff. Personally I like to work at places where the tradeoff falls in favour of writing tests. But I understand there are some businesses that just don't have a lot of money and where the cost of things breaking isn't that high, and then the right decision might be to skip tests. And one might argue if the customers don't notice it's broken, does it really matter?

torbrowser 4y ago

weego 4y ago

One of the biggest issues we face in the industry is the lack of reusability in software Disagree with this core premise. The biggest problems we face are that every developer is coached into believing everything they make needs to be unicorn scale and quality, that everything they build should conform to impractical levels of scrutiny and long-termism and that it is unavoidable for even basic development needs to have incredibly high levels of complexity in code / build / release tooling. Microservices are just the latest weapon in furthering this agenda for the good of a tiny minority of people who value indulging their time and business costs in esoteric software philosophy goals.

asim 4y ago
Not sure how to approach that comment really, I don't think it matters if the pattern used is microservices or not, the basic premise that we're still way far off reusability of software that's basically identical across thousands of orgs stands. Most devs are rebuilding identical software stacks to serve a very small different business layer product. There's probably 80% of software that we could open source as reusable building blocks. Do they need to be microservices? No, but if the logic was in libraries and we had to reimplement per language it would be really a waste of time. Could we package this in some other way? Someone please show me that solution because I'll stop talking about microservices and go use that. Ultimately from what I've seen at companies like Amazon, Google, etc is reusability is about services development exposed as APIs with common libraries, frameworks and platforms for that development/deployment, itself, that's it. Its not buzzwordy, but microservices encapsulates that model. Amazon/Google, etc are just hundreds of small teams all using a shared model of development, so the argument that you don't need microservices at small scale is not the issue here, it's that we outside of orgs don't have this level of reuse that they do, so we waste most of our time spinning our wheels building the same software, where as if we had a set of reusable building blocks or APIs on top of cloud infrastructure, we could actually then go solve even more interesting ideas rather than it being something only possible at massive orgs.
- throw827474737 4y ago
  But then I look e.g. at your weather microservice, and see again a (configurable, but still expecting some already standardized format) wrapper around an existing API that once more mingles the data all around? Sorry, but really not getting what this is achieving/solving?

lifeisstillgood 4y ago

I have had these exact same thoughts - and have half-built attempts all over. (I'm not convinced APIs running in Go are the way everyone will want this - I get the argument but I suspect this is the way language ecosystems will evolve) But this is looking far more polished - excellent. I am inspired. Good luck !

jakuboboza 4y ago

This feels very not-reusable to me. Guys has an idea that protocol buffers are the way to go. Cool but in many cases you really want to put a queue in front of things like email sending etc. And if you make email microservice that can't handle attachment it again isnt reusable. I would be more in favour of having option to point every service at a rabbitmq queue to listen on and have a format of message that containes the delivery report queue to use when email is sent to notify rest of the system. And here we come to conclusion, everyone has his own idea. This is who it is hard to make really good reusable micro services unless each of them becomes not so micro. Nice that people try but i'm still in the camp of building from lego bricks provided in libs and creating my own microservices in a way I see them interconnect fit for given project. It might be protobuf, http or qeueue systems.

Cthulhu_ 4y ago
That's the vibe I was getting; these all feel like focused libraries, but using these in an application architecture feels like you would have a distributed monolith. You need resilient task queues to turn it into a 'proper' microservices architecture, which is honestly a much more challenging task than encapsulating concerns like sending emails or geocoding. The other thing, as another commenter pointed out, is that these are nanoservices; I find it really difficult to imagine a situation where you would ever need 10x of one service for 1x of another, for example. It's a litmus test for microservices: do they have to scale independently. A lot of these just interface with an external service doing the heavy lifting, so the performance requirements for each of these is low; little to no value in running them on separate, independently scalable VMs.

rjrodger 4y ago

Microservices are about reusability - at the "business logic" level. This framework and its services gets that exactly right. All the network stuff is fine and dandy but first you need to build actual features, which is where intentionally reusable microservices like these really shine.

robertlagrant 4y ago

> GitHub made a major revolutionary change for developers, enabling all of us to reuse libraries, and code through reuse rather than writing everything from scratch This doesn't seem at all accurate.

jeltz 4y ago
Yeah, PEAR, CPAN, Maven and Ruby Gems all predate GitHub. And even before those there were other ways to share code. The author must be very young. CPAN is from 1995.
- robertlagrant 4y ago
  Also DLLs, all of the Debian ecosystem, etc etc. So much incredible stuff (and DLLs too) that still exists, and powers most of what we build now.
- asim 4y ago
  Born in 84. I have been a user of all the above. The reason I mentioned GitHub to this level is truly in 2009 onwards it unlocked sharing of code at a level I had not seen before. It really did eclipse the reuse of software to what came prior and a lot of that has to do with the associated social network and network affects. They in a way game-ified software for a new generation. And it's not that we didn't share software before, just not to this degree and that's because every decade we rebuild the same ideas for a new generation that then 10-100x what came before. So something will come after GitHub as well. But today that's what we have and that really changed software for a generation.
  - robertlagrant 4y ago
    I think Stack Overflow achieved the gamification and sharing of ideas much more than Github, and package managers such as NPM unlocked more and more reuse. Github has had some big benefits, but I think you're exaggerating quite a bit. Mercurial, SourceForge, etc etc were already around doing quite a lot of what early Github did, and while it's true that lots of projects transitioned from them to Github (it looked nicer, it was free and it was Git), it wasn't the sea change that some of the other platforms have brought.

nicolas_lorenzi 4y ago

I reassure you, we have the same observation in the field of hardware. A lack of agility coupled with an inability to reuse code from embedded/edge project to another. We have also chosen microservices to apply it to the embedded domain with our open-source project Luos, but there is still a long way to go.

skywhopper 4y ago

> GitHub made a major revolutionary change for > developers, enabling all of us to reuse libraries, > and code through reuse rather than writing > everything from scratch Uhhh, pardon me? We were sharing code, even packaged libs, long before GitHub or even Git.

hrdwdmrbl 4y ago

Wow! Incredible work. Is this the work of a single person?

asim 4y ago
It is the work of a number of people over a few years. Some of those people have now moved on but what's left is their contribution.

numlock86 4y ago

It took me a while to realize if this is satire or an actual effort.

thatnerdyguy 4y ago
Me too. However, I'm also not all that familiar with the Go ecosystem. Maybe they don't have the concept of libraries?
- asim 4y ago
  Done the library thing https://github.com/go-micro/go-micro https://github.com/go-micro/go-micro
asim 4y ago
It's real code https://github.com/micro/services https://github.com/micro/services It runs on software that's also real https://github.com/micro/micro https://github.com/micro/micro It's hosted on a cloud platform with real customers https://m3o.com https://m3o.com
mynameisash 4y ago
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.json#L21-L22 https://github.com/micro/services/blob/master/joke/examples....

jmartrican 4y ago

I applaud Asim's effort. I can't wait to try some of these APIs out. One of the APIs is for SMS. Any idea which provider is being used for these SMSs? Also, I see some similarities with Rapid API. Another API sharing platform. It would be cool if other devs can add their own APIs to Micro's platform to make some extra loot.

jimmyswimmy 4y ago
Looks like twilio

edfletcher_t137 4y ago

So... a whole new set of "reusable" components that must be vetted & audited? Why should these be trusted? Why should these be adopted and integrated into a team's ecosystem instead of their own work? I have a hard time seeing the true utility of this collection.

cultofmetatron 4y ago

a monolithic app with genservers is a better cost/efficiency ratio for getting to profitability.

bastawhiz 4y ago

I guess it depends on what "real world" means here. These are all things that people would want in the real world, but this collection isn't built for the real world. Am I really going to build my business around a cache service with no meaningful operational documentation? I mean I guess if I need to also get NFTs and Islamic prayer times, this is a compelling package. But really: much of this is either a) stuff that should be a library, even in a microservice ecosystem or b) could just be a static file (like the list of holidays).

no_circuit 4y ago

The related value is likely a service catalog and the common transports, not the services themselves, and that ship has sailed already with things like Kong Service Hub or the Swagger / OpenAPI spec [1]. A lot of people will likely not want to wait behind the open-source standardization effort on how to extend the service definitions for an API like email sending or file reading, e.g., does the file ACL go in the generic metadata map [2]? There probably could be value for service definitions and a proxy that allow you to directly access a proprietary API but with a transport of your choice like gRPC which only happen to offer REST/JSON. But trying to come up with a standard API without collaboration among the largest of industry players will likely go virtually unused. [1] https://en.wikipedia.org/wiki/Swagger_(software) https://en.wikipedia.org/wiki/Swagger_(software) [2] https://github.com/m3o/m3o/blob/fb7eb42512e4c7db49ab03da0b471bbe67fcf74a/services/file/proto/file.proto#L27 https://github.com/m3o/m3o/blob/fb7eb42512e4c7db49ab03da0b47...

perrygeo 4y ago

My perspective is that code reuse is a problem when "business logic" gets fused together with implementation details. When you evaluate bringing code into your project as a dependency, the primary blocker is all the operational assumptions and baggage that comes with the core functionality. For instance, the assumption that everyone wants to use an HTTP request for every little query and deploy, maintain, and debug dozens of live services. Don't buy into the microservices thing? Then you can't reuse this code.

kokizzu2 4y ago

no need to create a service for things that can be just a library '__')

lakomen 4y ago

Microservices without events are useless. I'm tired of repeating myself and I'm tired of the buzz hype. All this is, is putting you at a disadvantage, vs just a package that isn't hosted on its own. I'm tired of seeing wrong theorems applied and sold as something good when in reality its bad. Why this makes the top page of HN is beyond me

acjohnson55 4y ago
You seem exasperated, but it's not clear what point you're making. If you're saying that these utilities would be better off as libraries, what you get hosting them is language independence. With extremely light runtimes, the cost of RPCing to access some logic isn't that much greater than a library call. For things that aren't performance critical, the overhead might be fine.
mstafa 4y ago
> Microservices without events are useless why?

mbrodersen 4y ago

A colleague of mine is currently working on a 20+ years old micro services system. It has more than 50 services that are all super busy sending messages to each other in a wonderfully chaotic jaw dropping WTF way. While solving really simple business problems. It is without a doubt the most complex and badly designed software I have ever experienced or read about in my 30+ years career. I am predicting that 10 or 20 years from now developers unlucky enough to have to take over micro services systems created today will curse the developers who today are inexperienced enough to think micro services is a good idea.

ofrzeta 4y ago

I think it's a good direction to provide standardized services for running multiple containers as a cloud application. The current state is: get some "legacy" (old school unix) server, pack it into a container (with some ugly shell hackery, albeit in a Dockerfile or Kubernetes manifest), provide configuration through environment variables or rewrite the old-school .conf files through more shell hackery. All state management of those servers is done through more shell hackery (select statements or nc for databases; nc or wget for http services; touch a random dotfile after a certain state is reached).