MetaCall Frequently Asked Questions.

Last update: April 6, 2019

Section A: General

What is MetaCall?

MetaCall helps you build serverless applications using a more fine-grained, scalable and NoOps oriented FunctionMesh instead of ServiceMesh and DevOps approach. MetaCall automagically converts your code into a Function Mesh and auto-scales individual hot parts or functions of your app.

MetaCall not only helps to simplify application development but also speeds up time to market. Developers can focus purely on code and business logic instead of expending expensive development cycles on DevOps.

What is MetaCall used for?

Does Function Mesh application architecture pattern benefit from MetaCall technology?

Function Mesh is a new transparent way to inter-connect serverless functions. Function Mesh enables building of complex distributed systems while efficiently scaling only the hot functional parts of the system. MetaCall is an enabling technology that helps to build the function gateway of sorts, under the covers. The only thing developers need to care about is writing a small configuration file indicating what code they want to publish and the function gateway will be automatically created by MetaCall. Scaling up and down of MetaCall instances happens in an automatic manner governed by certain configurable limits such as $$ spent for resources, response time or latencies.

Function Mesh introduces a new way of development. It is possible to develop a complete monolith service and this will be scaled depending on the hot parts of the application. The Function Mesh will grow and subdivide parts of the monolith if needed or shrink when the workload is lower. At the same time it is non-intrusive. This means you can code normal applications without needing a new complete framework or architecting the code or infrastructure. At the same time, that code can be tested and debugged locally without needing clusters like Kubernetes or complex environments with many layers of abstraction. The developer can use existing common tools, debuggers and test runners. You can build a complete distributed system in a single project without worrying about the infrastructure.

There is any technology similar to MetaCall Function Mesh?

Nowadays it is possible to implement Service Mesh in your architecture. Service Mesh is a practical way to interconnect services in your architecture. You can use tools like Istio (Service Mesh) and OpenFaaS (FaaS) on top of Kubernetes (Orchestrator) to build your architecture. Other alternatives are appearing, like OpenFaaS Flow to interconnect functions.

This solutions have drawbacks. Kubernetes itself is a really complex tool that has a difficult learning curve, and OpenFaaS and Istio introduce even more complexity and knowledge. The resulting architecture can be powerful, but really difficult to build. Apart from this, testing the system must be done in the cloud, or in a powerful local machine, to handle the whole cluster and the consumption of all this systems. In addition, Service Mesh has the drawback that it injects a proxy for each pod or service instance, duplicating the size of the processes the cluster must handle and adding an intermediate layer between the functions.

The idea MetaCall Function Mesh is to unify the development. MetaCall allows a non-intrusive way to develop this architecture, without handling all cluster and complex tools by yourself (no more yaml abuse). In addition, in the Function Mesh each function is a load balancer and proxy at the same time. It takes advantage of concurrency and it also can be scaled horizontally, creating a uniform matrix of functions interconnected. Three levels of scalability that can drastically reduce costs, improve performance, and simplify the life of the developer.

Is MetaCall a Polyglot?

MetaCall Core can be seen as a Polyglot. A multi-language interpreter that can execute different programming languages at the same time. But MetaCall itself is not a MetaVirtualMachine, in fact it only provides foreign function interface calls between programming languages. It can help integrate functionality across application components written in different languages. We are using it to build our core for the FaaS. By this way we achieve an high performance of the execution of the calls.

For a complete list of supported languages, refer to MetaCall Language Support - Backend.

For testing performance of MetaCall calls, refer to MetaCall Benchmarks.

Who is the target audience for MetaCall?

Target Audience: Developers, Solution Architects.

Key Use case:

MetaCall is useful for enterprises that need to migrate legacy or traditional non-micro-services architecture based distributed application solutions (monolithic, SoA) without refactoring the entire code base. It is also very useful for developer’s productivity and eliminates the need to setup complex K8s cluster for testing code in production.

MetaCall enables developers to test the code in local just as it would run in production – saves time and resources and brings solutions to market faster.

Which applications / workloads have the potential to benefit the most from MetaCall?

Application TypeBenefits with MetaCallComments
Application with persistent or long-lived interactions and inter-service connections for performing tasks that can scale up or down quicklyYesNeed confirmation from V
Applications with short term intermittent communication across components or micro-services where these interactions can scale up or down fastYesNeed confirmation from V
Applications that are not front-end facing but in deeper end of the stack and deal with caches, databases and intermediary servicesYesNeed confirmation from V
Applications with bi-directional data flow?
CPU-centric applications?
I/O intensive applications?
Message Broker based big data applications? (ETL, Hadoop, Spark, Flink – data warehousing apps)?
Real time messaging application for Big Data Analytics?Need confirmation from V Reference: Real time messaging for analytics

