Lazy or Working Smart?
By CMD Technology Group
3 min read
In the old days (and not so old days), creating and maintaining a website or developing an app was such a tedious process. Most developers would create/update a website/application on their local PC and then via FTP (hello, utterly insecure) upload their changes to a single server. Many small IT shops would offer this service by hosting a server in their basement at home. The better ones would host on colocated servers. I’m surprised how many small firms are still hosting websites on these single points of failure. Changes were so slow and time-consuming that many just stopped updating their online presence or applications.
We all know about approval processes and peer reviews. In some organizations, this could take weeks or months. Some developers would ride out the approval process of changes like this:
Manager: Sees John running around out of breath and asks, “John, what are you working on?”
John: “I’m waiting for approval on the changes I made to the website.”
Manager: Realizing he’s the holdup, but refusing to let John know that he knows, “Let me escalate that for you.”
John: Sits back doing nothing for the next few weeks.
How the hardworking lazy do it
Mary is very lazy and hates repetitive tasks and truly dislikes approval processes. She invests a lot of time setting up her development environment so that she doesn’t have to deal with mind-numbing repetitive tasks. Now with a simple command or click of a button, her website updates have this workflow:
This process is part of a practice called Continuous Integration and Continuous Delivery or simply CI/CD. In the simplest of terms, it is hardworking laziness 101. In the conversation between John and his manager, John made one measly change and did nothing for weeks while Mary made dozens of changes in one week. In fact, Mary, the lazy one, will make more updates in a few weeks than John will make in his whole time at the firm.
In this example, we used a feature in BitBucket called Pipelines, which integrates nicely with AWS. Other repositories provide a similar process. By inserting the following YAML file in the directory, you will have a functioning CI/CD implementation.
– aws s3 sync –delete . s3://www.yourwebsite.com
AWS Cloudfront CDN
The above script references an S3 bucket with the name of your website s3://www.yourwebsite.com. Then your Cloudfront distribution monitors this S3 bucket and propagates changes as they are received. Like most things in AWS, there are so many configuration options, and as always AWS does a great job with the documentation. Many organizations will run there web app on load balanced VMs and use Cloudfront to distribute images, videos, and files. This way, the CDN does the heavy lifting.
Restricting your audience
If you only do business in specific geographic regions, then you can limit your CDN to only those regions. For example, the Cloudfront distribution below only allows four countries by using a Whitelist effectively blocking all other regions.
For testing purposes, I logged in to a VPN server in Asia and received this message when trying to access this website which is the desired behavior.
Now, this isn’t really a security feature because a user in Asia can log into a VPN server in the U.S. and gain access. One use case is for geo-compliance. The responsibility for lack of compliance will then be placed on the VPN user if he wishes to bypass this measure.
Of course, this setup requires many steps and processes for it to work, but the effort is well worth it. Once you learn the path of the lazy ones, you will never want to work any other way. CMD can set this up for you so your developers and web artists can be hardworking lazy people!
Get in touch
You can email us at firstname.lastname@example.org
Give us a call at 1-800-806-4173
Or contact us using the form below