Forem: Asim Aslam

M3O - A new serverless cloud platform

Asim Aslam — Wed, 16 Feb 2022 13:26:41 +0000

Hey all 👋

Happy to share M3O, a new serverless cloud platform we're building which tries to put all the common building blocks on one platform. Our goal is to abstract away the complexity of the cloud and provider higher level APIs to build on.

Would love your feedback. Oh and btw, its open source too!

https://github.com/m3o/m3o

Cheers
Asim

M3O - Next generation cloud platform

Asim Aslam — Sat, 05 Feb 2022 13:18:52 +0000

Hey all,

We've been hard at work on M3O for some time now. It's a new cloud provider that focuses on the developer experience. We've got 50+ apis, starting from a serverless postgres database, to user management, search, sms, email, geocoding and much more.

The majority of APIs are FREE to start with a 1 million api call quota per month and $1 per million calls after that. Signup with google, github or email.

Checkout the website https://m3o.com

See M3O Dev for more info and join us on Discord if you have any other questions.

Cheers
Asim

Why developers need an AWS alternative

Asim Aslam — Sat, 06 Nov 2021 13:04:30 +0000

Author: Asim Aslam, founder of Micro Services, Inc. (Micro). Micro is building M3O, an open source public cloud platform. An AWS alternative for the next generation of developers. Consume popular public APIs as higher level building blocks, all on one platform, for a 10x developer experience.

AWS was launched over 15 years ago, imagined as an operating system for the internet at a time before the cloud even existed as a concept. It was built to provide on-demand access to compute, storage and infrastructure services. What previously might have taken 6 weeks to provision was now being done in minutes. It largely unlocked productivity in a way that had not yet been imagined and enabled developers to quickly scale web services as users were coming online.

Yet for all it's worth, AWS has largely maintained this experience and failed to keep up with modern day needs of developers. In 2006, we expected a level of server and database management as developers. What we classified as sysadmins (not yet devops) was a skill we'd gladly learn if it meant being able to ship the next shiny Rails app.

Today we're looking for more. We're looking for not just fully managed (which AWS attempts to convince us they are), but an entirely serverless experience. We don't want to have to deploy that next database or spin up containers. We don't want to deal with the issues that arise when dealing with the complexities of this new fangled Kubernetes. As developers, all we want to focus on is building that next product and leveraging the APIs that let us do that.

In 2021, AWS is slowly being eaten by third party API providers like Algolia, Elastic, CockroachDB, Twilio, Stripe, Sendgrid, Segment and so many many more. We're looking for entirely API first experiences in the cloud that don't require us to think about the infrastructure. We're looking for platforms that compliment our modern day Jamstack architectures powered by the Netlify's and Vercel's of the world.

AWS now leaves a lot to be desired for the next generation of devs. Can they do anything to fix that?

We personally don't believe so.

Who is AWS for?

Then if AWS isn't built for developers, who's it for? AWS was never built for developers in the first place, let's be clear about that. AWS was about provisioning infrastructure services on which we could then run our software which was still automated by the sysadmins in our companies. How do we know that? Because we were heavily invested in AWS in our prior companies.

We contended with the complexity of the bare metal era before AWS and then what came after managed largely by a disarray of hand crafted bash scripts, python libraries and eventually configuration management tools like chef and puppet. We escaped just as the DevOps movement took off but continued to witness the extraordinary pains of building systems for the cloud as a software engineer.

Yet in all that time, we never once saw developers personally touch CloudFormation, or swim the sea of endless complexity unless they truly had to. No, those developers would gladly choose a Heroku long before an AWS, but if you worked at a startup that was scaling, at some point in the lifetime of the company you could expect an infrastructure engineer to join and quickly replatform you to AWS.

The truth of the matter is. AWS was built for operators, not the developers.

There's enough people now shouting at the screen pointing to services like AWS Lambda or Fargate talking about it's serverless nature or how it was built for developers but I'd argue, this is just AWS pandering to an existing Enterprise audience and checking off boxes. AWS is about building the 80% solution to keep existing customers happy, that doesn't mean the actual users in those companies are happy using them.

AWS was the "just good enough" solution for a time in which we had nothing else. The book store that started a cloud computing business even admits to being shocked that they had a 7 year head start on everyone else. Had Google gotten their act together and shipped their superior internal tools as
public services long ago, we'd be having an entirely different conversation.

The fact of the matter is, AWS doesn't understand developers and the harder they try the more complex their offering becomes. As a developer AWS is an overwhelming and anxiety inducing experience.

What do developers need?

What we need is a clean slate approach. As developers we need a new experience for cloud services. We need a new public cloud platform. One that focuses entirely on the developer experience. Higher level building blocks for existing public APIs.

Replicating an AWS isn't the answer. VMs (EC2) and file storage (S3) are not the primitives developers need today. We need to start with next level building blocks for the next generation of devs. Today we are all about the Jamstack and leveraging third party APIs as the backend.

We need a public API platform that aggregates the existing market and provides a new clean abstraction layer on top, all through a single unified offering. One that simplifies the pricing model rather than requiring a pricing calculator to know what you're spending.

For what it's worth, we thank AWS for getting us to this point, but now it's time to hand the torch to someone else. Someone who understands what developers need and provide the next level building blocks for new types of software we'll come to use.

The world is no longer talking about building mobile apps or web services but instead, crypto networks and the metaverse. Your grandparents can barely use a mobile phone, are we really expecting AWS and others to help us build the metaverse?

It's up to developers to build the future and with it decide the kinds of platforms we want to build on. We're now more than ever interested in open platforms. Not just in the case of Web3 but more so in regards to "open source eating everything". It's not enough that just the services you run are open source, the entire system also needs to be so.

AWS built in an era before GitHub, and the explosive nature of open source, is not. AWS is a silo, and a ship filled with containers of teams all building APIs in isolation. Their control plane is not open source, their platform is not open source, their system is not open source. AWS is not open source.

We are a generation of developers who are looking for a new platform, one that aligns with our goals, beliefs and mantras and one that is entirely based on open source software.

I'm Asim Aslam, the founder of Micro, and we're building M3O, a new open source public cloud platform, an AWS alternative for the next generation of developers. Come join me in deciding how, where and what we're going to build the future on.

See the source on GitHub.

M3O - An open source AWS alternative

Asim Aslam — Fri, 15 Oct 2021 14:53:29 +0000

M3O

M3O is an open source public cloud platform.
We are building an AWS alternative for the next generation of developers.

Overview

AWS was a first generation public cloud provider started in 2006. It's infrastructure services and pay as go pricing model made it an incredibly
compelling choice for a previous generation of developers. But what about the future?

M3O is an attempt to build a new public cloud platform with higher level building blocks for the next generation of developers.
M3O is powered by the open source Micro platform and programmable real world Micro Services.

Features