Can MetaCall be used for SOA / Legacy / Monolithic / Micro-services architecture-based applications? Or is it suited for only some of these application architectures?

MetaCall can be used for either of the above. It is not limited to an application architecture type.

Is MetaCall meant for private function calls or also for public APIs?

Yes, you can secure your APIs with MetaCall or maintain them public from the Dashboard.

Is there any benchmark data to show how MetaCall compares with alternative technologies?

Here is some of the available benchmark data for MetaCall. More benchmarking tests are underway and will be updated shortly.

MetaCall vs HTTP Servers Benchmark

Benchmark Description:

Simple function that merges two strings using the following technologies:

  1. Flask (Python HTTP server)
  2. Express (Node.js HTTP server)
  3. MetaCall with Python
  4. MetaCall with Node.js
  5. NginX (no back-end at all)



Flask614.82100.87KB1715 Timeouts
Express6433.611.39MB652 Timeouts
MetaCall (Python)11620.651.80MBNone
MetaCall (Node.js)8190.711.27MBNone


MetaCall FFI vs Runtime Call Benchmark

Benchmark Description:

Comparison of a Python C API call (hard-coded) versus a MetaCall call (ffi). No connection used, this is focused to see what is the overhead of MetaCall when executing calls between run-times. No optimization was used when compiling MetaCall (debug mode and all call optimizations disabled). One million calls was tried with two long integers for each call as an argument, and another long integer as a return value. The test has been done using only one thread, although the VM has more than one assigned to it.




Python C API544 ms42.0545MB/s1.75227M items/s
MetaCall Python Variadic Arguments Call988 ms23.1689MB/s988.54k items/s
MetaCall Python Array Arguments Call903 ms25.353MB/s1081.73k items/s


What are some of the benefits associated with adopting MetaCall?

Following is a placeholder answer, we need to refine it as per V's inputs.

Are there any challenges associated with MetaCall adoption?

How is MetaCall implemented? What is its high-level architecture?

MetaCall implementation uses a higher-level protocol (QUIC / HTTP3) to reduce RPC overheads. It uses a high-performance multi-core asynchronous I/O model.

What is MetaCall’s scaling model?

MetaCall has unique scaling model that is more granular and more compute resource-efficient than micro-services and REST based API interaction models. MetaCall can scale at 3 levels – per process, per pod and per function-mesh. Basically, it allows you to do more work with less resources and enables finer-grained resource utilization. {Any benchmark run numbers here would be useful – say with MetaCall, xyz micro-services benchmark ran 5X times faster than without MetaCall.}

Is MetaCall cross-platform?

MetaCall is a cross platform architecture – it is designed to work in multiple platforms. Current tested platforms:

Windows7, 8, 10x86, x86-64
LinuxDebian (8, 9, 10), Ubuntu (14.04, 16.04, 18.04)x86-64

What are some of the MetaCall use cases and examples?

MetaCall use cases – TBD

MetaCall examples - see Auth Function Mesh and refer to the examples folder in GitHub.

List some of the benefits of MetaCall.

How does MetaCall benefit Legacy code migration or evolution?

To bring Legacy code to cloud, or to evolve it using newer application architecture models such as micro-services, you need a service like Lambda. Instead, you can use MetaCall and without rewriting legacy code, migrate some or all its functionality to the cloud.

How does MetaCall help in progressive migration instead of refactoring and rebuilding legacy solutions?

Let us consider this example as shown in figures below:

Phase Approach
_Function A calls functions B, C and D, all implemented in PHP _

Lets say all functions are written in PHP, and ´Fn A´ calls ´Fn B´, ´C´ and ´D´.
Now you want to update your code with a brand new Node.js funcion ´Fn C'´.
With MetaCall, you can progressively transfer your calls from ´Fn C´ to ´Fn C'´ with ease, allowing you to migrate legacy code in production.
Refer to figures below that show phased migration of PHP code to Node.js:

Phase Approach1Phase Approach2Phase Approach3
Function C is implemented in Node.js and rest code is as isFunction B is migrated to Node.jsFunction B, C and D are all in Node.js now

Without MetaCall, you will need 6 months or so to move legacy code into new node.js or other models before you can verify and test. With metacall, you can do it in chunks – it helps with phased migration.

As indicated in the figure above, with MetaCall, you don’t need two teams – one to maintain legacy and another to refactor the code and make it work again using newer design and application architecture models. Helps agile and reduces TTM.

How is MetaCall different in terms of number of functions that can be invoked or called per file?

