Question
Genworth Financial
US
Last activity: 16 May 2018 8:36 EDT
One big Pega environment or an environment for each major application?
I am looking for the opinion of architects on this topic.
We are developing multiple major applications in Pega. Each application has 500 users. We are thinking about creating multiple Pega environments (separate application and database servers), one per major application.
Some of our concerns about having one environment hosting all applications:
- Development teams developing conflicting code
- Deployment conflicts
- Upgrading all applications at the same time when upgrading Pega
- Applications competing for resources
- Performance issues.
Would anyone mind sharing their opinion or experience on this topic?
Tata Consultancy Services
US
what kind of design does this application have -Class structure specifically? IF there are dependencies at the organizational and unit level where the re-usable components need to be shared then you would NOT like to segregate the physical resources (DB, app servers); rather than that ,you would have to handle the requirement adding more infrastructure for the various environments (JVM's and nodes to environments).
To answer your concerns:
what kind of design does this application have -Class structure specifically? IF there are dependencies at the organizational and unit level where the re-usable components need to be shared then you would NOT like to segregate the physical resources (DB, app servers); rather than that ,you would have to handle the requirement adding more infrastructure for the various environments (JVM's and nodes to environments).
To answer your concerns:
- Development teams developing conflicting code - can be handled using branch development approach; segregating developer AG's
- Deployment conflicts - Again can be handled using branch development and consequent code merge processes.
- Upgrading all applications at the same time when upgrading Pega - shouldnt be an issue in multi nodal environment.
- Applications competing for resources - the infrastructure (adding nodes and JVM's) has to be planned correctly
- Performance issues. - The development ,System Integration ,QA wont have the production user levels? If you want to exactly simulate the load of a production system, you should have a separate performance testing (PT) environment identified. Although the performance issues coming out of code can be handled by adhering to Pega guardrails and/or following simple design approach which would help you out handling major issues going forward in the development/ qa time frames.
Techmahindra
GB
We are using Pega at one our customer premises for about 5 years, and whenever there is a hardware crunch we used to co-host applications. As a result, our development environment has 3 big applications on same tomcat node. The only disadvantage with this approach is that whenever there is a memory or CPU leak, its hard to find. Issues like this bound to happen whenever a system is under development and if it happens then it blocks all the pega team not just the problematic area. If you are new to Pega or developing a new application, then better choose new server per application.
The advice would be to atleast run multiple tomcat nodes (any server of your choice) on different ports leveraging same hardware and there by achieving full advantage. Very rarely, you need a system restart.
Randstad Technologies US
US
you can go cluster infrastructure managemnt.in one cluster there can be many Nodes..jvm will be different but DB will be same. So that your processing time will be faster as ur are uisng different jvms.
- Development teams developing conflicting code --Can be achived using branching based on team
- Deployment conflicts :if all teams work for same application its fine.you can achive using rule set managemetn
Toyota Financial Services
AU
In my opinion, an application split is a cleaner and manageable approach. However, please ensure you have considered the following advantages and disadvantages before deciding on a final design.
The application split provides following advantages:
- Upgrades and any cloud migration can be handled at each application level
- Less regression impact
- Flexibility in planned outages; High availability
Some disadvantages:
- Additional governance needed for development and sync enterprise and other shared layers
- When one or more of the splits migrated to a newer version, enterprise sync can be became an issue
- Multiple parallel TEST and DEV env's needed, thus in "some cases" increase in Infrastructure costs
- Common users between each application need to switch URL's or use federated case management. FCM might not be effective for all business use cases.
However, the following points can be managed with equal, ease and efficiency in both monolithic and split applications when a team takes full advantage of Pega OOTB CI/CD features
In my opinion, an application split is a cleaner and manageable approach. However, please ensure you have considered the following advantages and disadvantages before deciding on a final design.
The application split provides following advantages:
- Upgrades and any cloud migration can be handled at each application level
- Less regression impact
- Flexibility in planned outages; High availability
Some disadvantages:
- Additional governance needed for development and sync enterprise and other shared layers
- When one or more of the splits migrated to a newer version, enterprise sync can be became an issue
- Multiple parallel TEST and DEV env's needed, thus in "some cases" increase in Infrastructure costs
- Common users between each application need to switch URL's or use federated case management. FCM might not be effective for all business use cases.
However, the following points can be managed with equal, ease and efficiency in both monolithic and split applications when a team takes full advantage of Pega OOTB CI/CD features
- Development teams developing conflicting code
- Deployment conflicts
- Upgrading all applications at the same time when upgrading Pega
- Applications competing for resources
- Performance issues.
Thanks
Sandeep P V
Accenture
AU
One scenario that hasn't been mentioned yet is when often changing data instances at the organisation level are consumed by the various major applications.
If org level instances seldom change, for example... a list of countries with properties updated annually (ie. population) then sync'ing instances between multiple environments might be manageable. However imagine a high traffic environment when org data instances are being added, updated and deleted every few minutes. If your major apps rely on that data then you might be better off with one big environment.