What do architecture and cloud architecture have in common? It’s a good question! (And one we hopefully have an answer for given we made this whole post about it.) Here are five things a cloud architect can learn from Frank Lloyd Wright.

This post was created based on Joe’s talk at the ACG Community Summit. You can (and totally should) check it out here. The content below has been edited for clarity, brevity, and/or general awesomeness. Any mistakes are likely on the part of the editor, not Joe.

The principles of organic architecture in the cloud

You may be into architecting for the cloud. (You’re reading a blog post about it, after all.) But even if you’re not into architecture in the traditional sense, you’ve probably heard of Frank Lloyd Wright. 

Frank Lloyd Wright architected over 1,000 structures. He was active creatively for 70 years, he influenced generations of architects, and he started his own school of architecture for training architects. (So… he was a training architect too? Cool! I’m in great company.)

What does Frank Lloyd Wright have to do with the cloud? We’re getting there!

Frank Lloyd Wright called his design philosophy “organic architecture.” And there are many parallels between organic architecture in the physical world and to the world of cloud computing architecture — specifically on Google Cloud.

In this post, we’ll talk about architecture — in the designing of buildings and in the cloud computing solutions sense, and how the two are maybe more similar than you might expect. We’ll look at some of the principles of organic architecture and see how we can apply those bits of architecture wisdom to building in the cloud — whether you’re just considering which Googe Cloud certification is best for you or looking to create your Google Cloud masterpiece.

1. Deeply understand your materials

Once you know the characteristics of what you’re working with, it can lead you to interesting (and novel) solutions. 

Take for example the Guggenheim Museum in New York City. The primary material that makes up the Guggenheim is concrete. Concrete flows. And that inherent movement can form curves and spirals, leading to an artform that houses other art. 

How can we apply this approach to Google Cloud?

• Know your materials’ properties and benefits
  Just as building architects have to know their materials and their properties and benefits, the Google Cloud architect has to know the available GCP services, their primary uses, what they do well, and what they don’t do well. Knowing all of the GCP services is really a baseline requirement for a GCP architect.

• Choose materials based on their strengths
  Next, you want to select materials based on what they do best. For the Guggenheim, concrete was a natural choice because it had the fluidity that Wright wanted to incorporate into his design. For the cloud, you want to incorporate the most appropriate service.
  
  For example, let’s say your team needs to transfer their Apache Hadoop data pipeline ETL capabilities to the cloud. Google has two really terrific data pipeline services: Dataproc and Dataflow. Which do you choose? (Dataproc, right? It too is Hadoop-based and would make for an easier transition than Dataflow.)

• Use the fewest materials possibleAnother related principle is to use the fewest number of different materials possible. This simplifies design and portrays its essence without unnecessary busy work. In the cloud, this approach leads to greater efficiency — especially when it comes to that most important resource: personnel. The fewer technologies involved, the tighter the organization.

2. Be mindful of grammar in architecture

Another organic architecture principle that resonates in both forms of architecture is grammar.

Each building has its own grammar — its distinct vocabulary of pattern and form. You can see this in works of Wright’s like Taliesin East and Taliesin West. The form, the elements, the total design of the two structures are wildly different. But at the same time, each is consistent within itself. 

The commonality and specificity of grammar bring to my mind one of the key tenets of DevOps, in general, and, in particular, Site Reliability Engineering, which is an integral part of Google Cloud architecting. That is: by finding systems that share your languages, tools, and methodologies, you can do three things:

• Make the most of those resources
• Keep away the differences that can cause difficulties 
• Get everyone on the same page working toward a common goal

Get the Cloud Dictionary of Pain
Speaking cloud doesn’t have to be hard. We analyzed millions of responses to ID the top concepts that trip people up. Grab this cloud guide for succinct definitions of some of the most painful cloud terms.

3. Megre form and function 

You’ve likely heard the phrase “form follows functions.” This comes from Louis Sullivan, who believed that the purpose of the building should be the starting point of its design. Frank Lloyd Wright worked for Sullivan, but he didn’t just blindly follow his mentor.

Wright felt that form and function should be one — especially when it comes to the building and its location. You can see this in the Wright masterpiece Falling Water.

Wright’s client bought this property thinking he would build a house with a view of a waterfall. But Wright designed the house on top of the waterfall.

Just as Wright saw a relationship between building and site, I see a strong relationship between the cloud solution and the company you’re architecting that solution for. Let’s break that down.

• The building enhances the site
  Likewise, any cloud computing system should serve the organization for which it is intended. Maybe that seems like a given, but it’s really easy to lose sight of that concept under the pressure of coming up with computer system design that fits the requirements. You might come up with a solution, but is it the solution that’s right for the company?

• The nature of site defines the building
  On the cloud computing side, I take that to mean work with the company where it is now. If they’re in the middle of an initial cloud migration from on-prem to cloud, you’re probably going to make different decisions than if they’re maturely along the way on their cloud journey and looking to increase efficiency and reach.

• The building is unique to site
  Just so, your cloud architecture design should be unique to the company and project at hand. Customize. Customize. Customize.

Post-COVID DevOps: Accelerating the Future
How has COVID affected — or even accelerated — DevOps best practices? Watch this free, on-demand webinar with DevOps leaders as we explore DevOps in a post-COVID world.

4. Give shelter to your creation’s inhabitants

Let’s tackle one more principle of organic archaic: shelter. Wright said, “A building should convey a sense of shelter, refuge, or protection against the elements. Its inhabitants should never lack privacy or feel exposed and unprotected.” How does this apply to cloud?

• “A sense of shelter“
  I see shelter, and I immediately translate it into security. You have to always, always keep security at the forefront of your mind when architecting cloud computing solutions. It doesn’t matter if you set up the proper Kubernetes engine cluster configuration if you leave the network wide open for bad actors to act badly upon.

• “Protection from the elements”
  You don’t have to be on guard just against humans — it’s nature, the world around you, and the other systems you rely on. Google Cloud has a high degree of redundancy built into many of its services, which you should definitely take advantage of. And also add in additional failsafe or fallback mechanisms that are appropriate.

• “Never lack privacy or feel exposed”
  This is the age of governance, risk, and compliance — especially for multinational companies that serve a global marketplace. Many nations have very specific rules and regulations to protect citizens. If you are to offer your applications to those areas, you have to be aware of and compliant with all of them.
  
  Google Cloud has terrific cryptographic functionality for data both at transit and at rest. But you should be savvy enough as a Google Cloud architect to scrub sensitive data that lies outside of those controls. For example, take user logs, where you’d want to take advantage of Google Logging agent’s Fluentd capabilities. This takes knowledge, attention to detail, and follow through.

5. Iterate, iterate, iterate

There are a great many other principles from Frank Lloyd Wright that evoke similar concepts in architecture on earth and the cloud, including concepts around space, proportion, scale, and simplicity. But the key thing to remember is, as Wright wrote, “The complete goal of the ideal of organic architecture is never reached. Nor need be. What worthwhile ideal is ever reached?”

Or, in my words: Iterate. Iterate. Iterate. Keep optimizing your solution and continue to make your systems as fault-tolerant as possible.

I hope these ruminations are helpful for you for giving you a fresh perspective on architecting solutions for the Google Cloud Platform!

Build a better career in the cloud.

Learn more about Google Cloud, cloud architecture, and the most in-demand tech skills with A Cloud Guru. Check out this month’s free courses or get a free 7-day trial.