Nowadays when you do functions, you can only do one function per file. MetaCall can do N functions per file. MetaCall allowsyou to write multiple functions in the same deployment. You can keep monolithic architecture or micro-services architecture and MetaCall will slice everything. Monolith refer to pre MSA or SoA application architecture. {Need to highlight the benefit of this – how does this help developer , project, business}

How does MetaCall offer the benefit of being a common solution for gateway, SQS?

Answer to be provided by V

Are there any disadvantages of using MetaCall?

Lots of upside of MetaCall – downside – a small amount of resource is always consumed – to avoid cold starts.

How does MetaCall benefit developer productivity?

MetaCall simplifies test and debugging which is a nightmare in distributed application development. Test in local and the same code runs exactly the same way in production – across process, pod and container boundaries. During test it runs local. So no need to test in dev and again in production.

Who deploys MetaCall and scales it at runtime?

Self – automated? There is way to limit resource consumption – say by $$$ or number of replicas etc. How? {Elaborate with teh help of V}

Is MetaCall pluggable and supports different protocols?

MetaCall implementation has two interfaces – on caller side the function gateway uses simple http (for now) – in future it could be pluggable so it could use GraphQL or XML or WebSockets. At the other end, for function level communication or function gateway, it uses JSON-RPC. That could be pluggable too – it could use QUIC or gRPC or RabbitMQ – whichever works better for the user in terms of solution performance, required communication bandwidth and latency.

What kind of FaaS does MetaCall support?

Answer TBD

Are there any specific industries or applications that can benefit from MetaCall based application designs?

MetaCall is not industry or application specific solution. It is a newer, better model for bu
ilding your Function Mesh. (More details TBD by V)

How does MetaCall model impact contemporary application design and architecture?

Application architectures have evolved from traditional monolithic applications and SoA architectures to applications built using micro-services architecture. The next step in evolution in serverless and Functions – FaaS. The granularity of application ‘execution-unit’ has become finer and finer at each step of evolution. Consequently, application complexity has exploded and begun to impact application development and distributed application architectures.

Application granularity and resultant complexity is a disadvantage to distributed application development and testing process and a big drain on compute resources. Ideally, this granularity ought to be transparent to impart its benefits seamlessly to modern applications – for example – efficient and optimal consumption of underlying compute and cloud resources and services. This granularity, ideally, should not reside in the hands of the developer. Instead, it should be part of the underlying infrastructure.

With MetaCall FaaS model, you can maintain your traditional monolithic applications or contemporary micro-services-based architectures, gain the benefit of FaaS granularity without having to bother about application restructuring or developmental complexity. Your legacy code and old big architectures can be migrated to serverless and FaaS models, fully distributed by functions easily with the use of MetaCall and without needing to refactor it, or spending extra resources in development, DevOps or specialized serverless developers.

Section B: MetaCall vs. alternative solutions

How is MetaCall different from REST and RPC?

If you look closely, REST APIs comprise of CRUD (Create, Read, Update, Delete) operations using HTTP. It is sort of RPC with limited functions the CRUD. MetaCall extends this abstraction to any function that can be called remotely and not just limited to semantics of CRUD. In other words, REST, ie, CRUD over HTTP is sort of a degenerate form of RPC. In addition, these functions could be implemented in a different programming language and may be running on a different pod or container or node or server which is distributed geographically. TBD - How MetaCall is different from RPC or is it?

How is MetaCall same or different or better than pure REST and RPC?

What are the key MetaCall differentiations factors from say OpenFaaS, Zeit, Kubeless, other competing technologies?

Refer to the picture below. It shows how MetaCall differs from competition:

MetaCall Competition
MetaCall vs. Competition

What is the difference between MetaCall and AWS Lambda?

Unlike Lambda, MetaCall does not have cold starts. Refer to the figures below:

Lambda Model
Function scaling model with Lambda
MetaCall Model
Function scaling model with MetaCall

With Lambda, you can have two or more layers of LB to scale up function and obtain function mesh – see figure. With MetaCall, you can have any-to-any function mesh and it is much less expensive. In MetaCall model, each function also acts as a gateway with the help of MetaCall library. This tremendously helps in scaling and everything is integrated. No third party products are required for integrating across languages, platforms and components or routing function calls.

Is MetaCall similar to AWS Lambda, Microsoft Azure Functions and Twilio?

AWS Lambda and Microsoft Azure functions are generic serverless platforms that can be used to create FaaS solutions. Twilio is a cloud-based enterprise contact centre software platform which is specialized for communications code (SMS, Text, Voice) and allows creation of Twilio based apps for contact center, marketing and customer engagement.

