Explore insights on real-time edge computing, AI, and cloud solutions. Learn how our technology optimizes performance across industries.

Blog

I’ve been involved in some great edge-related activities over the past few years. Some of these activities have been focused on Infrastructure as a Service (IaaS) or orchestrating workloads around a distributed cloud. While IaaS and workload orchestration are important parts of an edge cloud solution, where does the platform for developers fit into all of this?

In my last blog post, I said that building applications for the edge will require a different set of tools. The edge (and the 

 in the most extreme sense) is about real-time performance and an improved experience for humans and machines. It’s this concept of service immediacy that goes beyond industries.

Even though there are many applications and technologies residing in the centralized clouds, they don’t always translate into workloads that make sense at the edge. The main reason a traditional 

 is because it doesn’t face the same barriers as distributed architectures. Even if they technically can run at the edge, that doesn’t mean that they’re optimized for the edge. 

, especially mobile network operators with 5G, are transforming their business in two main ways. The first way is technical, i.e. network transformation and evolving from the traditional physical network functions approach to network deployment to a virtualized approach (VNFs and now CNFs). The second way is monetization, i.e. business transformation and how they monetize that network asset and capabilities to attain a return on their investment.

Telcos are essentially becoming edge technology services with the goal being to offer their unique value proposition in the form of network-centric edge cloud services.

Telcos that focus their edge cloud services on 

 and service immediacy are going to be more successful and fit into the technical and business requirements of modern distributed systems.

What application developers need for the edge

Rather than simply hosting application workloads created by others to run at the edge, 5G mobile network operators can become enablers of solutions. But first, they’ll need to address the needs of enterprise application developers at the edge. Telco edge cloud providers need to consider three main concerns: Performance, developer velocity, and costs. 

, low latency real-time insight, and actuation. Developer velocity isn’t just about the speed of development or deployment, it’s about the rate of developer adoption as well. The costs also have to be worth the investment – does the platform’s cost result in tangible performance and increased developer velocity?


To meet the demands of enterprise applications and the developers that create them, network operators need to support a polyglot approach to enterprise architecture primitives. Imagine a platform that embraces an edge native approach to application development. Developers can leverage 

 computing to maximize the dynamic, mobile (migratory) nature of deployed software services at the network edge. 

How Macrometa overcomes obstacles of the edge

The edge is born from the principle that data has gravity. Basically, the existence and mass the data has, in itself, attracts processes and workloads to it. Like any large body that has gravity, other objects are attracted to it and sit (and therefore operate) in its orbit.

At Macrometa, we have built an edge cloud platform that embraces the principle that data has gravity. For example, if insights need to be generated in real-time, our platform enables a distributed approach to application design that brings workloads, 

, and application logic to where the data actually is. The mechanisms required to intercept, capture, process, and manipulate data have everything they need.

Telcos and mobile network operators that work with Macromenta are able to deploy an application that is natively low latency, built for high-velocity data ingestion, manipulation, and actuation. Data replication, query, processing, and insights can be performed and generated across the operator’s footprint with near-instantaneous synchronization, or even globally (off-net) within ms.

 is built around persistent streams and real-time stream processing via our Stream Worker technology. Our Stream Workers allow developers and Telco enterprise customers to define sources and sinks, tables, processors, and javascript functions. Stream Workers are extremely powerful in real-time event execution in an 

 / ELT architecture. Stream workers give the developer the power to collect, shape, analyze and act on application in-flight data and data at rest.

The platform also provides a stateful container runtime that is distributed across a network topology with both compute and FaaS capability.

Hopefully I’ve managed to explain what we have in our platform, its features, and how our Telco customers are using it to offer real-time edge cloud services. It’s pretty exciting stuff.

We (Macrometa) have telco customers today who are right in the middle of this transformation and using the Macrometa platform to build their edge cloud services while addressing complex use cases like connected vehicles, 

 you can find tons of demos and tutorials, from simple “hello-world” type applications to more complex ones like 

. We also have all the documentation you need to get started to familiarize yourself with our platform and build your own global edge applications today.

How To Build Applications The Edge Native Way

