In traditional cloud deployments, the ability of developers to dictate and influence the overall experience and delivery of applications is really quite limited. Want to make your application faster or more secure? There’s only so much you can do. But that sphere of influence is growing – rapidly – and developers would be wise to consider the larger view of what that means for user experience, and how they build their apps.
Let’s back up a bit to understand what’s changing, and what it means for the DevOps community.
In a traditional hyperscaler deployment (AWS, Azure or GCP, for instance), the cloud instance exists within a datacenter protected behind a firewall. At the far end of the connection sits the application user. Between that user and the application is a many-hop pathway comprised of the user’s ISP, the intermediate provider, the internet backbone, the hyperscaler ISP and then, finally, the application instance inside the datacenter. Everything except that last bit is outside of the control of the application developer. Have security or performance concerns about that user experience outside the datacenter? Too bad.
This is one of the fundamental reasons that Content Delivery Networks (CDNs) were created almost 30 years ago. What a CDN does is move some of the application (typically, content) out of the datacenter and place it closer to the user. This allows the developer to influence the user experience, in this instance making delivery of content – say, the images on a website – more efficient and responsive. Or it might entail adding a security layer to prevent bad actors from stealing user data or penetrating your application from the outside.
But as applications have become more sophisticated, the staticn things that a CDN can do have become comparatively more rudimentary.
Extending Developer Control
Enter distributed edge computing. What distributed compute does is create a general-purpose workload platform that extends from the datacenter all the way out to the user’s local ISP, in the process dramatically extending what is within the application developers’ sphere of control.
By swallowing what can be termed the “middle mile” of the internet into your scope, developers are able to mitigate and manage many of the issues that might arise across any of those links.
Let’s look at an example. Most users and developers have little understanding of what goes on in that middle mile: it’s actually a complex series of buying and peering agreements between link providers. And the interests of providers may not always align with those of users and developers. For instance, the fastest/lowest latency route from user to server might not be the cheapest route, and it will be entirely up to those interim providers which route to choose. As a developer or user, you get what you get.
The idea behind distributed compute is to upend this paradigm, giving developers much greater control over the entire deployment. This argument often focuses on improvements in latency that come from moving application workloads out to the edge, i.e., closer to the user. And while that’s incredibly valuable, less thought is being given to the larger implication of claiming more responsibility for – and control over – overall application outcomes by developers.
By participating in these middle-mile decisions, the central opportunity for developers is balancing various parameters that impact application experience: availability, cost, throughput, responsiveness, security and privacy, compliance, etc. In a traditional cloud environment, this all happens outside your sphere of influence. With a CDN, you might get some limited, rudimentary opportunities.
With distributed computing, all of these things are now in your control, and can even vary based on time, location, load, etc. And best of all, you get this control on a global basis, ensuring the optimal experience whether your users are in San Francisco, Singapore or Stockholm.
One proponent of distributed compute is Netflix, which was once one of the primary users of the CDN model to ensure efficient static video content delivery for users. Over time, Netflix realized that running a CDN was not only extremely expensive, it also didn’t give them the level of control over different parameters around programmable content they were hoping for. So they built their own distributed network. In other words, they built their own Section.
New Considerations for Application Design
Extending this sphere of influence presents tremendous opportunities for developers. But it also gives them new factors to consider in designing applications. One primary consideration is application database calls. Developers have been taught a three-tier architecture for dynamic web design: the browser HTML, the server application and a database. In our traditional cloud deployment, the server application and database will sit in the same datacenter, and possibly the same rack. This proximity means that there’s little incentive to maximize efficiency in database calls… the link is short, fast and effectively free, so a chatty application is not a concern. When the round trip is under a millisecond and costs basically nothing, a thousand calls only takes a second.
But move that application out to the edge, and all these calls back to a central database suddenly become a significant consideration. First, it hampers the performance gain you were seeking by moving closer to users – now each call might take 10 milliseconds. Moreover, it can also cause cloud costs to skyrocket because you’ve got a significant amount of chatty round-trip traffic between the edge application and a central database.
Consider an ecommerce example using GraphQL. The notion of GraphQL is to expose a single API, while aggregating responses over many different backend services. So instead of a single customer order database, we now have a bunch of different microservices wrapped by a GraphQL aggregator. In our ecommerce example, when the application asks for the checkout page, GraphQL will typically send the product name, description, images, cost, quantity, etc. – multiplied across each item in the cart.
In a traditional centralized deployment, this doesn’t matter. But distribute the application and that’s a lot of traffic between the front and backend.
There are different ways around this, but here are two: first, you could write the GraphQL calls to be less chatty. For example, maybe it sends all descriptions for products in a cart in one go. If I’ve got five items in my cart, I’ve now cut that traffic by a factor of five.
Another approach is to recognize that the contents of the cart are specific to the individual user, but things like product names are shared. The developer could thus distribute GraphQL and an application cache out to the edge. By making the interaction around specific basket contents a non-cacheable call, while caching all of the shareable content (names, descriptions, etc.) in a local file, you would eliminate most of the database round trips entirely.
When Facebook developed GraphQL they experienced this exact challenge. The company’s answer was to create a GraphQL component called Data Layer, and its job is to distinguish between shareable and non-shareable items and work out how to minimize resulting interactions with backend services.
It’s important to note that this isn’t a new problem. As soon as applications reach any scale, it’s typical for their database to fall over. There have long been three solutions: buy a bigger database, which is how Oracle has made its money. Or you can optimize your database, which is why the industry of DBAs exists. Or add caching layers into the application and write more efficient code to minimize database calls.
As we move into the distributed compute age, this same need for efficient database call design is not only important for application scalability, it’s also an important consideration for application distribution.
Does this imply you need to redesign an application for distributed compute? Not at all; we can get you there today, possibly for less than you’re paying for your centralized cloud deployment. However, it does mean that over time you should think through the new opportunities and considerations offered by more complete control over application delivery.
Democratizing Distributed Deployment with Section
Companies like Netflix and Facebook have already grappled with these issues and settled on distributed compute as the best possible answer for user experience. Yet they obviously have massive teams and budgets to not only build these distributed networks, but also manage them daily.
Organizations without billion-dollar budgets can get this same ability to command, control and optimize a distributed application platform through Section – without having to bother with the underlying network. This significantly extends the sphere of influence for developers, allowing them to balance and optimize a wide variety of factors that were previously outside their control. Moreover, they can stay focused on the application, and not worry about network operations.
And that’s important, because as we all know, with great power comes great responsibility. Embracing a distributed compute paradigm is both simple – when you use Section – and opens a whole world of opportunities and considerations in future application design. As developers extend their sphere of influence all the way to the user, they’ll have to start thinking through the implications.
If you’d like to get started today on deploying your containers over this type of modern global network, get started now.
