Platform as a service might work like magic for some apps.
It seems ever so many magical solutions are available to us these days.
"Want to build the Next Big Web App? Open an account with WhizBang PaaS Services and we'll take care of everything for you -- all you need to do
is upload your code!"
The promise is that you won't have to waste time with all that scary sys admin stuff. You're free to pursue the greatness that is your application without a care in the world about how it will function, deploy, scale, or secure itself. It's magic, more or less.
As many people are coming to understand, there is some legitimacy to these claims -- to a point, and with significant caveats. If you're looking for the quickest and easiest way to get a simple Rails or Django app up on the Web, these services are definitely the way to go. Fire up a stack, and
Many services claim they avoid lock-in because they're standards-based, and thus you can move your code anywhere. This may be true on one side, but the other side is that you're locked into what the service provides.
If you need certain packages or libraries that aren't offered, you may find yourself in a corner, in which case you not only have to develop your code to function as intended, but you have to do so within the confines of the stack supplied by the service provider. If a provided utility isn't the version you need or is lacking certain file type support or introduces any number of other issues that can and do crop up all the time, you'll have to figure out a way around that in your code. Thus, you're coding for your service provider's stack, not for your app anymore. This will of course impact your ability to move to another PaaS provider that might have a different stack or even require moving to an IaaS solution where you have control over your own stack.
Of course, there's the trust issue. You trust your stack provider not only to provide appropriate service levels, but also to avoid making changes that might break your code. At a time when languages and frameworks seem in constant flux, that can be a scary situation.
What version of PHP or Python will your code run on? What happens if your provider upgrades the stack and you get caught because a module you're using is now missing or fails? What if you didn't even know that was happening, and suddenly your app or site is down because someone decided to upgrade from Python 2.7.3 to 2.7.4? (Adrian Holovaty provides an example.) Further, since you don't really control your own database, you're at the mercy of whatever is happening behind the scenes. When (not if) something does break down, all you can do is send email, wring your hands, and hope the magic happens and it gets fixed.
There's also the lack of visibility. When trying to figure out why something isn't working, it's immensely helpful to be able to inspect every part of the process in question to see where the fundamental problem lies. Since you're locked out of the back end on a PaaS, you are working blind in many cases. The code you've written works on your dev platform, but not in production, and when you investigate, the trail leads to a brick wall. Your only troubleshooting method from there is to contact the provider and hope its techs can help. You are at their mercy, with no alternatives. For some, that is an unreasonable trade-off.
As Adrian Holovaty mentions, he's not a sys admin and he doesn't want to be one. He simply wants to write code. That's where these platform services excel -- to a point.
They cater to those who can't or don't want to build their own stack, and they provide a very easy path to launch. They even scale in terms of load as needed, but they don't scale in terms of development. A big app or website will eventually outgrow a stack service. It will get to the point where the continual concessions made to development constraints within the provider's stack will be more onerous than moving everything elsewhere, where more control and flexibility is possible.
When I hear about the great magic provided by PaaS and how it fixes everything, I have a tendency to avoid the conversation. If the app or site in question plateaus at a certain level of functionality and load, it'll probably be fine on a PaaS solution, but if it grows in functionality or popularity, it will inevitably outpace its stack. It will need to be moved elsewhere, and that lesson will have been learned. Huge numbers of projects will have great success on these services, but many projects will fail.
Those who possess the skills to develop their solution on hosted infrastructure services like AWS and Rackspace will find that while it takes a bit more -- truly, not significantly -- time to stand up these services for many applications, the long-term benefits of managing your own stack far outweigh the advantages touted by PaaS providers.
The promise is that you won't have to waste time with all that scary sys admin stuff. You're free to pursue the greatness that is your application without a care in the world about how it will function, deploy, scale, or secure itself. It's magic, more or less.
As many people are coming to understand, there is some legitimacy to these claims -- to a point, and with significant caveats. If you're looking for the quickest and easiest way to get a simple Rails or Django app up on the Web, these services are definitely the way to go. Fire up a stack, and
git pull your code; with (ideally) a small
amount of adjustment, you're up and running in a few minutes. It's once
you try to move beyond the high and tight walls of the provider that you
immediately run into problems, and those problems may indeed prove
intractable.Many services claim they avoid lock-in because they're standards-based, and thus you can move your code anywhere. This may be true on one side, but the other side is that you're locked into what the service provides.
If you need certain packages or libraries that aren't offered, you may find yourself in a corner, in which case you not only have to develop your code to function as intended, but you have to do so within the confines of the stack supplied by the service provider. If a provided utility isn't the version you need or is lacking certain file type support or introduces any number of other issues that can and do crop up all the time, you'll have to figure out a way around that in your code. Thus, you're coding for your service provider's stack, not for your app anymore. This will of course impact your ability to move to another PaaS provider that might have a different stack or even require moving to an IaaS solution where you have control over your own stack.
Of course, there's the trust issue. You trust your stack provider not only to provide appropriate service levels, but also to avoid making changes that might break your code. At a time when languages and frameworks seem in constant flux, that can be a scary situation.
What version of PHP or Python will your code run on? What happens if your provider upgrades the stack and you get caught because a module you're using is now missing or fails? What if you didn't even know that was happening, and suddenly your app or site is down because someone decided to upgrade from Python 2.7.3 to 2.7.4? (Adrian Holovaty provides an example.) Further, since you don't really control your own database, you're at the mercy of whatever is happening behind the scenes. When (not if) something does break down, all you can do is send email, wring your hands, and hope the magic happens and it gets fixed.
There's also the lack of visibility. When trying to figure out why something isn't working, it's immensely helpful to be able to inspect every part of the process in question to see where the fundamental problem lies. Since you're locked out of the back end on a PaaS, you are working blind in many cases. The code you've written works on your dev platform, but not in production, and when you investigate, the trail leads to a brick wall. Your only troubleshooting method from there is to contact the provider and hope its techs can help. You are at their mercy, with no alternatives. For some, that is an unreasonable trade-off.
As Adrian Holovaty mentions, he's not a sys admin and he doesn't want to be one. He simply wants to write code. That's where these platform services excel -- to a point.
They cater to those who can't or don't want to build their own stack, and they provide a very easy path to launch. They even scale in terms of load as needed, but they don't scale in terms of development. A big app or website will eventually outgrow a stack service. It will get to the point where the continual concessions made to development constraints within the provider's stack will be more onerous than moving everything elsewhere, where more control and flexibility is possible.
When I hear about the great magic provided by PaaS and how it fixes everything, I have a tendency to avoid the conversation. If the app or site in question plateaus at a certain level of functionality and load, it'll probably be fine on a PaaS solution, but if it grows in functionality or popularity, it will inevitably outpace its stack. It will need to be moved elsewhere, and that lesson will have been learned. Huge numbers of projects will have great success on these services, but many projects will fail.
Those who possess the skills to develop their solution on hosted infrastructure services like AWS and Rackspace will find that while it takes a bit more -- truly, not significantly -- time to stand up these services for many applications, the long-term benefits of managing your own stack far outweigh the advantages touted by PaaS providers.
Hello, my name is Mohd Azahar. I'm a self-employed Pivrate from the India.
No comments:
Post a Comment