Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Your Problems are Your Fault with PaaS

DZone's Guide to

Your Problems are Your Fault with PaaS

· Cloud Zone
Free Resource

Site24x7 - Full stack It Infrastructure Monitoring from the cloud. Sign up for free trial.

There's a lot of momentum behind moving to Platform-as-a-Service (PaaS) for delivery of applications on the cloud, but is there enough maturity in PaaS to deploy a mission-critical application? Here's a story regarding one loyalty program provider that offers his customers SaaS solutions. This SaaS provider deployed his platform on a PaaS that offered SQL Server and ASP.NET services. The SaaS has been operating perfectly for months handling the needs of his clientele, but unexplainably stopped working midday on a Saturday—a busy retail time period.

While the PaaS provider supposedly offered 24x7 support, they responded only to the first support ticket with a single response, “we really can't identify problems within your application.” The developers did what they could to discern the problem, but all their research pointed to something changing on the server. Upon hearing this, I had a bevy of thoughts regarding the maturity of PaaS:

1. With IaaS, the customer takes responsibility for maintenance and updates to the server OS, so, hopefully, they test changes before rolling out into production. SaaS providers also could implement changes that could impact their customers, but, again, I would expect that these would be tested before rolling out into production with the ability to rollback should some unforeseen problem arise. However, PaaS providers can make changes to the platform that are all but impossible to test against every customer's application, meaning that changes the PaaS provider rolls out could shut your application down. Moreover, they may not even be aware of all the nuances of a vendor-supplied patch making it very difficult to recover and correct.

2. Out of IaaS, PaaS, & SaaS, the PaaS provider has the greatest likelihood of pointing their finger back at you before pointing at themselves. After all, other customer's applications are up and running, so it must be your application. Hence, a PaaS provider needs to provide much more expensive help desk support than the other two service models in order to be able to ascertain the severity of a problem and get it corrected. Additionally, PaaS providers need to provide more 1-on-1 phone support as these issues are too complex to handle by email and trouble tickets alone.

3. IaaS, PaaS and SaaS each offer less visibility into the internals of the service respectively. However, lack of control over the PaaS means that key settings that may affect the performance of your application may be outside the ability for you to affect. Case in point, the specific problem this loyalty SaaS provider had was that the PaaS was reporting a general error and telling him to make certain changes to his application configuration environment. However, the recommended changes were already implemented and it was seemingly ignored by the platform. At this point, the lack of visibility meant that the PaaS service provider was the only one capable of debugging the problem, even it was the fault of the application, which in this case it was not.

4. Which brings us to the next point, the problem according to the PaaS provider was that an update forced the application to run under an incorrect version of .NET. Even though the developers forced the appropriate version through their control panel once problems started occurring, it seems that the control panel changes didn't actually have any affect. Hence, the customer must have a lot of faith that the tools the PaaS provider offers actually do what they state they are doing and if they don't then the visibility issue in point #3 will once again limit any ability to return to full operating status.

All this leads me to question if PaaS is actually a viable model for businesses to rely on. IaaS gives them complete control, but they will need to learn how to architect for scale. SaaS removes all concern for having to manage the underlying architecture and the SaaS provider will live or die based on their ability to manage the user experience. PaaS, is fraught with pitfalls and dangers that could cause your application to stop running at any point. Moreover, should this occur, the ability to identify and correct the problem may be so far out of your hands that only by spending an inordinate amount of time with your PaaS provider's support personnel could the problem be corrected.

I welcome input from PaaS providers to explain how they overcome these issues and guarantee service levels to their customers, when they cannot guarantee that customer's applications are properly written, that the libraries they use will run as expected in a multi-tenant environment or that a change they make to the platform won't stop already applications from running. Additionally, I'd be interested in hearing answers that equate to PaaS solutions that are more than pre-defined IaaS images, such as CloudFoundry or Azure.

 Source: http://www.jpmorgenthal.com/morgenthal/?p=271

Site24x7 - Full stack It Infrastructure Monitoring from the cloud. Sign up for free trial.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}