Netlify for the frontend, Micro for the backend (opens in new tab)

Thanks for the feedback. I'm assuming you mean the website. We have info and tutorial in docs but agree we could provide more clarity on the website. There is a redesign coming in the next few weeks. There are tutorials in the docs and many code examples in https://github.com/micro/services. The blog post also links to this code. But again I agree we could do more to showcase it. This post was more to demonstrate positioning of us in the market and fill the gap for those building stuff with Netlify.

Here's a few besides Heroku I'm keeping an eye on:

* https://render.com/

* https://www.digitalocean.com/products/app-platform/

* https://www.koyeb.com/ (announced today)

* https://vercel.com/

Heroku for sure. It’s all running on AWS so you can leverage AWS services without as much of a performance penalty for routing as say another provider.

I don’t understand how this Micro framework is valuable unless your entire team writes Go. Even then, this is not just ‘micro services’ it’s a monolith on a proprietary framework that happens to have network hops between function calls. It is the kitchen sink!

Check out NHost [1], which isn't an exact match, but worth a look. What it gives you (currently) is Postgres via Hasura, which gives you (AMAZINGLY) easy GraphQL database access, along with a very nice auth service. And their entry level is cheap.

I've written Hasura actions for the service, which allow painless redirection of arbitrary GraphQL to (e.g.) an AWS Lambda function. Direction function support is on NHost's roadmap.

1: https://nhost.io

It's in preview but Azure Static Web Apps

https://azure.microsoft.com/en-us/services/app-service/stati...

Deploy JavaScript/TypeScript/Python/C# backend function apps with a modern frontend in one go, sets it all up for you on GitHub and handles the build process and SSL certificates for custom domains too.

