Designing enterprise architecture is a tough job at any scale. It requires wearing numerous strategic and tactical hats across business and technology subject matters. And, on top of that, days are often filled with never-ending meetings where your mood can be surprisingly dictated by participants’ virtual backgrounds–from tranquil beaches to Brady Bunch.
Cloud computing has added interesting wrinkles to the role of an Enterprise Architect (EA). Whereas prior years were focused on data center layout and infrastructure deployments, modern times have pivoted towards an entirely new way of constructing services. Today’s challenges combine a heavy mixture of cloud-native applications, continuous integration and delivery pipelines, API contracts, tag-based governance, service meshes, and other developer-centric frameworks being stitched into on-premises environments to create a hybrid cloud.
From Infrastructure to Platforms
I consider cloud a sunset for infrastructure engineering and dawn for platform development. EAs are asked to evaluate migrating “old but financially relevant” on-premises infrastructure and applications into the cloud. Many of these solutions carry baggage from years of updates and redesigns. Getting them to play nicely with the hip, shiny cloud-native applications and services is a golden opportunity.
Paying down technical debt or removing some oddball design created by an employee 15 years ago described as “here there be dragons” is a good thing. And in those scenarios, I’m always excited to move an application to the API candy-store in the sky. “Sounds great,” you may exclaim, “but where do we start?”
Rubrik Proven Architecture
Design documents are the language of architects. We use them to clearly convey stakeholder requirements coupled with constraints and assumptions. The real value, however, is in the why behind each design decision. This includes the available design options, the justification for the option selected, knowing which design qualities were affected, and mitigating intolerable risk.
I’m stoked to announce the release of our Rubrik Proven Architecture for Cloud-Native Protection in AWS. This technical paper is written from the perspective of an Enterprise Architect working for the super chic and affluent Zaffre Fashion Group (we’ll just call it Zaffre) as they tackle the deployment, management, and protection of their on-premises application into AWS.
While Zaffre may be fictitious, the paper is based on a field-tested design that closely mirrors a real enterprise environment from successful Rubrik customers. Each design decision is backed by business requirements, existing constraints, and the why behind each option selected. We’ve also provided working infrastructure-as-code samples, when applicable.
Design Scenario
One of Zaffre’s business units, Mabel, is taking a phased approach to re-platforming their flagship application, Mabel eCommerce, onto the AWS Cloud. Their plan is to migrate the three-tier application largely as-is in the short term. Later, they will modernize the application using additional cloud-native services.
Based on customer demographics, Zaffre selected the AWS Oregon region (us-west-2) as a target for their first phased rollout of Mabel eCommerce. The company plans to direct web traffic from that region into the AWS Cloud to handle customer requests. After several stakeholder meetings, the requirements, constraints, and assumptions required to form the necessary designs have emerged.
Conceptual Design
Rubrik’s enterprise customers often ask for a specific set of deliverables when constructing a robust design with Rubrik Polaris, our SaaS platform, to manage and protect their AWS investments. Thus, we have made sure to include high-priority items in the design:
- Ensure that backup data never leaves Zaffre’s corporate AWS account(s).
- Protected Amazon EC2 instances should meet or exceed defined RPO and RTO goals.
- Backup data is stored in the local AWS region for fast recovery coupled with replication to a non-local AWS region for disaster recovery.
- Provide an excellent user experience with global search across all current and previous states of the backup data, including files and folders.
- Safeguard backup data to meet long term retention needs associated with PCI compliance.
This paper focuses on the application tier of Mabel eCommerce, which has been deployed onto Amazon EC2 as shown below:
Each instance in the application tier is pieced together using infrastructure-as-code with a specific naming convention, tag structure, and protection schema. This dovetails nicely into Rubrik’s Polaris SaaS platform to ensure that all functional requirements are delivered at or above the qualities necessary to consider this design a success.
Logical Design
Rubrik Polaris is able to surround the Mabel eCommerce application without any material changes to the application layout.
- SLA Domains are mapped to the product manager’s service level agreement, including the frequency of backups, data retention period, and disaster recovery.
- Tag Rules are leveraged to connect SLA Domains to AWS resources using new or existing AWS tags.
- The Polaris platform provides protection, replication, indexing, and recovery for the instances, volumes, files, and folders that comprise Mabel eCommerce without the need for long-running compute instances.
- Instances with a temporary volume attached will exclude protection for that volume without needed to alter the SLA Domain or protection workflow.
Summary
The release of our Rubrik Proven Architecture for Cloud-Native Protection in AWS provides a common reference architecture among Enterprise Architects. This paper clearly conveys stakeholder requirements and explains the why behind each design decision. This includes the available design options, the justification for the option selected, knowing which design qualities were affected, and mitigating intolerable risk.