It’s time for me to properly launch Cloud Adventures. Up to this point, I’ve been running the website over a public HTTP tunnel to my local machine. Now, I want to do some real marketing campaigns to position the blog, my brand, and the Cloud Adventures’ domain in Google search and people’s minds. To achieve this, I’ll need to build the page’s software infrastructure and start using the cloud to document these adventures.
The first step to properly configure an infrastructure in AWS is to define the non-functional requirements (NFRs) of the project. These requirements come from security or compliance restrictions, and business objectives and principles. Let me guide you through my thought process to define them for Cloud Adventures. You should be able to use that to define your own project’s NFRs.
Defining NFRs for Cloud Adventures
As I mentioned in the intro post of the blog, as an entrepreneur I’ll be building API services; and, I’ve decided the target market for Cloud Adventures is going to be cloud computing. This market is highly competitive as incumbents in the industry have specialized knowledge and capabilities, and “unlimited” resources. Some of these incumbents include Amazon, Google, IBM, and even Hashicorp.
To properly compete against these giants, I will need to have disruptive go-to-market strategy by targeting small niche and underserved segments (divide et impera); and, develop an experimentation infrastructure that enables fast, reliable and secure development of services, websites, content, and marketing initiatives.
Speed, reliability and security as an NFR
When it comes to business objectives -the primary driving force for Cloud Adventures’ NFRs-, there is only one: solving a problem that is big enough with a product users love. Even tho this objective might seem simple and straight forward, in practice, it is difficult. This is the process I will use to get there: (1) identify a problem, (2) estimate the total available market and it’s growth, (3) infer the economic value of Cloud Adventures’ solution, and (4) divest or double down. In future posts I’ll dive deeper in the specifics, but for now it is enough to say that proper execution of the methodology requires me to reduce the time of each cycle (going from 1 to 4). Also, I’m broke so costs must be kept under control.
From the business objectives and methodology of product discovery of Cloud Adventures, we can derive the following NFRs:
-
The platform should enable the fast development of solutions, provide reliable usage statistics, and ensure divesting from a product is simple.
-
The system has to be reliable, as the cost of bugs in production is high. There is no time or money to waste on bug-fixing or environment downtime; therefore, the platform should find bugs early in the software lifecycle.
-
Just as failures on production are expensive, security breaches have the potential to be catastrophic due to the high fines (USD $1m +), and reputation loss. To reduce the probability of being hacked the dev team must follow secure software development (SSD) practices, the platform must have periodic and automatic checks, and workloads/environments should be isolated from one another.
The simplest way to ensure these NFRs are met, is by creating a standard platform that every product must use. Most of the time, platform teams have application teams as clients, but if personalization is allowed in the early stages of the platform, companies end up with a half working platform for every application. In Cloud Adventures, I’m going to enforce one way of doing things.
Cloud Adventures’ platform design principles
Let’s start by stating what the platform won’t be supporting: custom website designs, custom service architecture/infrastructure. There is going to be only one website design and one way of developing services.
Every website will serve as a distribution tool for interactive content which include blog posts, use case descriptions (a.k.a landing pages), and API documentation. As a content tool, the only NFR for websites is to empower marketing with easy content creation and modification, analytics, and retargeting capabilities.
Every service is going to be a monolith with access to zero or more data stores, and will serve as a tool to solve ONE problem, where the problem is a job to be done by the target persona. The NFRs for services is to provide and awesome development experience with robust pipelines and access to diverse infrastructure services.
In the next posts of the blog I’ll share the Terragrunt & OpenTofu code for the websites’ infrastructure and the results of some statistical analysis (along side the scrapers’ code) on the public cloud market. If you are interested on following along the way, don’t forget to subscribe to the news letter.