Although cloud growth has slowed recently, the future is still in the cloud. New and existing companies continue to opt for hosting their servers in the cloud, so they don’t have to worry about maintaining them on-premises. Some companies use a hybrid approach, keeping some of their computing or storage infrastructure on-premises, with the rest in the cloud. There are also many companies that use more than one cloud vendor at a time.
Whichever way you slice it, cloud vendors such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), are undeniably popular and an essential part of the business landscape. To take advantage of the hundreds of services and benefits that cloud providers have to offer, it takes talented cloud engineers who can interact with the cloud and get the business’s cloud infrastructure set up in an optimized, cost-efficient manner.
Knowing how to work with the cloud is important for any software developer looking to advance their career and expand their breadth of knowledge. Many young developers today, including myself, come into the workforce after graduating with minimal to no cloud experience at all. The only inroads that seem to exist for getting exposure to the cloud appear to be studying for and obtaining the respective cloud provider’s cloud certifications. However, often those certification exams only consist of theory and do not provide the developer with any hands-on experience. Developers are always striving to learn a new framework or programming language. We can do the same thing with cloud services!
Below are a few of the cloud service architectures that I have previously worked with myself. These are good introductory stacks that are relevant to web developers and can help you get your feet wet. Since most of my experience and credentials involve AWS, that is the cloud provider I will be going over here. However, if you are more interested in Azure or GCP, know that there are equivalent services to most of these common AWS services that I will mention. For example, AWS Simple Storage Service (S3) Buckets and Azure Blob Storage are both very similar services involving object storage and static website hosting.
S3, API Gateway, Lambda, RDS
This is one of the most popular cloud infrastructure stacks for any simple Create, Read, Update, Delete (CRUD) app, and personally my favorite. This serverless architecture is quick to set up, scalable, and cost-efficient. S3 is an object storage service that can also act as a static website host with just a quick configuration change. S3 is the most cost-effective and lightweight option when hosting static single-page applications (SPA) built in React, Angular, or any other popular JavaScript framework. The front-end stored in S3 calls out to the API Gateway where all of the application’s REST api endpoints are located. An Application Programming Interface (API) is the interface that bridges communication between the front-end and back-end of a web application. It is a crucial part to any application, as without APIs the user interface would have nowhere to go to get any dynamic data it needs to display!
Now, Gateway triggers a Lambda function, which allows you to run your back-end code, using nearly any programming language, without thinking about servers at all. Just type your code into the Lambda text editor or upload it as a zip file and click run! It is convenient to use these two services together, as they break up the logic between the APIs and the rest of the server side code.
This is the paradigm of a “Microservices” architecture, to break up as much of the application as possible into many standalone components or services that serve a single purpose. This is the opposite of a “Monolithic” architecture, which is an application that has many tightly coupled and intertwined parts that depend on each other. Setting up an application in the cloud lends itself well to following a microservices architecture, which is beneficial for larger size applications with many moving parts since you can modify and scale each part independently without affecting the rest of the application. Monolithic architectures tend to be better suited towards smaller applications where it might cause unnecessary development overhead to break up the application’s parts since it is already smaller and more manageable.
Lastly, the Relational Database Service (RDS) provides an easy setup for whichever SQL database you want to use. It is fully managed, meaning that AWS will handle all the administrative tasks of the database so you can focus on handling the data. RDS integrates seamlessly with Lambda making data transfer between the two services painless. In this instance I needed an SQL database and didn’t need to pay extra for performance, so RDS was the best-suited option for this. If I was willing to pay more for stronger performance, then Amazon Aurora would have been the best option for hosting my SQL data. If a NoSQL database option is needed, Amazon also provides plenty of services for that such as DynamoDB for key-value style data, DocumentDB for document style data, and Neptune for graph-style data.
Fargate, API Gateway, Lambda, S3
This was the first cloud infrastructure stack that I ever helped build in AWS! The application consisted of a simple page with a form where the entered form fields would then be taken and applied to several documents that also required those fields, finally spitting those documents out in PDF format back to the user. The front-end page was built using the lightweight Python framework of Flask, wrapped in a Docker container. We were able to take that container image and easily deploy it to Fargate, which is a serverless engine for containers. In other words, it is the preferred lightweight option for hosting apps wrapped in container images.
Our team originally tried to host this Python web app using S3 static website hosting like in the stack above, however, the application was too dynamic since it was a front-end and back-end combined as one, unlike an Angular or React app that is just HTML/CSS and JavaScript for the browser. In this scenario, we did not necessarily need to create a Docker image to wrap the Flask app in, but since we were in an educational setting and wanted the experience, we did it anyway. A container is an isolated environment that holds an application and is agnostic to where it is hosted, allowing for easier deployments and scalability.
The deployed Python code shot its form data through an API Gateway to a Lambda function. This specific Lambda function used a Node.js runtime and built the PDF of all the documents using the form data.
Lambdas are a great way to host your specific back-end functions that only need to run asynchronously, like in response to an event. This is opposed to hosting that same code on an Elastic Compute Cloud (EC2) instance. Which is better purposed to run operational code consistently over an extended period. The EC2 service also comes with the baggage of the user having to maintain and provision all the configuration and infrastructure of that server, such as memory, processing power, networking, etc. All the stacks I mention in this article are serverless because I am not a fan of having to make those fine-grain configuration choices for any type of server!
Next, the Lambda sent the PDF file to an S3 bucket where it would be stored. Notice in this case that our S3 bucket is being used specifically for object/file storage vs static website hosting like in the stack mentioned above. After all this took place, the user would then be able to access the PDF file stored in the S3 bucket via a link back on the user interface.
Elastic Beanstalk
This service is great because it uses another AWS service, CloudFormation, to deploy an entire cloud infrastructure stack of configured services all at the same time. Elastic Beanstalk is perfect for allowing developers to deploy their web applications quickly without worrying about setting up any of the infrastructure. It gives more time to the developers to focus solely on their code and enhancing the application itself. Simply choose your platform, upload your code, select any extra infrastructure configurations if you want, click deploy, and voila, your app will be up and running!
The drawbacks to this service, noted amongst the developer community, are that sometimes the deployments are unreliable, and that there is a lack of documentation provided around stack upgrades or deployment failures that occur. Overall, this service is the best option for developers who want their full-stack applications up and running quickly, along with their configuration highly abstracted and centralized.
Route 53, S3
Say you have a personal website that is a purely static informational site, you recently registered a domain for that site, and want to deploy it to the internet using an AWS cloud infrastructure for cheap. Route 53 is a handy Domain Name System (DNS) web service that will connect your domain names to the IP addresses of whichever internet applications they need to be matched up to. For example, with DNS “142.251.46.206” becomes “google.com.”
In this scenario, the personal website can use S3 static website hosting which we discussed earlier. Set up the routing between that S3 IP address and your records in Route 53, and you will be good to go!
Wrapping Up Cloud Infrastructure Stacks
It can be an intimidating process for any developer to figure out how to start getting their hands dirty in the cloud. There are a countless number of flashy services for each cloud vendor making it overwhelming to figure out which ones best pertain to what you are trying to accomplish. Whether by developing an entirely new web app in the cloud or moving an existing web app to the cloud, the introductory architectures mentioned above are solid ways for any developer to begin their cloud journey. Once you start to master these basic cloud services and branch out into more specialized services, the number of tools in your developer toolbox becomes an endless possibility!
