A colleague of mine who served in the USMC once told me that in the military they have a saying: “Slow is smooth, smooth is fast.” I love this phrase and think it beautifully expresses the contradiction that moving (a little) slower—albeit deliberately and thoughtfully—usually ends up being faster. Or as your grandpa told you, “Do it right the first time.”
Typical example: you’re late for work and are rushing around cramming your stuff into your bag. You hop into the car and halfway to work it hits you…oh crap, you forgot XYZ (important paperwork, device, badge, etc.). Now you have to go all the way back home to get the thing and drive all the way back. If you’d been deliberate about getting ready, sure you may have been in your car 30 seconds later, but you’d have been at work an hour earlier. Slow is smooth, smooth is fast.
Now how does this help you with an AWS migration?
Having been part of a significant number of AWS migrations, I wanted to point out some of the challenges that I’ve seen when it comes to rushing things into AWS. Below are some suggestions on how to have your migration go smoothly.
Give your team time to figure things out
To successfully migrate to AWS, you need to allow for your teams to experiment and learn. I promise that the complexity of undertaking a migration isn’t understood by anyone who hasn’t done it before. Yes, I’m certain that your team is intelligent and capable. I’m also certain that while AWS isn’t magic and many of the concepts will be very similar, there are quite a few AWS-specific things to figure out that require change(s) in thinking. This takes time, that’s all. If you rush your team or have unrealistic expectations, you’re going to hurt the project, the quality, and the people. I’ve seen many companies lose senior engineers because of this.
“There’s no compression algorithm for experience.” – Andy Jassy
Tactical wins aren’t always strategic wins
After you’ve spent 3 months yelling “Just get it into prod!” at your development team (who started with zero AWS experience), lo and behold they shoehorned your application from on-prem onto a manually provisioned single EC2 instance! Congratulations! That means they can now move onto the next application, right? Another 3 months of yelling and you’ll have what you’re looking for.
Wrong! It means is that you’ve just introduced technical debt, burnt your engineers, and haven’t actually done anything repeatable.
Give yourself time to do it right
I’m aware that businesses are beholden to dates: quarterly planning deadlines, financial deadlines, product release deadlines, on and on ad-nauseum. Turns out though, that’s not how development/software works. Waterfall works if you’re building bridges, not software—hence the general shift to methodologies that encourage small, high-quality increments (DevOps, test-driven development, agile, scrum, extreme programming, etc.).
There will be surprises. In order to give yourself the chance to address these surprises and succeed, the migration team needs to be able to focus on quality, not arbitrary dates. Foundational pieces should be viewed as strategic investments to serve as a solid foundation for each successive step in the migration. Trying to change foundational pieces once the migration train has started is extremely disruptive and frustrating to the development teams (You told me to learn and build a huge CloudFormation template and now you want me to re-write it in Terraform?!).
Don’t misunderstand me: iteration is necessary but asking people to throw out tens or hundreds of hours of work because the Cloud Engineering team wasn’t given time to think through CI/CD isn’t a winning strategy. Build a solid foundation and the rest will take care of itself.
There are some things in AWS that take very little effort upfront but are extremely difficult to remediate later. For example, IPv4 CIDR blocks for VPCs can’t be changed after the fact. If instances are deployed into VPCs with overlapping CIDR blocks they won’t be able to route to each other without significant re-architecting.
Another example is tagging and governance. It’s pretty easy to tell which EC2 instances can be shutdown to cut costs when you have 10 instances. It’s a huge problem when you have 1,000 or 10,000 instances running.
Focus on building an AWS environment that is thoughtful and allowing your Cloud Team to learn and you’ll be much better off.
Remember: slow is smooth, smooth is fast.
If you are wondering how solid your foundation is, contact us about performing an AWS Well-Architected Review of your workload. If you are interested in learning more about how 1Strategy can help optimize your AWS cloud journey and infrastructure, please contact us for more information at info@1Strategy.com.
