Decoding Cloud PaaS for the Developers of Today and Tomorrow
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
What are the commonly used leading PaaS providers/platforms?
Microsoft, AWS, GCP, RedHat, IBM are some of the major PaaS providers. Microsoft Azure Web App provides development and deployment of PaaS spectrum for .Net, PHP, Java Python, Ruby or .Node.js. AWS Elastic Beanstalk is another option for application creation and deployment at scale. This platform is quite friendly for developers as it offers a great deal of ease for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go and Docker, on familiar servers such as Apache, Nginx, Passenger, and IIS. Google App Engine supports popular languages such as Java, PHP, Node.js, Python, C#, .Net & Ruby and offers a flexible environment option. In this option, you can write the software code in any version of your choice and programming language offered by Google. It is also possible to customize a runtime or use your own runtime on a custom container image.
In simplistic terms PaaS offers an ecosystem of runtime, middleware, operating system, virtualization, servers, storage and networking. This speaks volumes in favor of the coveted deployment model as the developers get all this at their disposal and can focus on innovations in code.
Organizations have moved or will move to cloud under IaaS model because it needs small or no change to the code and architecture of application. Nonetheless, applications migrated under IaaS inherit a lot of attributes of perpetual deployment in the data center. These attributes put a limit on benefits that the enterprises can avail on cloud.
Wave of containerization may gain on PaaS in future as containerization technology helps to package code with runtime and associated libraries. In early days, containerization helped in orchestration of PaaS, but there is a possibility of both conflicting with each other. Containerization helped by container management systems, such as Kubernetes; and its ability to deliver microservices, can potentially replace PaaS. But as of today, PaaS continues to win the confidence of businesses.
Do you think implementation of PaaS model helps enterprises better than IaaS and SaaS?