The textbook definition from SearchCloudComputing.com and Tech Target as written by Margaret Rouse in August 2010 is as follows:
Platform as a Service (PaaS) is a way to rent hardware, operating systems, storage and network capacity over the Internet. The service delivery model allows the customer to rent virtualized servers and associated services for running existing applications or developing and testing new ones.
Platform as a Service (PaaS) is an outgrowth of Software as a Service (SaaS), a software distribution model in which hosted software applications are made available to customers over the Internet. PaaS has several advantages for developers. With PaaS, operating system features can be changed and upgraded frequently. Geographically distributed development teams can work together on software development projects. Services can be obtained from diverse sources that cross international boundaries. Initial and ongoing costs can be reduced by the use of infrastructure services from a single vendor rather than maintaining multiple hardware facilities that often perform duplicate functions or suffer from incompatibility problems. Overall expenses can also be minimized by unification of programming development efforts.
On the downside, PaaS involves some risk of “lock-in” if offerings require proprietary service interfaces or development languages. Another potential pitfall is that the flexibility of offerings may not meet the needs of some users whose requirements rapidly evolve.
Incredibly, there seems to be a lack of valuable discussions on PaaS that are recent or relevant. When I did a Google search I was amazed at how little there was.
Let’s break down the points in the definition and examine them more closely.
- With PaaS, operating system features can be changed and upgraded frequently.
This would seem to be music to any CIO or IT Manager’s ears. In today’s world of technology who would want to have their feet in cement. Although operating systems don’t appear overnight it would make sense to leave all options open for your IT infrastructure. I would think the key word would be “upgraded” – that’s where innovation and technology intersect.
2. Geographically distributed development teams can work together on software development projects.
Exactly. If you’re in an enterprise or ISV environment then there are significant, real savings that can be made.
They would include:
- People-power – real savings in costs related to personnel size.
- Time – probably the most important element for enterprises or enterprise clients. If you were an ISV or hosting company then the same could be said for any size client. Small and medium size clients could have the need for quick service.
- Hardware – no one would want spend extra capital dollars to supply dispersed offices/data centers.
- Synergy – hard to measure “intangible” from company to company but you know when it’s there and when it’s not there. This could be a real hidden powerful force if it’s coming through from your personnel.
- Customization – two things come to mind here that could be at play. First, local (meaning in-country) needs that can be best met and understood by local or nearby resources. Second, an opportunity to “crowd source” your own personnel resources and come up with a truly customer-centric solution.
- Services can be obtained from diverse sources that cross international boundaries.
Pretty much what I outlined in #2 with geographically dispersed teams. One of the biggest elements here would be the savings in time by continual operations around the clock. However, I have a friend who worked for a software company and his development resource was in Eastern Europe. He could never seem to make contact with the development manager and it cost him his job. So, management has a duty to stay on top of those areas to make sure that performance and cohesion don’t suffer.
- Initial and ongoing costs can be reduced by the use of infrastructure services from a single vendor rather than maintaining multiple hardware facilities that often perform duplicate functions or suffer from incompatibility problems.
I’ve already touched on this but the statement is pretty self-explanatory. Why duplicate hardware especially when you’re looking at capital expense budgets and “IT as a profit center” logic. Then there’s that compatibility issue – what’s new today in the tech world can be old tomorrow. Beta or VHS?
5. Overall expenses can also be minimized by unification of programming development efforts.
It would seem very true and logical. Again, we could go back to the points about geographically dispersed teams, across borders, and time zones. However, think of management like the stage coach driver. It’s their job to pull or loosen the reins as needed to make it all work.
Now let’s look at those two items mentioned on the “downside” of PaaS.
A.) PaaS involves some risk of “lock-in” if offerings require proprietary service interfaces or development languages.
That’s very true. XaaS is like a long-term engagement without the ring ceremony. There is a contract between the client and the provider with the Service Level Agreement (SLA) spelled out. It denotes not only what must be done for the client but what happens when and if the service provider doesn’t deliver. However, proof is often in the eyes of the beholder. That’s’ why reputation and references from a service provider are an essential for a prospective client.
B.) Another potential pitfall is that the flexibility of offerings may not meet the needs of some users whose requirements rapidly evolve.
So now we’ve past an engagement moved on to the marriage ceremony. It’s time for a true heart-to-heart about needs vs. service. If you’re a client whose development needs move that rapidly then maybe you need to take a second look at PaaS before committing. Maybe you need to segment you entire IT operation and development process to see where the great divide between internal resources and PaaS can take place.
I think if you follow these guidelines and think diligently about PaaS before jumping in the water you will be well advised.
Lastly, someone had asked me from a previous blog if Infrastructure as a Service (IaaS) and PaaS were the same. I think they might be cousins but not the same. Perhaps the biggest difference would be the use of virtualization and application delivery. This would be a great spot to ask for some feedback from you.
Please make sure to copy your response directly into my blog Comments section at:
Regards – Dom
Dominic J. Frúges