Skip to end of metadata
Go to start of metadata

This is what we do in the implementation phase:

Set up remote access to the customer's on-premise instance

The customer gives access to WSO2 to manage the data center in the customer's environment. The VMs, servers, and operating systems should be made available by the customer according to the infrastructure needs given by WSO2 (e.g., minimum memory). WSO2 is responsible for setting up WSO2 products in the given servers, monitoring the servers, setting up applications etc.

We can identify two ways in which WSO2 can access the servers in the customer's data center as depicted in the diagrams below:

  • Access using a bastion host with WSO2 coorporate IP addresses in the firewall allowlist
  • Access using a customer-provided VPN (Client Server VPN)

Set up the environments

Click here to download a responsibility/accountability matrix for the list of tasks involved in setting up and managing the environments.

For additional services, the customer can purchase WSO2 Support.

Implement monitoring and alerting

  • Monitoring dashboards: WSO2 hosts monitoring services and collects statistics about resource utilization (i.e., disk, CPU, memory, and JVM heap usage) and application health. All statistics collected are presented using  dashboards. WSO2 requires direct access to all monitoring dashboards, and will grant read-only access to the customer upon the customer's request.
  • Application monitoring: WSO2 product runtimes are monitored by the WSO2 Operations team. WSO2 is not responsible for monitoring the  services deployed on top of the WSO2 product runtimes. They must be managed by the customer.
  • Alerts and notifications: WSO2 requires an email server with SMTP Authentication enabled to send direct email alerts and notifications to other servers. If the customer cannot provide an email server, WSO2 uses Amazon Simple Email Service (SES). We need support from the customer to verify the domain and set up DomainKeys Identified Mail (DKIM) which is an email validation system designed to detect email spoofing.  

    The monitoring and alerting implementation is depicted in the diagram below:

  • Diagram: Monitoring and alerting implementation

If the customers wants to synchronize their monitoring with that of WSO2, the operations teams from both sides need to agree on certain technical requirements such as additional agents that must be installed on hosts, how to expose dashboards to other networks, how to send alerts to additional email addresses and phones etc.  

Implement backup and disaster recovery

<Coming up soon>

Manage users and permissions

  • The WSO2 operations team should have accounts with admin privileges to the Linux servers and provide read-only access to the customers upon request. 
  • If WSO2 is connecting to the customers data center through a VPN, the customer has to provide VPN accounts to the WSO2 operations team.

Manage environments and artifacts

Artifacts are resources such as scripts, patches, updates, and services that run on top of the WSO2 products. 

  • All non-production environments (e.g., Dev, Test, Pre-Prod, etc.) should be architecturally identical to the production environments.
  • WSO2 can set up non-production environments, reset, and upgrade them upon the customer's request.
  • In case of a migration or an upgrade, the customer and WSO2 account manager are to decide how to handle the migration of customer-specific data and any custom codes.
  • WSO2 does not monitor and take backups of non-production environments. If there is an issue in a non-production environment, the customer is expected to open a hosting incident in the bug tracking system.
  • The customer is responsible for storing, versioning, updating, removing, testing and verifying artifacts in the non-production environment.
  • The customer hands over tested and verified artifacts to WSO2 to be deployed in the production environment.
  • WSO2 ensures the security and availability of the artifacts deployed in the production environment.
  • WSO2 is responsible for storing, versioning, updating and removing artifacts in the production environment.
  • WSO2 installs software patches and upgrades WSO2 products upon the customer's request. Security patches provided by the OS vendor are installed automatically.

Manage logs and backups

WSO2 manages the following types of logs:

  • Audit logs: These are generated by the Linux audit daemon and capture all important/privileged system activities.
  • Application logs: These are WSO2 Carbon-level logs that capture all activities related to WSO2 Carbon servers. Carbon is the base platform on top of which all WSO2 products are built.
  • System logs: These are Linux syslog and the auth.log files.

Note the following:

  • WSO2 uses the Amazon Cloud Watch service to collect and manage logs.
  • All log types mentioned above are stored in a private Amazon S3 bucket. An agent in each host collects and streams log events into the S3 bucket.
  • If the customer has log management and analysis tools in place, WSO2 can forward the logs to the customer.
  • WSO2 stores logs onsite for 30 days and then archives them to Amazon Glacier Vault.

Diagram: Managing logs and backups

Hand over the environments

WSO2 is to hand over the production environment to the customer with:

  • URLs of the WSO2 products deployed in the Managed Services.
  • Credentials with admin privileges to access the Management Consoles of the WSO2 products.

Tip: Note that WSO2 can facilitate the following upon the customer's request:

  • Arrange a third-party consultant to carry out penetration tests.
  • Provide reports and dashboards on the production environment.
  • Arrange trainings and workshops for the customer.
  • Provide read-only access to the monitoring dashboards and the log viewer.

Next, go to Support and Maintenance.

  • No labels