4 ms·

A new API backend for the jamstack

39 points by asim 6y ago

asim 6y ago
Hi all! Co-author of the post here and founder of Micro. Let me know if you have any questions. As always interested to discuss and get feedback. Cheers, Asim.
- tmikaeld 6y ago
  Why invest time and money in your platform, instead of an established one like Cloudflare and their new Workers platform? Features are similar, especially when combined with Cloudflare Access (50 users free).
  - friendly_chap 6y ago
    It's open source and you can self host it yourself if you want. Micro also provides a full development model for services development, since it's also a framework and not "just" a platform. Disclosure: I'm a contributor.
    - tomcam 6y ago
      > It's open source and you can self host it yourself if you want. But you can’t use it commercially, right? https://github.com/micro/services/blob/master/LICENSE https://github.com/micro/services/blob/master/LICENSE
  - asim 6y ago
    Good question. Cloudflare and many other platforms like it are closed source and you're mostly locked in to a very custom development model, there's also no escape hatch. For what you get, it's great, I love cloudflare but I also think we're in a world where being open source first matters. Micro is open source (https://github.com/micro/micro https://github.com/micro/micro) and that's how it started life. It's now "source available" in the sense that we use a license that stops AWS from picking up and hosting it for profit without contributing back, but it's otherwise completely usable for any purpose. Micro as an open source platform enables the ability to self host, develop locally and move beyond our offering m3o.com. I think it also creates trust and thats something we're going to really be thinking about a lot in the next 5-10 years. We're also looking beyond the core primitives themselves towards these value add services in the category of "backend", "logistics", etc. I think providing a generic platform as a service isn't good enough anymore, we really have to push a lot further.
    - tmikaeld 6y ago
      Thanks, I'll take a deeper look and check it out.
- monkin 6y ago
  What’s with your name? Micro? Mu? m3o? Are you thinking about establishing one name for the whole brand? Especially as “micro” isn’t good searching term, it’s more like “go”. :)
  - asim 6y ago
    Yea good question. Micro started with the domain micro.mu for the open source project and we recently found m3o works as a nice moniker and were able to get the dotcom so I think for searchability its "m3o" but the name is Micro, that's what we've always been since inception. And yea Go users search for Golang :) so Micro users search for m3o.
- mindhash 6y ago
  Looks interesting. Where is the data from services stored? I went through the docs and code, couldn't figure this out
  - asim 6y ago
    The data is stored on the platform itself through something called a "store" service. In the long term we'll offer exporting that or backing by your own data storage if that's preferable. Micro provides built in primitives for auth, config, storage, etc. You can learn more about them here https://micro.mu https://micro.mu
