AWS Feed
Why a Cloud Automated Operation Model is Key for Enterprises Moving to AWS
By Juan Alvarez, Cloud Sr. Advisor – DXC Technology
By Diego Garcia, Manager, Partner Solutions Architect – AWS
By Pierre Merle, Partner Solutions Architect – AWS
 |
A transformation step is key to achieving the cloud strategy benefits for organizations moving or implementing workloads to the Amazon Web Services (AWS) Cloud.
According to Gartner, workloads can be more expensive in the cloud unless they are transformed to use the services that optimize their operation. Keeping up with the dynamic evolution of cloud services requires extra efforts and new skills that make some organizations self-conscious about using cloud services.
Organizations that adopt the cloud without transforming their operation model may not realize the full benefits. With time, they may even face the necessity of embarking on a broad optimization program to control unexpected costs. This affects both traditional and cloud-native architectures alike, with respect to the transformation of their operations.
IT organizations need to transform traditional workloads and operation methods to be native dwellers of the public cloud. This does not come without cost and effort, however, and it must be balanced with the overall total cost of ownership (TCO) and available resources, which calls for structured, systematic, and automated methods.
DXC Technology is an AWS Premier Consulting Partner and Managed Service Provider (MSP) that is helping organizations achieve excellence in the operation of their public cloud hosted workloads.
In this post, we will present DXC Technology’s approach to cloud operation excellence through a Cloud Automated Operation Model. We’ll also explore how to implement it at scale and purely over managed AWS services.
Cloud Automated Operation Model
The diagram in Figure 1 below shows how the Cloud Automated Operation Model conceptually layers on top of cloud resources. It creates higher levels of governance, security, and automation, while at the same time reducing the required skills and technical effort needed.
Figure 1 – Cloud Automated Operation Model stack.
Any cloud service or workload is formed by a set of resources that can range from equivalents to traditional ones like servers, block storage, and load balancers. They also include cloud provider managed services such as databases or container clusters, or even cloud-native types such as AWS Lambda functions that run code without requiring a provisioned server.
Those bare cloud resources are represented as the green layer in Figure 1, and the AWS Cloud provides several interfaces for their creation and operation, as well as a user interface (UI), command line tools, and APIs. All of this is done manually using the tools, and privileges need to be granted on each API action and resource, offering fine granularity but higher effort and complexity than found in a traditional environment.
In the yellow layer, automation is discretional and uses multiple methods and tools depending on the task. Use of the automation artifacts still requires high cloud skills and privileges provided for the underlying cloud API actions and resources.
The orange layer is where the high benefits happen. The underlying resources are abstracted in concepts traditionally used in the IT organization, grouping them in environments, instances, or other terminology the organization is used to working with. For the purposes of this post, we’ll call them environments.
Those environments use a set of parameters to define the characteristics needed for their deployment, and are provided with a catalog of operations, each one referring to the whole set of resources by the environment ID. Skills are reduced to those required to use the catalog of operations, without needing knowledge of the architecture or the cloud environment. Privileges are defined in terms of the operations allowed on environments.
The blue layer in Figure 1 is optional and exists to provide an additional layer of abstraction that exposes certain operations that are delegated by the IT organization to reduce the effort and provide agile services to the business.
This is a loosely coupled model where each layer does not create hard dependencies on the rest. A resource provisioned from the product catalog can be acted upon directly using the cloud UI or command line tools, or by modifying the templates that created it. No resource is essential, and all can be destroyed and replaced by new ones with the same or an updated persistent configuration.
Operation Catalog to Become Cloud Native
Not all operations need to be implemented or implemented through the layers in the Cloud Automated Operation Model. Specifically, we only need four tasks implemented to transform any workload into a native tenant of the cloud:
- Create environments of the service.
- Decommission environments of the service.
- Do a backup of the data in an environment to some persistent storage.
- Recover a backup of the data on an environment of the service.
If these four tasks are automated, the whole operation model is transformed for the affected service, becoming much like a platform as a service (PaaS) that’s managed by the IT organization instead of the cloud provider. The resources themselves become dispensable, and just the data needs to be cared about.
These four operations open the capability to destroy the workloads and recreate them in the same or different environment, with the same or changed characteristics. This revolutionizes change management, optimizes costs by reducing environments to those needed in each moment, favors agile methods by providing on demand environments, and is inherently resilient to any sort of disaster.
How to Do it the AWS Way
AWS provides all of the necessary services to implement the Cloud Automated Operation Model, without any third-party tools or licenses required. You can even do so in a serverless fashion that doesn’t require permanent resources or incurs cost while services are not being used.
DXC Technology uses three AWS services to create the yellow, green, and blue layers in the Cloud Automated Operation Model:
- AWS CloudFormation: Gives you an easy way to model a collection of related AWS and third-party resources, provision them quickly and consistently, and manage them throughout their lifecycles by treating infrastructure as code. A CloudFormation template describes your desired resources and their dependencies so you can launch and configure them together as a stack.
- AWS Systems Manager: Gives you visibility and control of your cloud infrastructure. AWS Systems Manager provides a unified UI so you can view operational data from multiple AWS services, and allows you to automate operational tasks across your AWS resources.
- AWS Service Catalog: Allows you to centrally manage deployed IT services and your applications, resources, and metadata. This helps achieve consistent governance and meet your compliance requirements, while enabling users to quickly deploy only the approved IT services they need.
DXC Technology uses AWS CloudFormation to define the sets of resources that form each “environment” type for each different architecture.
AWS Systems Manager automation documents receive parameters, provides outputs, and can invoke any action on any other AWS service. A key feature of AWS Systems Manager automation documents are scripted steps that run arbitrary Python code. These are used to add logic, do transformations or validations, discover the environment, and interface with other AWS services.
The AWS Systems Manager Parameter Store is used to store all of the parameters that were provided for the deployment and defines the creation attributes and state of each environment.
The AWS Systems Manager delegated administration security model enables redefining the privilege model to one based on assigning users to operations instead of providing them with direct access to AWS APIs. Privileges are owned by the automation, not by the user, who is allowed permission to run the operation and eventually to modify the stored parameters.
With these tools, we can implement the paradigm of each service being a resource meta-type of which we can create multiple environments, for which the Parameter Store acts as their persistent state storage.
Figure 2 – Sample operations catalog seen from AWS Systems Manager.
The catalog in Figure 2 above is an example of the basic operations catalog for an example service as seen from AWS Systems Manager automation console where they can be made available through AWS Identity and Access Management (IAM) policies to specific users or groups.
Figure 3 – Sample input parameters to a IaaS workload deployment operation.
Any attribute that’s required but can be obtained from the environment is discovered by the automation. The automation required parameters are tailored to the level of detail and knowledge of the environment of its intended users or integrated tools, hiding as much of the underlying environment as necessary.
Environment attributes enables not stopping and completely decommissioning environments while they are not being used, or re-creating environments in the same or a different AWS account in the event of a disaster.
Figure 4 – Sample execution steps of an IaaS workload deployment operation.
In the example of the execution of a deployment automation shown in Figure 4 above, steps from 18 on are custom to the application being deployed in the environment. All others are reused from one service to another and form the basic skeleton for automations that implement the service environment resource paradigm.
Project teams provide the custom installation, backup and restore scripts, and approximately 75 percent of existing automation code is reused.
DXC Technology provides customers with all of the code used in their automations, so they don’t acquire any lock-in and can use DXC Technology services, their own resources, or a third parties to maintain them the automations.
Cross-Account Scenarios
Many organizations use different accounts to isolate environments of the same workload or centralize operations in specialized accounts. These organizations need to guarantee their service’s architecture is aligned across different AWS accounts.
An additional benefit of the implementation described in the Cloud Automated Operations Model comes from the inherent ability to perform the operations provided either on the same or different account.
AWS CloudFormation can create stacks of resources in the account where the templates are applied and also, through the use of StackSets, manage the creation of resources on multiple other accounts and regions.
When included in the same template as an AWS Systems Manager automation document resource, a DXC-provided CloudFormation resource invokes automations in response to its creation, deletion, or update. Automations can run in any other account just as easily as in the same account.
Figure 5 – Technical design of a cross-account operation approach.
In Figure 5 above, we are showing a central operations account where our catalog of automated operations is deployed by the operation administrators as a CloudFormation stack containing the AWS Systems Manager automation documents that implement them, and a role that will provide the required privileges.
Operators and external tools will, through the AWS Systems Manager API and IAM privilege controls, be able to update environment’s parameter values and run operations from the catalog.
Operations that need to run in a different account are packed in the same CloudFormation template, including the AWS Systems Manager automation document, the role with the required privileges, and a custom resource that triggers the document execution when the stack is created. This is deployed in the target account through a CloudFormation stackset that provides the cross-account capability to create stacks in multiple other accounts and regions.
Without any additional overhead, the same custom CloudFormation resource provides a method to execute operations through the creation of stacks from the AWS Service Catalog portfolio of products in a controlled way, using its portfolio management and access control capabilities to expose operations to people outside the IT organization.
Benefits of the Cloud Automated Operation Model
Traditional workloads with essential resources are transformed into cloud-native ones with disposable resources. Any change in the architecture or implementation of the service is done by modifying the deployment automation and migrating to a new environment.
Workloads are by definition resilient to disasters and can be relocated to different regions or AWS accounts.
Using predefined patterns to implement automated operations ensures the same architectures, standards, and policies are implemented across workloads and cloud environments, reducing risk and improving governance and accountability.
With minimal effort, IT organizations can use the Cloud Automated Operation Model to selectively delegate tasks, while implementing ad-hoc controls and governance rules.
Privileges are managed through a straightforward, auditable, and secure model based on the IT organization’s definition of “environments” and their catalog of operations.
Finally, the operations catalog provides an abstracted interface for the integration of external tools, such as orchestrators, DevOps, or ITSM catalogs, without exposing the underlying cloud services and architecture.
Conclusion
Using the Cloud Automated Operation Model and its available set of automation resources, DXC Technology helps customers transform their AWS workloads to be native cloud tenants.
Producing the four basic operation automations (create, remove, backup, and restore), customers move from having cloud infrastructures that are not operated differently from how they would in their on-premises environments, to harnessing the benefits of flexibility, elasticity, and reduced operational costs of the public cloud.
DXC Technology also uses this model to build PaaS services on AWS, providing end customers with a product and operations catalog supporting AWS-hosted infrastructures.
.
.
DXC Technology – AWS Partner Spotlight
DXC Technology is an AWS Premier Consulting Partner and MSP that understands the complexities of migrating workloads to AWS in large-scale environments, and the skills needed for success.
Contact DXC Technology | Partner Overview
*Already worked with DXC Technology? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.