What separates a cloud environment from the rest
The term “Cloud” is frequently misused and abused in the industry, most commonly mixed with “some service accessible via the internet.” This is particularly misleading because it is hard to find services that are not available via the internet.
A server connected to the internet in not a cloud environment. If that was true, the laptop that I am using to create this blog post would qualify for my personal cloud, since it runs Hyper-V which hosts a few virtual servers. It does not qualify to be a cloud environment even if the servers were accessible via a static IP or a domain name, as the case is with most data centers.
Here are some must have features that make a cloud environment. These points are not only about Platform as a Service (PAAS) which leverages cloud as a development platform but are also about basic Infrastructure as a Service (IAAS) where you lift or build your existing infrastructure in the cloud.
Perhaps the most important part of having your infrastructure in the cloud is Geo or location independence. This means that you can host your server at different geographic locations based on your user-base and traffic source. For example, Azure is available in 141 countries, with 8 regions within the US itself. So when you are creating or uploading a VM in Azure, you can specify the region in which this server will be hosted and manage your farm and place your servers closer to target markets / users giving them a quick response time.
The ability to increase capacity by adding up multiple application servers so that they work as independent logical units is referred to as horizontal scalability. The classic example of this would be an online retail store during the shopping season. When you are expecting more traffic, the business can quickly add more servers to the cluster to maintain high availability. At the same time when the traffic slows down, these servers can be shut down and removed just as quickly to reduce non-required infrastructure cost. This is a huge advantage for any business situation be it the online retail store or a proof testing an idea. In the latter case the business might want to start with one lean server and add up as the business progresses.
In the case of a real cloud environment, there are multiple ways to get to your infrastructure for the purpose of making changes mentioned in the above points or for day to day health monitoring and maintenance. In a typical data center scenario, to add or change the configuration of a server, you would have to contact your data center support team. In case of a cloud environment, these activities could be completed by logging into a self-service portal or maybe just running some scripts. The portal typically gives you a snapshot of your overall infrastructure with many inbuilt utilities like health monitoring and analytics like traffic sources and other business critical client information.
The cloud environment also comes with a lot of security built in. Your application might be shielded from many vulnerability attacks just because it is hosted in a secure infrastructure. Also, depending on the cloud provider, you might not have to worry about infrastructure compliances like HIPPA or EU Model Clauses depending on the nature of the business. Here’s a list of compliances that Azure brings to your application without any effort on your side.
Time to market / Integration to development environment:
Imagine this scenario: A developer makes changes to a development branch in a version control system. As soon as the changes are checked in, a build script gets triggered which:
- Spins up a new VM
- Takes the latest changes, creates a build and deploys it on the VM
- Runs a suite of Unit and Regression tests and provides feedback to the team if anything fails
- Automates User acceptance testing on this VM
- Saves the successful release candidate and tears down the VM
This model is referred to as Continuous Integration (CI) & Continuous Delivery (CD), and a cloud environment can fully automate this. Because everything is running in the cloud you don’t have to buy or manage servers for build or test environments. You can spin up environments using automated build scripts, run in-depth tests against it and drop it when you are done.
This model significantly cuts down the time to market for new changes and ensures repetitive and consistent quality check processes. With the cloud environment integration, the cost of delivery drops dramatically since the amount of money you will spend on this will be limited to the time that your machine is actually running, that is, the script is testing the build.