🔥 Dev UX - The developer experience is first priority. A slick new UX for the next generation of developers.
☝️ One Token - Use one Micro API token to fulfill all your API needs. Access multiple public APIs with a single token.
⚡ Fast Access - Using a new API is easy - no need to learn yet another API, it's all the same Micro developer experience.
🆓 Free to start - It's a simple pay as you go model and everything is priced per request. Top up your account and start making calls.
🚫 Anti AWS Billing - Don't get lost in a sea of infinite cloud billing. We show you exactly what you use and don't hide any of the costs.
✔️ Open Source Software - Built on an open source foundation and services which anyone can contribute to with a simple PR.

Rationale

AWS is a fairly complex beast which makes it hard for new developers to get started. In the past we needed VMs and file storage, but today with the Jamstack
and other modern development models, the building blocks we're looking for are changing. They're mostly now third party APIs. M3O is looking to
aggregate all those third party public APIs into a single uniform offering with a slick new dev UX.

Services

So far there are over 35+ services. Here are some of the highlights:

Backend

Cache - Quick access key-value storage
DB - Simple database service
Functions - Serverless compute as a service
Stream - Publish and subscribe to messages
User - User management and authentication
File - Store, list, and retrieve text files

Logistics

Address - Address lookup by postcode
Geocoding - Geocode an address to gps location and the reverse.
Location - Real time GPS location tracking and search
Routing - Etas, routes and turn by turn directions
IP - IP to geolocation lookup

Web

Email - Send emails in a flash
Image - Quickly upload, resize, and convert images
OTP - One time password generation
QR Codes - QR code generator
SMS - Send an SMS message
Weather - Real time weather forecast

See the full list at m3o.com/explore or the source at github.com/micro/services.

Getting Started

Head to m3o.com and signup for a free account.
Generate an API key on the Settings page.
Browse the APIs on the Explore page.
Call any API using your token in the Authorization: Bearer [Token] header and https://api.m3o.com/v1/[service]/[endpoint] url.
See the m3o/cli for command line usage.

Learn More

Checkout the Examples to see what you can build
Follow us on Twitter
Join the Slack community
Join the Discord server
Email Support for help

How it Works

M3O is built on existing public cloud infrastructure using managed kubernetes along with our own infrastructure automation
and abstraction layer for existing third party public APIs. We host the open source Micro project as our base OS and
use it to power all the Micro Services, which provide simpler building blocks for existing cloud primitives.

UX

We host our own custom dev UX (m3o/cloud) on top of the infrastructure stack and a backend
which acts as the management control plane.

Services

Developers build and contribute to services in github.com/micro/services, a vendor neutral home. We then automate the
building and publishing of those services and client libraries. This creates a shared and fully managed platform for everyone to leverage.

Infrastructure

We primarily use existing open source software, fully managed services and third party public APIs as the backing infrastructure then layer a standard interface
on top. With all the services on one platform, accessible with one API token, we drastically improve the Dev UX.

Development

This project is a combination of open source projects and a platform managed by the Micro team. Our goal is to enable any developer to
contribute to the open source while benefiting from the platform as a shared resource.

Cloud Hosting

The cloud hosted providers of Micro services:

m3o.com - a fully managed offering of micro services

Open Source

The core cloud OS and services exists in a vendor neutral org

micro/micro - an open source operating system for the cloud
micro/services - open source micro services powering m3o.com

M3O Dev UX

The hosting of Micro services on m3o.com is powered by the following:

m3o/cloud - locally hostable angular based dev UX for the website
m3o/platform - the infrastructure automation for cloud hosted stack
m3o/backend - the services which power the m3o.com product backend

Publish APIs

If you'd like to publish your own APIs on the M3O platform fill in this form and we'll get back to you.

Contributing

Write examples - m3o/examples provides a place to showcase things built on top which we'll feature on the website
Write services - micro/services are all the services we host and hope for more devs to help
Write docs - m3o/docs is where our docs will live and we know without great docs this isn't going to work
Show support - Tweet @m3oservices and let the world know what we're building so that more people can get involved

Thanks for reading

Hopefully you buy into what we're talking about and the need for something new in the public cloud space.
If you like what you’re hearing, Signup for Free or send us some feedback.
Reach out on slack or twitter if you have any questions.

Micro APIs for everyday use

Asim Aslam — Wed, 30 Jun 2021 09:38:11 +0000

Hey all,

Today we’re excited to announce our new Micro API cloud platform, now in beta. Simple, fast and affordable APIs for everyday use. Signup for free (no credit card needed) and get $5 of free credit to get started.

API building blocks

Micro has evolved from an open source framework to a full blown API platform, one that continues to focus on the developer experience first and foremost. The majority of our users are building APIs for end public consumption but having to rebuild many of the building blocks they need wherever they go.

We wanted to solve that problem by providing a set of programmable building block services as simple APIs for public consumption from anywhere in the world, all in one place.

Some of the APIs we’re offering are as follows:

Cache - Ephemeral key-value storage -
Store any data up to 1mb for fast key based lookup. Set TTLs to expire entries so you don’t have to remember to delete them.
DB - Simple database service -
Use CRUD via an API and leave the SQL behind. A really dead simple database service which provides JSON document storage.
Crypto - Cryptocurrency prices and quotes -
Stay up to date with bitcoin, ethereum, dogecoin and other prices. Track them in real time and build any sort of visualisation on top.
Image - Upload, resize and crop images -
Upload images, resize on the fly and serve them via a CDN all without having to do anything more than curling our API.
OTP - One time password generation -
Throwaway the passwords and use one time token generation to login or authenticate users. Simple OTP generation and validation.
Routing - Turn by turn directions and etas -
A vastly cheaper Google Maps API alternative powered by OSRM. We’ll give you turn by turn routing directions and etas using OpenStreetMap data.

Third Party APIs

Additionally we’ve partnered with third party API providers such as Finage, ExchangeRate-API and the WeatherAPI to bring more functionality to the platform like Currency conversion, Stock prices and Weather forecasts, so you can access everything you need with just one account and one API key, all in one place. We’re adding more and more third party API providers everyday so keep your eyes peeled!

Taming Complexity

AWS is the cloud giant in the sky we've all come to know as the definition of API building blocks but over time it's complexity has also grown, making it
more and more difficult to work with as a developer. We see this, we feel this and we know there needs to be a change.

Micro attempts to remove the marketing spiel, cloud complexity and bottomless billing by doing the following:

API docs and usage are always just one click away
Billing is Top-Up only. Only use the credit in your account
Everything can be accessed via Curl or any simple HTTP library

Here's some of what we're talking about.

API docs provide examples and usage along with the pricing clearly next to the endpoint

Test out the API right there in the UI

We'll add $5 free credit to your account to start but just top-up with however much you need

Then just head to the token page to create yourself a well scoped token for external use

And finally. Curl it from anywhere!

curl "https://api.m3o.com/v1/id/Generate" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MICRO_API_TOKEN" \
  -d '{"type": "snowflake"}'

Thanks for reading

Hopefully you buy into what we're talking about and the need for something new in the API space. If you like what you’re hearing, Signup for Free or send us some feedback. Reach out on slack or twitter if you have any questions.

Why and how we built Distributed with Next.js and Micro

Asim Aslam — Fri, 26 Mar 2021 19:55:39 +0000

