Overview¶

Deploying an PSS®X platfrom application is not different than deploying any .NET or ASP.NET Core application. You can deploy it to a cloud provider (e.g. Azure, AWS, Google Could) or on-premise server, IIS or any other web server.

However, there are some topics that you should care about when you are deploying your applications. Most of them are general software deployment considerations, but you should understand how to handle them within your PSS®X based applications.

Single¶

Consider an application deployed as a single instance.

The following deployment scenarios were targeted when developing the application:

• Single "under the desk" windows machine
• Data Center

Single "under the desk" windows machine¶

PSS®X platfrom application is based on client-server architecture. Although it may be possible to use a single windows machine as both a client and a server, it is NOT targeted as deployment scenario.

Each feature offered on the PSS®X platfrom application is a bounded context according to the DDD software development approach. bounded context can be hosted independently for development and testing purposes.

By taking advantage of the independent hosting capability of bounded contexts, a fast feedback cycle can be created between co-innovation partners and developers.

For this purpose, each module and application project can have delivery.

The positives and negatives of using delivery folders are stated below;

Positive:

• doesn't require fully blown PSS®X platfrom application.
• easy to run with powershell scripts.

Negative:

• co-innovation partner must have the docker desktop engine and have access to the docker-compose.yml file which is prepared by the developer.
• registry.gitlab.com is part of gitlab.com repository co-innovation or customer may need have a business agreement.
• since the development is carried out on the Windows operating system, all scripts are Windows compatible.

Data Center¶

The single version of the PSS®X platfrom application should be preferred in the following cases;

• the customer has limited physical resources such as data centers,
• horizontal expansion is not possible,
• the customer's IT operation capabilities are limited.

The positive and negative aspects of the most basic deployment scenario are listed below;

Positive:

• deployment can be customized easily by the I&S team.
• it is simple to install and manage, only consist of Backend Api, UI (MVC or Angular) and IAM.
• operation cost is more lower compared to clustered deployment.
• it does not require any infrastructure other than Redis, RabbitMQ and MSSQL database engine.

Negative:

• in case of any application or server failure, the entire system may become inaccessible.
• services cannot be expanded horizontally.

Clustered¶

Clustered deployment is the way of running multiple instances of your application concurrently in a single or multiple servers. In this way, different instances can serve different requests and you can scale by adding new servers to the system.

The following deployment scenarios were targeted when developing the application:

• Private Cloud
• AWS, Google or Azure Cloud Account

Private Cloud¶

Due to the domain we operate in, our customers are responsible for managing critical infrastruces this causes many customers to hesitate to use their data in a public cloud. Security or governance issues force organizations into using a private cloud. Certain countries require that the application data pertaining to critical infrastruce in that locale remain within the country. There may be conditions where internet connection is limited or non-existent. Since the competencies and existing infrastructures of customers can be very diverse we have to avoid lock-in certain technologies as much as we can.

This type of scenarios requires certain delivery team.

This clustered version of the PSS®X platfrom application can be preferred if customers have dedicated an IT unit or willing to get support from certain delivery team.

Positive:

• highly flexible and scalable.
• high availability and resilient to application errors.

Negative:

• requires team and expertise to manage deployment and operation.
• it requires certain 3^rd party infrastructure services and a team that can manage this type of deployment.

AWS, Google or Azure Cloud Account¶

In cases where customers who are they willing to upload their data to the certain cloud provider, we may need to deploy the PSS®X platfrom application on a different provider other than the AWS we use for development. Using any AWS dependent service within the X source code may lead to customer loss. PSS®X platfrom application should be cloud agnostic.

Both single and clustered versions of PSS®X platfrom application versions can be preferred. The demands from the customer will clarify the choice.

Unless there is a special request, the multi-tenancy feature will be disabled of the platform.

GridLab Infrastructure¶

Shared Application (multi-tenant) on AWS Cloud Account¶

Both single and clustered versions of PSS®X platfrom application supports multi-tenancy. Each customer can be manage with single deployment. Infrastructure requirements (like Keycloak, Redis, Kafka, RabbitMQ very similar with others) can be shared with others. These infrastructures can also be managed by CLO teams.

This clustered version of the PSS®X platfrom application needed for scability and high availability.

Positive:

• highly flexible and scalable.
• high availability and resilient to application errors.

Negative:

• requires team and expertise to manage deployment and operation.
• requires AWS managed services.

High level architecture¶

High-level elements of the architecture that’s employed by this PSS®X platfrom application. Below, you’ll see each of the layers that are part of the PSS®X platfrom solution.