Towards Serverless

Sudheer Kumar
2 min readFeb 26, 2021
Photo by Carl Oldenbourg on Unsplash

AS the world is moving towards Serverless, here we are taking a glimpse back on how we reached there.

Computing Evolution

  • Physical servers: Scaling the physical server infrastructure. Issue => Utilization factor can be low, lot of initial investment
  • Virtual machines: Efficiency achieved by virtualizing the hardware
  • Containers: Better results with faster start times
  • Functions: Best results by abstracting the runtime

At the same time, the architecture resolution has been happening this way.

Architecture Evolution

  • Monolith — single codebase or the entire logic in a single layer.
  • N-tier — the functionality is split to multiple laters like UI, Business, DB
  • Microservices — do one thing and do it well. Large complex applications can be broken down into components with a bounded context (business domains). Deployed & scaled independently
  • Nanoservices with serverless: We’re not focusing on building infrastructure or runtime, but just running business logic with pay peruse. Many nano services can make up one microservice.

Tradeoffs- Nano-Services

Pros:

  • Reporting for cost control can be fine-grained
  • Can also help a Product Owner prioritize the optimization of a particular function
  • lowers the Time to Value

Cons:

  • having many more functions increases the complexity of the deployment, versioning etc
  • Inter-service dependencies in terms of how we maintain which nano services have relationships with other services and data sources
  • complex computational tasks, long-running or huge memory task — a microservice hosted in a container might be better

Event Driven Design

Nano services are not good enough, we also need to see how to orchestrate the business process. Event-driven architecture makes the architecture more loosely coupled. Cloud-native applications are built using AWS Managed Services (SQS, Kinesis, Event Bridge, Kinesis, Lambda) and they natively support event-driven behavior.

Serverless Framework

Now we have a great set of features ready to help us with Serverless development, but for a production-ready development environment, we will need a lot of additional features like:

  • Code and run deployments from your local machine
  • Share common libraries and utilities
  • Work with multiple developers on the same project
  • Version and control changes to assets and resources
  • Write test suites and enable development standards across all functions and services
  • Focus less on the nuances of the implementation details like IAM roles required etc.

To help with them, we need multiple serverless frameworks. I will continue with that in another blog.

--

--

Sudheer Kumar

Experienced Cloud Architect, Infrastrcuture Automation, Technical Mentor