Today, we have many hyper-scale, distributed data platforms that can handle big data workloads with elasticity and simplicity. This simplicity comes from the fact these workloads run within a single data center in a single, centralized region. As long as those resources needed to scale are available within that same data center, everything scales as it should. But we’re entering a new age of data decentralization enabled by powerful next-gen devices, 5G networks, advances in 

, AI/ML, and the current geopolitical trends for regulating sensitive data.

This new world requires a new cloud –one that is distributed rather than centralized. The problem is that cloud native approaches that worked well in our centralized architectures 

 in this new paradigm of dispersion and decentralization. 

Edge cloud needs an edge native approach that is designed to meet the challenges of the edge, built for distributed architectures, and optimized for decentralization.‍

The centralized approach doesn’t work because it doesn’t face the same barriers as distributed architectures. Unlike single region architectures, decentralized architectures need to deal with these five following challenges:

Large network latencies with 100s of milliseconds

For any data platform architecture to be truly edge native, it has to effectively address these five primary challenges of edge.

Cloud native and the network latency and unreliability problem

Current cloud native data platforms are primarily 

 systems. This means that they rely heavily on data center class networks (i.e., very low 

 and high reliability) for their throughput, performance, and availability. The primary reason is the need for 

Consensus is the task of getting all nodes in a group to agree on some specific values based on each node’s votes. For example, in election algorithms, the goal of consensus is to pick a leader. With distributed transactions, the goal of consensus is to get an agreement on whether to commit or not. In short, any algorithm that relies on multiple processes or nodes maintaining a common state relies on consensus. 

While consensus algorithms solve many distributed systems problems, these algorithms are 

. Coordination creates three primary penalties for distributed systems:

Increased Latency (due to stalled execution)

 seconds to execute, the maximum throughput of the concurrent transactions operating on the same data items is 

. If a data platform is within a single availability zone or a single data center, this is not usually a problem. The network delays are slight (i.e., hundreds of microseconds or low single-digit milliseconds), permitting from a few 100s to a few 1000s of concurrent transactions per second.

However, if the data platform is spread across multiple regions/PoPs, the penalties will dramatically increase. The read & write delays are lower bound by the network latencies, which run into 100s of milliseconds. This leads to a rise in request latencies and a reduction in throughput. 

For example, if you have an eight-region cluster, the 

 across those eight regions, bringing down the system’s throughput to 2-3 concurrent transactions per second. This is assuming the network is reliable. If the network is not reliable, then the system degrades to unavailability. Neither of these are practical solutions.

Everyone talks about the data tsunami that is on the horizon (or already here, depending on who we talk to). Then the focus switches to how to optimize the read path for costs & performance? how to analyze data effectively? Or how to serve the ml models? These are certainly valid issues.

A big omission is that first we need to write the data, and that’s at least 50% of the data tsunami problem. This is an area where current distributed data platforms underperform. 

For example, let’s take a sample eCommerce store. This reference architecture from AWS Blueprints shows a fairly standard model for an eCommerce store. The blue text is my annotations.

aws-samples/aws-bookstore-demo-app (github.com)

Like most enterprise apps, the store requires:

A DynamoDB /document store for its users, items, and order information.

A search store to provide search capability for users.

A graph store to record its user activity and items for recommendations.

An API gateway and lambdas to wire all these together.

While this architecture will technically work, it still presents a few problems::

You have to store the same data in multiple formats in multiple stores. In essence, your writes are amplified as they fan out across various stores.

You give up on consistency & transaction semantics across these multiple stores. You will also have to spend a lot of time and money to address the pain from these problems.

Your developers will spend 80% of their time learning & writing extra glue code to integrate these stores, while spending only 20% on business logic that actually moves the needle.

In short, you have expensive writes, loss of developer velocity, and solution complexity.

It’s estimated that IoT devices will generate 

 by 2025. In the current cloud native system, all this data needs to be transferred to centralized cloud locations for processing. That increases not only the data transmission costs but the data write costs as well. In addition to being costly, the latencies involved with this approach make it difficult to take advantage of data in real-time, let alone react in a timely manner for recommenders, predictions, alerts, or something else.

