How to Build Next-Gen Apps With Serverless Infrastructure

The cloud has completely changed the game when it comes to building applications. Engineering teams dont have to settle for monolithic apps or hard-to-manage infrastructure anymore. And with the right cloud service vendor (our choice: Amazon Web Services), making the jump into the modern era of application building is easy.

In this post, well explain why legacy applications fall short and how teams can upgrade the services they offer. Well also answer some of the most common questions we receive on this topic to give you confidence that the right serverless solution is out there.

Stateless Vs. Stateful Architecture Designs

Monolithic applications have traditionally depended on stateful architectures in which user session information is stored on a server rather than on external persistent database storage. This server-based session storage gets in the way of modern application design.

The problem with stateful session storage is that session information cant be shared across multiple services. Once a user establishes a connection to a particular server, they have to stick with it until the transaction completes. IT teams also cant perform round-robin” requests to distribute traffic across multiple services and applications cant scale horizontally.

Fortunately, there is a better model that leverages stateless architectures. If companies put user session information on persistent database layers rather than on local servers, state can be shared between microservices. This unlocks a wide range of performance benefits and the potential to leverage service-oriented architectures (SOA).

Service-Oriented Architecture (SOA)

Service-oriented architectures (SOAs) use components called services” to create business applications. Each service has a specific business purpose and can communicate with other services across various platforms and languages. The goal of an SOA model is to implement loose coupling, enabling teams to optimize, enhance and scale services individually. But the challenge with SOA is that it requires more nuanced governance.

Simple object access protocol (SOAP) and representational state transfer (REST) are the two primary service architectures used to implement SOA with appropriate governance. SOAP is older, heavier and relies on XML for data exchange. REST is newer, more efficient and allows JSON, plaintext, HTML and XML data exchanges. The good news is that going the REST route is easy on AWS with a tool like Amazon API Gateway.

Amazon API Gateway gives engineers the ability to put RESTful endpoints in front of Lambda serverless functions and expose them as microservices.” Going stateless with REST sets the stage for game-changing microservices-based applications.

Microservices Best Practices

The clear advantage of microservices is that discrete business functions can scale and evolve independently with dedicated IT infrastructure. Engineers can also maintain a much smaller surface area of code and make better choices when it comes to supporting individual services.

Best practices for designing microservices architecture include:

  • Creating a separate data store so that individual teams can choose the ideal database for their needs
  • Keeping servers stateless to enable scalability
  • Creating a separate pipeline for each microservice so that teams can make changes and improvements without impacting other services that are running
  • Deploying apps in containers to ensure standardization across services
  • Using blue-green deployments to route small percentages to new service versions and confirm that services are working as expected
  • Continuously monitoring environments to proactively prevent outages

When all of this is done in a serverless fashion, engineers have much less infrastructure to manage themselves. They can focus more on application code and less on operating systems, server specifications, autoscaling details and overall maintenance. Serverless microservices with stateless session storage via REST are the core ingredients of next-gen applications.

That said, there are aspects of this strategy that can be confusing to new adopters, such as the need for containers and how to deploy event-driven applications. Well touch on these concerns next.

Why Do we Need Containers if we Have Instances?

When educating clients on the benefits of serverless infrastructure and containers, were often asked why we need containers at all. Dont instances already provide isolation from underlying hardware? Yes, but containers and Docker, specifically, provide other important benefits.

Docker allows users to fully utilize virtual machine (VM) resources by hosting multiple applications (on distinct ports) on the same instance. As a result, engineering teams get portable runtime application environments with platform-independent capabilities. This allows engineers to build an application once and then deploy it anywhere regardless of the underlying operating system.

Deployment cycles are also faster with containers, and its easier to leverage infrastructure automation. Furthermore, its possible to run different application versions simultaneously, as well as package dependencies and applications in a single artifact.

What Happens if a Particular Service Goes Down?

Good question. We recommend using a tool like Amazon SQS, which is a messaging queuing service designed specifically for serverless applications.

Such queue-based architecture prevents potential data loss during outages by adding message queues between services (REST endpoints). These queues hold information on behalf of services.

What About Event-Driven Architecture?

Implementing event-driven architecture can work for serverless infrastructure through either a pub/sub model or an event stream model. With the pub/sub model, when events are published, notifications go out to all subscribers. Each subscriber can respond according to whatever data processing requirements are in place. The service we recommend for this is Amazon SNS, a fully managed pub/sub service designed for serverless applications.

On the event stream model side, engineers can set up consumers to read from a continuous flow of events that come from a producer. For example, this could mean capturing a continuous clickstream log and sending alerts if any anomalies are detected. We turn to Amazon Kinesis for this type of functionality.

Anthony Loss

Anthony Loss is a Lead Solutions Architect at ClearScale. He has nearly a decade's experience helping clients reduce IT expenditures, increase business agility, accelerate innovation and mitigate risk. Loss has a Bachelor of Business Administration from Illinois Institute of Technology and a Master of Business Administration from Dominican University.

Anthony Loss has 1 posts and counting. See all posts by Anthony Loss