In our experience working with hundreds of organizations on compliance projects ranging from AWS PCI compliance and AWS HIPAA compliance to internal risk management initiatives, it’s clear that achieving and maintaining compliance is a delicate balance. Too many rules can slow progress and sometimes even cause teams to avoid complying at all. And too few guidelines can obviously result in unwanted fines, or in a worst case scenario, a security vulnerability that causes the business serious harm. Central to establishing and ensuring AWS risk and compliance efforts is the well-known practice of AWS configuration management. It plays a central role in keeping systems in a known, good state and with the application of automation can help organizations strike an optimal balance.
In 2013 Gene Kim, Kevin Behr and George Spafford published The Phoenix Project, a book that marries the concepts of manufacturing agility from Eliyahu Goldratt’s The Goal and relates them to IT. As they elucidate in the story, a new approach to IT is clearly needed and many organizations are embracing that change through the DevOps methodology. However, DevOps can be a very broad term making it difficult for people to know where to begin. As a result, we have narrowed the DevOps model
A misconfigured data bucket in AWS Simple Storage Service (S3) led to a Republican contractor’s database of nearly every voter being left exposed on the Internet for 12 days, according to CRN. This news presents an unfortunate reminder of why good AWS security hygiene is important to designing, building and managing AWS environments. In this spirit, we’d like to explore two basic AWS best practices that when built-in can help stave off extreme events like this.
Berry Christ, Chef CEO predicted at Chef Conference 2017 that Web and mobile will eventually become table stakes, the lowest bar to market entry. Taking his prediction one step further, we see a day where DevOps will be the minimum entry requirement needed to become and remain market competitive. That may sound aggressive given the fact that only 20% of businesses have adopted DevOps, according to research last October by Gartner. Yet, for organizations that have implemented DevOps, 66% saw faster realization of business value. And, according to McKinsey, firms with high performing IT organizations were twice as likely to exceed their profitability, market share, and productivity goals.
Where does code end and configuration begin? It’s a perennial question. And, as the lines continue to blur between the two we here at Flux7 have begun defining new terminology and ways of thinking of the issue that we’d like to propose in our blog today. As part of a community of developers whose work often entrenches them in these issues, we greatly appreciate your feedback and help in fine-tuning these definitions for the betterment of our collective work.
In our last year in review blog, we took a look at how to best use new features and tools to streamline DevOps processes like Continuous Integration and Continuous Delivery (CI/CD). Today we are turning our attention to another topic that garnered a lot of interest this year, Configuration Management.
Continuous Delivery (CD) is a core facet of successful DevOps and as a result, a core Flux7 strategy for implementing DevOps-based IT modernization. At Flux7, we always view DevOps as streamlining the delivery of not just Code but also the delivery of Infrastructure (networking, firewalls, VMs), Server Configuration (software packages such as Apache or JAVA), and Security Rules (policies for AWS Config Rules or HashiCorp Vault). Among these, efficient delivery of infrastructure and configuration are both very critical for full stack agility. For our customers in AWS, our typical choice for infrastructure delivery is CloudFormation. We like AWS CloudFormation because it is native to AWS, follows a simple YAML or JSON syntax, and has deep integration with other AWS Services such as the AWS Service Catalog.
In our last article, we took a look at how marrying Ansible and AWS makes a great deal of sense for DevOps enterprises and discussed eight specific ways Ansible helps create greater efficiency and effectiveness for AWS deployments. Today we will dive into the recently refactored Ansible to discuss its newest features and how they can further help bolster your AWS efforts. In addition, Ansible likes to bill itself as “batteries included”. As a result, we will also review the new "batteries" or modules that are available with the release of Ansible 2.0.
Before diving straight into the new Ansible 2.0 updates (which we will do in Part 2 of this short blog series), let’s take a step back and look at why Amazon Web Services (AWS) and Ansible make such a terrific match for DevOps enterprises. As you likely know, AWS is a collection of cloud computing services that make up the on-demand computing platform offered by Amazon.com. These services operate from 12 geographical regions across the world. The most central and best-known of these services arguably include Amazon Elastic Compute Cloud, also known as "EC2", and Amazon Simple Storage Service, also known as "S3". AWS now has more than 70 services that range from compute, storage, networking, database, analytics, application services, deployment, management and mobile.