Part one: cloud computing
Cloud computing is technology owned by another organization, the cloud service provider, made accessible over the internet. Cloud computing services can be delivered in a few different forms or levels of abstraction, such as infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS).
IaaS provides access to virtual private servers (VPS) and virtual private networks (VPN) where cloud providers take on the responsibility of provisioning the hardware and virtualization technology for customers. Customers are then responsible for installing application software required to deliver technology like web servers (Apache, Nginx), application servers (Tomcat, Gunicorn), databases (Postgres, MySQL) or messaging (RabbitMQ, Kafka).
PaaS is an abstraction on IaaS where cloud providers offer commonly used technologies, often referred to as stacks. For example, a PaaS provider may offer a Python platform service with a Nginx web server plus a Gunicorn application server for executing code in commonly used Python frameworks like Flask, Django or FastAPI.
SaaS represents the highest level of abstraction that cloud providers offer, but it’s also a rather broad category. In its simplest form, SaaS offers the ability to run user-supplied code to carry out specific functionality often referred to as a function as a service (FaaS). Popular examples of FaaS are AWS Lambdas, GCP Cloud Functions, and Azure Functions. On the other end of this spectrum are full business capabilities like internet-based payment processing offered by companies such as PayPal, Stripe or Venmo.
What’s driving the demand for cloud computing?
The cloud computing industry has achieved significant success over the last decade with total revenue nearing $100 billion in 2022. Let me describe the benefits I’ve seen using cloud computing as a means for delivering technology solutions, which seem to be driving this breakneck demand and paradigm shift in how we deliver software.
Time to market and focus on business capabilities
In my experience, time to market tends to be the strongest constraint I see placed on projects. I’ll do this by contrasting the process of delivering an application to a traditional on-prem platform versus that of a cloud-based platform.
First, let’s level set. There are an overwhelming number of factors that go into delivering even relatively simple business apps like hardware for servers, networking and storage technologies. These require people with specialized skills to operate them either by staffing technology specific teams in more established organizations or relying on survivalist developers who learn just enough of all these areas to get the job done. The specialized teams often encounter cyclical working patterns while the survivalist developer battles with making risky trade-offs especially when under tight timelines.
When delivering technology on the cloud, much of that headache goes away. This is particularly true in the case of PaaS and SaaS solutions where delivery is focused on building business capabilities through composition of other existing capabilities. This removes the need to rely on work queues across specialized teams as well as the need to learn lower-level technologies to operate hardware and servers. The result is much faster technology delivery focused on business capabilities.
Reduced barrier to market entry and consumption-based costing models
As described earlier, the traditional on-prem model of technology delivery required the burden of recruiting and staffing pools of technologists highly specialized in narrowly focused areas like hardware, networking, servers and storage. On top of that, the physical hardware resources had to be purchased as a capital expense requiring complicated accounting and assembly by their respective teams before a single business application can ever be presented to a user.
To entrepreneurs, this upfront investment in technology capital just to enter the market before truly understanding the demand of new products and services represented a significant risk. Not only did it require significant capital to even attempt, in many cases the amount of time that elapsed before their product or service could be delivered made it difficult to pivot or modify. In some cases, other competitors beat them to the punch.
In most cases, delivering technology solutions on the cloud involves a shift to a consumption cost model where the business only pays for the service it used. This means that entrepreneurs have greater ability to experiment by delivering products and services over cloud services provisioned on demand. In this way the business can closely monitor the success of products or services, modify the offering or shut down the service and try something else to minimize the risk of sunk capital. On the other hand, if the product or service is successful more cloud services can be proportionally consumed, which is likely to be balanced by the increased revenue from the product or service’s success.
Engineering innovation
I previously described the innovative potential for entrepreneurs resulting from reduced barriers to market entry through the on-demand ephemeral nature of cloud services, but here I’ll focus on another aspect of innovation that is near and dear to my heart as an engineer, technical variety. The cloud has led to a huge breadth of technical selections to experiment with and build the best possible solution given the myriad of different constraints or trade-offs we face.
The major cloud providers like AWS, GCP and Azure have all made a variety of technologies easily accessible, which can be provisioned and deprovisioned in minutes using APIs or infrastructure as code (IaC). A large portion of these technologies are simply managed offerings of popular open-source projects that are well known with strong community support.
In usually only a few dozen lines of code or clicks of a mouse, I can provision popular infrastructure components and experiment with how they can be put together to evaluate as a solution for a particular opportunity. In the traditional on-prem model, such experimentation and learning were a real challenge because of the complexity of sourcing and installing software dependencies, exacerbated by limiting constraints around hardware availability.
Thanks for reading part one! Don’t miss part two where we cover various systems integration techniques, plus best practices for supporting cloud engineering and systems integration. Look for part two next week.