Developing Software in a Cloud Centric World
written by Shay Scarberry 9/10/2020
We’re living in a cloud world, yet companies moving to the cloud still fight the battle of legacy workloads and predictions say that 80% of Enterprise IT will move to the cloud by 2025. In an effort to prevent as much of this time consuming battling as possible, let’s talk about what it means to build “Cloud Native” Software.
What does Cloud Native Mean?
Throughout the history of software development we have seen lots of languages, design patterns, and architecture patterns emerge; we will be focusing primarily on architecture throughout this article. The availability of the cloud has inspired many good architecture patterns and building Cloud Native software means embodying those key components when designing how your software will operate.
But How Do I Do It?
Let’s say for the sake of simplicity that you have already built a successful MVP (MInimum Viable Product) or a pre-existing software that you’ve been tasked with transforming. This has a lot of implications like understanding the solution you are targeting, the logical flow of functionality, and how to write it.
Your next steps for making this are as follows:
Step One: Choose Your Service
You understand your solution and now it’s time to pick the services (services in this case specifically means the cloud services that are available in your cloud platform of choice) that best suit your needs. This step boils down one of those aforementioned architecture patterns; micro services. Does your application need microservices? If it’s cloud native it does. Seriously though, one of the key concepts of building applications in the cloud is containerization and microservices. The services available from AWS, GCP, and Azure are heavily catered toward running a stateless service that is a part of a larger stateful Solution. Look at services like AWS Lambda, GCP Cloud Functions, and Azure Functions; these are pre-built runtime environments that execute the code you write. Using these will get you doing more Dev and less Ops.
Step Two: Development Environment
It might seem a bit obvious to some of you reading this, but to write Cloud Native software you need to set up the right build environment. Each of the 3 major cloud providers offer an SDK that is rigorously developed to make using their services as easy as possible; needless to say you will want to install this. In addition to the appropriate SDK(‘s), you will likely find yourself using containers; for using containers locally (which you probably should be) you will want Docker or an alternative.
I find it to be a good practice to simulate my prod build environment as closely as possible when using cloud native services, as it can alleviate a lot of potential headache with Environment Variables, ingress/egress, and runtime quirks (cloud isn’t perfect).
Step Three: Ops not Oops.
Remember in the first Step I said “more Dev and less Ops”? It doesn’t mean there aren’t any Ops to be done, it’s just done more efficiently. To make this more efficient you will need to adopt DevOps principles and use things like IaC (Infrastructure as Code) and a medium for CI/CD (Continuous Integration / Continuous Deployment), I personally prefer Terraform for IaC and GitLab Runners for CI/CD, but to each their own.
If you are reading this and haven’t heard of these technologies / principles it will majorly benefit you to do some research.
Building out your Infrastructure as Code and creating your CI/CD pipeline up front means you’ve done the bulk of the Ops work, and will only need to make minor changes to those portions of your overall application as you build your application at the Speed of Cloud.
In Practice
To put these concepts into practice, a simple and common application to put in the cloud is a static website like a blog or product page. Building the application with words, it comes out something like this:
- Infrastructure:
- IAM User or Service Account (In depth topic for another day)
- AWS S3 (Where our website is stored and hosted)
- Route53 (custom Domain)
- Cloud Front (only if you need HTTPS, highly recommended*)
- Website Code:
- Static Site Generator (SSG) like Hugo, Gatsby, or Next.js
- Ops:
- Use Terraform to create your AWS Infrastructure components (more mature environments also deploy Terraform with a CI/CD pipeline separate from the application).
- Create a CI/CD Pipeline that does the following:
- Build your website using the appropriate commands for your SSG.
- Authenticate to your AWS environment.
- Copies contents of your built website (usually “/public”) into the bucket.
Ultimately it ends up looking something like this:
I’ve mentioned a lot of technologies in this article and almost nothing about security, which is a crucial part of the development process, and can drastically slow things down. This major intimidation factor deters companies and individuals during the decision making process a lot of the time. With our help and security tooling, you can spend that valuable time saved scaling at the speed of cloud.
