DEV Community: Ewere Diagboya

Deploying Fast and Secure Web App on AWS — Part 2a

Ewere Diagboya — Thu, 14 May 2020 12:46:58 +0000

We have spent the last two part of this series Part 1a and Part 1b talking about how applications are websites have been hosted in last fifteen to twenty years of website application development. We have looked at the ways they were scaled and what it costs to host, deploy and manage them. We also spent a deal of time on the second part where we explained what can be done better in terms of cost of hosting, management, scaling and availability of our websites and web applications. From this point on, we are going to set a new tone of how those things mentioned in the second part can be applied. We are taking it from the ground up to lay a foundational architecture and take you through the journey of setting up a fast and secure web application on the cloud using specific AWS cloud computing services. While we do that, we will be focusing no three things as we set the stage:

Initial Setup and Deployment
Configuring Security and Speed
A/B Testing and Availability

This piece will be focused on the first item mentioned in the list. Which is the Initial Setup and Deployment. In this part we will be looking at understanding how we are going to achieve the goal of deploying a fast and secure web app on AWS.

What is a Website ?
For the purpose of this series, a website is basically an application built using HTML, CSS and Javascript. The applications we will be focusing on here are apps that do not require a compiler or run-time environment to run. Applications built with Angular and React and VueJS fall under this. It could also that you used VanillaJS and pure HTML and CSS to build the website or application.

The Architecture

Before we go further to start setting up anything, it is good to have a holistic idea what is being built. Hence we will need a an architecture that clearly shows the services that are going to be used and how request will flow in from when a user sends a HTTP request; say www.xyz.com. The architecture above shows all the components of our website, with each AWS service serving a unique purpose. We will be explaining the whole process from this point and start setting up each item in other parts of the series. The flow goes thus;
The user sends a HTTP request to the DNS service (Amazon Route53); with the URL of the website www.xyz.com. Route53 already has the configuration to point the domain request to Cloudfront (This will be done later in the series).
The address profiled in the DNS is that of Cloudfront Distribution, which is a caching service that makes it possible to; distribute the website or web application closer to users. It can also be used to configure custom Header Requests and Responses and Viewer Request and Responses this feature is called Cloudfront Edge.
The last item that looks like a bucket is actually a bucket that hosts the website, it is called Amazon S3. This is where the HTML, CSS and Javascript of the website will be uploaded to. This is where the web application files are stored and downloaded via the Cloudfront Distribution which serves as a caching layer.

Now that we understand where we are going to, the next part will involve setting up, and for this we will be starting from the last item which is the S3 bucket. AWS services can be setup using the GUI console or using Infrastructure as code.

Infrastructure as Code
Infrastructure as Code is a declarative scripting method of defining setup and infrastructure configurations across different environments. It saves the time involved in clicking through things and ensuring that there is a consistent configuration when ever any infrastructure setup needs to be done. It also makes passing on of setups and runbook operations much easier as they are codified and not documentations that might be misleading. All that is required is to run the script for it create that setup. The language used for Infrastructure as Code could be JSON or YAML. AWS Cloudformation is an Infrastructure as a Code service that can be written in either JSON or YAML. For this setup, Terraform will be used as the Infrastructure as code tool for all the configurations in this course.

Conclusion
Now, the target is set, we have spent some time explaining the new website setup and architecture that will cover the rest of the series, using S3 to host the website files, attaching Cloudfront to ensure the website is globally distributed to reduce latency for users all over the world, and requests from the user will be served using the highly available redundant DNS service called Route53. The next stage is to start setting things up and getting our tools ready to build this end to end. Watch out for Part 2b

Deploying Fast and Secure Web App on AWS — Part 1b

Ewere Diagboya — Sun, 12 Apr 2020 17:36:18 +0000

Introduction Continues
In Part 1a, I explained how websites are hosted using Shared Web Hosting and Dedicated web hosting. I itemized some of the characteristics that the Shared Hosting and Dedicated Hosting have, and how they can restrict your business growth and eventually make you want to seek another option to be able to scale when you get more users visiting your application. In some cases, you spend so much to keep your website available and to scale you have to pay more. In this part, I will be explaining how the Cloud has changed all these perspectives we had. It will also show ways cost can be drastically cut down and how you can grow your business spending less.

