The Merits of Application Hyper-Locality

What if every food option you ever wanted was just a few miles away?

Spending my career in Dallas, TX while working for companies in California has been fun and offered me the experience of traveling all over the world.  Business travel is anything but glamorous – if you’ve done much traveling you’ve probably shared my experience of watching the last flight out of a random city be cancelled due to weather somewhere else on the continent while you’re desperately trying to get home before a holiday weekend.   

Having said that, there are some perks.  One of these was In-N-Out Burger. For decades this franchise was a California phenomenon.  It was another place like Shake Shack, NY Pizza and White Castle. Delicious and totally unavailable in Dallas.  I enjoyed the opportunity occasionally to grab a great In-N-Out Burger in California, but that highly centralized model meant if I was sitting at my home in Texas and wanted one I was completely out of luck.  It was the opposite of fast food for me, and required a lot of planning and waiting to make it happen.

On a brighter note, over the last few years they’ve been popping up in Texas.  Now there are 3 convenient locations near me, so I can grab one any time I feel like it (or more appropriately, my kids can have one now instead of listening to me tell them it is really good… if they only had the time and opportunity to make the trip out West.)

What’s the point of this? 

Hyper-locality of resources is a huge consumer benefit, and a way to service and acquire customers in a much shorter amount of time.  When it comes to applications and backend services, there really isn’t much difference between my experience with In-N-Out Burger and my experience with companies like AWS and Google.  It’s a great service, but requires me to cross huge distances to access what I need. To put it another way, when I’m hungry in Dallas the In-N-Out in Santa Clara doesn’t do me any good, and even if I decided to go there I’m going to be starving by the time my flight lands.  If I need data in 10-25 ms, then traversing a thousand miles also doesn’t make sense.

When my apps are hungry for data and performance, a datacenter a thousand miles away isn’t satisfying.  What if instead of using 5 or 6 fixed datacenters in distant locations (that I didn’t even get to choose) I could use 5 or 6 datacenters right here in Texas?  Now my app is blazingly fast.

That’s the value of Macrometa.  Our globally distributed edge network provides 5 or 6 datacenters per state or country instead of forcing me to perform a costly data backhaul and wait for functions to cold start somewhere in a faraway cloud.  The end result is a massive improvement in application latency and user experience. 

Macrometa has been proven to eliminate over 240-425ms of backend round trip latency for apps that need dynamic content at the edge.  For developers who know where their user populations live across the globe, they also have the freedom of selecting which datacenters serve their app.  Why should I shoehorn my app into a geographically limited design, when I can run it literally anywhere?  This is hyper-locality, and it is the foundation of a concept Macrometa has pioneered called the Global Data Network (GDN).  Like a CDN for static data and global footprint, the GDN is purpose built for dynamic data and global distribution - unlike existing cloud datacenters which are built for local scale and centralization. 

The GDN provides multi-model database capabilities including Doc, Graph and Time Series, along with global pub/sub, Streams, and rich APIs.  End users never have to send data requests a thousand miles away and wait, they can make local requests and get local performance from the GDN.

Want to see what Macrometa’s GDN can do for your application?  Sign up for a free developer account by clicking the button below.