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
Upgrading all applications at the same time when upgrading Pega
Applications competing for resources
Would anyone mind sharing their opinion or experience on this topic?
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.
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.
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
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.