Distributed is a live social chat app built as a Jamstack demo using Next.js and Micro. We built it to demonstrate the value proposition of M3O - a cloud platform for API development. This post explains what went into building Distributed in just a few weeks and how M3O helped rapidly build our MVP.

You can find the source code for distributed on Github. If you want to build and host your own version signup to M3O and start running the same services from our open source repository micro/services.

Why we built Distributed

Distributed was built as a jamstack demo to show how you could leverage M3O as an API backend for rapid MVP development. M3O itself is a cloud platform for API development, built on the popular open source project Micro. Micro enables you to quickly build APIs in Go on the backend and M3O provides simple free hosting of those services.

We wanted to show the Jamstack audience how you could quickly leverage those APIs to build something on the frontend. Not only that, we really wanted to understand and experience the frontend developers perspective through dogfooding of our own APIs rather than just throwing stuff over the wall and hoping it works.

Hopefully in that we we've done is demonstrate the value of our platform and how others can also make use of it with a real world app like Distributed to learn from. Let's talk more about Jamstack now.

Jamstack Development

Jamstack is a new architecture pattern for frontend which offloads dynamic aspects of the stack to javascript and third party APIs. Vercel, the makers of Next.js and related companies are pioneering the way forward for jamstack development.

Credit jamstack.org

JAMstack stands for Javascript, API and Markup. The static part of the application is deployed to a CDN with javascript dynamically loading various pieces of dynamic content from backend APIs and rendering it.

Why we chose Next.js

Next.js is a massively popular react based framework for Jamstack development. When we were looking at building out a demo on top of M3O we had the choice of going down a number of routes but what really appealed to us was the how deliberate a lot of the choices were in how the Vercel team had constructed the Next.js framework.

Being framework creators ourselves with the dominant framework Go Micro for Go, we could appreciate the efforts required and strong opinions needed to drive such adoption and success. Vercel has done a phenomenal job in this way.

Beyond praising Vercel's efforts. The Next.js framework includes a lot of key components needed for the Jamstack including server side rendering, api routes and typescript support. For us these were mandatory feature requirements when building against not only our APIs but third party providers.

Micro for the Backend

Micro is an open source cloud platform for API development. With modern day complexity in writing software for the cloud, Micro has attempted to distill that down to a handful of primitives and a framework for building services in Go.

Micro took learnings from the original Go Micro framework and focused on not just gRPC based service development but actually packaging together a runtime and platform which exposes those services automatically as APIs. What this means is we can write microservices on the backend using gRPC and protobuf and immediately provide value to consumers and clients on the frontend via HTTP/JSON.

To learn more about that check out the project at micro.mu or the hosted platform at m3o.com.

Building on Netlify

We initially chose Netlify for hosting as we saw many people adopting it for Jamstack apps. Initially this proved really great for static content. As our apps got more complex and we started to build out the Distributed demo we found Netlify no longer scaled with our basic needs. The first example we can share is Netlify Functions for Next.js API routes.

Next.js routes can be turned into Netlify Functions which are essentially hosted as AWS Lambda functions. It's a clever way of pushing certain requirements to the server side, like calling third party APIs with keys you don't want to expose to the client. Next.js is great in this regard and plugins like netlify-plugin-nextjs and next-on-netlify
let us do this really quickly but the performance left a lot to be desired.

Our APIs are primarily hosted in London on DigitalOcean and while Netlify has a CDN for static content, the Lambda functions are deployed in a single region in US-East on AWS. For those who've suffered this pain you know exactly what that means. We were making cross atlantic calls from JS in the client to api routes on lambda and then finally to our apis.

Needless to say this didn't scale for us. We weren't able to reach out the Netlify team to get help and so in frustration had to go down the self hosted route. Note we did test out Vercel and found the experience to be faster but self hosting on DigitalOcean just made more sense for our demo needs.

Switching to Self Hosted

One of the things DigitalOcean now provides is App Platform, a container hosting solution which lets you pick regions, does TLS certificate management for your custom domain and automatic builds from Git. This turned out to be a perfect solution for self hosted Next.js apps.

Next.js at the end of the day is a React and node.js based application. As much as you may want to separate out the static content to something like Netlify and functions on Lambda, it equally just makes sense to host the entire thing in one place and run many copies of it much like we did in the old php and rails days.

Because the APIs are colocated with the frontend we find this experience fairly fast, sub 100ms for all the API calls but we know it's not an ideal demonstration of the Jamstack's architecture and so we'll be working towards hosting on Vercel in the future to showcase that experience.

How It All Fits Together

We're running Distributed as a Next.js application on the frontend talking to Micro APIs on the backend. All of this is constructed as API routes in Next.JS firing requests at our M3O platform and the various APIs we need. Let's walk through a typical request.

For example, when loading a group we need to get the group info, user profile, chats and more. We could do this as a GraphQL APIbut that would require too much stitching together in terms of the schema on the backend. Instead we're using protobuf and RPC for rapid development there and Micro automagically exposes that as a HTTP/JSON API.

So a typical flow is like so.

Frontend makes a request to /api/groups/[id] which loads the api code in the Next.js app
We validate the user is logged in by calling the /users/Validate endpoint and ff authenticated load the group data by id using /groups/Read
Skipping ahead, we'll load group messages via /threads/ListConversations and private messages using /chats/ListMessages
We can check for already read messages via a "seen" API and then subscribe to the streams API for instant messaging
Finally we render everything based on the content loaded for the user

.gist-data { max-height: 600px; overflow: auto;}

Here's a code "snippet" for those interested. From an MVP standpoint this is just a very quick and rapid way for us to build against numerous separate APIs on the backend all hosted in the same place.

For anyone interested in the "call" function. It's simply a small function we're using to call the Micro APIs on the backend. Remember Micro turns any RPC based service into a HTTP/JSON API automatically via an API gateway. M3O provides hosting for all this.

Performance & Productivity

Aside from the structural benefits of a framework like Next.js we find it really unlocks significant productivity by providing an opinionated approach to frontend development. That coupled with Micro on the backend and our APIs hosted on M3O it's enabled us to rapidly ship this MVP within the space of 4-6 weeks with mostly 1 person doing the work.

That really speaks to the power of the combination of Next.js and Micro. For this demo we built APIs for user management, group messaging, websocket streaming, sending invite emails and audio/video through Twilio WebRTC. One can only imagine where it would go with a dedicated team and full product focus.

On the performance side, Next.js is blazingly fast by all measures. Whether it be the local reload for development or the server side rendering. It all adds to a really snappy experience on both the development and consumption side of things. With the backend we tried to pair this with Go based APIs written with Micro to ensure not just speed of development but also speed of delivery.

All in all, we think Next.js and Micro are the perfect pairing for any Jamstack and API based development.

Conclusions

Thanks for reading this post on how we built Distributed on the Jamstack using Next.js and Micro. Find the source code for distributed on Github. If you want to build and host your own version signup to M3O and start running the same services from our open source repository micro/services.

Reach out on slack or twitter if you have any questions.

M3O - A platform for API driven services development