Dark (https://darklang.com) is a very cool platform for building serverless backend APIs.

The Dark language itself is not what you’re looking for, and I don’t know if I would trust it in production (it’s still in beta). But the platform makes it extremely quick to get a POC backend working.

Google Cloud Run / AWS Fargate. You upload a Docker image and you instantly have a service with auto-scaling, load balancing, HTTPS, etc. It works with any programming language thanks to Docker.

(Python) AWS chalice (https://github.com/aws/chalice). Nice wrapper for lambda that lets you write "Flask" like routes.

I'll answer my own question (after doing some research).

Besides the other answers, I found Cloudfare Workers[1] seem to nearly fit the bill (the only problem is that workers are written in JS - though you can also write them in Rust, C or C++, with the caveat that they compile to WASM, then are executed via the JS API).

Pricing start free! With $5/month you get access to KV (Key-Value Storage) and a generous amount of requests (10 million/month) which seems appropriate for my needs... and it's still in beta, but they also have consistent storage now with Durable Objects[2].

[1] https://developers.cloudflare.com/workers/tutorials

[2] https://developers.cloudflare.com/workers/learning/using-dur...

I think it's a good point and something I find myself worrying about as well. The hype around GraphQL and Apollo, for example, made me feel that I was losing serious time developing a REST APIs until I finally committed and decided to use it on a project. Obviously there ended up being a lot of trade-offs but in the end it was hard to tell if I saved any time at all. More generally, after falling for this a couple times of I realized that often you're just pushing problems around to different parts of the stack, or hiding complexity in places you'll eventually need to uncover. My experience says that the time consuming parts of building a product are rarely solved by adding flashy new services and libraries, and so I try to worry about these things less. On the other hand, trying out new stuff even just for an hour or two can give you a lot of insight into how much time it's actually going to save you - so worse case you just take it for a test run and see what it's actually all about.

Maybe microservices might seem buzzwordy on the surface, and this might be an anecdote, but I have seen it working first hand at Hailo (Uber competitor back in 2013). Relatively inexperienced people not knowing anything about Go or deeper architectural issues deploying Go services in no time, without even asking for permission.

I don't think that would have been doable with a monolith. It enabled innovation I have never seen before. My 2c

Netifly at least was as painless as a deploy process as I've ever had; I had a local jekyll instance i was using to build my blog, and all i had to do was setup Netifly so it was pointing at the remote Github repo for that instance, then simply push to master and everything deployed instantly. There certainly are some tools in the area that feel very over-engineered but so far this one has been quite the opposite (other than weird SSL woes, but that was still more or less painless) Can't speak to the backend product being sold here, but the frontend really was painless and performant.

Happy to talk more about the benefits of Polyform and why we chose that. If you've seen what's happening with open source and AWS you'll understand that this is one of the few ways to protect against cannibalisation of our ecosystem and ability to build a real business. AWS gives nothing back to the creators, and we believe cloud will have its music industry moment. Polyform is a fairly liberal and standardised set of licenses co-drafted by Heather Meeker is well known for her work on open source and enterprise licensing. We believe licensing evolution is required beyond Apache 2.0 and MIT in this new world of cloud and AWS. By choosing licensing standards over custom drafting we think it will make it simpler for companies to adopt and get approval of those in larger orgs. Again happy to speak more on the topic.

> One concern is your pricing seems too reasonable (free)!

Is that reasonable? Building anything on top of obvious loss leaders is risky. And the costs here for a year of service are either $0 on the free plan or $420 for the cheapest paid plan. There's a chasm of difference there.

I can't understand people offering platforms and services with a pitch that tries to describe what sets $THING apart from others, but when it comes to pricing, they settle for looking around at what everyone else is doing and copying that—which usually results in offering a free tier and paid plans usually starting at $5–9+ per month. Chances are, what you're selling probably isn't as unique as you think it is (this post mentions Netlify several times, for example, but Netlify doesn't only do static hosting―you can run microservices with Netlify, too, and Netlify's paid plan is cheaper).

More businesses could and should differentiate themselves in their pricing model, because the door is wide open and pretty much nobody else is showing interest in taking advantage of the opportunity.

Thanks for the feedback. And yes we're learning and iterating on pricing. I think the key will be fair usage policy and resource limits that allow people to scale with their usage. We'll also work on additional pricing tiers for larger teams which I think will be more appropriate. Theres a lot we can't do on $35/user/month. But it's a start!

I worked a bit on this space, mostly for https://simplesql.redbeardlab.com/ (not running at the moment, but if folks would like to test it, please leave your email or contact me) and https://redisql.com

KV is the simplest thing you can provide, but in general it is hard to build applications on top of it, especially with changing requirements. KV means basically that all your query and way to interact with the storage must be well-known in advance. While with SQL, all your data is there and it is fast to add an index.

The problem with the solution above are the wrapper for libraries, nobody want to write a django or rails app, and integrate with an HTTP service for the database.

But maybe people are willing to do so for micro...

This is a great point and one reason I am left scratching my head when considering building applications on the JAM stack.

We are working on a solution to this with WeBase [1] and I'd love to see us do an integration with Netlify here where you build with WeBase and host on Netlify (and get automatic API integration with your data models).

[1] https://www.webase.com

Yeah there is a KV store which is more lower level and an ORM like library on top, check this: https://github.com/micro/dev/tree/master/model

Founder of Micro here. Yes the key-value store is basically like a crud database. We're working on some modelling on top of that and something we'll present more like a document database. Watch this space.

> fleed to netlify to avoid insane over-engineered technology stacks

Take a sober, 1000-foot look at Netlify today. They're so caught up in their GitHub-integrated value-add that if you try to follow the docs to do a straightforward "deploy" from a directory with a simple "hello world" index.html, there are multiple failure conditions. The dumbest one being that if it's a Git repo and it encounters a remote that it doesn't recognize, it will shit the bed. I'm not talking about error output; the CLI itself will straight up fail, throw an exception, and terminate.

That's before we even mention the experience of successful use of the CLI. The cacophony of color and the volume of output makes for a sensory overload that's akin to watching a Safdie brothers film.

Just minor feedback.

Was looking for the pricing, and the description for the paid tier is kind of vague when mentioning "2x Increased resource limits". 2x increase compared to what?

Otherwise, looks really nice and will give it a spin this weekend.

Yeah this bits kinda weird. Heroku is still easiest host I’ve found for throwing up an API + database.

Heroku IS the netlify for backends. This product has good intentions though. Good luck!

Big things have small beginnings. In fact, last year this time, we were a global multi-cloud, multi-region play. Because we've done it before it was fairly simple to do again but being so early in our journey it was actually more effort than it was worth. In our case now we will expand geographically as there's a demand for it and we'll put some of that control in the hands of users. If your own user base in the US or EU or Asia, you may not want your backend to be global, you may not want that cost, and you may not want to incur the issues related to distributed storage, synchronization, eventual consistency, etc and the complexity that comes with it. So I think this is something that will evolve over time. Micro builds in the concept of "Environments" and this will be the form of expansion to different regions and cloud providers. The key thing to note, we are not an edge network, Netlify wants to distribute your assets everywhere, but I think APis are for the most part centralised in the cloud with some form of geo load balancing to different regions. All of that will play out over time, so again watch this space.

Go Nitro is not a thing. "Go Micro" was a framework that launched this company into existence, it's now been consolidated into a single project called "Micro". The "Go Micro" project has been renamed to "Nitro" to reduce confusion around the two.

Your services must be written using the Micro framework, as you would use something defined by iOS and Android for those platforms.