Billing
In Cloud billing, there are usually upfront costs, most of the billing in the cloud is pay as you use. You save more because you do not pay for resources or services you do not use. The rate is not fixed, giving you the customer/user the power to choose what you want, and be in control of how much you spend. In Cloud computing, you will also need a domain name, but the hosting is quite different from that of shared hosting. You are charged for the size of data you have on S3, and you are also charged for the number of requests that the S3 website serves. The cost of the service is determined by the amount of traffic the website receives within a month. This bill could start from as low as $0.00/mo (this is our monthly cost at mycloudseries.com). This means we practically pay nothing for the website hosted in Amazon S3 every month.

Availability
When you use Amazon S3, your website is hosted in an environment that scales automatically. That promises 99.999999999% durability of your website and 99.99% uptime. It means that you might have downtime in only 8 seconds in one day (here). You are also guaranteed of replication of your data, because your data in S3 is by default replicated across the availability zones in the region you choose to create the Amazon S3 bucket and host the web application. There are various ways to store objects and applications in S3 but we will be elaborating on that in the Part 2 of this series. The availability and durability that are on S3, does not your require any form of developer or user intervention, as they are handled automatically by S3 itself.

Deployment
Just like the popular cPanel or Plesk consoles, Amazon S3 also has a very user friendly GUI console that makes it easy to copy website files, and manage them. Amazon S3 also has option of SDK and CLI for copy web files into S3. Amazon S3, has a unique feature called versioning, which if enabled makes it possible to store your old files and even if a new ones over-writes it, it is still possible to retrieve the old ones. The option of CLI makes it possible to configure and setup automated deployments for your websites in S3, using CI/CD tools such as AWS CodePipeline to help make deployments of websites faster. It also enables to possibility of a rollback in the eventuality of an error or wrong deployment happens. With this you do not have to update the website with a "Down for maintenance" page, you can perform deployments anytime with little or no downtime noticed by the customers and users.

Security/Scalability
Amazon S3, on its own does not come with a lot of security features for hosting web applications in AWS. But he has a brother that makes this happen. A complete serverless website suite is not complete with Amazon Cloudfront. Amazon Cloudfront is AWS web caching service that helps to cache your website to be available globally across over 200 Edge Locations. This does not only increase the speed of your website by bringing it closer to your customers, it also has a programmable layer to it called Lambda@Edge. The Lambda@Edge is a programmable feature in Cloudfront that gives the ability to inject code within every AWS web request and response. With this in-place security headers such as; CSP, X-XSS, Referrer-Policy, HTTP Strict Transport Security, are easy to integrate and extend. Lambda@Edge can also be used to perform web page compression, HTTP header validation, image compression and many more functionalities. At the moment Lambda@Edge supports Python and NodeJS.

Conclusion

As we have seen in this part, we have described new and better ways to setup, deploy, scale and spend less on our websites and web applications. Using a combination of S3, Cloudfront, Lambda@Edge, we can deploy planet-scale web application without breaking a sweat. It is also interesting to note that, we do spend less having all these amazing feature and scale intermittently as the demand increases. The next part of this series will start with S3 and talking about what it can offer and how we can host a website on S3. Stay glued.

Are you interested in understanding how Cloud connects to your current tech career or role ? Do you want a Cloud Computing training that speaks to your current career or job function ? Click this link and see how we can help

Deploying Fast and Secure Web App on AWS — Part 1a

Ewere Diagboya — Fri, 20 Mar 2020 11:31:56 +0000

Introduction
The internet is filled up with millions of websites. Most of these websites are hosted on servers in different locations around the world. In the days of Shared Hosting only, the server configuration, system availability and scalability solely lied in the hands of the hosting company. These websites were hosted using cPanel and WHM.
A cPanel WHM hosting typically had a webserver (Apache/Nginx/Lightspeed) for Linux servers. For the Windows option, it is usually Windows IIS. As a customer, you are usually not bothered by how these servers have been configured because you do not have direct access to the server. So what happens is that you copy/upload the files of your website (HTML, CSS, and JavaScript) to the server of the hosting company via a management console. cPanel is still king in that space, and it has been hard for any other web hosting service to come and take that place.

Billing
The payment model for this is usually a yearly fixed-rate or monthly fixed rate as the case may be. You pay for the domain name; for example, ewere.com and you have to purchase a hosting account which is the server where your website will be stored. The price for this could vary in terms of the size and bandwidth that will be offered per month. In my 15 years of website, what I notice is that most websites are ever able to fill up the size allocated or even the bandwidth allocated per month. Which is more of offer provisioning? But it is static so it can’t be changed. Well, what used to happen then was we could smartly use the concept of “Add-on Domain”. Instead of buying a fresh hosting account, you can use the same hosting account to host more than one website, but you will have to purchase a domain name for it. With this, the value of the hosting account is increased because more than one website can be uploaded to that same hosting account (Please do not tell our clients).

