Building a Cloud Native App

TLDR: I built a cloud native application and it wasn't easy but it sure was fun, here is the link: https://sam.askjohnwhite.com/

What’s the deal with cloud native? Every pundit and new age cloud expert is telling the enterprise to ditch their monolithic applications and refactor their application to be cloud native. It sure sounded easy, so I wanted to give it a shot and find out exactly what it meant to build a cloud native application.

Since I was a teenager I have followed the same process to deal with this technology addiction I suffer. Read, dream, obtain, apply, and talk. For years I have been reading and dreaming about cloud native applications. They actually could solve insane huuuuge problems for us like world hunger or cancer one day. Using mass computers without bounds is just a crazy concept to think about and we have it here and available today. Obviously, reading and dreaming needed to stop and I finally needed to start obtaining and applying. Let me give you details about that journey and walk you through my first cloud native application.

Obtaining

Before I could apply this knowledge, I had to obtain on the tools necessary. My desired toolbox consisted of a few items.

1.    Cloud. I needed a platform to develop against, so I started with AWS, Google, and Azure. To get an understanding of each them I followed a pretty simple process. Sign up for accounts on each, play around with the interface to get a basic hang of it, watch a few YouTube videos to get a head start on the tips and tricks, browse their native documentation, and then head to third party tutorials to perform some basic function in each environment. In the end, I hated Azure’s interface so that was a quick nix, Google worked great for running VMs and containers. When I started to focus on functions I couldn’t find enough reference material to make it easy. I finally settled on AWS as I could quickly navigate the interface, I found tons of tutorials to walk me through getting started, and after heading to Re:Invent for two years I had a community to help with any problems I ran up against.

2.    Programming. I have been programming or hacking as some would call it for 20 years. I understand what I want to do I just didn’t have an understanding of some of the newer languaes to make it work. Two languages I thought I needed to know were Python and Go. At first glance of each, I gravitated towards Python as I was very familiar with Perl and it felt similar. To get an understanding I took the Google course on writing Python. It took me a few days to complete and I was comfortable writing code quickly. Go is still on my list and Kelsey Hightower did make a recommendation on where to get started, just need the time.

3.    Micro-services. I realized quickly that one of the keys to making a cloud native application was to understand the concepts of micro-services. I watched this tutorial, and quickly got the hang of it. The micro-service concept was really no different than object-oriented programming I learned in college. Passing variables via GETs and PUTs was really no different than passing variables via classes.

With that phase complete it was finally time to start applying. First, I needed an app to write. Something I wrote a few years ago to explain the purpose of containers and function as a service was an app that provided random phrases said by my colleague Sam Sarnicke. I thought it would be fun to evolve that app and include videos. After a quick conversation he was onboard, and it was on me to build the app. Here is my process on how I went about it.

Applying

1.    Sketch - I sketched out my micro-services and the basic framework of the application. Here are the services I needed to create:

• Website – I needed a place to launch an index page to present quotes and videos
• CDN – I needed a place to serve videos
• Randomizer – I needed a place to build arrays of data and present them back to the website to give the user new random quotes and videos on demand

2.    Building

• Website - The way my brain works I get excited with some visual wins to get going. I am not a person that can code the whole thing first and then see if it works or not. I read a post about using an S3 bucket as a website, so I thought I would give that a try. Walked through the documentation and got a basic index.html up and running in 10 minutes or so. My only hurdle was that I forgot to make the index.html publicly accessible the first time. Just because the folder is publicly accessible doesn’t mean your uploaded content is by default. While I was building everything else, I had my talented friend and colleague Nick Leaf make me a pretty front-end interface. If it was left up to me, you would have got two buttons and basic text. His version is better.
• Randomizer – This is the meat of the app and the area I struggled the most to get it all working properly. I will break it down into the three main parts.
• Functions – Easy peasy as my kids say. I created two functions in Lambda, one to return back a random text quote from an array and a second to return back a random title of a video. Each function was a few lines of Python and was very basic. I did think about putting the data in a database, but I didn’t want to add the extra cost to the app. Easy to do, and probably the better way if you are actually building a production app. Here is the code for the phrase selector:

def lambda_handler(event, context):
    # TODO implement
    #!/usr/bin/env python
    
    import random

    #Samism Selector
    samphrase =['It takes 15 minutes for me to introduce myself', 'All ships will rise', 'Buyers are liars', 'MOST IMPORTANT: Just cash the check', 
    'Fish or get off the pot', 'The hardest place to stay is on top', 'Not trying to boil the ocean', 'I asked for them to put their meat on the table', 
    'In the spirit of collaboration', 'Heretofore...', 'Directly Proportional', 'Mutually Beneficial', 'Open the kimono', 'where the rubber meets the road', 'further galvanize', 'get out in front of our skis']
    samism = random.choice(samphrase)

    return samism

• API – This was a big struggle for me. I knew I wanted an API layer so I could extend the application to other things in the future, but I didn’t really understand how it all worked. It was really simple to get the API to interact with the Lambda functions and through the test function I was able to see that I could return data by doing a GET request against a certain section of my newly created API.
• Javascript – This was my beast. Running the web page on S3 relegated me to use only JS to interact with my API as it can’t execute server-side code like Node.js or PHP. I spent hours trying code examples others created to perform the basic function of executing a GET against an API. After many failed attempts I started looking at the problem in chunks. I was running into security issues, so I fixed that with applying a cert to my API and domain. I ran into identity issues, so I fixed that my allowing anonymous connections to hit my API. After implementing those two things I finally was able to receive data back after a button was pushed to request a Sam’ism.
• CDN – This was pretty simple, and AWS has a ton of documentation to show how it works. I simply uploaded the videos to a S3 bucket, added CloudFront pointing to the bucket, and put it behind a domain. This was up and running in a few minutes.

After about 40 hours of work I finally had an app up and running. Surely, I can build it faster next time, but the learning curve was definitely steeper than I expected. After it is all said and done, here are my thoughts on the people that are preaching cloud native or bust.

1. Building a cloud native app from scratch is pretty tough. Refactoring an existing application to be cloud native must be damn near impossible or for most really cost prohibitive. I think enterprises should pause and understand the costs of refactoring. If your application is running great on that mainframe and it doesn’t really need much care and feeding it might be better to keep that running and start building new portions of your app in cloud native frameworks and leave that as the data source. 10 million to run that app for 3 years opposed to 40 million to refactor will be a tough pill to swallow.
2. Invocation is cheap! I have had the Expedient team hitting the site on a regular basis since I debuted it during the recent Sales Kickoff and I think my bill is still just a few pennies. If I was building a new app I would definitely push as much as possible to invocation functions (Lambda).
3. Cloud engineers will need to be a strange mix of infrastructure and coding. If you are heavy on one only you are going to struggle with understanding all of the concepts needed to support this new world developing. Lucky for you, many are already on the path, so tutorials and documentation is plentiful.

Please feel free to ask any questions about my journey or where you should get started. Always happy to help a fellow tech addict. And without further ado, I present to you SAMISM(https://sam.askjohnwhite.com/).