This is part two of a series of three articles on building and delivering amazing apps at the edge. To read part one, click here.
There are millions of apps available today, and it’s incredibly easy for any user to download and install any of them with just a few taps on a screen or click of a mouse. If you want to build and deliver an app that will amaze users, you need to be able to differentiate from the rest of the pack.
Over the past 14 years, I’ve been working closely with the top companies delivering the most popular apps, helping them optimize their apps for speed and scale so users get a great experience. In this three-part series, we’ll explore the fundamental steps you must take to build and deliver your own amazing app at scale that will keep users coming back for more.
We’ll break these steps down into three key areas:
- Front end: Covers the parts of the app that end users interact with.
- Back end: Looks at the required origin infrastructure to support the app, including databases, application, web servers and more.
- Middle-mile: Explores the internet, where all the information needs to traverse back and forth between the front end and back end.
In this article, we are going to explore five things you can do on the back end.
In a nutshell, distributed architecture means having origin (back end) infrastructure that is geographically dispersed to maximize availability and performance.
There are three main types of back end configurations:
- On-premises: This is where the hardware and software are owned and managed by your organization. This type of back-end architecture is often more expensive and resource-intensive to maintain but offers a higher degree of security and flexibility because you have full control of the hardware and software.
- Cloud-hosted: This is where the hardware and software are hosted on a third-party cloud provider. This type of architecture runs on dedicated or multi-tenant servers, and is usually more cost-effective to create and manage because some of the cloud providers include efficient infrastructure configuration/orchestration tools.
- Hybrid: This is where your architecture is a mix of on-premises and cloud-hosted. This is the most flexible and common solution, since most companies that traditionally have relied upon all on-premises architecture are slowly migrating some of their back end to the cloud. For this type of solution, it’s best to use open source, multi-cloud tool solutions.
The goal for your configuration should be having a back-end system that is geographically dispersed enough (with most locations close to your users) to ensure low network latency, while at the same time avoiding a single-point-of-failure to ensure the service runs, despite any localized outage.
Regardless of your configuration, the general idea of distributed architecture remains the same: Using data centers where the load is distributed via a global load balancer, and where critical information is replicated across the data centers via fast, fiber-optic private links.
Here are some concepts you can research that will help you to choose the most optimal, distributed architecture for your needs: virtual machines, containers, microservices, data replication, stateless apps, serverless, distributed processing, etc. DevOps.com is an excellent resource to learn more about them.
Generally speaking, you can simplify your origin infrastructure and maximize end-user performance by putting a content delivery network (CDN) between your end users and your back end. A CDN is a super-distributed network of reverse proxies that allows you to put your content very close to end users, minimizing network latency to achieve rapid app interactions, especially when the CDN caches your content on its edge servers.
You can optimize costs and performance by choosing an architecture that auto-scales (up and down) depending on current traffic demands. To implement this effectively, you need to monitor global traffic and set triggers that launch infrastructure on-demand so it is ready when needed. Most of the largest cloud services companies support auto-scaling services, and some of them even allow you to tune your settings to favor either costs or performance. One of the easiest ways to implement effective auto-scaling is with CDNs, which can automatically scale traffic with minimal effort just by configuring a set of rules that define what content should be handled completely by the CDN (either dynamically generated at the edge or cached) and what content should be pulled from your origin infrastructure.
Continuous monitoring helps maintain the quality of service. There are many open source tools for continuous monitoring that fall mostly into the following four categories:
- Infrastructure monitoring: This allows you to keep track of compute resources, storage, network usage, etc.
- Cloud providers: Most of the largest cloud providers have integrated tools for monitoring your back end in each respective cloud platform.
- Application performance monitoring (APM): To monitor your application’s framework.
- Aggregators: Tools that allow you to aggregate and analyze data across several monitoring tools.
In addition, it’s a good idea to complement server-side monitoring with real user monitoring (RUM) tools to identify whether a specific code deployment impacts performance.
A faster back end makes for a faster front end, and, as we know from part one of this series, performance is a major contributor to user experience. In addition to focusing on improving metrics including latency, throughput and errors (all of which are directly correlated with back-end performance), it’s critical to have a “culture of performance” in your company. José Pérez provides an overview of that concept in his article, “Fostering a Web Performance Culture.” This is a perfect example of how you could implement a culture of performance in your organization, by having performance tools integrated into your IDEs—this can provide instant feedback to developers on how new code performs against a defined performance baseline so that any code that might degrade performance is identified before it is deployed.
For content that is not personalized, such as a product catalog, news or media assets, you can easily improve performance by putting a CDN in front of your back end (and caching that content on the CDN’s edge servers). Those edge servers are distributed around the world, located much closer to end users than your back-end infrastructure, to minimize network latency and maximize throughput.
Finally, a big part of setting up monitoring that works (and in responding to failures quickly) is DevOps automation. Building automated DevOps tooling allows you to react to changing conditions automatically, in real time.
For example, you can use DevOps automation to alert your team via a chat system such as Slack when a deployment impacts the service, with an option to roll back easily the deployment within the chat app. Another great example of DevOps automation is Pinterest’s implementation of a “performance detective” that runs a binary search (similar to git bisect) to determine the offending commit that is degrading app performance after a release. If you combine these two automations, you could detect a performance degradation caused by a release; let the DevOps team know that it has been rolled back and track the offending code in the version control repository. That’s just one specific example among the many ways that DevOps automation can further optimize your back end.
Coming up next in this three-part series: Everything you need to know about optimizing the middle-mile.