Rise of Self-Service - Templatizing cloud operations using AWS Service Catalog
By: Team Shellkode
Tags: AWS, Infrastructure As Code, Jira, DevOps, Cloud Computing

Enabling Accelerated Deployments with Self-Service(AWS Service Catalogue)

Most organizations nowadays are looking for a solution that would be much more quick, easy to deploy, organize and govern resources with all organization standards. Self Service enables your end-users to perform any actions on your templatized products without needing to grant users full access to AWS services.

Img credit — https://www.freepik.com/

However, AWS already has CloudFormation for automated cloud deployments. Also with just a little bit of research, you can find tons of tools on the market like Terraform, Jenkins, Ansible, etc to automate everything. Then why do you need an AWS Service Catalog?

Let’s explore it from a business point of view. You are a stakeholder and maintaining the Infra-sec part. A dev needs an EC2 instance to run his new module. You want to have an automated process that will solve the following requirements.

Support of DevOps implementation — auto-provisioning of infrastructures like storage like EC2, storage, and RDS.

Removing manual processes to avoid configuration errors.

Procure resources based on organization standards.

Reduce the time and effort of the Ops team to procure resources.

Procure resources and log tickets on deployment.

If we use the traditional tools and services, then the flow will look something like this.

This is also automated deployment, but, there is still room for improvement in some places to improve the process and reduce the time.

Create the request. Once the business user raises the ticket for the new instance, it goes to his manager’s approval. After the manual approval, the ticket will go to the Ops team and they will route it to the DevOps team for the deployment of the instance. If some necessary information is required like subnet details or routing details, they need to collect those details in the ticket log. Most people will do this in a manual way. Or DevOps teams need to prepare the code(cloud formation/terraform) for the instance provision(If not templated) and push it to the repo. Then the deployment will begin through either Jenkins/CodeBuild/ CodePipeline or any CD tool. Provision of the resources and tagging needs to be done(maybe in step 5, can take this too) AWS cloud-config will be scanning the resource and sending the alerts if something is fishy, then again the DevOps or security team needs to fix it. A security team will involve and validate it.

While reading the whole process you might judge the time taken for each step. From the tech side, automation needs some time. But can we reduce the time from the process perspective and the time lost due to over communication? Ok, now let’s see how a self-service process can solve this.

AWS Service Catalog in a nutshell:

AWS service catalog is a centralized place to provision and manage a catalog of resources that are approved in AWS services. A tight integration with any ITSM tools like Jira will be a plus and it is completely powered by CloudFormation.

The DevOps team will gather requirements and understand current problems of operations team-based and design a boutique solution. Based on the proposed solution, the DevOps team develops IAAC code (CloudFormation or Terraform) and pushes it to Code Commit. The IAAC template will be pushed to a sandbox environment where the cloud operations team will test the products. The Cloud Ops team will test the product with real-world scenarios and report back to the DevOps team if there are any gaps or security concerns. Template receives a green flag If all the Cloud ops team’s requirements are met and the product adheres to security and compliance in the Service Catalog. Based on needs Business users will launch the products in the service catalogs using native UI/Jira/Servicenow. Launch Products will invoke IAAC and procure a tailored resource to business users with all the tagging in place. Track any changes in the existing environment. The drift in the environment will be captured by AWS config and Notified to the operations team if any anomalies are detected using CloudWatch alerts. All the event details will be logged in CloudTrail.

What it solves here:

In the ticketing portal itself, we can collect all the necessary values.

Templates are already configured and infra/DevSecOps already reviewed it.

So just one approval will launch the stack that is requested by the business user.

And all other components like Tagging, logging, Audit, and everything is part of this implementation.

We’ll see a live demo in the upcoming blog series on how we achieved this with Jira integration.

Value brought by Service Catalog:

Ensure to adhere to organization compliance with corporate standards

Business users can quickly find and deploy approved IT services

Centrally manage IT service lifecycle in a distributed environment

Integrates with ITSM/ITOM software like Jira and service now

Update and manage all of your application information on AWS

How can Service Catalog be controlled?

Under the hood, Service Catalog uses Cloudformation as well terraform in the background as a core system for procurement of the product

Governance

The service Catalog is governed using portfolios with which we can control how the product will be launch, how the access to the product is controlled, and at last to whom the product should be shared

Restricted product

Product launch is restricted by adding constraints to the portfolios (constraint like what IAM role can be assigned to product)

Restricted user

Product access can be restricted to a specific user, IAM role, or Group using access control in portfolios

Sharing to member accounts

Portfolios can be shared from delegated admin account further which can be imported from member account

Tagging at procurement

Using service catalog tags library admins can define which key-value pair can be selected by end-users to procure certain products so that tagging will be standard for all the applications without any spelling mistakes or invalid case

Release management

Updates to product templates or patches for the product can be managed using product versioning.

Benefits to the organization/customer:

Reusability of CloudFormation template

Reduces IT ops efforts by 40%

Integrates with ticketing tool to avoid who, why, where, and how a resource is provisioned

Auto-tagging/enforced policies, etc

Ease of environment cleaning

Conclusion:

This is just an introductory blog post in the “Service Catalog blog series”, and the subsequent blogs in the series will talk about deployment strategies, Integration with ITSM tools like Jira, and best practices. So please do follow our blog and stay tuned!!