Environment Strategy and Planning

Document created by anton_damiani Employee on Oct 31, 2016Last modified by Adam Arrowsmith on Dec 14, 2016
Version 14Show Document
  • View in full screen mode

This article provides an overview of Environments and how they can be used to logically separate your runtimes (Atom, Molecule, Clouds) to support stages of your software development life cycle as well as restricting user access.

 

 

Overview

One of the first tasks when setting up AtomSphere is establishing your runtimes. Whether it be in the Dell Boomi Cloud, a local Atom, or a Molecule, how these runtimes interact with the platform is encapsulated by the AtomSphere environment object. Environments can be thought of as logical containers for the runtime. Planning your environment strategy is crucial to establishing your deployment methodology, user security, and your testing environments.

 

Environments play several roles in the platform:

  • Abstraction of the runtime for deployment. Processes are deployed to an environment, not directly to a runtime.
    • Attach Atoms, Molecules, or Clouds and effectively become the container for the runtime.
    • More than one runtime can be attached to the same environment
  • Restrict user access to runtimes using custom roles / segregation for different groups/projects/teams
  • Classify environments as test or prod for purposes of AtomSphere connection licensing
  • Software development life cycle (SDLC) and version control for taking snapshots of your integration configuration
  • Define process configuration variables ("extensions") for processes deployed to a given Environment

 

Considerations for Determining Your Environments

In order to lay out how many environments are needed, consider:

 

  • SDLC stages and other app instances
  • Runtime deployment topology
    • Cloud vs. local/hybrid
    • Multiple data center
  • User access
    • Privileges
    • Segregating projects or regional teams
  • Use-case specific runtimes

 

Software Development Life Cycle

Environments lay out the journey a process will take from initial configuration on the build tab, all the way to production. Processes typically are deployed from the build tab to the initial development environment, then promoted up to other testing environments and eventually to production.

 

Deployment and Version Control

Within the platform, processes are deployed directly to environments, and only indirectly to runtimes. A runtime can also be attached or detached from one environment to another. This allows a new Atom installation (think server replacement) to not cause the loss of deployment version history. These versions, or deployment snapshots, are maintained in the AtomSphere platform and associated with the environment. A process can be deployed to the environment, the Atom detached from the environment, then later re-attached to show the prior version history.

 

Using this, we can setup multiple environments, even if we do not have a separate runtime for each environment. Environments are typically a one to one with an Atom or Molecule installation. However we can have multiple environments setup and only have one runtime setup.Think of maintaining a Regression Testing environment that only needs to be periodically used. The Atom could be resident of the Test Environment but then detached for a period of time to be used in the regression environment, where a different deployment version of an integration resides.

 

Environment Variables

Environments also contain the override variables to be used by an integration, defined by extensions within processes, including endpoint connections. By maintaining environments and using extensions, we can deploy the same code across multiple environments, with connection parameter variables defined at the environment rather than within the process configuration. This allows us to construct environments to meet the requirements of the SDLC - no code changes needed when promoting a deployment.

 

How many instances of an endpoint exist for testing could justify additional environments. If there is only one sandbox and one production, at least two environments are needed. If there is a sandbox, preview, and production tenant, you may wish to maintain three environments.

 

Traditionally, the SDLC landscape would comprise DEV, TEST, and PROD. DEV would be an unstable testing ground, TEST would mirror production and be used for UAT, and then ultimately land in production. Some business requirements require additional environments for regression testing, load testing, etc. These should be factored into your environment landscape and SDLC.

 

Deployment Topology

Hybrid deployments and distributed deployments will also justify additional runtimes, and therefore environments as well. Think of running some integrations in the Dell Boomi Cloud and running other integrations locally in an on-premise Atom for local applications. As companies move to the SaaS space, legacy systems are often still in play. Establishing a local and cloud environment can help during this transition.

 

We can also have distributed deployments, a group of Atoms or Molecules, that all run the same processes and use the same environment variables. Here we are taking advantage of the many to one relationship runtimes have to environments. We can install multiple Atoms or molecules all grouped under one environment. This allows for the same integration to be run on multiple runtimes using the same deployment version and extension variables. Keep in mind with the approach that although deployments are at the environment level; schedules, persisted process properties, passwords, and license usage is all done at the Atom, or runtime level.

 

User Access and Roles

We can define which Boomi users can access that environment. In this way only users with the correct permissions can access the environment, including deployment, process monitoring, or execution abilities.

 

Boomi is a shared platform for configuring your integrations. However some integration requirements deal with sensitive data and may not be accessible to all of your integration builders.

 

Boomi uses environments as a way to control user access to the integration process executing. With custom roles, users can be setup to be restricted to a environment that holds the sensitive integrations. Then only they would be able to execute integrations or see execution history for those integrations that reside there. The runtime restrictions work in tandem with any permission restrictions setup in the custom role (e.g. Build only, process monitoring only). Keep in mind that on the Build tab, all Integration Developers have access to components.

 

Additional runtimes could be required to create isolated environments to control user access.

 

Integration Use Case-Specific Runtimes

Sometimes diverse types of integrations can be grouped according to key patterns. Depending on the nature of your integrations, the runtime configuration may vary and require separate runtimes by integration type. For example batch or ETL processing often has different resource demands than high volume real-time processing. Consequently may decide to segregate these integrations into optimized runtimes for each.

 

Bringing it all together

Let’s a look at a few scenarios to see how our environment landscape takes shape.

 

Basic SDLC

  • For SDLC, we will ideally maintain three environments: DEV, TEST, and PROD.
  • Some of our applications have two sandboxes, some only have one.
  • AtomSphere users have access rights to all integrations however users have different permissions depending on role.
  • Single runtime needed per environment (no distributed runtimes)

 

