The global IT landscape is undergoing a rapid digital transformation. This has impacted areas such as software development, software testing, software deployment, underlying infrastructure, business processes, ways of working, and mindset. With Cloud becoming the mainstay of digital transformation solutions for user-facing applications, enterprises are increasingly looking for quick Cloud adoption methods. In fact, they are willing to invest in Proof of Concepts (PoCs) and transformation projects to kick start their Cloud journey. Although Cloud requires no introduction, a confusion still persists regarding private, public, IaaS, PaaS, and SaaS definitions. This article discusses some important aspects of platform and infrastructure touch points in reference to applications intended to be developed, deployed or migrated to PaaS. Also, the objective of this article is to address the concerns of application teams before they ﬁnally decide to adopt PaaS and help build a checklist they can follow to avoid last minute hurdles.
You Think Migrating To PaaS Is Simple?
Think Again. Migrating to a PaaS platform is considered simple, with the application of middleware framework for developing, deploying, and running Cloud native applications. A person with limited knowledge could be misled to choose PaaS as a preferred application for deployment platforms. This could prove disastrous as the key elements of application development ecosystem can be easily missed out. Similarly, not everything can be deployed on PaaS. In this article, we will discuss some common touch points which are essential for application development, deployment, and migration to PaaS.
PaaS as a solution started with the concept of making key services available on public Cloud for end users who were trying to execute quick software projects. It required them to test their business ideas without investing in infrastructure and platforms required for PoCs. Soon, it became a popular way of building and distributing Cloud native applications. Open source Cloud Foundry based PaaS software framework was accepted as private PaaS Cloud for developing.
The key components of private PaaS are containers that host applications and orchestration layers to manage the containers, and a few more software processes to handle routing, scheduling, monitoring, and logging requirements of the platform. Another essential element of PaaS software framework is to provide service catalog for supported services. Inherent support for DevOps philosophy and easy integration with open source tools set makes it a preferable platform for agile and cloud-native application developers.
Not all types of applications can be migrated to a PaaS platform, and a signiﬁcant change would be required before migration is planned to the PaaS environment.
Private PaaS Offerings and Frameworks
Now, let’s shift our focus to private PaaS solutions and frameworks. We will discuss them under the following three categories:
Services used by applications
Application deployment architecture
Stack Dependency: PaaS in Linux Containers:
The choice of application technology plays a crucial role in PaaS solution selection as well as the utilization of the PaaS framework’s full potential. Cloud native applications include non-data intensive and user interactive applications. User-facing applications need dynamic load-handling capability and are the best ﬁt to beneﬁt from Cloud features like elasticity. New Cloud native application can be designed keeping the 12-factor application development guidelines in mind. The legacy application would require extensive analysis to further qualify application for PaaS. Applications deployed in PaaS are meant to run in containers. These containers are primarily Linux containers, and each PaaS vendor has created their own version of containers to run the applications. For instance, popular open source Cloud Foundry PaaS uses Garden containers, and Red Hat supported Openshift uses Docker as a container.
Consider the following questions before your legacy application migration to PaaS: Is your application using OS native features for business logic? Is your application having a dependency that can't be separated from the main business logic? Is your application compute intensive? Does your application use enterprise application server native features? Does your application component use native ﬁles system for IO?
If you answered ‘yes’ to most of them, then your application would need signiﬁcant architectural changes. Most of the private PaaS framework support is limited to out-of-the-box language and frameworks.
But what about the support of languages and framework or libraries that are not natively supported in PaaS products? Support for these can be added through build-packs. However, do keep in mind that future support for these or your custom changes may not be there with vendors. The process of build pack development is unique for each PaaS solution. This may need skills and adequate language understanding. It’s a good idea to join the developer for clues, inclusions, and exclusion before you start to build pack development from scratch.
Build and Deployment: Once the application is designed and coded, all its dependent components and services need to be linked. In the case of cloud-native applications, this is done prior to the deployment of applications in PaaS-based containers. The CI/CD pipeline would need to be built for the application in PaaS. Cloud native application by nature would need very frequent updates. With time, you may need to update the dependent libraries also. This would require proper version control in the system. Versioning is essential to keep track of containers and applications deployed in the production.
Is your team using Jenkins, GIT, Maven, and Ansible for versioning, build, and deployments? A team can use any such tools that meet the objective of a full control on versions, smooth integrations, and deployments. See how much effort is required to move current build, release, and deployment processes for current applications to target the PaaS environment.
Cloud Foundry and other popular PaaS platforms provide built-in platform services to manage end-to-end development and QA lifecycles.
Services Used By Application
PaaS is all about using services provided by the platform to quickly launch applications that fulﬁll specific business requirements. While public players in PaaS have a plethora of services that are hosted on the public Cloud, it is a different case in private PaaS with very limited choices. Services providing out-of-the-box solutions in private PaaS products are limited. For application-migration, it’s very important to map the current services with the available out-of-the-box services in PaaS. A common set of services is inbuilt in PaaS framework in one way or the other. The services include logging, basic monitoring, caching, service discovery, and lookup to name a few.
The next step involves listing down all critical services used in applications and get the mapping from target PaaS. Is this covering all the aspects? If not, then we will have to create missing services in a PaaS supported format. This requires the additional skill set of scripting in PaaS product supported languages. Some services would need extensive manipulation in the orchestration module of PaaS framework for proper support. For instance, if session persistence is not supported natively by the PaaS product, then it would need a lot of re-engineering to introduce this concept. Will you be interested in making those changes or would you rather look for solutions outside the PaaS product domain?
Similarly, Cloud Foundry and Openshift provides open source SQL products as servers. All mainstream non-SQL database areas are also supported in private PaaS software. It’s important to note that DB is always kept outside the orchestration domain of the PaaS platform and not provided in the container format in most of the cases.
Architecture: The architecture of application varies from single server solutions such as FoxPro, VB or C++ with MS-Access or MySQL as database, to multi-layer EE distributed applications based on MVC architecture. An in-depth study of the architecture is required and the metrics related to capacity, the number of users, upgrades frequency, and vendor support would play an important role in helping to decide the future stack. This evaluation will help in determining the PaaS migration qualifying criterion. VM-based solutions with close integration and PaaS solutions might be applicable for applications that can’t be containerized.
HA/DR: With HA/DR, some questions are raised – how is high availability ensured and how is DR conﬁgured? Is the application critical enough and requires DR? How many levels of HA conﬁgured in the current installation are external and internal dependencies? High availability is ensured in PaaS products at various levels. This is a key feature of PaaS and is implemented at the container level, orchestration level, and infra level. The concept for availability zones is used to ensure HA.
Dependencies: Applications having external and internal dependencies need to be reviewed on PaaS ﬁtment. Some applications are dependent on multiple external feeds to perform business logic. Managing these downstream feeds in the container world would require a careful analysis of the nature of the data. This may entail speciﬁc memory and compute for data processing and dedicated bandwidth for incoming data. How will this be handled by PaaS containers? While replicating this exactly will be difﬁcult in PaaS, you will need to come up with a workaround to handle these situations.
Session Management: The old world applications were developed during session management. They were subsequently handled internally via application logic and the session data was stored in session beans. Session management calls for a different approach as PaaS natively doesn’t support session management in containers. Containers are ephemeral in the PaaS framework, and if lost, will result in data loss. Session management is handled differently in various PaaS solutions such as storing data in the database or using persistent storage.
Application Touch Points during Migration Planning
Caching requirements in application
Question the current caching architecture: Can this be handled with an external tool? What is the frequency of cache updates and other information?
Current integrations with other applications and tools
Consider premise applications, web services, messaging or broker integrations. Also, consider integrations with master data source and mainframe integrations to name a couple. Question: Is the application using any shared service?
Question: Is your application using Serialization? If yes, change the code for serialization in order to ensure compatibility with the target.
Web, UI dependency or architecture modiﬁcation in current modules
For Web, UI dependency or architecture modiﬁcation, consider the following while planning:
Technology used for forms, events handling of business layer and data layer, caching conﬁgurations Web Server Conﬁgurations: Any non-standard module used in Webs Server Conﬁgurations
Multiple web server for reverse proxy or cache hosting, - Static content and dynamic content placement. - SSO conﬁgurations. - SSL and other conﬁgurations. - Associated background services - any dependency?
Business layer dependency
Question: Where is the logic residing? Are you using JAVA beans? How will this be handled in PaaS?
Business logic implementations
Implementations to be considered while using business logic:
J2ee beans location and dependency on bean containers, .NET resource mapping, IIS conﬁgurations.
App server features used, native call used of app server
App server conﬁgurations (clustering, OS-based calls, JDK conﬁgurations on GC, and MEM usage)
Explore possibility to convert code in spring boot from EJB
Implementations to be considered while using business logic:
J2ee beans location and dependency on bean containers, .NET resource mapping, IIS conﬁgurations. • App server features used, native call used of app server
App server conﬁgurations (clustering, OS-based calls, JDK conﬁgurations on GC and MEM usage)
Explore the possibility to convert code in Spring boot from EJB
API usage and exposer
Find out more details around:
A-Synchronous or synchronous
Other key conﬁgurations
API security conﬁgurations and more.
Web services / SOA calls
Type of web services and locations
Access and security mechanism
Native services tied with the OS or app server dependency
Third-party Web services, and how are they consumed?
What will be the equivalent possibility in target PaaS solution?
So, if you are planning to design and develop a new application for Cloud, there is no better solution than PaaS. There are ample examples around PaaS ﬁtment and not much debate is happening around that. If you are planning legacy application migration, then you have to carefully weigh commercial and technical viability of the solution.