- FlorianRappl 6y ago
  Thanks for sharing! How is it different to DAPR (https://dapr.io https://dapr.io) (besides using a side car to enable all kinds of frameworks instead of just go)? Are the goals similar or actually quite different? How difficult is it to run it completely independent and on premise (i.e., define custom storage provider etc)? Any examples available? Thanks!
  - asim 6y ago
    I think Dapr has the same goals as Micro. Dapr is from the team who built Azure Service Fabric, which is basically a microservices platform, and with this they've decided to take an open source angle for kubernetes. We're going the other way. Open source is great, but it's not enough. Micro 3.0 is a hosted platform and focused on removing that operation burden but also providing value add higher level services. I think like most things you either prefer dapr's primitives or ours. As was the same with go-micro vs grpc-go. Micro can be self hosted. It's an open source project for which you can find the docs here https://micro.mu https://micro.mu.
- yewenjie 6y ago
  Does anyone have a link to the detailed limits of the free plan? I don't see any numbers on the pricing page.
  - asim 6y ago
    Here you go https://docs.m3o.com/faq#fair-usage-policy https://docs.m3o.com/faq#fair-usage-policy
dgb23 6y ago
First of all I think there is merit in trying to do "Netlify for the backend". Or a more flexible and backend focused variation of Vercel (I think they only let you do FaaS, correct me if I'm wrong). Services like these provide a constrained, "just works" user (dev) experience. However, I don't like the name "Micro Services". It seems like the authors are trying to hijack a well established term for their brand. This might be incredibly confusing for new developers and at the same time turn off experienced ones. Also there seems to be little explanation of the storage system. From the docs: > State is a fundamental requirement of any system. We provide a key-value store to provide simple storage of state which can be shared between services or offload long term to keep microservices stateless and horizontally scalable. Is key-value standard practice for the target audience? This is a little bit of a point of confusion. Especially if we're dealing with a language like Go, which has many benefits and advantages, but expressiveness is not one of them. So building up ad-hoc relational logic with it seems scary! I'm not too familiar with Go. But from reading some of the example code[0] I get the feeling that there must be some very good reason for avoiding relational. And what confuses me further is the name collision with go-micro[1]. [0] https://github.com/micro/services/blob/master/messages/handler/handler.go https://github.com/micro/services/blob/master/messages/handl... [1] https://github.com/asim/go-micro https://github.com/asim/go-micro
game_the0ry 6y ago
I am going to coin a new tech jargon buzz word: Micro Service as a Service (MSaaS). Copyright 2020. I guess it was only a matter of time for the back end to be totally commoditized. As a UI dev, I find this pretty exciting that I have more options (serverless or building the server myself) and at what layer (IaaS, PaaS, FaaS, etc) from a variety of service providers (amazon, ms, google). But if I was a back end dev, I would a little concerned about job security. It seems like that that career path is becoming more AWS/Azure/Google Cloud admin and less about needing to code business logic for the back end layer, especially as companies like Micro start becoming popular. From personal and professional experience, my servers tend to have little business logic and are usually a thin CRUD layer between the UI and DB layer (over-simplified, I know, but that is like 90% of the back end work I have done). Then again, tech fads come and go and we need to adapt to the times.
- sagolikasoppor 6y ago
  In my humble experience as a full stack dev, backend jobs are going nowhere. Sure stuff like firebase and similar works for CRUD apps but as soon as you want to do more specific stuff they usually are worthless. I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side?
  - game_the0ry 6y ago
    > In my humble experience as a full stack dev, backend jobs are going nowhere. Agreed, mostly. What I am trying to say is there is a lot of change in the back end of the stack and it's in our best interest to adapt to that change. But if you're not willing to change, your job security will become an issue.
  - game_the0ry 6y ago
    > Sure stuff like firebase and similar works for CRUD apps but as soon as you want to do more specific stuff they usually are worthless. Agreed again, but the fact that you have the option to use Firebase at your discretion is better than not having the option to use. > I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side? It depends on the use case, and that is key. Too many engineers spend too much time arguing on a hacker news that their way is the One True Way (Trademark) - that is not always the case. Your business needs should drive your tech stack choice, and no one tool is perfect. So if, like in your example, your use case involves a lot of data processing in the back end, then the choice is easy: favor building the custom server and associated data processing yourself, over using a BaaS or FaaS. However, if you are building a CRUD app where you have like less than 1,000 people using your app, you're time constrained, you don't have enough devs, then Baas/FaaS starts to become a more viable option.
tomcam 6y ago
License is Non commercial use only. https://polyformproject.org/licenses/strict/1.0.0/ https://polyformproject.org/licenses/strict/1.0.0/

39 points by asim 6y ago

asim 6y ago

Hi all! Co-author of the post here and founder of Micro. Let me know if you have any questions. As always interested to discuss and get feedback. Cheers, Asim.

tmikaeld 6y ago
Why invest time and money in your platform, instead of an established one like Cloudflare and their new Workers platform? Features are similar, especially when combined with Cloudflare Access (50 users free).
- friendly_chap 6y ago
  It's open source and you can self host it yourself if you want. Micro also provides a full development model for services development, since it's also a framework and not "just" a platform. Disclosure: I'm a contributor.
  - tomcam 6y ago
    > It's open source and you can self host it yourself if you want. But you can’t use it commercially, right? https://github.com/micro/services/blob/master/LICENSE https://github.com/micro/services/blob/master/LICENSE
- asim 6y ago
  Good question. Cloudflare and many other platforms like it are closed source and you're mostly locked in to a very custom development model, there's also no escape hatch. For what you get, it's great, I love cloudflare but I also think we're in a world where being open source first matters. Micro is open source (https://github.com/micro/micro https://github.com/micro/micro) and that's how it started life. It's now "source available" in the sense that we use a license that stops AWS from picking up and hosting it for profit without contributing back, but it's otherwise completely usable for any purpose. Micro as an open source platform enables the ability to self host, develop locally and move beyond our offering m3o.com. I think it also creates trust and thats something we're going to really be thinking about a lot in the next 5-10 years. We're also looking beyond the core primitives themselves towards these value add services in the category of "backend", "logistics", etc. I think providing a generic platform as a service isn't good enough anymore, we really have to push a lot further.
  - tmikaeld 6y ago
    Thanks, I'll take a deeper look and check it out.
monkin 6y ago
What’s with your name? Micro? Mu? m3o? Are you thinking about establishing one name for the whole brand? Especially as “micro” isn’t good searching term, it’s more like “go”. :)
- asim 6y ago
  Yea good question. Micro started with the domain micro.mu for the open source project and we recently found m3o works as a nice moniker and were able to get the dotcom so I think for searchability its "m3o" but the name is Micro, that's what we've always been since inception. And yea Go users search for Golang :) so Micro users search for m3o.
mindhash 6y ago
Looks interesting. Where is the data from services stored? I went through the docs and code, couldn't figure this out
- asim 6y ago
  The data is stored on the platform itself through something called a "store" service. In the long term we'll offer exporting that or backing by your own data storage if that's preferable. Micro provides built in primitives for auth, config, storage, etc. You can learn more about them here https://micro.mu https://micro.mu
FlorianRappl 6y ago
Thanks for sharing! How is it different to DAPR (https://dapr.io https://dapr.io) (besides using a side car to enable all kinds of frameworks instead of just go)? Are the goals similar or actually quite different? How difficult is it to run it completely independent and on premise (i.e., define custom storage provider etc)? Any examples available? Thanks!
- asim 6y ago
  I think Dapr has the same goals as Micro. Dapr is from the team who built Azure Service Fabric, which is basically a microservices platform, and with this they've decided to take an open source angle for kubernetes. We're going the other way. Open source is great, but it's not enough. Micro 3.0 is a hosted platform and focused on removing that operation burden but also providing value add higher level services. I think like most things you either prefer dapr's primitives or ours. As was the same with go-micro vs grpc-go. Micro can be self hosted. It's an open source project for which you can find the docs here https://micro.mu https://micro.mu.
yewenjie 6y ago
Does anyone have a link to the detailed limits of the free plan? I don't see any numbers on the pricing page.
- asim 6y ago
  Here you go https://docs.m3o.com/faq#fair-usage-policy https://docs.m3o.com/faq#fair-usage-policy

dgb23 6y ago

First of all I think there is merit in trying to do "Netlify for the backend". Or a more flexible and backend focused variation of Vercel (I think they only let you do FaaS, correct me if I'm wrong). Services like these provide a constrained, "just works" user (dev) experience. However, I don't like the name "Micro Services". It seems like the authors are trying to hijack a well established term for their brand. This might be incredibly confusing for new developers and at the same time turn off experienced ones. Also there seems to be little explanation of the storage system. From the docs: > State is a fundamental requirement of any system. We provide a key-value store to provide simple storage of state which can be shared between services or offload long term to keep microservices stateless and horizontally scalable. Is key-value standard practice for the target audience? This is a little bit of a point of confusion. Especially if we're dealing with a language like Go, which has many benefits and advantages, but expressiveness is not one of them. So building up ad-hoc relational logic with it seems scary! I'm not too familiar with Go. But from reading some of the example code[0] I get the feeling that there must be some very good reason for avoiding relational. And what confuses me further is the name collision with go-micro[1]. [0] https://github.com/micro/services/blob/master/messages/handler/handler.go https://github.com/micro/services/blob/master/messages/handl... [1] https://github.com/asim/go-micro https://github.com/asim/go-micro

game_the0ry 6y ago

I am going to coin a new tech jargon buzz word: Micro Service as a Service (MSaaS). Copyright 2020. I guess it was only a matter of time for the back end to be totally commoditized. As a UI dev, I find this pretty exciting that I have more options (serverless or building the server myself) and at what layer (IaaS, PaaS, FaaS, etc) from a variety of service providers (amazon, ms, google). But if I was a back end dev, I would a little concerned about job security. It seems like that that career path is becoming more AWS/Azure/Google Cloud admin and less about needing to code business logic for the back end layer, especially as companies like Micro start becoming popular. From personal and professional experience, my servers tend to have little business logic and are usually a thin CRUD layer between the UI and DB layer (over-simplified, I know, but that is like 90% of the back end work I have done). Then again, tech fads come and go and we need to adapt to the times.

sagolikasoppor 6y ago
In my humble experience as a full stack dev, backend jobs are going nowhere. Sure stuff like firebase and similar works for CRUD apps but as soon as you want to do more specific stuff they usually are worthless. I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side?
- game_the0ry 6y ago
  > In my humble experience as a full stack dev, backend jobs are going nowhere. Agreed, mostly. What I am trying to say is there is a lot of change in the back end of the stack and it's in our best interest to adapt to that change. But if you're not willing to change, your job security will become an issue.
- game_the0ry 6y ago
  > Sure stuff like firebase and similar works for CRUD apps but as soon as you want to do more specific stuff they usually are worthless. Agreed again, but the fact that you have the option to use Firebase at your discretion is better than not having the option to use. > I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side? It depends on the use case, and that is key. Too many engineers spend too much time arguing on a hacker news that their way is the One True Way (Trademark) - that is not always the case. Your business needs should drive your tech stack choice, and no one tool is perfect. So if, like in your example, your use case involves a lot of data processing in the back end, then the choice is easy: favor building the custom server and associated data processing yourself, over using a BaaS or FaaS. However, if you are building a CRUD app where you have like less than 1,000 people using your app, you're time constrained, you don't have enough devs, then Baas/FaaS starts to become a more viable option.

tomcam 6y ago

License is Non commercial use only. https://polyformproject.org/licenses/strict/1.0.0/ https://polyformproject.org/licenses/strict/1.0.0/