One option is to optimize the data for transfer by compressing it through some intelligent means to reduce the data transfer costs. But that ends up just trading one problem for another with the increase in processing costs. The rest of the problems still remain.

In reality, over 90% of the data is noise, depending on the use case. A better approach is to just process data at the location near the data source and only transfer the signals. There are some solutions that provide this capability at the edge, but the problem is that they are mostly stateless solutions.

 solutions require and benefit tremendously from the state (aka context) around the data event that is being processed. But maintaining state at the edge requires a data platform that can run in 10s and 100s of locations around the world. In essence, one needs an edge native data platform to provide state.

Cloud native and complex service orchestration

Think of the last time you worked on a distributed system paired with another region for active-active or active-passive replication. This could be a hybrid cloud or a multicloud solution. I don’t need to tell the complexities inherent in this, the multidimensional expertise required from the engineers, and the efforts involved – those are all pain points we know too well. Not to mention the deployments, upgrades, and monitoring. You have to account for so many factors as part of the development of your service using these cloud models. Now multiply these factors by 10x or 20x to account for the 10s, if not 100s, of PoPs required for the edge.

 (CDN) have perfected the art of providing a Single System Image (SSI) addressing these challenges for website developers. We need similar SSI capabilities for backend developers working with data and streaming platforms dealing with dynamic data. 

Macrometa GDN provides a Single System Image (SSI) of the platform to the developer while running in 10s and 100s of PoPs just like CDNs provide an SSI of their network for a website developer.

To summarize, we don’t use a hammer to chop wood! Hammers are a perfectly useful tool, but if we need to solve the challenges at the edge, we need an edge native approach.

 and I discussed edge native in late 2015, it was a far-fetched idea with its fair share of skeptics. We benefited from those who provided constructive feedback and ignored those who were bound to the status quo. It is nice to see the industry trending towards the edge these last few years. The five challenges of the edge mentioned in this post guide all the fundamental principles for stateful edge computing. 

Building technically complex data platforms like Macrometa isn’t easy, but I believe there will be more data platform providers in the future who will address these principles natively in their architecture. Similarly, consumers will want these capabilities from their data platform providers as they learn the hard way that the cloud of today is ill-equipped for the edge of tomorrow.

, including our Globally Distributed Multi-Model Database and Real-Time Stream Processing. If you want to see Macrometa in action, 

How to build applications the edge native way

The Great Shift - Edge computing & faster data processing

Cloud Native Is Not Edge Native

“No one can whistle a symphony. It takes a whole orchestra to play it." – Halford E Luccock

 for the first time in July of last year (2020) at the 

 near the Giants stadium in San Francisco. It was during the peak of the pandemic lockdown, and the streets of this great city were empty of the usual excitement and energy that fills it. 

But Chris, Blake, and Zain’s energy and enthusiasm more than made up for the unusual stillness of that day. We spent three or more hours together sitting outside the cafe while I listened intently to Chris and Blake share the many life lessons of being an early-stage investor. Lessons of great disappointments from missed opportunities, poor execution, and bad luck, along with lessons of courage, accomplishment, and winning against great adversity and all odds. As I sat there enthralled, it hit me like an eighteen-wheeler truck - Chris, Zain, and 

 embodied everything that I believed were the most important characteristics of a great investor. They were kind, humble, tenacious, and utterly optimistic people who shared my belief that building a great business with amazing people was one of the most sacred, noble, and rewarding endeavors one could attempt. 

they invested a small check into Macrometa

 in the fall of 2020. And with that, we got the opportunity to start collaborating closely with Chris, Zain, and the Pelion team. They taught me many things in a very short amount of time - like how to race cars and make them drift and how to think big, not just with my head but with my heart. 
Today, we are incredibly proud and excited to share that Macrometa has just raised a $20M Series A round led by Chris, Zain, and the Pelion team with full support and participation from our amazing investors 

. This brings our total raised to ~$30M, with $28.5M of that raised during the pandemic in just under 12 months. This Series A funding comes on the back of skyrocketing interest and adoption of our serverless edge data platform by enterprise customers, triple-digit ARR growth, and game-changing 