Recommendation: Three environments to match SDLC.

 

EnvironmentDevTestProd
RuntimeAtomMoleculeMolecule
Role Restrictions
  • Developer: Deploy, Monitor, Execute
  • Developer: Deploy, Monitor, Execute
  • Business User: Monitor, Execute
  • Deployer: Deploy, Manage Extensions
  • Prod Support: Monitor, Execute
  • Business User: Monitor
Endpoint AppSandboxes:
  • App 1
  • App 2
Sandboxes:
  • App 1
  • App 2 (UAT)

Production:

  • App 1 PROD
    App 2 PROD

 

License usage: 4 Test, 2 Prod

 

 

 

Sensitive Data

  • For SDLC, we will maintain at least 1 test environment and production.
  • Only HR developers can access HR integrations. Non-HR Boomi users own other business integrations.
  • Single runtime needed per environment (no distributed runtimes)

 

Recommendation: use separate environment to restrict user access for sensitive integrations vs. non-sensitive.

 

For example, if your SDLC has two only tiers (e.g. test and production) and you want to maintain isolation throughout test and production, you would need 4 environments.

 

Environment

HR Test

HR Prod

Biz Test

Biz Prod

Runtime

Atom

Atom

Atom

Atom

Role Restrictions

HR Developer: Deploy, Monitor, Execute

HR Admin: Promote to Production, set environment variables, view HR executions

Developer: Deploy, Monitor, Execute

Deployer: Promote to Production, set environment variables

Prod Support: Monitor, Execute

Business User: Monitor

Endpoint app

Sandboxes:

  • HR App1
  • HR App2

HR App 1 Prod

HR App 2 Prod

Sandboxes:

  •  App1
  •  App2

App 1 PROD

App 2 PROD

License usage: 4 Test, 4 Prod

 

 

Additional setup:

  • Custom user roles setup per environment.
  • White list sensitive data runtime IP at application level
  • On the Build tab:
    • Folder permissions enabled, and restricted by custom user role
    • For connection components, force extensions (no credentials saved in connector)
    • If credentials must be saved (for browsing), use a separate connection component with dummy data or user permission restricted to schema only (no data), or whitelist IP to Boomi HR server only

 

Hybrid Deployment

  • For SDLC, we will ideally maintain three environments: - DEV, TEST, and PROD.
  • Applications may have multiple test environments, some are in the cloud and some are behind a firewall
  • On premise integrations and cloud based integrations
  • Integrations can be separated by either cloud-to-cloud, or on-premise to cloud.

 

Recommendation: 5 environments. One shared development environment, with separate tracks for on-premise deployment vs cloud deployments.

 

Environment

Shared Dev

Local Test

Local Prod

Cloud Test

Cloud Prod

Runtime

Atom

Atom/Molecule

Atom/Molecule

Boomi Test CloudBoomi Prod Cloud

Role Restrictions

  • Developer: Deploy, Monitor, Execute
  • Developer: Deploy, Monitor, Execute
  • Deployer: Deploy, Manage Extensions
  • Prod Support: Monitor, Execute
  • Developer: Deploy, Monitor, Execute
  • Deployer: Deploy, Manage Extensions
  • Prod Support: Monitor, Execute

Endpoint app

Sandboxes:

  • Local App1
  • Local App2
  • SaaS App1
  • SaaS App2
  • SaaS App3

Sandboxes:

  • Local App1
  • Local App2
  • SaaS App3

Production:

  • Local App 1 PROD
  • Local App 2 PROD
  • SaaS App 3 PROD

Sandboxes:

  • SaaS App 1 
  • SaaS App 2 

Production:

  • SaaS 1 PROD
  • SaaS 2 PROD

License usage: 10 Test, 5 Prod

 

 

Optimizing Specific Integration Use Cases

  • For SDLC, we will ideally maintain three environments: - DEV, TEST, and PROD.
  • Some application overlap between ETL jobs and Real-time jobs
  • ETL integrations and Enterprise Real-time integrations (real time/event-based vs. scheduled/batch. Maybe even a third for very large ETL migrations)
  • Separate environments → separate runtimes → fine tune configuration for specific use cases (high volume & small data vs. lower volume & big data)

 

Recommendation: 5 environments. One shared development environment, with separate tracks for ETL processes and Real-time processes.

 

Environment

Shared Dev

Real-time Test

Real-time Prod

ETL Test

ETL Prod

Runtime

Atom

Molecule

Molecule

Molecule

(w/forked processing)

Molecule

(w/forked processing)

Role Restrictions

  • Developer: Deploy, Monitor, Execute
  • Developer: Deploy, Monitor, Execute
  • Deployer: Deploy, Manage Extensions
  • Prod Support: Monitor, Execute
  • Developer: Deploy, Monitor, Execute
  • Deployer: Deploy, Manage Extensions
  • Prod Support: Monitor, Execute

Endpoint app

Sandboxes:

  • App1
  • App2
  • App3

Sandboxes:

  • App1
  • App2

Production:

  • App 1 PROD
  • App 2 PROD

Sandboxes:

  • App2
  • App3

Production:

  • App 2 PROD
  • App 3 PROD

License usage: 7 Test, 4 Prod

 

 

Conclusion

During your initial AtomSphere setup laying out the runtimes is often a first step. With this, environment features should also be considered to look at how this may affect your deployment scheme. From establishing the change management path, to user access, to unique runtime deployments, understand how environments can help you meet your functional and non-functional requirements.

5 people found this helpful

Attachments

    Outcomes