Asim Aslam — Sun, 22 Nov 2020 15:52:39 +0000

Most of the time API development itself is not challenging. It's booting and managing the infrastructure and workflow for those APIs. M3O is a new platform for API driven services development. Write your API in Go. Push the source directly or from a public Git server. Watch it become publicly routable in seconds. No ops needed.

https://m3o.com

Turn any blog or RSS feed into an API

Asim Aslam — Mon, 16 Nov 2020 15:45:45 +0000

Last time we talked to you about how we believe Micro is Netlify for the backend.
We got a very strong positive reaction to that, filling a pain point it looks like many people had. In that post we used headless cms aka blog posts
as an example of the API you'd build on the backend to be consumed by a frontend. Today we're going to take it a step further.
We're going to turn any blog or RSS feed into an API.

An API on its own isn't enough. There's no content. You have to populate it yourself. So what if we made it just a little bit easier. How about we help
you turn any blog, any content with an rss feed into an easy to consume API with just a handful of commands. That's the power of Micro.
Exciting right, let's get to it.

Things to know before we start

Before we start, just a little housekeeping. Here's the tools we provide and are making use of.

Micro - is an open source framework for microservices development
M3O - is a hosted platform for backend API development powered by Micro

These two things are fairly important to know before starting. Ok back to it.

Content in 2020

For the most part blogging platforms haven't really evolved. There's still wordpress but interestingly everythings a bit of a silo or you have to
run something yourself, we use a bit of jekyll + markdown, etc and that works but it's not very developer friendly (from an API standpoint).
That's really led to firstly a bifurcation in adoption of tools and how content is stuck in walled gardens (another story for another day) and
why we're seeing an explosion in headless CMS.

People want to write content and get paid. Most of those places don't really have APIs but do have RSS feeds. Developers want to consume and
use this content, quite honestly it goes beyond developers. Content is king and it's used for all sorts of sentiment analysis and other
market research. It's also actually reblogged, retweeted, and put in lots of different places. It would be really great if there was a much
simpler way to go about providing APIs for all this content out there.

So let's do it. Micro is going to turn any blog or RSS feed into an API so it can be consumed from anywhere in any which way. And the key point
here, it's all hosted for you, without having to think about doing that yourself.

Deploying the blog backend

If you weren't around for the other post, we'll help you deploy the existing posts api and related services.

Signup to M3O

You'll need to install micro and signup to M3O for this.

curl -fsSL https://install.m3o.com/micro | /bin/bash

For those wary of curl into bash, you can view it first https://install.m3o.com/micro.

Signup is purely CLI based for now so just issue the following command and follow the steps

micro signup

Once you're done you should have an account on M3O and be automatically logged in.

Run the API

All the services you're going to run are open source. You can check them out at github.com/micro/services.

Let's bootstrap the blog super quick. Because Micro is all about microservices development, we've decomposed the blog API into posts, comments and tags.
You can find all the code on github.

Deploying these is super simple.

# run the posts service
micro run github.com/micro/services/blog/posts

# run the tags service
micro run github.com/micro/services/blog/tags

# run the comments service
micro run github.com/micro/services/blog/comments

Check they're running using micro status. You should see the status progress through starting, building and running.
If you want to see logs or anything related just do micro logs posts and the same for any other service by name.

Now you've got those installed we need to move on to pulling the content from your current blog's rss feed.

Crawl your blog or RSS feed

RSS feeds are a staple of the content industry. its a powerful standard that basically allows anything to be published as an XML based
stream and then consumed and published in any other form. For most of us we're probably used to using RSS feed readers like
Feedly or similar. Its not glamorous but it definitely gets the job done.

We've written a simple feeds service that can consume any RSS feed and populate your posts API. The code lives on
github alongside all the other services you just started.
Follow below to run and populate the feeds service.

Run the feeds service

micro run github.com/micro/services/blog/feeds

Check and wait for it to be in a running state

micro status

OK now the fun part. Enter your favourite rss feed to be saved and crawled.

micro feeds new --name="hackernews" --url=https://news.ycombinator.com/rss

Now if you give it a minute or so, what you should see is a list of posts from hacker news.

