Managing a single cloud account is a challenge all by itself. Only adding more instances and services to one account can lead to challenges from keeping track of what is running to quota limits set by the providers. When you hit the logical limits of that account, expanding the footprint of your cloud strategy is more than just spinning up a new account and dropping the corporate credit card on it. Both Azure and AWS have created logical ways to organize your accounts along project, product, purpose, team, or billing boundaries. Figure out how to organize and plan for your expanding cloud environment and then learn the basics of using AWS or Azure structures and hierarchy to manage the growth of your cloud ecosystem. Enjoy this introduction of AWS Organizations, Control Tower, and Policies along with an overview of Azure Management, Subscriptions, and Resource Groups to effectively manage your workload.
Category: Technology Blog Page 1 of 2
Here you will find my walk throughs, musings, thoughts, and experiences in working with technology over the years of my career.
As in the last post Demystifying Infrastructure as Code, it should be clear how important it is for organizations moving their DevOps initiatives forward to learn and use IaC. The same importance should be applied to Configuration Management as well to prevent environmental drift, enable rapid deployments, provide scalable solutions, and maintain system integrity. Using source control, continuous integration, testing, and other software development practices will allow for sustainable automation at the operational level.
It’s an important piece of a successful and high performing DevOps organization to treat configuration management and infrastructure as code. Why? Because if someone working within a cloud provider can apply the same rigor of quality to systems that development teams do to application code, it will prevent environmental drift, enable more rapid deployments, provide solutions that scale, and ensure maintainable system integrity. Using source control, continuous integration, testing, and other software development practices will allow for sustainable automation at the operational level. Infrastructure as Code is especially powerful in that it can create an underlying base of stability that operational-focused teams demand, while also providing the support to move quickly in a way that business and application developers often require.
Also see part 2 here: Demystifying Configuration Management.
Most of the things I learn on Linux, I’ve learned to play around with as virtual machines on my Windows Desktop. I’m putting this here for me to remember my steps in the future, but in case anyone else finds this helpful, yay, internet!
First of all, I’m a fan of VMware Workstation Player. Their website says: “The free version is available for non-commercial, personal and home use.” When you do pay for it (once you start making money or are working somewhere that you need it), it’s only $149.99 (as of 8/22/2019 when I checked)
https://www.vmware.com/products/workstation-player/workstation-player-evaluation.html
Organizations that have built a positive DevOps culture have transformed as part of a continuous and ongoing journey. The members of the organization should have a noticeable difference in how they behave presently versus how they behaved in the past. If the ultimate goal is to change the way the entire organization functions and operates, that means two things: changing the way everyone in the organization thinks about how they work and changing the way people behave.
For those hearing my talk on the topic or wanting a single place to get to each item in the Anti-Pattern list, here is a link to the original summary post and the individual posts for each anti-pattern I discussed:
Automation is the force multiplier that makes a DevOps effort so powerful. While it requires the technical skill and know-how to create frameworks for automating processes in an organization, an automation-first mindset is not easy to start out with. The rest of the DevOps anti-patterns are all about different modes of thinking and this one is no different.
All of the previous cultural pitfalls I discussed have been focused on systemic issues with organizations, teams, or groups of people. This is truly the one that requires individual effort to defeat. Even I have to be intentional about sharing what I know that would make others on my team have the same successes. This differs from the Tribal Knowledge Anti-pattern in that organizations create and force single threaded resources. This forces people to “stay in their lane” which creates hard boundaries in what people know how to work on. Information hoarding usually comes from an individual place of fear and insecurity.
In 2017, I took a very hard look at the issue we caused for Quality Assurance teams I worked with. By automating many Operations tasks, we did not speed up the whole development effort of the projects we worked on. The flow of work through an entire system is the only metric that matters to project leaders and clients, not that one particular piece is better. We had unintentionally created a new, bigger bottleneck by not supporting our QA team properly with what they needed to succeed.
“It is better to ask for forgiveness than permission.” A statement like that is pervasive in an organization that follows a decentralized command and control structure. As organizations become more complex, it is nearly impossible for any single person to fully capture detailed information in making decisions. Yet, many companies still try to run significant decision making authority through single threaded resources.