Real World Example: This is like owning a car. All the “Maintenances” that is required for the car must be done by your or you can hire a vendor to do the maintenance. The ownership of the car is yours. You can have your own Depreciation cycle and can replace or replenish the Hardware. All the contents that you put in the hardware (based on any specific core licenses) is your call. You can either host your own Data Centre or you can hire a rack in a huge data centre (a farm) and have your servers / hired servers hosted in there. On-Premise Data centres for Primary and Secondary works the same way.
On AWS: AWS Outpost enables many of the cloud services to be deployed on-premise. Outpost comes with preconfigured rack with network, compute and storage. organizations can run EC2, containers, EBS, few variant of databases on premise as you will deploy in the public cloud.
IAAS — Infrastructure As A Service
Real World Example: This is like HIRING / LEASING a car. All the “Maintenances” that is required for the car during the period of lease must be undertaken by you. Once the car is returned, it is not your responsibility any more. You do not own the car.
On AWS: You lease an Instance and deploy your services in that instance. As long as you pay for the service and you use it, it is yours. No one else can get access to that area. Under the shared responsibility model, all the Data / Resources / Users you create / Network traffic / Patching & upgrading etc., is your responsibility. Hardware maintenance / Networking / Switches is AWS responsibility.
PAAS — Platform As A Service
Real World Example: This is like a TAXI. You hire a taxi to travel from Point A to Point B and pay for the “Metered” use of the Taxi.
On AWS: Service provider delivers platform to clients, enabling them to develop applications on them.
SAAS — Software As A Service
Real World Example: This is like getting TICKETS in a Bus. Depends on the number of tickets / seats you purchase, you will be charged accordingly. Certain bookings may have a minimum booking requirement.
On AWS: Application comes pre-built on cloud where you can pay for the number of seats required and use the software where you can input the data and process it. Configuration and Rules setting according to your needs, configuring the fields usually will be allowed in few of the SAAS.
Real World Example: Ride-share using Uber or Grab is equivalent analogy for Serverless. You don’t have to worry about how much mileage the care will give, breaking system, security etc. All you have to make sure is the ride can take you from point A to B without any issue and you can opt for any additional services the ride provider may provide.
On AWS: Any fully managed service in the AWS stack is pretty much a serverless service. You do not have to spin up and maintain any server / service on your own — it will be auto managed by AWS. For serverless it is not a debate between whether we should go for a serverless approach or server based approach. Even if you go for complete server based few of the services can be serverless in your technology stack such as Dynamo DB, AWS Glue etc. Serverless stack for AWS includes Compute: Lambda & Fargate; Application integration: Eventbridge, Step functions, SQS, SNS, API Gateway, AppSync,
Data Store: S3, Dynamo DB, RDS Proxy, Aurora Serverless
Why would you choose one for another?
To decide this, it is important to understand the Trade-off between IAAS | PAAS | SAAS.
The XAAS Offerings?
Anything and Everything as a Service — XAAS.
What I want to see more is Cloud offerings for specific “extremely sensitive verticals”. Finance may not want to share the data with Health-care and vice-versa. A FAAS — Finance Cloud As A Service or HAAS — HealthCare As A Service, will make it even more attractive for Cloud adoption. The reason one would need vertical wise offerings is that having the ability to have a complete Checklist defined Cloud Book of Knowledge, Required security practices for that industry vertical etc., This will enable more cloud adoption.
Next section is also about Cloud Models from Deployment point of view.
Next Part: Business Case for Cloud.