There are many questions in the air when it comes to architecting your application for a cloud or virtual environment. Designing with a systems thinking approach means that we want to look at our requirements, constraints, assumptions, and risks. The best way to do this is to look at a specific scenario played out which is what we are going to here in the first of our Couch to Cloud Native (C2CN) series.
Think Like an IT Architect
Before we fast-forward to the code and the fun stuff (like I often do myself), we need to start with a basic set of drawing board processes to lay out what we have to do. This begins with evaluating the conceptual architecture across four areas:
- Requirements – Business needs that define the application outcomes
- Constraints – Limitations (soft and hard) which we must work within
- Assumptions – Things we expect to be there that must be accounted for
- Risks – Clearly document which risks are present as a result of our design
These foundations will help us define the architecture and as we grow and scale things out it gives us guidance on what (and why) we are doing things in the environment. It’s particularly important that you begin with requirements that include business needs! We tend to run right to the technical features as technologists. This is our chance to elevate the approach to something that you will find in design thinking approaches like TOGAF, Nutanix NPX, and the VMware VCDX frameworks.
Our First Scenario: The Cloud Rush Application
The Cloud Rush team is a small group of folks who are building a small startup and they want to begin with their website. They hear about the throngs of people and companies who are rushing to adopt public cloud and want to get in on some revenue opportunities. You have been asked to support them in deploying a lead generation application which will gather customer information so the Cloud Rush team can contact them to consult on cloud deployments.
They are fans of Ruby on Rails, so they decided to spin up a simple VM-based environment on their current internal VMware dev cluster which they have full access to. The dev team has built up their own VM to test with among themselves. Now the dev team has a version that is ready for move to production, so they decided to just bring it up live then ask for help with solidifying the build. Sound familiar? It happens to the best teams everywhere. We call it DevOps without the Ops.
Time to reel it in and start with our cross-team meeting between the developers and the VMware operations team. This is what they got from reviewing the application design needs:
- Must be able to receive customer sign ups from the internet
- Data gathered must be stored in a shared database for data mining and sharing with other applications
- There will be no single point of failure
- Application must be hosted in a private data center for regulatory reasons
- Ruby on Rails must be used for the application platform
- Database must be MySQL to support other back-end processes and current software availability
- Phase 2 will use MongoDB for a NoSQL solution to store some data
- Infrastructure must be VMware virtualization
- Application code and supporting libraries will be available with ongoing support for production
- Application developers are able to modify application as needed for scale-out architecture
- Application may not support a scale-out design at high volume
- Testing “at-scale” is not part of the MVP and will be introduced later
Based on these findings, you and the Ops team are confident that you can map out the next steps and deliver what the Cloud Rush team needs. Now it’s time to map out the logical architecture with the information you have.
From Monolith to Multi-VM
There are many applications which actually thrive as what we call the monolithic design. They aren’t necessarily huge apps and sometimes they are. Monolith simply means that the entire application architecture and multiple components are held in a single application deployment. It’s not necessary in every case to make the move into micro-services. It’s also not necessary to use containers or functions for applications in order to make them scalable.
We want to start with the basics, so let’s stay with the Cloud Rush team example which features a VMware VM-based deployment. All the elements are supported today by your Ops team and the future state must be as well. We take the conceptual design and map it out using logical elements first.
Figure 1 - Current Logical Architecture
This may seem like a rather simplified view. This is why we can take the logical architecture a bit further by looking at the current physical layout of our mini-monolith.
Figure 2 – Current Physical Architecture
It’s still a very simplified delivery in a single VM. We now have the products mapped in to the application layers and we can go back to our requirements, constraints, assumptions, and risks to break this app out to meet the desired outcomes.
Our dev team discussion highlighted a rather important requirement with there will be no single point of failure. This is the one we have to focus on throughout the design process. Based on the other two requirements, let’s quickly map what a physical design would look like bearing this in mind.
Figure 3 – Desired Physical Architecture
That escalated quickly. Don’t worry, though. All these moving parts have been put together in order to eliminate the single point of failure while meeting the other requirements and constraints. We also gained some future infrastructure because we are building potential shared services with our SQL cluster and our NoSQL environment. This is a bonus of our systems thinking approach.
Now is the time to also stop and remind ourselves how we can do this more effectively to achieve a successful outcome for not just a single implementation, but for the ongoing life of the Cloud Rush application.
Setting Up for Systematic Success
Building the future state environment manually is definitely doable, but not desired. Now you have a chance to work with the dev team to do something that is more future proof. We like to call this part “slowing down to speed up” because it lets us do work up front that removes unnecessary steps and pain down the road.
- Codify the deployment and operations where possible
- Use collaborative tools for code and documentation
- Use systems and environment variables to store secrets
- Unify the approach across every environment
- Test, Test, Test
- Automate wherever possible
Now you’ve got your architectural mind warmed up and our next post will cover how we map out these conceptual design elements into the physical deployment and how our systematic approach will be used. This also means we are getting to the products and code that will help us deploy the Cloud Rush application and up our own Infrastructure-as-Code skills as part of the process.