For the last 12 months, the Woolpert Cloud Solutions team has been leading you on a Practical Cloud Journey. The team of architects, software engineers, site reliability engineers, data engineers and solutions consultants have offered ideas, insights and advice on a wide range of topics. 

We have remained firmly rooted in the practical realities of leveraging cloud technology and practices, occasionally waxing poetic within a tidy, theoretical world. While theory is a good place to start, any journey gets more interesting when we take our first actual steps. 

At the bottom of this post is a complete list of the blogs and audiocasts that made up our journey throughout 2021. We have approached the cloud broadly, incorporating economics, security, governance and, most importantly, the people involved in this journey. Now that we’ve reached the end of the year, which is always a good time to pause and reflect, we thought we'd share the key takeaways from our 2021 Practical Cloud Journey. 

User Value 
Your cloud journey should start with the specific benefit that you want to provide to your end users, preferably described as a “business goal” or “user benefit.” Context is key. Doing things out of context of user value and business outcomes will cause you to miss the point. 

For example, consider when we build a sketching app for the CAMA industry. It’s got all the right DevOps-y things going for it, it’s doing some neat stuff with functions as a service and we’re modernizing the code base as we go. But what do users value? Availability, simplicity and predictable operation—in other words, making sure it is not buggy and works as intended. How do those user values inform our design? Well, when Amazon Web Services had a significant regional outage earlier this month, we looked at how that affected availability and had to decide whether to make our sketching app a multi-regional app. What complexity would that add? Was it a decent complexity-to-cost tradeoff as compared with the impact it would have on users? 

Focusing on user value helped us make the right call. 

Keep it Simple Until You Can’t
We talk about what we call “boring solutions” on the Woolpert Cloud Solutions team. That does not mean we’re boring or unimaginative people! Instead, it comes from experience and not wanting to overcomplicate problems that often have a simple, although sometimes less exciting, solution. 

Complexity really carries a cost. Every step in a different direction comes with hidden work: a new programming language, platform, service, approach, technique. It all adds up on day two when you must maintain and iterate on your cloud solution.

A good mental model is the technology radar. We encourage cloud architects and friends to read widely and to experiment in new areas (Web3, anyone?!) Being informed and up to date is crucial. But you don’t immediately do production work with everything on the radar; it must earn its place in your toolkit. 

Simplicity often means that you are focused on solving the real customer or user issue rather than picking one tech stack over another. It’s a point that we made in April when we discussed the new variable in build vs. buy. We proposed that SaaS offerings from cloud product vendors can substantially decrease their complexity, while at the same time ceding control (and headaches) in return for focus on your core business value. 

For example, we switched from an on-prem Microsoft SQL Server instance to a Google Cloud SQL for SQL Server database as a service product. It was an absolute joy to stop worrying about database backups, latency, availability and the like. We traded the complexity of ownership for a paid service, and we love the bargain. You can listen to that story to learn how we made the decision. 

Culture of Learning
Devising a successful plan stems directly from having a culture of learning. Cloud is different. Even the most basic assumptions you have about how systems works may be incorrect between on-premises and cloud, or between public cloud vendors. Learning by doing (dabbling, experimenting) and learning by studying (taking a certification exam, attending a local user group, etc.) are basic assumptions on the Woolpert team. 

We also learn as a team. One strategy that works well for us is to collaborate on architectures and solutions. For example, David Hollema provided good tips on how to approach cloud native architecture. But he didn’t mention in that blog was the time spent sharing and debating the GeoAwareness architectural choices and tradeoffs with the team. That included hands-on experimentation with various tools to ensure the architecture was solid before he wrote a line of production code. 

Table Stakes 
Call it “table stakes” if you play poker, or “meat and potatoes” because you think it’s a solid meal, but in the cloud world, basics like security, governance, policy and compliance are non-negotiable. 

Stuff happens. As I’m writing, the Log4Shell exploit is ruining the best laid plans of incident response teams to have a quiet end of the year. How would your team respond to this incident? Could you determine whether the affected library is included in your software supply chain? Could you find instances in production? The best approach is to have a structured, documented and preferably automated set of patterns and practices. This would help you interrogate, for example, a consistent set of logs for your entire cloud presence and find that Log4j dependency.

We recently completed a project called Cloud Foundations for a large organization. Rather than start from scratch, we used the Google Cloud Architecture Framework as a starting point since it covers a wide range of best practices regarding reliability, network security, billing controls and more. Our consulting team cloned the battle-tested Terraform Infrastructure as Code (IaC) modules developed by Google architects. In conjunction with our client, the team adapted as needed, lending support to Microsoft SSO, for example. It then deployed the entire infrastructure in one go. 

As a result, now our client knows that it is impossible for anyone to accidentally create a default network with the RDP port open to traffic. It may be table stakes, but it feels more like a great security blanket. And don’t skip the meat and potatoes! 

When One Practical Cloud Journey Ends… Another Begins
I really enjoyed talking with Technical Solutions Consultant Jason McCollum about data science and data engineering. My key takeaway was not to get too hung up on planning and preparation. Yes, experimentation and learning are important when the toolset, paradigms and platforms are new. But at some point, you learn a lot more by building the thing. 

Jason also talked about building a thin vertical slice of the entire solution as his preferred method, and I agree. In the 2021 book, “Agile Conversations,” authors Douglas Squirrel and Jeffrey Fredrick describe the concept of The Walking Skeleton, a phrase coined by Alistair Cockburn in the 1990s. It’s the simplest thing you can build that gives you a sense of the shape of the final result, without trying to put much meat on the bones. I think it’s quite analogous to Jason’s thin vertical slice. 

Thanks for joining us on this journey over the past year. We hope that the practical side of the cloud has been informative and maybe even fun. And if you need a hand getting started, or fine-tuning or extending, we’re always here to help at CloudSuccess@woolpert.com.