Despite the hype around microservices, there are high chances you have not adopted it. We know the benefits. But the barriers to getting started are just to high.

The fact is, architecting applications for scale is difficult. You have to choose the right database, the right frameworks and in many cases, the right programming language.

Things don’t end there. We need to zero in on a cloud vendor too right? Choose the right deployment strategy. That’s a lot of hard work.

The Monolith Design (A lone warrior)

Traditionally we have been designing monoliths. Here we have one huge codebase. Everything is built using the same language and the same framework.

The pros :

This makes it super easy to build the application. Everything is just a function call away. The framework does the heavy lifting of building the APIs. We are used to the ORMs available. Development is well under our control.

Everything is awesome till we have to scale.

The cons :

Scaling a monolith is difficult. The cost we pay for ease of development is agility. Pushing out updates and new features in a monolith design is where things break. A minor bug can bring the entire app down.

Microservices (The chaotic team)

Enter microservices.

Microservices solve the agility at scale problem by breaking down the big fat monolith into smaller modular counterparts. In essence, every feature or functionality of you app now runs as a completely different microservice. Each microservice is a server on its own running in a separate process.

The pros :

The most obvious benefit of microservices is that the deployment cycle of each microservice is now independent.

This means you can have a separate delivery platform set up for every microservice customized to its needs.

Another benefit is that you need not stick to a single language or framework anymore. This opens up doors to built microservices in the language best suited for the job. You can use python for data science stuff and something like golang or elixir for io bound workloads.

The cons :

How do you make sure all microservices are working harmoniously together? Can they even find each other? What about breaking API changes?

Thinking in terms of microservices is difficult. Deciding how to break up your app is not an easy task either. It takes some experience to get this right. And if you think you have mastered this art, try debugging your microservices. It’s a nightmare.

The Work Around.

A part of the debugging problem can be solved by using a powerful monitoring system. Something like Istio.io or Linkerd can help you here. They also let you set up a control plane to implement tight access controls in a zero trust environment.

These service meshes give you great control and observability for microservices. You can now zero down on precisely those links which are failing. Other useful metrics like latency and number of requests are trackable as well.

But these service meshes need some deployment tool like kubernetes to work on.

So how many things do we need to work with now? A little less than a million.

Wait! I’m a bit lost now

So am I. Let’s go back to where we started from, agility at scale.

All we wanted was to break down our monolith into smaller pieces. That was it. Microservices just seem to make that dream a reality.

What if we had a way to get the agility of microservices without having to manage the chaos that comes with it? Can we make things easier?

To make it easy to follow, I’ll list out the features we need.

  • An easier way to break down the monolith. Maybe start with one and break it down when needed.
  • Everything should be just a function call away. Nobody wants to waste time on getting the networking right.
  • Ability to deploy each piece independently. Potentially have them in different languages binded together with a consistent API.

##The Functions Mesh (Organized chaos)

What if we could break down each operation in our services into functions? No, I’m not talking about a function as a service (like AWS Lambda). We are still talking microservices.

No matter which language or framework you use, each endpoint is handled by a function right? So why not expose these functionalities directly as functions!?

What does all of this mean?

You don’t need to trigger HTTP requests to consume the APIs exposed on your microservices. All you need to do is call a function on the microservice directly from your code. All networking like load balancing and service discovery is completely taken care of.

Since you are exposing functionality via exposing functions, you can start with a monolith and eventually break things down easily. Its as easy as moving the functions from one directory to another.

Sounds incredible right?

This is what we call a functions mesh. All of your functionality, local or remote, is just a function call away now.

Space Cloud

We have baked the functions mesh into the core of Space Cloud. You can register and invoke functions and services using the Space Api library available in python, java, javascript and golang.

Since Space Cloud is vendor agnostic, you can set up a functions mesh on any kind of an environment. You could run it in Kubernetes, a VM or even bare metal.

Space Cloud also offers a super powerful security module to fine tune access controls to these functions.

Since all networking is managed by Space Cloud, you can even have your frontend invoke these functions in the same way as your backend services. Couple it with a realtime data access layer, and you have a unified API to handle most of the use cases out there.

If you thought this was all, think again. Space Cloud is completely open source! You can start building your very own functions mesh right away!

Wrapping Up

Microservices aren’t going away anytime soon. There are many use cases where a FaaS setup just cannot tackle the same problem as microservices.

This has left a huge scope of improvement. Specially around the way microservices communicate. We believe that the experience of building a microservices based architecture should be no different than going the traditional way.

The functions mesh does seem to solve many operational problems around microservices. It combines the ease of a FaaS along with the flexibility and environment control of a microservice.

Do try Space Cloud out. I would love to know how you are using the function mesh.

If you like what we are doing, do star us on GitHub. We would love to get you onboard as well! You can start by posting about a bug or suggest improvements. Also, you can join our discord server to get in touch with us directly. Welcome to the new way of writing microservices!