Decoding Cloud PaaS

The popular rhythmic cloud axiom “Infrastructure as a service (IaaS), Platform as a service
(PaaS), Software as a service (SaaS)”, might put us in an illusion that IaaS came first in the
evolution cycle of cloud services. But, this theory is not factual. Although IaaS became a popular
way of cloud adoption as it gave enterprises an option of quicker movement to the cloud, the
very first public cloud service offered was Simple Queuing Service (SQS), a messaging service
by Amazon Web Services, in 2004. Soon after, PaaS became the choice of most developers as it
takes away the hassles of managing the IT infrastructure of business applications.

According to Oxford dictionary, a platform is defined as, “A raised floor or stage used by public
speakers or performers so that they can be seen by their audience.”

To understand this in the context of cloud, replace ‘raised floor’ with ‘computing ground’,
‘public speaker’ with ‘developers’, ‘can be seen’ with ‘produce’ and ‘Audience’ with ‘useful
applications’.

A computing ground used by developers

where they can produce useful
applications.
“Developer” has been deliberately chosen to keep infrastructure from backdrop. Basically, PaaS
provides developers with the essentials that are required to run a useful code and asks for little
that deviates from their basic goal of deploying useful applications in cloud.

Let us consider a simple analogy to understand PaaS better with crops farming. A farmer first
studies the soil and then thinks of the right crop it can produce, to support his aspirations. He
then chooses the right season in which the activities of the soil are intensified and is ready to
embrace the seed – be it plowing, leveling or manuring. After seeding the soil, he irrigates the
fields to help get the best yield.

Now, consider a situation where the farmer just decides on the crop and delegates another person
to take care of arranging the rest of the process. You see a crop production platform in action.
Replace the farmer with developer and code in place of seed. And, if the soil was considered as
infrastructure, infrastructure management would be plowing, watering, manuring, weeding, etc.
The PaaS provider in this scenario would be the delegated one who does it all but at scale. With
this simple analogy, let us understand the concept better.

Why does PaaS have better scope over

IaaS and SaaS?
Although IaaS gives a lot of flexibility to the developers for deploying applications with full
control, it comes with myriad of hassles related to infrastructure building and operations. On the
other hand, SaaS limits the innovations as the developers’ role in SaaS offerings are restrained.

PaaS allows the developers to innovate at a speed that is inspiring. As soon as the developers get
the details of environment such as region, deployment plan and language, the environment is
ready and coding is set in action. Developers are also given the liberty to choose their preferred
development tools built into PaaS solution depending on their methods of preference.

Cost is always a crucial factor in decision making while selecting from multiple options. PaaS
offers pay-as-you-go model where the payment is done in terms of the actual usage. In addition,
you have the freedom of aligning to the right type of hosting plans based on the load you expect
on the application. Another feature of PaaS is promoting the code across the chain of
environments – test, staging, pre-production, and production. This brings in consistency of
experience in multiple stages. PaaS platforms are quite resilient as more than one node serve the
actual load to maintain high availability. Code and configuration can be replicated across
facilities and regions to add the capability of recovery in disaster situations.

What are the pitfalls or inhibitors of

PaaS?
Even though PaaS offers a multitude of solutions for the betterment of enterprises, there are
some limitations that need to be addressed before the implementation. Here are some of the
pitfalls or inhibitors that come with cloud PaaS:
 One of the major inhibitors of PaaS is provider lock-in. Simple transportability of code amongst
providers is far from reality. To replace the provider for performance or cost, you will need to
plan and invest, as the code in one platform will not work in another.
 PaaS does not support legacy applications as they don’t easily fit in the groove provided by
PaaS.
 Multi-tenant nature of PaaS brings a few concerns such as system isolation and security on fore.
 The need to embrace the change in development and deployment ecosystem of provider may not
be well taken by the developers.
 It’s imperative that the enterprises follow providers’ service roadmap as strenuous situations
could arise if the provider stops supporting specific language platform or associated tools.
 High performance benchmarks and atypical network layout may be deterrents to PaaS.
 PaaS roles out the VMs or machine instances underneath its offering. There is a limit on these
machines in terms of computing power such as memory and CPU. Hence, a challenge of
application load to which PaaS can scale will have to be encountered.
 IaaS deployment could be a better choice if cost is the prime decision-making factor in a
situation.

Even though the above listed points throw some concerns, they may not be the road blockers in
PaaS adoption. Careful planning and bottom-up decision making should be able to make
enterprises come close to implementing PaaS.

We, at Mindtree, came across one such situation wherein the client envisaged moving his
applications – modern and legacy to Azure PaaS. Our process started with a careful assessment
led by PoC, and soon, we were face-to -face with reality. Size of the sitecore platform and
serving marketing websites of this client did not receive matching workloads on Azure PaaS. If
you are wondering why workloads are arising in PaaS discussion, well, there are workloads
provisioned to serve the code in PaaS too. And here in PaaS, a choice of larger workload that is
rolled out under IaaS model cannot be matched. Finally, to resolve this issue, we moved legacy
application to PaaS but still ran sitecore on IaaS.
 What are the common applications that
allude to PaaS?
Though PaaS is not a one-stop solution to all the challenges, it helps in solving some of them
when the use case is carefully identified and built. Some prevailing use cases are mentioned
below:

 End to End API Development and Management

 BI and Big Data systems such as (HDInsight, Hadoop EMR, etc.)
 Content Management System
 Databases such as RDS, Azure SQL
 Lightweight Websites: Building small organizations’ marketing websites
 Internet of Things and Messaging Queues
 Business Process Management Applications
 Master Data Management