$ micro posts query
{
        "posts": [
                {
                        "id": "334ff5ad67cfd018a42ddd6095d3d51c",
                        "title": "Winners of Close-Up Photographer of the Year",
                        "slug": "winners-of-close-up-photographer-of-the-year",
                        "created": "1605277921",
                        "metadata": {
                                "domain": "news.ycombinator.com",
                                "link": "https://www.theatlantic.com/photo/2020/11/winners-close-up-photographer-year/617070"
                        }
                },
                {
                        "id": "33a807b3636f0d232f219e01ff6ee576",
                        "title": "Scientists discover two new mammals in Australia",
                        "slug": "scientists-discover-two-new-mammals-in-australia",
                        "created": "1605277920",
                        "metadata": {
                                "domain": "news.ycombinator.com",
                                "link": "https://www.cnet.com/news/scientists-discover-two-new-mammals-in-australia/#ftag=CAD-09-10aai5b"
                        }
                },
                {
                        "id": "148774c2fa4762587f84375dd5359a64",
                        "title": "The Next Decade Could Be Even Worse",
                        "slug": "the-next-decade-could-be-even-worse",
                        "created": "1605277919",
                        "metadata": {
                                "domain": "news.ycombinator.com",
                                "link": "https://www.theatlantic.com/magazine/archive/2020/12/can-history-predict-future/616993/"
                        }
                }
}

Your posts as an API

And just like we did last time, here's how to directly query your posts via an api .Get your namespace using the command
micro user namespace and compose the url as $namespace.m3o.dev/posts.

# get your namespace
$ namespace=$(micro user namespace)

# get the posts from the api
$ curl https://$namespace.m3o.dev/posts/query

And hey presto! Just like that we have turned your blog or RSS feed into a http API!

The value proposition

What is the value of turning any content into an API? The world is moving towards being entirely driven by technology. It's not enough that
we be able to consume through the web, we're now moving to mobile, voice and other platforms. APIs will power the world and to really
have full opportunity to realise that we have to get this content out of silos and into a consumable format, that being http APIs.

Companies like Stripe, Twilio, Sendgrid and others have been API-ifying (yea I said) payments, communication and email but content
is still stuck in the dark ages. We think the best way to make it happen is by putting power into the hands of those actually creating
the content or those who really want to program against it. Hopefully this serves as a nice example of how to do that with Micro on M3O.

Micro 3.0 (M3O) is a platform for cloud native development

Asim Aslam — Tue, 10 Nov 2020 18:44:18 +0000

This is the official announcement for the release of Micro 3.0 better known as M3O - a platform for cloud native development.
Our 3.0 release is a major refactor and consolidation of the existing tooling into something that addresses the entire workflow of build, run, manage and consume all from the developers perspective.

Read on to learn more or go straight to the latest release. Head to m3o.com for the hosted offering.

Overview

Micro focuses on developer productivity for the backend. It's clear that the Cloud has become infinitely more complex over the past few years. Micro attempts to create order out of that chaos by distilling it all down to a handful of primitives for distributed systems development.

Why should you care? If you're reading this you've no doubt encountered the tedious nature of infrastructure management,
wrangling a kubernetes cluster on AWS or the thousands of things you need to do to cobble together a platform before
starting to build a product. We think we've nailed the solution for that just as Android did for Mobile. Keep reading
if you want to find out more.

Quick Flashback

Micro started out as a toolkit for microservices development,
incorporating an api gateway, web dashboard and cli to interact with services built using a Go RPC framework.
Back then it felt like getting anyone to buy into PaaS again was going to be a losing battle. So we chose to write single purpose tools around an RPC framework thinking it might allow people to adopt it piece by piece until they saw the need for a platform. It was really straight forward right until it wasn't.

There was a simple Go framework plus some surrounding
components to query and interact with them, but like any long lived project, the complexity grew as we tried to solve for that platform experience that just couldn't be done with a swiss army knife. The repo exploded with a number of independent libraries. To the creator its obvious what these are all for but to the user there is nothing but cognitive overload.

In 2019 we went through a consolidation of all those libraries which helped tremendously but there was still always one outstanding question. What's the difference between
micro and go-micro? It's a good question and one we've covered before. We saw go-micro as a framework and micro as a toolkit but these words were basically empty and meaningless because multiple projects working in coordination really need a crisp story that makes sense and we didn't have one.

In 2020 we're looking to rectify that but let's first let's talk about platforms.

PaaS in 2020

5 years ago the world exploded with a proliferation of "cloud native" tooling as containers and container orchestration took centre stage. More specifically, Docker and Kubernetes redefined the technology landscape along with a more conscious move towards building software in the cloud.

Micro took a forward looking view even as far back as 2015. It was clear distributed systems and cloud native was going to become the dominant model for backend services development over the coming years but, what wasn't clear is just how long we'd spend wrangling all sorts tools like docker, kubernetes, grpc, istio and everything else. It felt like we were rebuilding the stack and weren't really ready to talk about development aspects of it all.

In fact at that time, people mostly wanted to kick the tyres on all these tools and piece something together.
Running kubernetes yourself became all the rage and even using service mesh as the holy grail for solving all your distributed systems problems. Many of us have come to realise while all of this tech is fun it's not actually solving development problems.

We've gotten to the point of managed kubernetes and even things like Google Cloud Run or DigitalOcean App Platform, but none of these things are helping with a development model for a cloud native era. Our frustrations with the existing developer experience have grown and Micro felt like something that could solve for all that, but only if we took a drastic step to overhaul it.

We think PaaS 3.0 is not just about running your container or even your source code but something that encapsulates the entire developer experience including a model for writing code for the cloud. Based on that Micro 3.0 aka M3O is a platform for cloud native development.

What even is Cloud Native?

What is cloud native? What does it mean to build for the cloud? What is a cloud service?

Cloud native is basically a descriptive term for something that was built to run in the cloud. That's it. It's not
magic, it might sound like a buzzword, but the reality is it simply means, that piece of software was built to run in the cloud. How does that differ from the way we used to build before? Well the idea behind the cloud is that its ephemeral, scalable and everything can be accessed via an API.

Our expectation for services running in the cloud is that they're mostly stateless, leveraging external services
for the persistence, that they are identified by name rather than IP address and they themselves provide an API that can be consumed by multiple clients such as web, mobile and cli or other services.

Cloud native applications are horizontally scalable and operate within domain boundaries that divide them as
separate apps which communicate over the network via their APIs rather than as one monolithic entity. We think cloud services require a fundamentally different approach to software creation and why Micro 3.0 was designed with this in mind.

Micro 3.0 aka M3O

Micro 3.0 (M3O) reimagines Micro as a platform for cloud native development. What does that mean? Well we think of
it as PaaS 3.0, a complete solution for source to running and beyond. Micro has moved from just being a Go framework to incorporating a standalone server and hosted platform. Our hosted offering is called M3O, a hat tip to Micro 3.0 or M[icr]o, whichever way you want to see it.

Another way to think about it. What Git is to GitHub, Micro is to the M3O platform. Let's dig into it.

Micro 3.0 includes the following.

Server

The server is our abstraction for cloud infrastructure and underlying systems you might need for writing
distributed systems. The server encapsulates all of these concerns as gRPC services which you can query via any language. The goal here is to say developers don't really need to be thinking about infrastructure but what they do need is design patterns and primitives for building distributed systems.

The server includes the following:

Authentication: Auth whether its authentication or authorization is part of the system. Create JWT tokens, define access rules, use one system to govern everything in a simple and straight forward manner. Whether it’s for a user or a service.
Configuration: Dynamic config management allows you to store relevant config that needs to be updated without having to restart services. Throw API keys and business logic related configuration into the secure config service and let your services pick up the changes.
Key-Value Storage: We’re focused on best practices for microservices development which means keeping services mostly stateless. To do this we’re providing persistent storage on the platform. Key-Value allows you to rapidly write code and store data in the format you care about.
Event Streaming: Distributed systems are fundamentally in need of an event driven architecture to breakdown the tight dependencies between them. Using event streaming and pubsub allows you to publish and subscribe to relevant events async.
Service Registry: Micro and M3O bake in service discovery so you can browse a directory of services to explore your service APIs and enable you to query services by name. Micro is all about microservices and multi-service development.
Service Network: Because you don't want to have to resolve those service names to addresses and deal with the load balancing aspect, the server bakes in a "service mesh" which will handle your inter-service requests (as gRPC) and route to the
appropriate instance.
Identity Proxy: We include a separate identity proxy for external requests using gRPC via the CLI and other means. This enables you to query from your local machine or anywhere else using valid auth credentials and have it seamlessly work as if
you were in the platform itself.
API Gateway: Finally there’s an API gateway that automatically exposes your services to the outside world over HTTP. Internally writing service to service using gRPC makes sense, but at the end of the day we want to build APIs consumed from clients via HTTP.

Clients

The server provides inter-service communication and two means of external communication with a HTTP API and gRPC proxy but that
experience is made much better when there's user experience on the client side that works. Right now we've got two ways of doing this.

Command Line: The CLI provides a convenient and simple way to talk to the server via gRPC requests through the proxy.
The most convenient commands are builtin but every service you write also gets beautiful dynamic generated commands
for each endpoint.
gRPC SDKs: Every service in the server is accessible via gRPC. We're code generating clients for the server itself
so you can access them from any language. What this enables is a wide array of experiences on the client side without
having to handcraft libraries for each language.
Web Interface: Coming soon is a dynamically generated web interface that creates a simple query mechanism through a
browser for any of your services. We've got a http api, gRPC proxy and command line interface but feel like the browser
could use some love too.

Framework

One thing we really understood from our time working on go-micro was that the developer experience really matters. We
see Go as the dominant language for the cloud and believe most backend services in the cloud will be written in Go. For
that reason we continue to include a Service Framework which acts as a framework for building your services and accessing
the underlying systems of the server.

The Service Framework provides pre-initialised packages for all of the features of the server and creates a convenient
initialiser for defining your own services starting with service.New. A Service has a name, endpoints, contains
a server of its own and a client to query other services. The framework does enough for you but then attempts to
get out of your way so the rest is up to you.

A main package for a Micro service looks something like this

package main

import (
    "github.com/micro/micro/v3/service"
    "github.com/micro/micro/v3/service/logger"
    "github.com/micro/services/helloworld/handler"
)

func main() {
    // Create service
    srv := service.New(
        service.Name("helloworld"),
    )

    // Register Handler
    srv.Handle(new(handler.Helloworld))

    // Run the service
    if err := srv.Run(); err != nil {
        logger.Fatal(err)
    }
}

When you want to make use of something like the Config service just import it like so.

import "github.com/micro/micro/v3/service/config"

val, err := config.Get("key")

You can find many more examples in github.com/micro/services.

Environments

From our experience writing software isn't constrained to a single environment. Most of the time we're doing
some form of local development followed by a push to staging and then production. We don't really see tools
capturing that workflow effectively. Thinking about how to do this now we've built in environments as
a first class system.

M3O offers 3 builtin environments; local, dev and platform.

Local - is Micro running on your local machine
Dev - is a free development environment in the cloud
Platform - is a paid secure, scalable and supported production environment

Our goal here is to really direct the flow from local > dev > platform as the lifecycle for any backend service
development. Start by running the server locally, writing your code and getting it to work. Ship it to the
dev environment for further testing but also to collaborate with others and serve it publicly. Then if you're
interested in a scalable and supported production environment, pay for the platform environment. That's it.

Interact with the environments like so.

# view the environments
micro env

# set the environment
micro env set dev

# add a new environment
micro env add foobar proxy.foo.com:443

Micro isn't constrained to our built in environments. You can add others as you wish.

Local Environment

The local environment is just that, your local laptop. Its where development starts and normally
this requires you to run all sorts of crazy infrastructure. Micro focuses on providing pluggable
abstractions as gRPC services so your service just talks gRPC directly to Micro and we hide the
details from you. Locally that means we're using best effort stuff like mdns, file storage, etc.

We've almost made it drop dead simple to start locally. You just run one command.

micro server

This will boot all the services you need and let you build a service that will look identical
in any cloud environment running Micro as a Service.

Set your environment to the local server when using it.

micro env set local

Curl localhost:8080 with your namespace

curl -H "Micro-Namespace: $NAMESPACE" "http://localhost:8080/helloworld?name=Alice"

Get your namespace like so

micro user namespace

This might be blank locally but you'll get the idea for how namespace isolation works in a bit.

Dev Environment

The 'dev' environment is a free cloud hosted environment that provides Micro 3.0 as a Service. What we've
learned in the past few years is that open source is not enough. There's some great open source tools out there
but as soon as we get to deployment there's so many hurdles to overcome. The dev enviroment provides
everyone the ability to get up and running in minutes with the same tools you'd use for local development
in the cloud.

All you have to do is set the env to 'dev' and use it like local.

If you're using the dev environment URLs are *.m3o.dev. Find more details at m3o.dev

Platform Environment

The 'platform' environment is a secure, scalable and supported production environment for where you'd likely
run customer facing services and products. This is a paid tier with 2x the resource limits of dev to start
including slack & email support along with SLAs. You can think of it as the equivalent of a production platform
you've come to know at any work place.

Our goal with Local, Dev and Platform is to invoke that workflow we've all come to know and expect as a real
product. These are totally separate environments and they're managed exactly as that with M3O as well.

Multi-Tenancy and Namespacing

With the advent of a system like kubernetes and a push towards the cloud we can see that there's really a need
to move towards shared resource usage. The cloud isn't cheap and we don't all need to be running separate
kubernetes clusters. In fact wouldn't it be great if we could share that? Well Micro is doing it. We build in
multi-tenancy using the same logic kubernetes does called Namespaces.

We've mapped this same experience locally so you get a rudimentary form of namespacing for local dev but
mostly we're making use of kubernetes namespaces in production along with a whole host of custom written
isolation mechanisms for authentication, storage, configuration, event streaming, etc so Micro 3.0
can be used to host more than one tenant.

Whether you decide to self host and share your cluster for dev, staging and production we felt like
multi-tenancy needs to become a defacto standard in 2020. How it works in practice. Each tenant
get's a namespace. That namespace has its own isolated set of users and resources in each subsystem.
When you make any request as a user or service, a JWT token is passed with that so the
underlying systems can route to the appropriate resources.

Once you've signed up to the dev environment your namespace will be set for you. You can get it using
the command

micro user namespace

When you're using any sort of CLI commands, your namespace and auth token are automatically injected
into request including refreshing those tokens. The same happens for any of your services running
on Micro. If you want to use the http API or the public api url [api.m3o.dev] then go ahead
and grab your namespace and set the header as Micro-Namespace.

Additionally each namespace gets its own custom domain so the foobar namespace becomes foobar.m3o.dev
with say the helloworld service routing would be to foobar.m3o.dev/helloworld.

Source to Running

Micro was built out of a frustration with the existing tools out there. One of the things I've really
been saying for a long time is that I wanted "source to running" in just one command. With
Heroku we sort of got that but it really took too much away from us. Back in 2010 Heroku was focused
on monolithic Rails development. Since then I've really said Heroku took too much away and AWS gave
too much back. We needed something in between.

Micro can take your source code, from a local directory or a repo thats hosted on github, gitlab or bitbucket.
In one command it will upload or pull from the relevant place, package it as a container and
run it. That's it. Source to running in just one command. No more need to deal with the pipeline,
no more hacking away at containers and the container registries. Write some code and run it.

Development Model

Source to running is cool. It's what a PaaS is really for but one thing that's really been lacking even
with the new PaaS boom is a development model. As I eluded to, Heroku takes too much away and AWS
gives too much back. We're looking for a happy medium. One that doesn't require us to rely on VMs or
containers but on the other side doesn't limit us to monolithic development.

Micro has always focused on the practice of distributed systems development or microservices. The idea
of breaking down large monolithic apps into smaller separate services that do one thing well. To do
this we think you really have to bake the development model into the platform.

What we include is the concept of a Service which contains a Client and Server for both handling
requests and making queries to other services. We focus on standardisation around protobuf for API
definitions and using gRPC for the networking layering.

Not only that we're including pubsub for an event streaming architecture and other pieces like
nosql key-value storage and dynamic config management. We believe there are specific primitives
required to start building microservices and distributed systems and that's what Micro looks
to provide.

Multi Language Clients

One of the key learnings we had from the development of a Go framework called go-micro was
that we mostly use a single language for each platform we develop for such as web, mobile and so on. Cloud will be no different.
We support Go for the Cloud, but think there needs to be an ecosystem for consumption of Go services and potentially extending beyond
where there's no way around using python, java, ruby, rust or javascript. Because Micro's interface is gRPC we code generate gRPC
clients and allow any language to leverage the Micro server.

In the past multi-language clients have been pain stakingly hand crafted and one thing we learned from building a framework,
it's incredibly hard to replicate this across languages also. With gRPC we've really found a happy medium of saying, there's
a built in service framework you can use to write code really elegantly with Go but gRPC allows us to reduce the scope of the
surface area and provide strongly typed clients that can support a different model of development, one that might have
more scope for pushing microservices to wide scale adoption in a way that wasn't possible with frameworks.

We additionally include grpc-web generated clients which enable frontend to quickly and easily make use of typed javascript
clients to leverage the same development as the backend. We've seen grpc-web slowly gain adoption internally at various
companies and think this might extend to the public domain fairly rapidly as well.

See the micro/client/sdk directory for the generated clients. These will be
pubished to their respective package managers in the near future.

Building API First Services

Micro was built to make microservices development much easier and to increase developer productivity on the backend, beyond
being able to consume those services using gRPC we think the world still really cares about HTTP/JSON based APIs and so
Micro include an API gateway which translates http/json to grpc requests automatically. This means everyone is building
API first services in the cloud without having to do anything.

Here's a quick example.

Say you write helloworld on the backend with the following proto

syntax = "proto3";

package helloworld;

service Helloworld {
    rpc Message(Request) returns (Response) {}
}

message Request {
    string name = 1;
}

message Response {
    string msg = 1;
}

Then expose this as the "helloworld" service on the M3O platform. You'll instantly be able to access this as $namespace.m3o.dev/helloworld/message

We use path based resolution to map a http request to gRPC. So /[service]/[method] becomes [Service.Method]. If your microservice name doesn't match
the proto for whatever reason (you have multiple proto Services) then it works slightly differently e.g your service name is foobar then the endpoint
becomes /foobar/helloworld/message.

One neat hack we've picked up from web browser is auto detecting an endpoint so we can shorthand something to something like /helloworld. With the web
if an index.html page is found its served. In our case if we find the Call method in your proto we'll automatically use it so /helloworld/call just
shortens to /helloworld.

With Stripe, Twilio, Segment and others become huge API players, we think the world is going in that direction and you are probably building http apis
too. So Micro builds in this in as a first class primitive. In future we'll also look to include support for graphql.

Ten Commands

Alright so we talk a good game, but how easy is it? Well lets show you.

# Install the micro binary
curl -fsSL https://install.m3o.com/micro | /bin/bash

# Set env to dev for the free environment in the cloud
micro env set dev

# Signup before getting started
micro signup

# Create a new service (follow the instructions and push to Github)
micro new helloworld

# Deploy the service from github
micro run github.com/micro/services/helloworld

# Check the service status
micro status

# Query the logs
micro logs helloworld

# Call the service
micro helloworld --name=Alice

# Get your namespace
NAMESPACE=$(micro user namespace)

# Call service via the public http API
curl "https://$NAMESPACE.m3o.dev/helloworld?name=Alice"

Easy right? We see this as the common flow for most service development. Its a fast iterative loop
from generating a new template to shipping it and querying to make sure it works. There's
additional stuff in the developer experience like actually writing the service but we think that's
a separate post.

Documentation

Another thing we really learned from the past is nothing like this works without great documentation
and tutorials. So we've written a whole suite of docs for Micro available at micro.mu
and provide help for using the M3O on m3o.dev.

You can find other interesting resources at Awesome Micro.

Licensing

Micro continues to remain open source but licensed using Polyform Shield
which prevents the software for being picked up and run as a service. This is to contend with AWS and others
running open source for profit without contributing back. It's a longer conversation for another day.

Motivations

We really believe that writing software for the cloud is too hard. That there's far too much choice and
time wasted focusing on how to piece everything together. There are tradeoffs to adopting a PaaS but
ultimately our focus is developer productivity. By choosing one tool and one way we stop thinking
about the how and just get down to what we're trying to build.

M3O and Micro 3.0 look at the state of distributed systems development in the cloud native era and
try to drastically simplify that experience with a platform that bakes in the development model
so you can just get back to writing code.

Deprecating Go Micro

We will now be ending support for go-micro. Having personally
spent 6 years since inception on go-micro I feel as though its time to finally let it go. What
started as a tiny library to help write Kubernetes-as-a-Service back in 2014 turned into a widely
used open source framework for Go microservices development. Having now amassed more than 14k stars
you might wonder why we leave it behind. The truth is, while it solved a problem for many it never
became what it was intended for.

Go Micro was built on the premise that developers need a simpler way to build distributed systems.
With strongly defined abstractions and a pluggable architecture it did that well but that became
really unwieldy to manage. With an MxN matrix of complexity, Go Micro became the thing it was
trying to fight against. As we attempted to hone on this platform effort, it just became very
clear that to do that we'd need to start fresh.

Go Micro will live on as an independent library under my own personal account on GitHub but
it will no longer be supported as an official Micro project. Hopefully it finds second life in
some other ways but for now we say goodbye.

If you'd like to upgrade from Go Micro v2 to Micro v3 please see this upgrade guide.

Next Steps

You can use the Micro 3.O as a self-hosted open source solution locally, on a VPS or managed kubernetes,
whatever works for you. Our goal is to facilitate a vastly superior developer experience for building
services in the Cloud. Come join Discord or Slack
to chat more about it. And lastly head to to m3o.com if you're tired of the way you're
building software for today and want to learn of a better way that's going to make you 10x more productive.

So to revisit. To get started for free in the cloud based dev environment just run the following commands.

# Install the micro binary
curl -fsSL https://install.m3o.com/micro | /bin/bash

# Set the env to the dev environment
micro env set dev

# Signup before getting started
micro signup

# Create a new service (follow the instructions and push to Github)
micro new helloworld

# Deploy the service from github
micro run github.com/micro/services/helloworld

# Check the service status
micro status

# Query the logs
micro logs helloworld

# Call the service
micro helloworld --name=Alice

# Get your namespace
NAMESPACE=$(micro user namespace)

# Curl it via the public http API
curl "https://$NAMESPACE.m3o.dev/helloworld?name=Alice"

If you want to test things out locally first

# start the server locally
micro server

# set the environment to local
micro env set local

# login using user: admin pass: micro
micro login

And that's it! Please come chat with us in Discord or Slack and
invite friends to test out the M3O platform.

To learn more about the M3O platform see the dev docs at m3o.dev. And for the open source docs
check out micro.mu.

Written by Asim Aslam

Founder & CEO Micro

The value line in 2020: Dev vs Ops

Asim Aslam — Fri, 11 Sep 2020 12:39:01 +0000

Hat tip to my friend James Watters (@wattersjames) for teaching me about the value line.

What is the value line? The value line is how you distinguish what's core to your business vs what you can and should outsource. In today's world we outsource a lot of things as non-core concerns but somehow continue to blur the line when it comes to Dev and Ops.

I'm here to talk to you about the value line in 2020.

What's my priority?

The real question you have to start with is, what's my priority? What problem am I solving? Who's my user or customer? When you start with these questions then you begin to uncover where the focus really needs to lie. So let's begin with a thought experiment.

Alice is setting up a new business. For this example let's say its a Neobank focused on Millenials...

She's identified a real problem, as a millenial herself she understands the pains of managing money in 2020, trying to keep track of spending and what's worse, dealing with her bank over the phone or going to a branch when there's a problem. Banking just wasn't built for her. She's got a great idea, what if a bank was built just for her.

Alice sets out to solve the problem with an MVP. Her and one other engineer (Joe) figure out how much they need to build to make something like this work. They'll need a mobile app, some sort of prepaid card and a way to manage all this on the backend.

Alice knows how to build html5 apps and Joe is a pretty good full stack dev using ruby on rails plus they've seen that Stripe is a card issuer so they can potentially tap into that real quick. Alice and Joe decide to use Heroku for hosting a rails app with a mysql backend and try get something off the ground using Phonegap.

Its a convoluted example but here Alice identified the problem was one she felt herself and needed to prototype for quickly. Offloading much of the initial tech requirements to a fully managed PaaS, a card issuer with an API and html to app converter.

At every stage of your business you need to identify, what's the problem I'm solving and what tradeoffs am I making to solve that problem vs finding a perfectly scalable solution for the future. Basically, what's the value I'm creating and how much operational overhead do I need to incur.

Let's take it a step further.

Initial Traction

Alice and Joe put out the MVP and start getting traction. They're onboarding friends and posting on social media to get some of the initial users. The traction is good and they're starting to grow past a couple hundred users with line of sight to a thousand in a few weeks. They're already feeling the pains of heroku but decide to double down, phonegap performance is also poor so they're trying to find a solution.

Alice decides they should scale the dynos on heroku, pay for more mysql storage and contract a developer for the app side. If the app is slow the user experience is terrible and that's what matters. Paying for stuff is one thing, but waiting 2-3 seconds for screens to load is terrible. She pays someone part time to start hacking on something for Android since most the users are Android users.

Heroku has done its part, it seems costly compared to other solutions, but they don't need to manage anything which means more time to spend growth hacking and one less person to pay on the operations side. Phonegap also let them test out the market initially but has outlived it's time, they know now the user experience is what matters.

The Scale Out and Break Out

Things are blowing up faster than expected. Always a good thing, but now, everything's on fire. We need to figure out how to deal with the growth in the user base without having to completely rearchitect the stack. We need to break out the hotspots in the code into separate services.

Joe identifies that the API is super slow since its written in Ruby. The monolithic app has gotten them pretty far but there's alot baked in which could be separated out to be done in a more appropriate language. In this case, the API needs to be something more performant since its handling all the requests. It also just uses a ton of memory.

This is going to be non trivial on Heroku. They don't really support service oriented architecture. Everything is going to
be a public API call. Talking to the backend is going to get complicated. Joe decides he needs to bite the bullet and
make it work on Heroku, they're invested in it now and it still means they don't have to deal with Ops.

Joe's been learning some Go and has seen many of the big tech companies adopt in for backend systems. He decides to write
the API in Go and use a message queue in Heroku with Redis to publish anything to the existing monolith that needs to
be processed in the background. Its going to require a bit of change in the Rails app but worth the performance gain.

The Go API uses a 1/10th of the memory of the Ruby app, it actually only takes 1 dyno to serve all their needs. The monolithic Ruby app has now been left to deal with background job processing and some of the core functionality that was still pretty complex. The first phase of scale out and break out is successful.

Moving Beyond Heroku

It's all going great, but now we've maxed out the capacity of heroku. Breaking down into more services is useful but we're
incurring some pretty heavy costs to do it with a full blown PaaS. If we evaluate our costs in relation to our customer basethen we're actually losing money rather than making it. We have to find a better alternative. Heroku was built for
monolithic apps not microservices.

Pragmatism has gotten Alice and Joe this far. They proved out an MVP, got product/market fit and pushed the current
infrastructure as far as it would go. Now they need to get off Heroku and find a better route forward.

You're thinking I know exactly what you need to do now. A container platform on a major cloud provider. Just spin up
that managed container orchestrator, learn some yaml, maybe a bit of terraform and off you go. This is where you
need to start thinking very carefully about the value line. That's right we didn't forget about it.

The Value Line

Getting to the breaking point in terms of scale both technically and organisationally pushes many companies to bring more and more operational burden in house. It is only natural to weigh up the cost of a managed service vs our current needs and assume that self managed is the most appropriate choice for the future.

The customisation, the cost reduction on the managed service itself, all the possibilities. All without thinking about what the operational cost and maintenance burden is. I'm here to tell you, this, is a pivotal moment in your company's lifetime.

Deciding where the value line is for your company now will determine where you spend the majority of your time and money
moving forward. Self managed is a sunk cost, a pit that becomes incredibly hard to climb back out of. As much as you may believe you can transition off the in-house approach, we rarely see it happen.

It is true that when you reach the breaking point of scale you need to start deviating from what worked before. What worked for 1, won't work for 100, won't work for 1000. But it does not mean you need to take on the entire operational burden of the platform owners of today.

The Backend for Your Frontend

M3O was born with an understanding of this exact pain. At the breaking point of scale every team and organisation has to make a choice, either move to a self managed platform to do microservices or incur the costs of solutions that were not built for purpose. We felt this pain, so we decided to build a solution.

M3O is a cloud native development platform for Micro services. We focus on providing a fully managed platform for building
microservices in Go using the open source framework Micro. The goal is to enable
large scale developer productivity on the backend while letting the folks like Netlify focus on the frontend.

We think this solution works and why we coined the term, "Netlify for your frontend, Micro for the backend".

Large scale software development is hard. The cloud hasn't made it any easier. In fact we feel like over the past 5 years
if nothing else it's just gotten harder with all these tools promoted by the CNCF. We think
things have to change. With millions now expecting online services to scale from day 1, we as software developers need help.

The backend for your frontend. Let us manage the platform, help your write microservices, be super productive. Let
Netlify deal with the frontend, and talk to us through a single consolidated API. That's right, no need to wrangle
those microservices yourself into a cohesive API, we do it for you.

When you're thinking about the value line for your business. When deciding whether the future of your company is developing
software or managing the operations of it. Choose development every day of the week by letting us deal with the operations.

If you're interested to learn more check out m3o.com or join us at #m3o-platform on slack.m3o.com.

Micro v3.0.0 - A framework for cloud native development

Asim Aslam — Fri, 21 Aug 2020 10:11:26 +0000

Micro v3.0.0-beta is out! This is a huge departure from the Micro of past. We've now consolidated everything down to a simple server which you can run with the command micro server. We've also launched Micro as a Service so you don't have to. Check out https://m3o.com for that and the blog for more details.

Micro like Rails and Spring of the past is a development framework. We're focused on making cloud-native development super easy. Hopefully you'll see that in the tooling.

Feedback welcome!

https://github.com/micro/micro

Go Micro - A distributed systems development framework

Asim Aslam — Sun, 28 Jun 2020 16:33:26 +0000

Just like Java, the adoption of Go in the Enterprise will be driven a framework. Micro is that framework. Built for the next generation cloud and developers. https://github.com/micro/go-micro #microservices #golang #cloud