So you’ve built a landing zone in AWS. You’ve empowered some app owners to build. You now have some production applications running. You have a pipeline full of other applications you plan to move to AWS over the next year or two of your cloud journey. Now what?
The biggest selling point about cloud isn’t cost, or flexibility—it’s agility. It’s hard to gain speed and agility if your IT group continues to operate in the same traditional manner where there are human gates and processes and tickets and handoffs to get anything done. The reason start-ups can move fast and break things (and get acquired) is because they are not hindered by processes and gates that have been set up and meticulously followed by large enterprises. This is fine when the organization is the size of a start-up, but it doesn’t scale. At scale, organizations need to change their business processes to take advantage of automation and self-service. Let’s be real for a second here, too: most applications aren’t beautiful, highly available and stateless, or containerized or serverless. Most enterprise applications are legacy (i.e., they actually generate revenue). Add a little automation to your life, and you can “move and improve” these legacy apps.
No more tickets!
Ticket reduction is a byproduct of good cloud adoption, self-service, and highly available, self-healing infrastructure. Most organizations aren’t like Uber or Netflix, with just one major customer-facing application that all engineering resources are focused on. Instead, they have some combination of commercial off-the-shelf (COTS) software and custom homegrown software, and as a result engineering resources are spread thin across many applications, each of which has its own quirks and needs to remain resilient and operational. The only way to scale is to employ highly skilled engineers to write automation.
So, where exactly do you start automating away tickets? Try the server provisioning process. Automate the build of EC2 instances and VMs using AWS CloudFormation + user data, or AWS CloudFormation + a config management tool like built-in AWS OpsWorks or Chef/Puppet/Ansible. Then, integrate with AWS Service Catalog, a cloud management platform, or a homegrown self-service tool. You can even choose to bring over your existing build tools like Microsoft SCCM to build and deploy infrastructure.
Don’t forget to grant the app owner and the builder access to the newly created instance. This can be done within Active Directory by auto-creating AD groups. For Windows, join a domain using AWS EC2 Seamless Domain Join and let Group Policy Restricted Groups or Group Policy Preferences handle setting the local admin group. For Linux-based machines, leverage a config management tool like Chef, Puppet or Ansible Tower to set and enforce the /etc/sudoers file group. And, of course, notify the owners and teams when the instance is ready to rock and roll! Surprisingly this isn’t difficult to do with a little PowerShell scripting, but as of this writing, PowerShell Core (which is what Lambda functions support) doesn’t support the Active Directory PowerShell Module, so you’ll have to do this the old-fashioned way using a Windows EC2. I expect this to change in 2019.
Empower app owners, developers and lines of business to deploy their own infrastructure. This gets core IT out of the business of provisioning, so they can focus on higher value-add tasks like developing automation. With granular tagging, you can always show/shame/charge-back the application and business owners for the cost of their applications. Stop being the human cost gatekeeper. By creating this internal economy, you are forcing the business to be accountable for their costs. This could be a whole separate blog post in itself!
“Our goal is to automate ourselves out of a job.”
Don’t take that quote the wrong way. Successful automation engineers are always in demand. If you’re successful automating away most of your tasks, I promise there will be more work waiting for you. Looking for another thing to automate? Start with your incident and change ticket queues. What are the most common repetitive tasks? Here are a few ideas:
• Common power tasks: stopping, starting, restarting EC2 instances and RDS instances
• Extending EBS volumes and subsequent OS logical disk partition
• On-demand backup using EBS snapshots, or restoring from backup for EC2 and RDS
• Instance-type size changes (up or down, changing families)
• Creating images or standing-up duplicate environments
• Terminating instances
• Resizing RDS instances
With good tagging, the business becomes accountable and responsible for their spend, meaning the cloud team doesn’t need to spend time on some of these more common tasks. Rather than fielding tickets and emails, the cloud team can focus on the hard stuff—application provisioning and configuration and templatized infrastructure-as-code.
In my next blog, “Putting the Ops in DevOps,” I will show you ways to extend this self-service model to integrate your most common operational tasks, make recommendations or automatically take action, and integrate into a centralized automation and self-service platform.
Regardless of where you are in your AWS journey, Sirius cloud experts can help architect, implement and manage an optimal solution designed to enable and accelerate your business outcomes. For more details on how Sirius can help accelerate your cloud journey, contact a Sirius cloud expert today.
