Building ELZ’s (Enterprise Landing Zones) in OCI


Landing Zone or Enterprise Landing Zone refers to the implementation of cloud building blocks ready to be operated in production workloads by following a set of methodologies and best practices that helps in the adoption of the constantly growing capabilities provided by cloud vendors.

Cloud resources

SaaS, PaaS and IaaS (XaaS), networking, data and storage:

XaaS

PaCloud resources are provided by your cloud vendor in the 3 different delivery models

  • X=S: Software as a Service (SaaS) are cloud services completely managed by you cloud provider, typically metered by the name of users
  • X=P: Platform as a Service (PaaS) are services partially or fully managed by your cloud vendor, typically metered by units such as number of processors, disk capacity, bandwidth, transactions per period and the like
  • X=I: Infrastructure as a Service (IaaS) are cloud services managed by you with a metering model based in number of processors, disk capacity, bandwidth, transactions per period and the like

Nerworking

  • Define the different virtual networks
  • Configure virtual firewall (security lists)
  • Configure routing
  • Configure dns
  • Configure VPN and MPLS connectivity
  • Design and configure local peering between virtual networks in the same region
  • Design and configure remote peering between regions, specifically for DR or geographic distribution of load
  • Configure health checks to endpoints
  • Configure policies for load balancing and distribution of load between different availability domains and or regions
  • Configure protection of services with WAF
  • Configure load balancers

Storage

  • Identify the different qualities of disk storage provided by your vendor
  • Create block disk for compute instances
  • Create object storage buckets for several purposes like backup, archiving, big data landing zone, etc
  • Create shared file systems (NAS)
  • Create high performance clustered shared block disk for high performance computation
  • Define policies for archiving, retention and deletion of data in object storage

Data

  • Identify your sources of data
  • Design the high availability policies for your databases
  • Configure database replication between regions and cloud vendors
  • Identify the different options provided for storing data such as relational, json, XML, CLOB, binary, AVRO, etc..
  • Configure backup & restore procedures
  • Design and configure landing zones and data lakes and select the technology for implementing them

Business continuity & devops

In this chapter you will decide thing like:

  • the regions in which you will operate
  • the availability domains in which you’ll deploy artefacts
  • the high availability topology of your architecture
  • disaster recovery approach, preferrably between regions or even cloud vendors
  • backup policies
  • recovery procedures
  • interoperability between cloud vendors, if possible
  • patching procedures
  • software upgrade
  • ci/cd and devops policies and procedures
  • Content repository for documents and procedures

Other important aspects:

  • monitoring
  • cost control
  • tagging

Security & Identity

In this chapter you will do:

  • Define your primary identity provider (IdP)
  • Identify all the Service Providers (SP’s) in the picture
  • Configure federation between Identity providers and Service Providers
  • Configure Single Sign On (SSO)
  • Define password policies
  • Configure Multi Factor Authentication
  • Create groups and dynamic groups
  • Define the mechanisms for users provisioning including self service if needed
  • Configure synchronisation of identities between master and secondary IdP’s
  • Configure identity policies depending on the types of users interacting with the cloud
  • Configure a federated SSO with your on premises Identity Management System if needed

Governance

Compartments, policies, groups and admin users are the 4 concepts that OCI provides to create a secure, well structured and easy to manage cloud environment.

  • Decide and depict the structure for compartments: flattened or hierarchical?
  • Depict the names of the groups of users for administration purposes such as networking, systems, dba’s, middleware, edge networking, security, identity-management, etc
  • Define the authorization mechanism by defining policies that defne who can access which resource and how.  A policy simply allows a group  to work in certain ways with specific types of resources  in a particular compartment
  • Define naming standards for all the concepts

Automation

Consider thing like:

  • Use automation from the beginning
  • Avoid the temptation to create things with the portal dashboard unless you are prototyping
  • Define or integrate a solution for the whole inventory of assets
  • Use terraform for cloud infrastructure creation/update/destruction
  • Define the inventory for artifacts (terraform files)
  • Use ansible or similar tool for software
  • Define the procedures for CI/CD of the IaC code
  • Provission environments for testing the IaC code
  • Use the CI/CD environment provided by each cloud vendor
  • If you are doing hybrid or multicloud or both deployments, select a central repository for code, perhaps in another cloud…
  • Automate the start/stop cycle of cloud resources, if possible, depending on SLA’s and utilization
  • Create IaC procedures for recovering a complete landing zone from scratch if possible
  • Send alerts when automatisms fail

🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.