Getting Started with Serverless Architecture


Serverless Architecture is relatively very new. I’ve been exploring Serverless architecture for the new platform architecture off late. Though it is very interesting obviously there is a reasonable learning curve and I don’t see lot of best practices out there yet.

Everything looks green on the other side.. We will learn as we move forward..

Since, we use AWS as our cloud provider, most of the examples you will see are related to AWS Lambda.

Specific Reasons for exploring Serverless Architecture 

  1. No operating systems to choose, secure, patch, or manage.
  2. No servers to right size, monitor, or scale out.
  3. No risk to your cost by over-provisioning.
  4. No risk to your performance by under-provisioning.

One thing i learnt in the last few years about developing distributed applications is that, it is not about learning new things… it is always about unlearning what you have done in the past.

If you are specific about Vendor lock-in then this may not be a choice at all for you…

Following is my reading list on Serverless Architecture.

What is Serverless?

Serverless Architectures

What is Serverless Computing and Why is it Important?

Serverless Architecture in short

Is “Serverless” architecture just a finely-grained rebranding of PaaS?

IAAS, PAAS, Serverless.

Serverless Delivery: Architecture

Principles of Serverless Architectures
There are five principles of serverless architecture that describe how an ideal serverless system should be built. Use these principles to help guide your decisions when you create serverless architecture.
1. Use a compute service to execute code on demand (no servers)
2. Write single-purpose stateless functions
3. Design push-based, event-driven pipelines
4. Create thicker, more powerful front ends
5. Embrace third-party services

Serverless Architectures – Building a Serverless system to solve a problem

Serverless architecture: Driving toward autonomous operations

Serverless Developers

The essential guide to Serverless technologies and architectures

Using AWS Lambda and API Gateway to create a serverless schedule

Five Reasons to Consider Amazon API Gateway for Your Next Microservices Project

AWS Lambda and the Evolution of the Cloud

SquirrelBin: A Serverless Microservice Using AWS Lambda

A Crash Course in Amazon Serverless Architecture
AWS Lambda and Endless Serverless Possibilities

Awesome Serverless – A Curated List

Happy Learning!


The Blind Men and the Cloud

Not sure if you guys have seen this before. I was reading the book Executive’s Guide to Cloud Computing today, which had a reference to this. I checked in Web and found the actual post. Blogmarking it.

Inspired by the Blind men and the Elephant, this one tries to capture the essence of Cloud. Good One.

“It was six men of Info Tech
To learning much inclined,
Who went to see the Cloud
(Though all of them were blind),
That each by observation
Might satisfy his mind

The First approached the Cloud,
So sure that he was boasting
“I know exactly what this is…
This Cloud is simply Hosting.”

The Second grasped within the Cloud,
Saying, “No it’s obvious to me,
This Cloud is grid computing…
Servers working together in harmony!”

The Third, in need of an answer,
Cried, “Ho! I know its source of power
It’s a utility computing solution
Which charges by the hour.”

The Fourth reached out to touch it,
It was there, but it was not
“Virtualization,” said he.
“That’s precisely what we’ve got!”

The Fifth, so sure the rest were wrong
Declared “It’s sass you fools,
Applications with no installation
It’s breaking all the rules!”

The Sixth (whose name was Benioff),
Felt the future he did know,
He made haste in boldly stating,
“This *IS* Web 3.0.”

And so these men of Info Tech
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were partly wrong!”

Original URL :

Happy Reading!!!

SaaS: CapEx, OpEx…

If you are dealing something related to SaaS or Cloud computing, then you must have heard these terms very frequently. I wanted to understand it better and found useful information in Wikipedia

Capital expenditures (CAPEX) are expenditures creating future benefits. A capital expenditure is incurred when a business spends money either to buy fixed assets or to add to the value of an existing fixed asset with a useful life that extends beyond the taxable year. Capex are used by a company to acquire or upgrade physical assets such as equipment, property, or industrial buildings.

An Operating expense, operating expenditure, operational expense, operational expenditure or OPEX is an on-going cost for running a product, business, or system. Its counterpart, a capital expenditure (CAPEX), is the cost of developing or providing non-consumable parts for the product or system. For example, the purchase of a photocopier is the CAPEX, and the annual paper and toner cost is the OPEX. For larger systems like businesses, OPEX may also include the cost of workers and facility expenses such as rent and utilities.

Some useful links
CAPEX/OPEX from Project’s Manager point of view
CAPEX vs OPEX: What is the difference?
SaaS decisions: Cap Ex vs Op Ex
Accounting for Clouds: Stop Saying CapEx Vs. OpEx

Is Multi-Tenancy a prerequisite for SaaS?

I recently attended a conference on cloud computing and one of the speakers said, if your application is not multi-tenant, then your application is not SaaS.

Let us look at the SaaS system Characteristics

1. Availability via Web Browser
2. On-demand availability
3. Pay-per usage
4. Minimal or zero IT Demands.

Let us look at what a multi tenant application is all about.  It’s a model where multiple clients can be supported in one single software instance. This will help the SaaS Provider to support more clients on fewer hardware components; rollouts/updates will be easier.

Read this post on Multi Tenant Architecture from MSDN to know more about Multi Tenancy.

My point here is, it depends on the service offerings and the customizations required. Also, it’s about the way you manage your deployments. I am not disagreeing that this may provide the SaaS Provider some cost benefits, which may result in the form of lower services fees to the end users. It’s based on what is really needed.

I was searching in web and found a post on similar lines

If you buy SaaS, don’t get lured into multi-tenancy marketo-munjo-jumbo and concentrate on features, SLA, integration options and cost.

If you are a service provider, then, yes, multi-tenancy is a (potentially very important) internal secret sauce that you can use to augment your economy of scale (at the expense of other aspects) but it is by no means a prerequisite, the right trade-off between multi-tenancy and isolation will depend on a myriad of factors and is often unique to the situation. As mentioned in this blog in the past and in Phil’s post today, virtualization can be a very successful way of achieving interesting levels of economy of scale without architecting the application for full multi-tenancy.

A high level model that served me well in the past in helping company understand whether they should go multi-tenant or not is the “cost per feature” vs. “cost per tenant” model.


Some useful links
Cloud Application Architectures: Building Applications and Infrastructure in the Cloud

Happy Learning!!!