Another very interesting concept is the concept of Dedicated Hosting. I see people paying so much for this and they are not able to consume up to 20% of the resources. It gives the customer that feeling that they get a Dedicated IP address with a big server with so many resources, which puts so much hole in your pocket. In the end, you are still presented with a cPanel login for uploading your files because you have the notion that you will be expecting so much traffic to your website. Some of them start at $80/mo, and it is still a single server and you are not guaranteed of high availability.

Operations
In the case of Shared hosting, it gives you some kind of comfort, you do not have to worry about update patches and configuration changes, you only have to upload your website anytime you want and ensure you do not have bugs that will make your website unavailable. So it is something like the AWS Shared Responsibility Model. The hosting company takes care of the security of the server the racking and stacking, while you take responsibility for the security of your website. They also assist with security patches, for the operating system and applications within the server. So if for any reason your website is hacked due to your own negligence, they do not take responsibility for that.
In the case of dedicated, it goes in a fairly different direction, you are given access to the server itself, so you are responsible for updates and security of not just the application but also of the services and applications running within the server apart from your application hosted within the server. So there is still OpEX in having a man stand-by who has to watch that server for anything and ensure that the server does not go down in serving your customers.

Availability
Most times, you are not guaranteed of availability of Shared hosting, because the whole website sits on a single server. If anything happens to that single server. Your website goes offline. In most cases, that single server host other websites, hence it is called Shared hosting. On the side of Dedicated, you have some level of guarantee that your server is owned only by you, and only your files are hosted there, but hey, you got a single point of failure. When anything happens to that single server your application is hosted, you lose everything. If there is any kind of attack or hack on the website or server, there is nothing to fall back to, no system to keep the website or application highly, available.

Deployment
When there is going to be a deployment to the hosting, it is quite cumbersome, most times, you have to copy a zip file to a specific folder in the server. When the zip file is copied, the old website files and copied and backed up and the new file unzipped and tested. Most times, this leads to some temporary downtime on the website and in some cases, the website puts a “we will be back” back to let customers know of the downtime. But these are some of the problems and challenges DevOps solves. With concepts such as CI/CD and release management. I actually once did a pipeline from a CI/CD tool to a cPanel website and it actually worked fine. I used the FTP account on the tool and I was able to deploy automatedly to the cPanel hosting. It was a nice experience. I think it can be used to improve deployment efficiency.

Security/Scalability
The security in this aspect is truly in your hands. For web application security, you will have to rely on the .htaccess file of your apache website, to be able to configure custom HTTP header securities, like Content Security Policy (CSP), X-XSS Protection, Referrer-Policy, HTTP Strict Transport Security. These are security loopholes that can cause some serious damage to your web application is not closed or fixed on the header response layer of the webserver.

For the part of scalability, the only promise that exists is vertical scaling; which means if the system needs more resources, you pay for more resources in terms of server space and bandwidth. In simple terms, the hosting can start with 5GB of storage and 20GB of bandwidth, and scale-up, to 10GB of storage and 40GB bandwidth which in some cases you do not need both to increase maybe just the bandwidth because of high traffic volume, but you have no choice but forced to pay for both. This same principle applies to both shared and dedicated hosting. Just like deployment, you will need to notify your customers of scheduled downtime for this to occur because the server configurations need to be changed before this can be applied and available for customers.

There is a new way to deploy, secure, scale and give your website 99.99999999 durability. You also pay for as much Gigabyte that your website is, and you don’t get to overpay for space that you might never have to use for your website. Lastly, with a flip-switch, your website is available to the world, cached and given users all over the world a consistent and fast user experience that they have never experienced. It will also ensure world-class security on your web application, enforcing security on the edge. Also, you will cut down cost by 50% of your costing, and pay less than $1 monthly for your website and planet-scale scalability for your application and website.

In this three-part series, I will be explaining how all these work and solves most of the challenges I mentioned in this part 1a. I will also be showing us how to set up, configure and deploy a website in a whole new way, using Serverless Technologies that will cost you next to nothing to host, run and scale your website. Stay with me for 1b for more.