The Pandemic Is Speeding Up Cloud Migrations. Yours Can Too.
“Awww, damn!” I said to myself. I had just realized we were going to close the office due to the global pandemic. I was sure it was only going to be 1 month. And then I was sure it was going to be 2 months. And then here we are, 4 months into COVID-19 with no end in sight. While much of the economy has been put on hold, “The pandemic sped up digital transformation strategies at 97% of companies…” according to CIODive. Cloud migrations are also speeding up. Looking backward, this doesn’t come as a surprise; What else are you gonna do when everyone is at home investing their 401ks into buying toilet paper online? If you’re one of the companies that fall into the 97%, then you’re probably feeling pressure to produce results. We’ll discuss strategies to deliver your cloud migration on time. And if you’re one of the 3%, well… you have other problems.
The Scope Creep
Engineers loooooooooove technology. They tend to introduce it any chance they get, always for good reasons. Being stringent with requirements will save you months or maybe years off of a project. Istio and Kubernetes seem to be good candidates to create such delays. I’ve seen those projects delay cloud migrations by years — I’m not exaggerating. Learning entirely new technologies is a challenge on its own but an entirely new paradigm of computing is even more difficult. A couple of good questions to ask is “Do we need this right now? What is the cost of not doing it right now?”. A typical response from your team might be “If we don’t do this right now, then we’ll never do it” which is a good argument to bloat your releases. You can always add to the requirements later. It’s software, not a physical building. Making changes should be easy, prioritization is harder.
Things That Begin With The Letter ‘K’ for $200, Alex
Kubernetes and containerization require learning entirely new concepts around networking, security, and scalability. These new concepts should not be taken lightly. It opens the door for scope creep because you don’t know what you don’t know. Engineers will claim that “all the things” will be needed for this migration. The reality is that you really don’t know, all you have is best-guesses. To get similar benefits take advantage of the basic automation that the cloud providers have to offer like auto-scaling groups (ASG) in AWS, managed instance groups (MIG) in GCP, or Scale Sets in Azure. Avoid all things that begin with the letter ‘K’ during your migration. You’ll be grateful you did.
Living With Your Monoliths
Not all monoliths are bad and moving to the cloud should not be an invitation for breaking apart your monolith. Monoliths can be a source of pain but breaking it up before your development practices are prepared for it means you’ll have 1,000 papercuts instead of 1. Breaking up monoliths requires you to be much better at centralized tooling and distributed systems and processes. To be good at this it takes years of practice and iteration to get this right. Don’t jump into microservices because you read it on some digital transformation blog. 😊
Where To Add Scope
Where we do suggest you invest is in offloading services to the cloud providers wherever possible such as managed databases that are equivalent. Right now would not be the time to switch to a NoSQL database but would make sense to move to a hosted MySQL solution. Reducing overhead and maintenance duties of your team.
Networking is always a pain. We strongly suggest using cloud-native networking principles from the start instead of lift-and-shift concepts of networking. Networking complexity in the cloud is always the bottleneck. You should also consider rewriting parts of your software stack that rely on static IPs. While it might take a little bit more work, it’ll take you twice as much work to automate this in the cloud anyways. The trade-off just isn’t worth it.
Service Discovery & Cloud Loadbalancers
To make networking simpler, here is a good opportunity to reduce complexity in your stack while at the same time reducing vendor costs. I have yet to come across a use-case that couldn’t be resolved using cloud load-balancing or have a service discovery tool such as consul.
Focus on People
Due to COVID-19, your company is now distributed. Whether you like it or not, here we are. Now that you have a distributed workforce you have to think differently about leveraging your entire workforce, not just making decisions at the top. Continuing to make decisions as if you were working in a centralized office will lead to you — yes, you! — becoming a bottleneck.
Breaking Down Silos
As you move into the cloud one thing is for sure: how your teams are organized will have to change. Security, Compliance, Developers, and Operations have to work closer than ever to get applications into the cloud. In doing so you’ll want to create smaller teams that have cross-functional roles to accomplish your goals. Creating new processes and communication structures that break down the silos between the teams. The deliverable of moving applications into production should rest on the shoulders of this cross-functional team, not just one person from a single function. A side-effect of creating these cross-functional teams should be greater collaboration and individuals being heard in smaller group settings.
Speed Over Efficiency
This might sound crazy but having two teams creating similar pipelines is not a waste of time. In fact, it might help you achieve your goals faster and actually reduce waste. By creating centralized teams that manage deployments or security you create the “least common denominator” problem. Do you want infighting? Because this is how you get infighting. It will be hard for a centralized team to meet the goals of 10s or 100s of teams. When you’re first moving to the cloud you don’t know what you want. Your processes will change and you won’t know whether they’re good or not. You won’t know who you’re going to slow down. At this point, you should be concerned with efficiency because you don’t even know what it looks like. Focus on achieving your migration goals first, even if it means 10 teams doing it 10 different ways. You may find that working like this might never change. Netflix & Amazon are companies that are very decentralized and focus on speed to market over efficient org structures and processes.
Managing Failure
The truth is that you can’t prevent failure when you’re doing risky projects, you can only manage it and respond to it. Expect that your team will fail, miss deadlines, and get things wrong. This is ok; it is all part of the learning and innovation process. Aiming for 100% reliability has unintended consequences. To manage failure you also have to accurately measure risk. How you measure and define risk for any project will determine how we communicate. When ill-defined — and more likely undefined — we argue without making progress. If failure is inevitable then what should we do? Spend more time creating stringent root cause analysis and retrospectives process. Make sure that the teams are iterating and not making the same mistakes twice. Look toward positivity and progress as your guides not the intense focus on failure.
Don’t Forget To Celebrate The Journey
Celebrate early & often. There are many ways to show appreciation to your teams for making progress. Celebrate failures that were handled well. Google is known for having a great post-mortem culture and they celebrate failure by having the “post-mortem of the month”. Celebrate the wins too. Give your teams time off, announce their names at all hands, write them gratitude cards. Schedule time out with them at dinners or lunch. Google is your friend here.
Digital transformation is a terrible name for what our industry is trying to accomplish. The word ‘transformation’ implies a beginning and end. But in reality, there is no end. We’re constantly improving, little by little, day by day. It’s a neverending journey to perfect our craft. And when we look back at our journey we want to see our growth and be proud of where we’ve taken ourselves and our organizations.