Macrometa’s mission is to make every developer a hero by making it trivial to build stateful, real-time, low latency, globally distributed, edge, and multi-cloud apps that run simultaneously across 100s of edge or cloud regions. To do this, we are investing the proceeds from this round into engineering the most powerful, globally-distributed, stateful serverless edge platform, on a deeply capillated edge computing network connecting 175 global POPs, all wrapped together in a developer experience second to none.

This is a big and bold mission. It's not for the faint of heart, and it's the stuff that takes courage, tenacity, and audacious levels of leadership, optimism, and hope. If our mission makes your heartbeat a little faster with excitement, or if it speaks directly to your aspirations, 

, and let's get to know each other. We have incredibly smart, humble, and fun people like my co-founder and CTO 

, Developer Platform and Developer Relations leader 

many more to share this incredible adventure

 with (Oh and we have pets - lots and lots of 4 legged pets of all kinds). This mission to build the 4th cloud titan needs courageous, kind and brilliant people like you to join us. So come - Let's build Macrometa together. 

Announcing Macrometa’s $20M Series A round led by Pelion

When I updated that I joined Macrometa on my profile on LinkedIn, a couple of friends in my network messaged me. The first simply said “v.cool!”, which I loved (and couldn't agree more), and another said, “Congrats on the new role! This team gets it”.

This team does get it... and that's why I'm so excited and grateful to be part of Macrometa’s journey and be part of Chetan and Durga’s team.

I’ve been lucky enough to be in the Edge Cloud space now for almost four years and it’s been a great journey that I am truly enjoying, and very grateful for. Through all the pondering, debating, trying, and testing, I've come to the conclusion that to really make a difference at the edge, we need to enable developers to build at the edge and not just re-host (lift-and-shift) applications.

To be able to build at, and for the Edge, we need the right tools. I believe it’s a mistake to think that the tools that are available in traditional centralized public Clouds are the right tools to be used for the Edge; there is a formula for building platform services that developers can truly use, and that is what Macrometa has created with its GDN (Global Data Network).

For me the Edge has always been about improving the quality of experience for the end-user, whether they are human or machine, and much of what we consider to be quality of experience comes down to service immediacy; i.e. how fast does my application respond, how quickly can insight be generating, and an actuation triggered that ultimately translates into something of value.

Macrometa enables enterprises to build real-time, latency-sensitive applications or services that are located <50ms to 90% of the world's connected devices. This opens up a very broad set of use cases, and even makes real-time, data-intensive applications a viable proposal that would have ordinarily been impossible to achieve with a centralized Cloud approach both operationally and/or commercially!

Macrometa provides an Edge Cloud platform in the form of Serverless compute with built-in data services that can replicate data within milliseconds across 100s of locations globally, pub-sub, streams all wrapped in a developer-friendly and familiar environment.

Yes, this is v.cool, yes, this team gets it, and yes you can probably tell I’m really excited and proud to be part of the Macrometa journey!

Alan Evans On Why He Joined Macrometa

At Macrometa, we believe that the world deserves a better cloud - free from the constraints of geography, latency, and developer complexity. An edge cloud that is instant, everywhere, and simple to build and run apps in a way that that cloud was never meant to or ever can.

To this end, We are thrilled to announce our partnership with Cloudflare today.

Cloudflare is a bold and visionary company that has paved the path to making the edge a mainstream platform by empowering developers to easily and quickly build scalable, secure apps that run across a worldwide footprint of servers and data centers. Macrometa and Cloudflare share a common and powerful belief that the future of apps and web services is distributed, stateful, and global. By joining forces, we make building low latency, stateful data-driven apps at the edge a reality for developers everywhere.

Macrometa and Cloudflare enable building apps that typically require massive investments with high technical risk and complexity to be built intuitively and quickly. Imagine building a SaaS web app, 

, gaming, or cybersecurity application that runs distributed in 100s of global regions in hours - that’s the power of Macrometa and Cloudflare together.

Compose your applications’ business logic and front-end code as Cloudflare Workers and use our SDKs and REST APIs to connect, store, query, mutate, search, stream, and process data on Macrometa's 

 instantly anywhere in the world. Build and run your app’s backend across “region earth” instead of a single region like “US West 1” or “US East 3” - all in a way that enables developers to build full-stack geo-distributed applications completely serverless.

Building stateful applications, APIs, and web services that outperform the cloud by 50X -100X has never been this easy, and we can't wait to see what you build.

https://blog.cloudflare.com/partnership-announcement-db/

Macrometa partners with Cloudflare to extend the Edge

The last 15 years have seen several successive waves of big data platforms and companies offering new database and analytics capabilities. Leveraging the public cloud, these large scale distributed data systems work well in centralized, single region or single data center topologies and are geared for 

Companies such as Cloudera, Snowflake, and more recently Databricks are examples of successful companies that have innovated with novel “read architectures” that reduce the structural cost of reading immutable data and built new big data orientated analytics apps and capabilities by exploiting their lower costs of reads.

We are now faced with new challenges with workloads and use cases that are 

. The write path is far more challenging than the read path. This is because the read path is built on immutable or non-changing data. The write path necessarily involves mutable data with varying rates of change and growth in the data sets of use cases.

Additionally, the write path today has also evolved from the client/server’s “request – response”based interaction model to new, streaming data architectures where streams of “events” need to be processed as they are created or generated by various sources.

A similar cascade of innovations is needed on the write path to solve the structural costs of data writes as big data platforms have done to change the structural costs of data reads.

We summarize the challenges of the write path in modern cloud data platforms as follows:

Expensive Writes - (Ex: DynamoDB - writes are 16x to 64x more expensive than reads).

Centralized architectures - Introduces large access latencies for globally distributed users and as well as large transit latencies and network transfer costs for data to be shipped to the cloud.

Require network communication intensive and coordinated approaches to consistency such as using state machine replication or consensus and therefore are only feasible within a single cloud region (due to the need for ultra-low latency and reliable data center class networks).

Require synchronous replication to ensure all nodes in a distributed system make forward progress on writes with transaction semantics where either all related writes are accepted Macrometa 2or all are rejected. In combination with point #3 above, replication and coordination end up being the Achilles heel for write-intensive distributed systems.

Today’s enterprise apps and cloud workloads are no longer “read intensive”, but are a combination of:

 (ex: IoT, Monitoring, ClickStreams, Fraud Detection etc) or

This is because modern cloud native architectures don’t use just one database behind them for persistence but instead use several, specialized databases and data stores for different types of semi structured and unstructured data. This “polyglot persistence” pattern used by modern apps further exacerbates the write path and write intensity problem as now a single application level write generates a successive cascade of amplified writes to multiple data stores underneath the application.

 pattern where an application level write results in several cascading updates to multiple independent databases or data stores causes very high levels of write amplification and resulting costs.

Attempts to solve these problems using conventional techniques of “write back” and “write through” caching no longer work for such polyglot backend patterns – one simply cannot buffer writes in a single buffer and fan out to multiple databases and data stores underneath without completely giving up on consistency and transaction semantics.

For use cases where multi-region data, or edge based data processing are needed, the problems are further exacerbated by the physical link latency, topology and reliability of the wide area network. These use cases have to contend with well known problems such as:

Given the challenges just described, current centralized distributed data systems and the technologies that underpin them cannot be generalized well to fit edge & multi-cloud workloads.

Macrometa has been now for several years, focused on solving the challenges of the write path.We don’t just want to solve the cost and consistency problem of the write path but also enable globally distributed stateful apps & web services that can run in 10s and 100s of regions world wide concurrently with less than 50 ms end to end latency for data access by 95% of the world’s population.

This is a non trivial computer science problem because:

It requires our platform to run in wide-area deployments where nodes forming the database may be separated by more than 100ms of latency and unreliability in the network connections.

It requires our platform to run across 10s to 100s of data centers and yet present a single system image (SSI).

It requires us to have a significantly better write cost structure and cost-performance ratio than current cloud data systems built on centralized architectures.

Macrometa accomplishes this with a novel architecture that combines geo-distributed, coordination free write and replication techniques and a multi-modal data platform with tunable consistency levels to solve these problems in an edge-native way.

Solving The Trillion Dollar Data Problem In Edge Computing

Today I’m incredibly pleased to share that 

 has invested in Macrometa. Many of you already know of Pelion as a hugely successful, storied venture firm based out of Salt Lake City, UT. Pelion has previously backed Internet blockbusters like 

 and Riverbed from startups to public companies through frenzied hyper-growth and market making. Macrometa is delighted to team up with 

 on our mission to bring distributed cloud infrastructure and edge computing to developers everywhere.

I’m a big fan of humble investors who walk softly but carry a big stick (the stick here refers to an 

 on the startups they back). Pelion exemplifies this approach. From the many meetings and discussions with Blake, Chris, Ben and Zain– it was clear to me that Pelion was a team we wanted to work with. Their powerful curiosity for the end state of edge computing that Macrometa enables, coupled with first-hand experience of having built several category defining businesses like 

 (acquired by Okta), Riverbed and others, lead to a collaboration and new investment in Macrometa, despite us having closed our seed round of 

Incredibly smart, accomplished people who invest early to help founders build category defining companies.

Nowhere is this more apparent than in Pelion’s backing of CloudFlare as one of its earliest investors. Pelion helped finance Cloudflare’s monumental rise into a behemoth in security, CDN and now edge computing. They gave the founders of Cloudflare great latitude to pursue their vision and helped with their advice, network and experience where needed to create results that are self-evident. CloudFlare is today an incredible business with a 50% CAGR on revenues and a 

Passionate about solving complex infrastructural issues buried deep inside the Internet

Pelion backs teams that are going after hard problems. Take Riverbed for example – Riverbed arrived on the scene when WAN latencies made Remote Office / Branch Office connectivity an expensive and unusable nightmare. Riverbed transformed the enterprise’s ability to use the Internet to connect people, applications and data with its transformative WAN optimization technology. Riverbed’s approach was radical for its time and few investors understood what the implications were. Pelion saw that Riverbed’s proposition was transformative and powerful, and helped Riverbed quickly grow into a networking infrastructure powerhouse.

Humble, hardworking and heartful investors

Having worked on multiple startups before, both my co-founder and I decided early in the Macrometa journey that we only wanted to work with people who shared our values for humility, hard work and heartful engagement. We have been incredibly fortunate to get the best investors involved with our business starting with 

 leading our pre-seed in 2017, and most recently 

 leading our oversubscribed Seed round (with support from Partech, Fusion Fund, Sway and others in our investor syndicate). We now look forward to Pelion joining our journey and mission to open up the edge cloud to powerful new applications built by passionate developers everywhere in the world.

If you're interested in a role at Macrometa, we have 

 in our R&D, Site Reliability & Engineering (SRE), Sales (inside and outside).

Announcing Pelion’s Investment In Macrometa

Rob Fry is CTO of Armorblox and board member of Macrometa. Rob has a storied career in Silicon Valley having been at several noteworthy startups like Jask (acquired by Sumo Logic) and prior to that one of the architects of Netflix at a critical time in its life as it transitioned from a DVD by mail business to the global streaming giant that we know of today. Every time you netflix and chill - you can thank Rob for the experience.

While all the research says companies are accelerating migration to public cloud (

), what’s lost in the noise is how companies are inefficient at building infrastructure once they get there. 

 has validated the customer’s pain. The study reveals the frustrating customer story as more and more loads are moved into public cloud. Highlighted in the study is how customers need help to deal with cost issues, optimization needs for cost savings, and expertise and technology to deal with complexity. To add to customer angst, as companies desire to move more loads into public cloud, they additionally want to do so with more than one cloud service provider to commoditize and diversify the services but increases the challenges mentioned above.

One of the paralyzing realities in customers' daily lives is an inability to hire people with cloud expertise to help solve these issues. Even though public cloud has been around for over a decade, this extended period of time has not translated to providing a sufficient supply of experienced people to meet the business need for proper public cloud adoption.

In the years since I left Netflix, I’ve seen the customer struggles first hand and experienced them myself at companies I’ve led. Working at Netflix was an opportunity that showed me how to leverage public cloud 

Netflix adopting public cloud was an evolutionary step as a primary business model for a company. Similarly, today’s evolution in public cloud technology can help be a driving force for companies to be successful in building cloud-based architectures. Typically taking the form of a Platform-as-a-Service (Paas), these solutions abstract away complexity to provide optimized technical architectures that span globally across different public cloud providers while reducing costs and filling in the void of missing technical expertise.

Earlier this year, I was introduced to one such team & technology. At first glance, their technology seemed to be an improvement and more easily implementable approach to what is commonly referred to as Edge Computing. As I spent time with the co-founders and the technology, I realized the noticeable separation of their offering compared to the competition. If you’ve spent any time studying the Edge Computing space, you’ll quickly come to realize this term has different definitions depending on the use case and customer. However, this company had technology that could solve all of them with an impressive and broad set of exceptional customers to validate them.

With the excitement of realizing the potential for both the team and the technology, I’m delighted today to be part of the public announcement of the DNX Ventures lead in the seed+ round investment in Macrometa for the next stage of growth for this successful edge computing platform.

It has been such a pleasure working with the Macrometa team. Co-founders Chetan Venkatesh (CEO) and Durga Gokina (CTO) are the right mixes of intelligence, creative passion, understanding of strengths and weaknesses in the space, with high-achieving results. Watching their impressive traction and the vision of what this company could accomplish in the space will be fun to watch.

Now is the right time for the Macrometa team and their technology. Public cloud growth is increasing. Businesses desire to handle the challenges in front of them better and require optimization and reduction of costs. All will drive adoption in the edge computing space. The expertise Macrometa brings to supplement existing engineering initiatives along with Macrometa’s technologies capability of simplifying architectures for faster innovation at a lower cost will be a few of their keys to success.

And in the future, I think we will look back at the year 2020 as the beginning of a transformative change in what it means to build and efficiently leverage the public cloud.

I am excited to join this team as a board member and enjoy contributing to Macrometa’s journey to make edge computing ubiquitous.

Rob Fry On Why You're Doing Cloud Wrong

 is the former CEO of Identity Authentication Management Unicorn and disruptor 

 - an edge centric AI tools company acquired by Apple. Jon serves as independent director on 

I like products that make its users heroes. 

 does just that, and it makes me proud to be a new BoD member there.

Macrometa’s GDN(Global Database Network) is, among other things, a CDN (Content Delivery Network) that can deliver consistent live data globally with milliseconds latency anywhere in the world out of a Read-Write distributed database. So a write in Vietnam can be read by an app in California in a few mS. And there’s more: Durga Gokina and his engineering team realized that a table can be a stream, and made it so that it enables high-performance and inexpensive global stream processing in order to ingest, process and augment or transform data at the edge in real time. The app in California gets updated in mS with a push if it wants with no read required. In fact, with the GDN, queries can now become serverless API calls deployed globally.

The GDN at its most basic is a really great CDN attached to a globally-consistent distributed database, but when fully exploited is a super-fast, fully-featured, compute-at-the-edge backend.

And it gets better: Macrometa’s GDN is an order of magnitude cheaper than today’s distributed databases like DynamoDB or MongoDB, and it’s a drop-in cost-saving cache for them. Who doesn’t like cutting their AWS costs by 80%+ with a few hours of effort?

Enterprise SaaS startups win when they have a service that delivers more capabilities that can be deployed in an MVP in hours, and is significantly cheaper to run than incumbents, coupled with a high-performance team to build the product and the company. For me, all of these boxes were checked at Macrometa, so it was gratifying to have the opportunity to join its BoD. Macrometa’s GDN marks an inflection point for how scalable apps will be developed and I am proud to be part of the journey.

Jon Gelsey on "Why I Joined Macrometa's Board of Directors"

Macrometa is the hyper distributed cloud platform for enterprises building global applications at the Edge. 

PhotonIQ

Global Data Network

Learning Hub

Case Studies

Developer Hub

Demos

Support

About

Partners

Press

Careers

Contact Us

Terms of Service

Privacy Policy

Trust Center

Macrometa vs. Edgio

Are you an Edgio customer facing uncertainty? Discover how Macrometa ensures continuity and delivers high-performance solutions for your business.

Archive