This is a follow-up on my initial posting on IaaS vs PaaS. While part 1 was an introduction into what IaaS is and how PaaS differs, this posting will look into an exemplary business-case, comparing those two approaches.
The scenario and the numbers used in this business-case will be simple, as this exercise is not done to cover all possible situations, but to give you an idea on how the two approaches can be compared. It will not relieve anyone from doing their own calculation!
Scenario & Assumptions
For simplicity reasons, let’s assume we are an enterprise, who relies very heavy on applications, running on a Servlet-Container like Tomcat. Let’s also assume, that the number of Tomcat based applications grows by 50% year-over-year.
For manageability reasons our enterprise decided to put not more then one application onto a Tomcat and only one Tomcat per virtualised server. ( Sidenote: this is not an imagined scenario, but reality with the majority of the customers I talked to. )
Let’s also assume that we will start with the following hardware
When exceeding any of the provided resources, our enterprise will extend the environment by bulks of
For the allocation of resources per Tomcat environment, we will assume
- in the IaaS approach every Tomcat geht’s his own virtual server with the following resource allocation
- in the PaaS approach we will work with container, each being
The difference in required RAM per instance ( virtual server vs. container ) is due to way container share resources with their host. This results in a lower demand for memory.
Mapping of physical hardware to virtualised one will be done with the following ratio
- each physical core will ‚host‘ 5 virtual cores
- RAM will not be overcommited, as paging reduces performance
- as we assume to have a good mix of Development,- Test-, and Production environments, we can assume that only 50% is really needed at the same point in time ( or do you know a developer who gives back development- or test-server or who activly shuts down virtual server that he doesn’t need?)
IaaS Hardware consumption
For our calculation let’s look at the following number
- total number of virtual server required, one for each Tomcat
- the virtual cores required for this number of virtual server
- the number of physical cores occupied with running this number of virtual server
- virtual RAM assigned to this number of virtual server
- physical RAM assigned to this number for virtual server
- storage required to provide this number of virtual server
- phyical cores available
- physical RAM available
- Expansions needed
Taking this data into consideration and assuming a growth-rate of 50% p.a. we will get the following data
As you can see, there was a need to extend the physical infrastructure for 3 times in 4 years, and the need to double the hardware after only approx. 2 years.
PaaS Hardware consumption
Now let’s do the same exercise for PaaS.
- total number of deployed container, each running one Tomcat instance
- number of container actually running ( due to automatic hibernation )
- virtual cores required for running container
- physical cores required for running container
- virtual RAM required for running container
- physical RAM required for running container
- storage required to provide total number of container
- physical cores availabe
- physical RAM available
- hardware expansions required
Taking this data into consideration and again assuming a growth-rate of 50% p.a. we will get the following data
In this case, the first hardware extension was only required after approx. 3 1/2 years, with the extensions being able to provide compute power for more then two more years.
A PaaS platform, especially one who makes extensive use of container, like Red Hat OpenShift enables an enterprise to reduce investment in hardware and reduces the amount and cost of running the required amount of physical and virtual server.
In my next article on IaaS vs. PaaS we will compare the two approaches from a cost point of view, taking not only the CAPEX into consideration, but also the human labour based cost and effort.