There are many reasons customers seek out managed software solutions, especially when complex infrastructure is involved. The benefits of SaaS software have been enumerated many times and a lot of these benefits also apply to GRAX. However, we also understand that some customers want - or need - more flexibility around deployment options, while preserving the value that SaaS applications bring to their organizations. This is where the GRAX Virtual Appliance can help.
With GRAX, customers can fully capture, own, and access all of their historical SaaS application data by simply backing it up or archiving it to their own cloud environment.
With GRAX, customers can:
- Own their data
- Access their data 24/7
- Capture record changes
- Restore a record to an earlier version
- See and process historical versions of all records
Most importantly, GRAX customers can finally evolve from basic data loss recovery to starting to reuse their historical backup data to adapt faster and leverage data value.
The GRAX Virtual Appliance is GRAX, but running inside a public cloud service that your company owns. There are a couple of distinct differences you need to be aware of when using the GRAX Virtual Appliance when compared to the GRAX Fully Managed Runtime service:
- The public cloud infrastructure costs will be billed to you, not GRAX.
- There is a different customer support model here; with more control comes more responsibilty.
- The consumption of resources is dependent on your Salesforce org and your configuration of GRAX. This is not a "one size fits all" deployment model.
- This allows much more flexibility in monitoring of access and application logging.
- Direct access to AWS Cloudwatch and Cloudtrail events for the GRAX deployment. This provides the ability to redirect and process these logs in your existing enterprise logging framework.
- Provides the ability to integrate the GRAX Appliance into any intrusion detection or monitoring frameworks that are already in place in your AWS practice.
- Run a stricter security model than GRAX with bring your own bucket storage. The GRAX Appliance allows the complete control of the network which data transits.
- Improved compliance posture for the deployment infrastructure.
- Automated improvements in the GRAX Appliance over time as GRAX manages this infrastructure on your behalf. We bear the burden of evaluation and upgrades to the latest AWS primitives as they become available.
- Operating in your AWS environment means that your agreement with AWS is how the infrastructure is billed. This allows you to leverage any of the negotiated discounts in place as well as helping meet any annual usage commitments the organisation may have.
The GRAX Virtual Appliance is a managed service inside an AWS account that you own and control. The Virtual Appliance is deployed via CloudFormation templates.
To deploy the appliance, customers will need to provide a fully-qualified domain name, DNS hosted zone, and certificate which take approximately 30 minutes to buy and verify through Route 53. If you have internal requirements around domain registration and DNS management, R53 can support delegated DNS, or be circumvented entirely. Once these requirements are satisfied, the deployment takes approximately 30 minutes to automatically provision through CloudFormation.
GRAX can manage all the deployment, upgrade, and operation tasks just as you would expect from any SaaS that you have in your stack. You also gain an increased level of visibility into the operations as you can now include our application and access logs into your standard Enterprise processes. If you wish to have more control over this deployment, the Virtual Appliance Setup - CLI illustrates how you can deploy GRAX yourself, while utilizing the GRAX support team when questions arise.
The model that we are talking about here is much the same as the GRAX Fully Managed Runtime. In that model, we would create an Account for each individual customer and deploy, operate, and upgrade the service through IAM roles granted to our Control service. The only difference here is that you create the Account for us.
See the details on what we require from an account and role perspective. Simply put, we ask your public cloud admin to create a separate account for GRAX, create a role that is minimally-scoped for installation, and then grant our AWS Account permissions to use that role. This pattern is a well understood and often used mechanism for providing 3rd parties access to your infrastructure.
WARNING: Standalone Account
While it would be technically possible to create this role in an account that you are already operating other services inside, we strongly recommend that you create an empty account for GRAX to operate in.
As we mentioned above, the amount of resources you will consume in this model is largely dependent on the size and scope of your Salesforce org(s) and the job configurations of GRAX once deployed.
At a high level, there are three main cost elements in a deployed GRAX application.
The compute layer will run a single EC2 instance of type m5.xlarge (as of writing retail in us-east-1 is approx 19c per hour). Attached to this is a 500GB general purpose EBS (retail pricing).
2. Object storage
This is an S3 bucket and will vary on a per customer basis. S3 retail pricing is part of this equation, but the variables here also include:
- GRAX configuration. How many Salesforce objects are you backing up?
- GRAX configuration. How often are you backing up your records? Are you doing full backups or incremental jobs?
- Salesforce. How big is your Salesforce instance? How many records do you have?
- Salesforce. Record shape? Salesforce provides an estimate that a record is 2kb in size but this can vary greatly when writing to disk. In short, the shape of your data can influence size in the object store as well.
3. Search indexing
GRAX uses the AWS Elasticsearch service and will, by default, deploy with the r5.large sizing as data nodes, while using c5.large sizing for master nodes (retail pricing). This may be changed with your particular deployment if advised by the GRAX team.
The detailed components documentation will enumerate all the different components that are leveraged with the GRAX deployment.
While having the ability to manage the low level components that make up the GRAX Virtual Appliance enables some of these above advantages, it can often be tempting to start to "tweak the dials" on the moving parts of the deployment. Unfortunately, doing this would result in a GRAX deployment that is left in an unsupported state.
Some examples (though definitely not all) of things that we can't support are:
- Changing EC2 instance types or storage volumes
- Updating the Elasticsearch cluster instance types or configurations
- Modifying any of the networking primitives (Subnets, VPC etc)
- Building applications that connect directly to the Elasticsearch cluster
- Building applications that connect to the Aurora Postgres service (e.g. "using empty space" in this database for other purposes)
- Building applications that rely on the raw data format found in the GRAX S3 buckets
- Adding extra components into the GRAX VPC
The short story here is that we encourage you to actively monitor what we do, but thats about it. "Look, but don't touch" is the order of the day.
If you have any questions on what might impact the supported operations of your service, please contact your GRAX representative or flick us an email at [email protected].
Updated 1 day ago