“For the things we have to learn before we can do them, we learn by doing them.” Aristotle
(Note: these best practices, and a number of others, are now available in my book Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT).
This list could also be named “the 10 things I wish I knew when I started my cloud journey”. We were lucky enough to employ a handful of these at the beginning of the Dow Jones journey. Others we learned along the way. I’ve had the opportunity to meet with dozens of customers since joining AWS in September, and have seen these attributes reinforced inside some of the most transformative — and conservative — situations.
- They provide executive sponsorship. This is typically true for most initiatives. Projects in big companies are far more likely to succeed when the boss supports them. You don’t need to bet the farm in the first few months, but you want to give your organization the best chance to succeed. Help the organization understand the long game and celebrate successes.
- They create a center of excellence with their staff. Just because existing staff doesn’t have the skills today doesn’t mean they can’t obtain them. They can quickly become a center of excellence and promote best practices and solid governance. While there’s a lot that is different about working with the cloud, the computing fundamentals are still the same. Think of it as an investment into expanding your organization’s capabilities. Partners and consultants can be a big help here, especially if it’s to accelerate business outcomes or your independence. Be wary, however, of having them own all of your organizations cloud expertise. There is a lot of debate around on best ways to do this for the long haul — DevOps, bimodal IT, full stack engineering, and others. Based on what I’ve seen, you don’t need to make this decision right away. You can use this as an opportunity to transform your organization, or just add an alternative. You know your organization best. Once you gain some experience the right path will present itself. I will be detailing my thoughts on this as part of subsequent posts.
- They’re not concerned with how fast they get there. Remember, it’s a journey. Organizations who have decided to go “all-in” or move substantial portions of their infrastructure to the cloud did not make this decision over night. They started with an experiment, began to understand the value, and responsibly paced it throughout their business as they realized the benefits and grew their capabilities.
- They’re open-minded about what they move. There is a lot of rhetoric about the type of projects that are most suited for the cloud. You should pick something that meets a business need rather than perceived suitability. The possibilities are near endless. It could be driven by the leadership team or from an ambitious team/individual deep within an organization. If someone thinks they can accomplish their goals in the cloud, chances are they can. It may be worth trying to proactively identify these people and give them an opportunity to shine. You may uncover a few hidden gems.
- They’re careful in approaching cost comparisons. TCO (Total Cost of Ownership) analysis between on-premises and cloud infrastructure requires careful thought. The most common pitfall I see here is when organizations compare existing on-premises infrastructure that is underutilized and estimate the need to retain unused capacity. If, for example, you have a system that peaks at 6 servers for four hours a day, but during remaining 20 hours only consumes 2 servers you need (4 * 6 + 20 * 2) 64 server hours of compute per day. The TCO calculation is then the cost of 64 server hours rather than the traditional (6 * 24) 144 — roughly half the compute traditionally required. Even if you have a lot of virtualization in your environment, you’re likely stuck with the burden of having excess capacity to deal with changes in demand. The more you adopt cloud, the less of this you’ll need. AWS is building a center of excellence around TCO and is happy to help with this analysis. While this may seem self-serving, there is a lot of experience and best practices that AWS can bring to bear to paint a complete picture. Also, if you’ve found a way to do it cheaper, AWS would be happy to learn from it and improve its service. You can find our basic tool here.
- They’re prepared to make some mistakes. This is a good thing. As you gain experience you’ll make less of them, and you’ll find that adoption happens at an accelerated rate. This does not necessarily translate into slower delivery. There have been many cases where AWS pilot projects have been delivered faster than traditional approaches would have allowed, even with time for addressing mistakes. One of the greatest benefits that cloud computing offers is the low cost of experimentation. Many of the most innovative companies would argue that experimentation is an input to innovation. If something doesn’t work out, you can move on. There is no commitment for trying.
- They make automation a requirement. This is one of the most important technical shifts companies can make to take full advantage of cloud computing. Based on my conversations with customers along with my own experience, once an organization starts to think of their server infrastructure as fleets of compute instances rather than machines, the benefits of elasticity become apparent. Doing this well influences much better security posturing, environment predictability, and allows you to take advantage of auto scaling. Auto scaling is, in my opinion, one of the greatest innovations of all time. It is one of the most fundamentally new features that cloud computing has to offer. Per the previous TCO point, this will greatly influence your ability to reduce costs.
- They proactively monitor and create alerts for areas of concern. Every organization will have unique concerns and tolerance for risk. You may be most concerned with how many people are able to provision resources. It could be how quickly your bill changes. It may be certain areas of the network or application are more sensitive to change than others. Whatever these may be, make these known to your team and ensure that they’re using the appropriate tools (CloudTrail, CloudWatch Logs, Directory Service, and others) to mitigate them.
- They use the AWS Marketplace. The marketplace is full of solutions to common problems for all AWS customer types. When Dow Jones was forced to vacate one of its facilities we were able to find software equivalents for what we thought were hardware only solutions in the AWS marketplace. It was as simple as loading in configurations. The ongoing administration practices did not change. You’ll be surprised what you find here that can accelerate your initiatives.
- They talk about it. The rest of the organization will want to hear about the things that worked well and the things that didn’t. Sharing experiences can be a great way to reinforce your agenda and recognize the work from the contributors on the team. They’ll deserve it, and it will show the organization that acquiring new skills and execution is rewarded. Many AWS customers speak publicly about what they’ve accomplished. This can be another vehicle to reward your organization’s accomplishments in a meaningful and cost effective way. Finally, AWS is customer obsessed. 90–95% of the AWS roadmap is determined by customer feedback. Tell us what you think we should do better.
Do these resonate with your organization? If you have worthwhile additions or different experiences, I’d love to hear from you.