MetaCall is similar to AWS Lambda and Azure functions in the sense that it also enables you to create FaaS based solutions. However, the approach is very different. Unlike AWS or Microsoft, MetaCall does not host and handle these functions via triggers. MetaCall automagically converts your code into a Function Mesh and auto-scales individual hot parts or functions of your app. Both Lambda and Azure Functions are similar in functionality as they propose to segment the application architecture in order to scale only the parts that require scaling, thus making consumption efficient with pay-per-function-use pricing model. Unlike these two, MetaCall is not cloud provider proprietary as it can work for applications that are distributed across cloud, on-premises and even hybrid applications.

How does MetaCall provide value add that is beyond what other similar services such as AWS Lambda offer?

In this question, we will try to answer the following queries related to MetaCall versus other similar technologies:

Since it first appeared in 2014, AWS Lambda function implementation has not changed much. Microsoft Azure and Google cloud implemented very similar functions. The main drawback of these technologies as compared to MetaCall are detailed below:

exports.handler = async (event) => {
    return {
        statusCode: 200,
            "Content-Type": "text/html"
        body: "Hello",

Handlers are different from events or a function (callback). This handler is similar to the ones that exist in micro-services. When you use AWS Lambda, besides handlers, you will need to use AWS API Gateway in order to provide a valid REST endpoint to the Lambda handler. This complicates the problem multi-fold. Although it offers high granularity in terms of resource consumption, it imperates the use of other AWS services to make it work. Eventually, your application or solution will have to be split into many handlers, making it harder to manage.

For example, 10 lambda functions require 10 separate deployments and 10 additional entries into the API Gateway. If you consider Database or Message Queue service implementations, then this resource and service dependency list begins to grow even further. Now imagine, if we try to inter-connect other kinds of Lambdas to build a complete application, it just gets more and more complex.

MetaCall deals with callback or a function which is very different from a handler. A function is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time. The invocation may be immediate as in a synchronous callback, or it might happen at later time as in an asynchronous callback.

MetaCall functions look like as shown below:

exports.hello_world = () => {
    return "Hello";

Instead of looking like a handler, a MetaCall function looks like a normal function, that can be unit tested locally with common development tools. There is no need of extra framework or resource deployment in order to debug it or test it. Also, you can add more functions in the same file and they will be deployed separately.

If you want to call other functions, you just have to call it like a normal function:

import { other_function } from 'lib';

    exports.hello_world = () => {
        return other_function();

This will build a function mesh for you. The function ‘other_function’ may be executed on another peer, and the network resolution, scalability, and everything will be automatically taken care of by MetaCall.

Following are a list of benefits that MetaCall usage brings in to the developers and modern application development process:

  1. Developers can build monolithic applications that will be fully distributed through MetaCall model.

  2. MetaCall brings in an integrated API Gateway along with the functions, so there is no need for updating API Gateways for each function as in the case of AWS Lambda.

  3. MetaCall allows application developers to write functions that can be tested locally, and validated globally in one shot. This is because they are normal functions and after being upload to the FaaS they will be automatically scaled. Developers do not have to first test and then verify the deployment in production.

  4. With MetaCall usage, the organization’s development lifecycle can be speeded up. The developer encounters less friction when implementing the software.

  5. MetaCall abstracts and hides the nuances and differences across multiple cloud vendors. With MetaCall, the developer will not be required to understand AWS or any other vendor specific implementation models because MetaCall integrates with repositories seamlessly.

  6. MetaCall pricing is transparent and simpler. You will not have to deal with high segmentation and obfuscated costs. You will be able to see all telemetry and consumption of your code.

Here is how MetaCall overcomes some of the drawbacks associated with AWS Lambda:

In short, instead of having to use AWS API Gateway, DynamoDB, Lambda, Elastic Load Balancer, Simple Queue Service... (among others), MetaCall solves application scaling and distribution problem at the same time, without DevOps. There is no learning curve or new framework needed for MetaCall use. Local testing capability significantly improves development time and cuts down on resource usage. The function mesh model allows for a more effective way of scaling, so we can scale horizontally, vertically and in a new third dimension introduced by the code splitting.

All this is taken care of by MetaCall, with no additional cost or new knowledge required for the developer.

Besides the above, with MetaCall, there is an extra benefit: your existing code can be migrated to MetaCall easily, because as it does not need a new framework. MetaCall can consume classical functions. Migrations to MetaCall based FaaS environment can be done automatically.

How does MetaCall simplify the complex and time-consuming application restructuring required for serverless architectures based on AWS Lambda, Microsoft Azure Functions or Google Functions?

One of core objectives of MetaCall is to simplify application migration to FaaS. Most of the problems related to ‘fitting’ an existing application into FaaS model are caused by the limitations of current FaaS designs. With the cutting-edge design of MetaCall you will be able to migrate a monolithic application into FaaS easily. Refer to previous answer for more details.