This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - PaaS basics: Questions and concepts: Read more in this section
- Q&A with Appirio's Glenn Weinstein
- Questions to ask PaaS vendors
- Is PaaS vendor lock-in unavoidable?
Explore other sections in this guide:
Platform as a Service offers advantages over managing your own development infrastructure and allows more time to focus on designing and coding. While PaaS may be the preferred choice for new projects, it may not be a good fit for existing, legacy development efforts.
Here are five things to consider before moving your legacy development projects to Platform as a Service (PaaS).
1. How will you use PaaS?
Different companies have different uses for PaaS to suit their IT environments and goals. First you must figure out how to incorporate PaaS into your organization. Some services allow you to move computation easily to the cloud while maintaining other functions on local resources. For example, Pi Cloud provides an application program interface (API) for copying your local Python code to the cloud and running it there, while your development tools and code repositories can stay local.
Another option is to develop with on-premises resources and test with a PaaS product. This approach is useful when you run a large test suite or need separate instances of shared resources to test properly. You can also move all your development to the cloud by using a cloud integrated development environment (IDE). Review the features supported by browser-based IDEs -- some are lightweight and may not have all the features you may be accustomed to.
2. Do your software development practices and tools fit with PaaS?
If you have developed software using tools such as Git, SVN, Ant or Maven, consider how easy it will be to use those in a PaaS. There aren't many differences between working with a version control system from a PaaS than from your on-premises resources. However, rewriting build scripts is a more substantial task. If you are less formal with your practices or use home-grown tools, consider how those would fit within a PaaS environment and review your access control policies for your code and documentation. Check your PaaS provider's access control mechanism to ensure you can control access the way you need.
Finding a PaaS option that supports your full application stack reduces the barriers to adopting PaaS for development.
3. Do you need to integrate with on-premises resources?
Applications often need to integrate with other apps or shared resources, like enterprise databases. In this case, understand how you will access those resources from PaaS. If you use an in-house application that implements a Web services API and already serves external client applications, you should be able to move to PaaS. If security is a concern and only client applications on a virtual private network (VPN) are allowed to access on-premises resources, test the API from a PaaS early in your evaluation. If you need to implement VPN functionality and your PaaS provider does not meet your needs, you may need to consider an Infrastructure as a Service (IaaS) cloud instead.
4. Is your development stack fully supported?
PaaS offerings have quickly matured from single-language platforms to platforms that support a range of languages, databases and other services. Finding a PaaS option that supports your full application stack reduces the barriers to adopting PaaS for development. For example, if you are developing with Java and use Jenkins for continuous integration, then CloudBees may be a good option. If you need support for Ruby and Node.js, Engine Yard could work. If you're building on the NoSQL platform, Red Hat's PaaS, OpenShift, may be a good choice.
5. What is the development stage?
Where you are in your development process strongly influences the costs and benefits of shifting development from on-premises to the cloud. Typically, the farther along a project you are, the more investment you have in your development environment and tools. As the project progresses, you will need to create more software that must be moved to a PaaS platform, which increases the cost of making a switch.
Moving development of an ongoing project to a PaaS platform makes sense when the advantages of PaaS outweigh the costs and potential time required to make the migration. After moving to a PaaS you are relieved of managing servers, operating systems and other infrastructure. A big payoff can come if you need to scale your application and can avoid time-consuming and challenging engineering issues.
Running your application in a cloud that scales with minimal intervention on your part could save more time and money and is worth the effort of a move to PaaS.
About the author
Dan Sullivan, M.Sc., is an author, systems architect and consultant with more than 20 years of IT experience. He has had engagements in advanced analytics, systems architecture, database design, enterprise security and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail and education. Dan has written extensively about topics that range from data warehousing, cloud computing and advanced analytics to security management, collaboration and text mining.