Five DevOps Lessons from a CIO Getting in the Weeds on AWS

DevOps - Get in the weeds
I always advise CIOs and technologists to get into the weeds to figure out what's going on. So last week I spent some time getting a number of AWS services up and running. Nothing too crazy, but successful.

My first project was to set up a new domain, Driving-Digital.com on AWS Route 53 to enable landing pages and vanity URLs for my upcoming book, Driving-Digital: The Leader's Guide to Business Transformation Through Technology. While it's been a few years since I last set up DNS, the basics are fairly straightforward. What I had to learn was how to properly set up S3 to act as a web server and use the redirection rules to enable a set of vanity urls. Again, not too complicated especially if you configured an Apache web server.

My second project involved setting up an Amazon RDS Postgresql database with a VPC to enable selective inbound traffic. My goal was to enable an ETL service to automate moving data from my Google Analytics account into a database and then use Tableau to join data and build visualizations. This setup took a bit longer as I had to figure out how to setup a VPC properly and then grant appropriate permissions in the database.

My third experience was working with a client looking to setup a Node.js application on Elastic Beanstalk using Travis to automate deployments.

DevOps Lessons Learned in Cloud Configurations


So here are some of the lessons learned from my short and simple exercises -

  1. You can teach an old dog new tricks - If you've configured infrastructure in a data center, then enabling similar basic capabilities in AWS largely requires learning a new vernacular and tools. Again, I was only doing very basic DNS, VPC, web server and database configurations but was able to accomplish these tasks without training classes or reading extensive manuals. When I got stuck, I Googled for answers. For CIO, if you have system administrators and engineers that largely operate tech in the data center, getting them to operate similar technologies in the cloud only requires some basic training and time to experiment.  

  2. Planning required for more complex tasks - Setting up S3 to run a barebones web server is straightforward, but it doesn't have anywhere near all the capabilities of an Apache web server. Like all infrastructure needs, it's important to know your basic configuration requirements before selecting a technology and its implementation.

  3. Debugging is still hard - When I couldn't connect my ETL service to the database, I had to go through basic debugging steps to determine what network layer was blocking the traffic and how to configure it properly.  This took several trial/errors and the tools to debug weren't immediately obvious.

  4. Online documentation is very good, but not ready for DevOps - The documentation I poured over was very good explaining how to do basic and more advanced configurations. I  was also able to find reasonable documentation on solving problems once I had already recognized the source of the issue. It was poor in describing tools or steps to debug, or providing links to best practices. For DevOps, I was hoping to see some separation of duties to determine what steps should be automated as infrastructure configuration versus what should be setup as part of deployments.

  5. Move to Infrastructure as Software quickly - Tracing through a manually configured cloud environment is only slightly easier than doing the same task in your data center infrastructure. At least the cloud is web based and most of the tools are centralized, but navigating different configurations, naming conventions, and pipelines can become very complex if you're tracing through someone else's configuration. As CIO, we all thought setting configuration standards and moving to more homogeneous architectures would address the complexity, but I suspect only a small percentage of IT organizations are successful with this approach. On the other hand, if the configuration is automated in well structured and documented code, then there are fewer places and artifacts required to learn and maintain a computing architecture.
So today's post comes to you from my time in the weeds!

No comments:

Post a Comment

Share