Reshaping the Cloud To Meet Modern Workloads

The Amazon Prime Video team recently published a blog post that made waves among the cloud and developer communities. In the post, the team detailed how moving one of their monitoring tools from a distributed serverless architecture to a monolith helped lower costs and increase scalability.

So, is this the end or serverless, as some are calling it? Hardly. Just because the Prime Video team realized that a monolith architecture worked best in this use case does not mean that it should be the go-to architecture for monitoring tools. Those decisions should be made by individual teams choosing the best technologies and architecture for their own cloud deployments. Serverless makes a lot of sense for a multitude of use cases, especially streaming video.

The Case for Serverless

Serverless architecture should be used for workloads that require low latency and quick response time. It’s best suited for smaller workloads, while the traditional cloud is better for massive workloads that need scale – the problem that Amazon quickly ran into. Serverless is also ideal for workloads that need to be distributed among a bunch of different geographies.  

Streaming video and live streaming, in particular, benefit from serverless, given the volume, distribution, and real-time nature. There’s a lot that must happen for the images captured from the camera to make it to our screens in just five to ten seconds. First, the video needs to be prepared, which involves creating multiple resolutions and chopping them up into smaller chunks. This is a critical step to minimize playback issues. Once the videos are ready, content delivery networks (CDNs) are used to distribute the streams and implement local caching. Caching is just one part of the challenge, however. Access to the video streams must be limited to paying customers, and from there, experiences should be customized to each user. Serverless functions are often the best way to implement these small, discrete tasks. 

Knowing which use cases are best for serverless applications, we can zoom out to think bigger about what organizations should keep in mind before beginning new cloud deployments. 

Start With the End Goal, Not the Technology

When new technologies emerge, it’s natural to get excited about the potential. There’s an appeal to being on the cutting edge of new ways to work or trying a cool new prototype. But one of the biggest mistakes that can be made when beginning a new development project is considering the technology before the end goal. Deciding to run something on a serverless architecture before deciding on your objectives is starting with the solution in mind rather than the end goal. Once you choose your technology, you’ve already implicitly made decisions that will impact the rest of your project.

Every project should start by recognizing the goals you’re trying to accomplish, and from there, teams can work backward to figure out which workloads and technology infrastructure are necessary to deploy in which locations. It’s also important to be forward-thinking and consider how much capacity you’ll need in the future, not just in the present or initial stages of deployment. The end goal should always be your guiding star when beginning a new workload deployment project.

Think About Distribution, Not Just Regions

When selecting a cloud vendor, consider its distributed capabilities. Thinking of clouds as region-specific is outdated and won’t work for modern applications – the right partner can deploy a distributed cloud architecture without the regional limitations of legacy cloud providers. 

Similar to future thinking for capacity planning, location management for workload distribution and expansion is hugely important for long-term viability. Considering these factors at the beginning of projects will lead to easier scalability and flexibility later in the process.  

Don’t Be Afraid of Change as Long as It’s for the Right Reasons

Keep in mind that the architecture you start with will probably have to be changed at some point – especially if your project is successful. In the case of Amazon Prime Video, they realized that sticking with a serverless architecture would prevent them from scaling to their original plans.

Before you hit the reset button, ensure that the root of the change is addressing a pain point, like improving scalability, productivity, or latency. Ripping out your infrastructure and starting over might be daunting, but your team – and end-users – will benefit from the change, despite any short-term growing pains.

Transparency About Mistakes Helps Better the Industry

Admitting that a project has gone awry isn't easy. We need more transparency and discussions about when technology does and doesn’t work for specific use cases. Cloud and developer communities can look to the security industry as an example where information sharing is vital to educate and alert others of data breaches and ransomware threats. Any team that takes the time to share their learnings, like the Amazon Prime Video team, should be applauded.

As an industry, we need to have more of these discussions, especially as we navigate uncharted waters with new advancements in artificial intelligence, machine learning, and IoT. By sharing our learnings and experiences, whether in blogs, through platforms like The Open Compute Project, or through other methods of information sharing, we can offer new ideas and gain insights and solutions to help teams avoid mistakes and overcome obstacles.  

The Need for Modernized Cloud Architecture 

Ultimately, organizations going all-in on yesterday’s cloud architecture will run into issues, just like Amazon Prime Video encountered. The infrastructure of the future must be designed to accommodate modern applications with centralized and distributed requirements. With these challenges bubbling up publicly, it’s a race to see who can address these issues and build the cloud for the next decade.