Serverless / Sponsored / Contributed

What to Think About Before Building a Serverless App in Amazon Web Services

19 Nov 2020 8:05am, by

AppDynamics sponsored this post.

Wayne Brown
Wayne is a Senior Solutions Engineer with AppDynamics. He has more than 20 years of experience in software development, architecture and consulting across a wide range of technologies, disciplines and industries. Wayne is based in Montana and in his spare time keeps up his skills as a master certified BBQ judge.

Serverless is the fastest-growing model in cloud computing today, and no wonder. The promise of delegating infrastructure management to a cloud vendor is compelling in a business world that rewards high-speed innovation. If they weren’t already headed that way, many companies are feeling the urgency to go serverless to achieve greater resilience in the face of the global pandemic. The most well-known manifestation of serverless computing, functions-as-a-service (FaaS), is on track to be deployed by half of global enterprises by 2025 — up from only 20% this year, as reported by Gartner.

How do you know if your enterprise is ready to adopt serverless? If you’ve found yourself hitting bottlenecks or you’re unable to scale up and beyond the limitations of your current on-premise (or other) infrastructure to meet today’s demand, it’s time to look at how your cloud service provider can help. As the early leader in cloud computing with the largest share in the serverless market, Amazon Web Services (AWS) is a popular starting point for those beginning their serverless journey — and there’s prep work you can do to ensure that journey is successful.

How to Prepare for Serverless

Unfortunately, there’s no single one-size-fits-all approach when it comes to migrating to serverless architectures. However, as is the case with adopting any cloud model, it depends on what you’re trying to move.

For some companies, it might be most cost-efficient to run entire workloads as serverless. It’s not unheard of to completely re-architect an application from on-premise infrastructure to cloud infrastructure in one fell swoop — but it is rare. Usually, the timelines are too long for a complete rewrite; and there’s a lot of risk involved if clear goals and criteria for success are not defined.

The reality is, many organizations have legacy applications that aren’t ready — and may never be ready — for deployment to the cloud. Instead they take the microservices approach, migrating or refactoring one piece of their application at a time to take advantage of AWS Lambda and other serverless technologies as needed. This results in the hybrid architecture that enterprises more commonly find themselves managing. In fact, IDC says that by 2022, “over 90% of enterprises worldwide will be relying on a mix of on-premises/dedicated private clouds, multiple public clouds, and legacy platforms to meet their infrastructure needs.”

I’ll assume that you’re taking the hybrid route for the purposes of this post. But let’s backtrack a little. Before figuring out a strategy for migration, you need to lay the groundwork to take advantage of serverless technologies the right way.

Keep these considerations in mind:

What Are Your Business Needs?

When migrating parts of an application into serverless infrastructure, I’d start with an analysis of where the bulk of my costs are right now in terms of legacy infrastructure. Then, I would cross-reference that with what I estimate my cost to be, based on my current usage.

Bear in mind that billing for cloud vendors is often based on usage, so it’s important to be cognizant of what services you’re going to be consuming. Also, it’s crucial to make sure your components are optimized to take advantage of what AWS has to offer, without incurring any unnecessary or inflated spend.

What Are Your Goals?

To determine whether the move to serverless is successful, you’ll want to establish criteria for success from the very beginning of your migration project.

But those criteria will mean different things to different IT stakeholders. If your goal is to process customer requests 20% faster, for example, what does that look like across domains?

My background is in software development, so I might base success criteria on whether my refactored code results in performance improvements. But if I were in IT operations, I’d be more concerned with what infrastructure I’ll be using and how to get visibility into all of those components to see how they’re performing. An application owner, meanwhile, will look at the big picture — which critical functionalities to prioritize, and how the user’s journey flows throughout the entire application — to manage things not only from a performance perspective, but from a business perspective as well.

How Will You Know You’ve Hit Those Goals?

You can’t improve what you can’t measure, so once you’ve set criteria, you need to have some kind of observation framework in place to be able to gauge your application’s performance and how to optimize it. Then, as you go through each step of the migration, you can check these insights against your criteria to make sure you’re on track. It’s like managing any other project.

Except, of course, that the more complex your hybrid architecture grows, the more pieces that need to be monitored and observed.

Amazon offers monitoring tools like X-Ray and CloudWatch, which do a really good job within the context of AWS. But in a hybrid monitoring scenario — maybe you have components running in an on-premise data center, or in another cloud such as Azure — you won’t get a holistic picture of the entire application. You need a monitoring solution that makes observability central to the process, by providing complete end-to-end visibility across all these environments.

Another important thread to making observability central to the process is for the team to agree on a common framework and language. Not necessarily a computer programming language — just a common vernacular between teams. By bringing them into tighter alignment, you’ll operate more efficiently. Your monitoring solution should support this, too.

To Recap

You’ve assessed your business needs, set goals, and implemented an observability solution to help you reach them. Keep in mind that this is a continuous, iterative process, and that success looks different to different teams. If you’re not hitting your goals, you may need to reassess your criteria or methodology — but working together with a common vernacular will make the process much more uniform.

Amazon Web Services is a sponsor of The New Stack.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.