The Architecture of the Cloud: Designing a Solution for Clear Skies Ahead
In the first installment in our A Practical Cloud Journey blog series, Woolpert Cloud Solutions Director Dylan Thomas provided practical considerations for the planning stage of your cloud journey and provided an orientation for the trek. In this post, we give you pragmatic advice for solution design. Let’s hit the trail! First Stop: cloud architecture—with your guide, the cloud architect.
Do I Really Need a Cloud Architect?
In our agile, tech-savvy world, the need for a cloud architect is sometimes met with skepticism. But a cloud architect is professionally adept in this space. He or she can help you wade through your specific business and technical needs, map them to a proper solution design, provide counsel throughout the construction effort and inspect the build. The cloud architect creates order out of chaos. We see the architect as a key contributor to project success by maintaining vision and acting as a communications conduit between the business and engineering folks. These are difficult tasks for an agile software developer to tackle alone, not necessarily due to lack of skill, but rather due to a misalignment of scope and purview. We recommend having a hands-on cloud architect.
At the outset, a project’s scope and goals are often fuzzy. We need to figure out what’s most important to dampen the noise and amplify the value. Begin with understanding the business drivers, or the whys. These drivers have roots in your digital transformation strategy. Examples of these include, “minimize time to market” or “increase system reliability.” To materialize these drivers in tangible form, product leads and other influencers may participate in drafting service-level indicators (SLIs), objectives (SLOs) and agreements (SLAs). Technical requirements also need to be discovered. For example, it may be critical to build with a certain software stack (LAMP, .Net) or an open-source component such as Kafka for event streaming. These must-haves relate to a variety of reasons, including skill sets of existing personnel and integration with on-premises solutions.
The Drawing Board
Now that we know what’s important and why, we can begin mapping the system requirements to a design and sketch things out.
We stay oriented along our journey by following design principles. The three major cloud vendors publish frameworks, which are checklist reminders of the multiple facets we need to consider. Google Cloud’s Architecture Framework identifies the following principles of system design: operational excellence; security, privacy, and compliance; reliability; and performance and cost optimization. Remember these principles and revisit them at each stop along the way.
Recognize What We’re Building
Now that there is a clear understanding of the big picture, it’s important to recognize what type of solution we’re building. If we can identify an archetype, we can lean on reference architectures to jump start our design work. Is this an IoT ingestion platform with a streaming analytics component? Are we lifting an existing on-prem enterprise system wholesale to the cloud? Does it lend itself to a microservices design, built with container technology? Or, is this a machine learning/artificial intelligence project? Our solution may not fit into any single box. If that’s the case, we decompose it until each subsystem resembles one of the archetypes.
Charting the Course
We can use existing models to help identify which path(s) will get us to our destination. The many “Rs” mnemonics are useful here: rehosting, replatforming, refactoring/rearchitecting, repurchasing. These paths cover the common routes to reach the summit in a cloud migration, and they come with guidebooks—patterns and best practices.
Next, to build our planned components, we shop for public cloud products and services. You may want to sit down, the menu is long! It’s easier to digest if you group items along two dimensions. One dimension is service type: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), Function-as-a-Service (FaaS), etc. Another dimension is service function: storage, compute, database and networking. Fortunately, there are comparable offerings across the three major cloud vendors. Once you learn one vendor’s menu, it’s not difficult to interpret another’s. See Google Cloud for AWS professionals or Azure for GCP professionals to help with that translation. There are both substitutes and complements for nearly every service.
A Practical Example
Woolpert built the GeoAwareness solution to help businesses optimize customer service as curbside pickup demand surged. The business drivers repeat from customer to customer, and they can be captured as key performance indicators. Examples include reducing customer wait times, improving customer satisfaction and reducing abandoned orders. As GeoAwareness matures, these KPIs can be made tangible as SLIs/SLOs/SLAs to directly link business drivers to system performance. Since this was a new solution and not a migration, a cloud native architecture was possible.
Technical requirements included:
- A RESTful interface to support multiple sensor and client types
- Latency below a few seconds
- Ability to host within a customer-owned GCP project
- Ensuring no messages would be dropped
As we planned for the solution, the orienting principles that remained front and center were performance, reliability and cost optimization. We estimated cloud spend with the GCP pricing calculator for the 100th largest restaurant by revenue. And since this was built as a demo, speed and ease of build were also paramount. Any intentional omissions were recorded as technical debt to be addressed in a production build. We evaluated each of our choices below based on these factors:
- Prefer managed services for their ease of operations, autoscaling capabilities and built-in redundancy
- Prefer zero-cost services during standby periods
Our GeoAwareness GCP choices included:
- Compute: Containers running on Cloud Run and GCE
- API: Cloud Endpoints
- Messaging: Pub/Sub
- Database: Cloud Datastore
- Web Application: App Engine (Paas)
- Analytics (future): Dataflow & BigQuery
Designing a cloud solution that will best fit your needs is both an art and science. There’s no one-size-fits-all solution. It’s easy to get stuck in a phase of analysis paralysis, but you just need to keep moving. It’s good to have placeholders in the design for future expansion but plan lightly for things you may never need. Keep things simple, measure and revise your course based on constructive feedback.
And remember, Woolpert is always here to help you summit—fully hydrated and sunburn free.