Deploy Wisely with StackScript, Say No to Azure/AWS
It is more flexible and much cheaper to use StackScripts to set up server infrastructure on Linux Cloud VPS.
In recent years, IAAS (Infrastructure As A Service) engineers (in various titles such as Cloud or DevOps engineers) are in demand. I have been deploying my (and my clients’) apps on Cloud since 2008. Because I have always done it so efficiently (and reliably), people have rarely noticed my effort on infrastructure setup. In this article, I will share my experience on infrastructure setup on Cloud.
I don’t use Azure or AWS; I tried but disliked them as they are complex and expensive. Many infrastructure engineers I met eventually got it working, but often not well, or it took them too much effort. In my opinion, besides setting up and deploying Dev, Test, Staging and production servers, real IAAS engineers (or whatever you call them) should spend >80% of their time helping to create/maintain the infrastructure for Continuous Testing. If you are an IAAS engineer who is capable of providing good infrastructure for Continuous Testing with AZure/AWS, I take my hat off to you. You don’t need to read on.
Some might argue that AWS/Azure has many features, such as dynamic scaling, … ? Seriously, do you need that? From my 20 years’ experience in software industry, I haven’t seen a single past project that required that. In fact, the simple yet intuitive approach shown in this article can cater for 99.9% web apps (excluding those with dependent MS technologies, such as SharePoint).
Two days ago, my daughter who is studying at Uni expressed her frustration in deploying her group project onto Azure. Her other team member was struggling with AWS as well for 2 days. After noticing her stress, I suggested Linux VPS providers such as Vultr or Linode. While she was aware that all of my web apps were hosted on Vultr & Linode, she was hesitant as she was already on Azure/AWS path: “Our app uses docker container, …”. I reassured her not to worry: “your app will be deployed quickly”. So we did. I was quite happy after getting positive feedback in minutes, then I got it all done in around half an hour.
As my daughter saw that I spent most software development time on Testing (using TestWise and BuildWise), she forgot that I was a capable IAAS engineer too.
This article recaps what I showed my daughter and how she did it with the following three sections:
How long did it take my daughter to deploy her group-project app in Vultr? It took her about 30 mins, after a day of frustration with Azure.
From my memory, Azure infrastructure engineers I have met were not good except one. My typical request to these engineers was to set up a testing lab, one BuildWise CT server and multiple build agents. What I wanted were just clean machines with Admin login, I would set up the software myself.
However, it always turned out to be a big hassle. Quite often, these Azure engineers said it confidently in meetings, “That’s easy, it should just take 10 minutes”. In reality, I often needed to wait for several weeks with numerous request emails.
Showcase a setup and deployment of a Ruby on Rails app, all under 14 minutes
Make App Deployment fast, really fast! In seconds!
How? By using Stack Scripts
A stack script, also known as a Startup script, is run automatically after a VPS (Linux) instance is initialised.
1. I asked my daughter to sign up for an account on Vultr
Standard procedure and a credit card was required.
2. Create a Stack ScriptJust add the commands she used to install Docker there.
A note here: redirect the execution output to a file /root/stackscript.log for checking progress or errors. The log function prints out step information.
#!/bin/bashexec &> /root/stackscript.loglog "Updating System ..."
yes Y | apt-get update3. Deploy a VPS server
Then follow a simple, intuitive wizard to create a new server instance. She chose the latest Ubuntu Linux.
4. SSH into the server to verify
Click ‘Deploy Now’.
It takes about 1 minute for Vultr to get the server provisioned.
Once the server is up and running, SSH in.
Firstly copy the server’s IP address, then type the following command:
ssh root@IP_ADDRESSIf the certificate ( ~/.ssh/id_rsa.pub) is provided (see the animated GIF above), and you can get in straight away. Otherwise, supply the password which can be copied from the server instance page.
5. Monitor the stack script execution
Check the /root/stackscript.log to find out if there are any errors from the steps in the script.
tail -f /root/stackscript.log6. Refine the script and Re-install the server
It will usually take you several tries to get it correct. Once you are SSH-ed in, you may try out the new command to see if it runs as you expected and add it to your stack script.
To verify the updated version of the stack script, click ‘Server Reinstall’. This will wipe out the files on the server and rebuild from scratch, including the OS. The IP address will be retained, which will be handy.
7. Her app is up and running
Her group project app is now running (in two Docker instances) on this Vultr instance. It didn’t take long for that, maybe just over 30 minutes.
Showcase: Set up a new Ruby on Rails app server < 14 mins; Redeploy < 10 seconds
The above is my daughter’s first attempt at deployment using StackScripts. What about real complex apps? It will be the same though there will be more steps. I have been using this way for all kinds of apps for over 10 years.
Last night, I took the opportunity to update my existing Ruby-on-Rails stack script, which was set up to run a Ruby-on-Rails app from scratch and without human intervention at all. (No Docker containers are used)
1. Deploy a new Server
2. The server instance is provisioned.
Now, run the stack script.
3. SSH into the server.
Check the execution output of the stack script, in progress …
4. Nginx Web Server is up and running
5. Ruby (latest) is installed
I could use Ruby which comes with Ubuntu, but I prefer the latest version 3.0.2 which means compiling from source code (it takes quite some time).
5. Compile Assets (JS and CSS) for the app
6. Stack Script execution completes
7. The Rails App is up and running
All under 14 minutes. Please note, I am using the lowest machine spec: $6 per month.
Make App Deployment fast, really fast! in seconds!
One common mistake for inexperienced infrastructure engineers is to rebuild the whole server from scratch. Take my Ruby-on-Rail deployment, for example, it takes 13 minutes. That’s way too long. I want it done in seconds.
In seconds? Some might wonder: “how can it be possible?”. Seeing is believing. Below is a video (in animated GIF) that demonstrates it.
The actual deployment execution time is 4.29 seconds. It will be about 7 seconds in total if adding the time I trigger a run of deploy-rails.sh .
The deploy-rails.sh is a shell script created by my stack script which refreshes the release (by getting it via Git) and performs all the necessary steps.
As you have seen, I don’t invoke the whole stack script. This makes perfect sense as I need to refresh my app, not my OS, Ruby, Nginx, Node.js, …, etc.
Q & A
1. Is this type of VPS deployment based on raw OS (Linux) a proven approach?
Absolutely. In fact, Linode started this business 5 years before Azure.
By the way, Linode's revenue is over $100 million, according to Wikipedia.
2. Will this approach work for complex setups, such as multiple app servers + Database servers?
Yes. I have set up two WhenWise app servers + 3 database servers (with master-slave backup) + Redis server. In fact, apart from Microsoft-dependent technologies (such as SharePoint + Dynamic CRM), all software projects I have encountered can be done this way.
3. Are you related to Vultr or Linode?
Not at all. I have never received even one cent for referring VPS. On that topic, I just found my Vultr Referral link and Linode Referral link, which I think both Vultr and Linode are providing free $100 credit for signing up with the referral link. But please note that the $100 credit is only valid for 30 days. Therefore, it is not as good as it sounds.
4. How about the cost, in particular the ongoing cost?
It will be cheaper than Azure and AWS. One of the many reasons I’m not too fond of AWS and Azure is the complicated pricing scheme. There are even AWS/Azure cost calculator apps!
Linode, Azure and Digital Ocean are much simpler: a fixed low fee per month. For example, the Rail server I just set up costs only $6 per month. You will see the cost in real time, and you only pay what you have used (if you destroyed one).
5. If infrastructure setup is so easy, what will IAAS engineers do?
Do what they really should be doing: help test automation and Continuous Testing. All commercial projects have worked on were lack of testing environments; no one had a dedicated test server for test automation. When I said that I used 10 test servers for WhenWise Test Automation, they could not believe it.
6. Sounds like you don’t destroy the server instance at night time?
No, I kept all my servers running. The highest VPS instance I have is only $20 per month (typically $10). Why on earth do I take my time away from writing scripts to destroy servers for the sake of saving an 8-hour IAAS fee, i.e., max 22 cents per server instance? I am sure you have all experienced the confusion and issues with the “Building instances in the morning and Destroying at night” approach. This does not make business sense at all.
Once I contracted in a project. The tech lead was a big fan of rebuilding the server instances every day. In theory, it would work. However, he was not as good as he thought. Once per two weeks on average, our main build server would be down (we all had to use that service). When that happened, many highly-paid contractors (two floors) would take a break (sometimes for hours), to save maybe $.50 per day! If I were the CIO, I would have told him: “John, I will buy you a coffee every Monday. Please don’t play with the cloud server, just leave it up and running all the time.”
7. This looks cool! But how do I convince my manager or architects?
As an engineer, I can only say this approach works as it ticks almost all the boxes (speed, flexibility, cost, reusability, …). Unfortunately, these objective measurements usually won’t help with human factors. I can give you an example.
Over 10 years ago, one .NET architect challenged me for my switching to MySQL database (from MS SQL Server) on a government project. He said: “No large commercial companies would use a free database such as MySQL.”, My project manager answered: “Google did”. This .NET architect was silent.
Other examples include “Facebook uses PHP” and “Twitter developed using Ruby on Rails” which Java/C# programmers might find hard to believe. The most interesting story is the one that I heard from a tech manager of Microsoft Gold Partner company in 2013: “We recommend Microsoft TFS (Team Foundation Server) over Git (my proposal) for these reasons, …”. Five years later, Microsoft dumped TFS and acquired GitHub which is developed in Ruby.
For motivated engineers, I would suggest that you do what you can. If your proposal gets shot down, you can learn and practice in your own time. Learn test automation and Continuous Testing. One day, you may develop your own product.