The Cloud

This post is going to be a bit different from the usual.  I’m going to talk a little about cloud computing.  Specifically about Amazon’s cloud and what you should consider if you are thinking about using a cloud-based system.  This article will be geared more toward the business end of cloud computing, though I’m going to describe some technical details up front.

Some History

When the cloud was first offered, I was a bit skeptical about using it.  At the time I was working for a company that hosted their own equipment.  Internet connection bandwidth was not like it is today (I think we had a 5 megabit connection back then).  The cloud was new and virtualization was new and expensive.  There were a lot of questions about how to do it.  If I were to startup a new system for a company like that today, I’d recommend the cloud.

Any IT person who installs equipment for a data center today knows about cloud computing.  I have now worked for two companies that have hosted their equipment at a major data center, using virtual hosts.  The advantages of hosting equipment at a data center verses providing your own facility are numerous.  Off the top of my head are: Cooling, backup power, data bandwidth to the internet, and physical security to the site.  The cloud provides additional benefits: Pay for equipment as you need it, avoid delay required to order new equipment.

Amazon Web Services (AWS)

I examined a few different cloud services and I’ll blog about other services as I get time to gain some experience.  The reason I started with AWS is due to the fact that they have a 1 year trial for free.  That is marketing genius right there!  First, they encourage software developers to sign up and learn their system.  That allows them to get their foot in the door of companies that might start using cloud computing and abandon their physical data centers.  All because they have developers on staff that already know the technology.  Second, a year is a lot of time to experiment.  A person can get really good at understanding the services or they can attempt to build a new product using their service to see how it operates.

I signed up and it does require a credit card to complete the sign up.  That sends off a few alarms in the back of my head because technically, they could charge my card without me knowing it.  So the first thing I did was find out where I can review any charges.  I also noticed that there are warning messages that tell me when I’m attempting to setup a service that does not apply to the free tier (which means that I’ll get charged).  The great unknown is what happens if I accidentally get a flood of traffic for a test application that I’ve posted?  I guess I’ll find out, or hopefully not.

Anyway, here’s what the billing screen looks like:


This is accessible from the drop-down menu above with your name on the account (“Frank DeCaire” for my account).

There are a lot of services on AWS and their control panel is rather large:

Where to start?  I started with Elastic Beanstalk.  Amazon uses the word “Elastic” in all kinds of services.  At first, I thought it was just a cute word they used to describe their product the way that Microsoft uses the word “Azure”.  I began to read some documents on their services and the word “Elastic” refers to the fact that you can program your cloud to provision new servers or tear-down servers according to trigger points.  So you can cause more servers to be put on line if your load becomes too high.  Conversely you can automatically tear-down servers if the load gets too low (so you don’t have to pay for servers you don’t need during low volume times).  This is where the term “Elastic” comes in.  The number of servers you apply to your product is elastic.  

Back to Beanstalk.  The Elastic Beanstalk application has a web server and an optional database server.  So I clicked into the Beanstalk app and created an IIS server (there are several web server types to choose from).  Then I added a SQL Server Express database under RDS.  The database server required an id and password.  Once that was created there is a configuration details screen and it contains a url under the section named Endpoint,  This is the connection url that can be used by SQL Server Management Studio.  Once connected, I was able to manipulate SQL Server the same as a local instance.  I created tables and inserted data to make sure it worked.


IIS

The IIS server control panel looks like this:



You can click on the blue link to pop-up the website url that points to this web server (or server farm).  I have intentionally obscured the id by replacing it with “abcdefgh”, so the id above will not work.  You’ll need to create your own account and a random id will be generated for your own server.

Next, you need to download the tool kit for Visual Studio (click here).  I installed it on VS 2015, so I know it works on the newest version of Visual Studio.  I also tested on VS 2013.  There are a few gotchas that I ran into.  First, I ran into an error when attempting to deploy to AWS.  The error I received was that the URL validation failed (“Error during URL validation; check URL and try again”).  This turned out to be a false error.  What I discovered was that there was a permissions problem with access to IIS.  This can be found in the Identity and Access Management console (IAM).  I had a user created, but I did not assign a group to the user.  The IAM console is rather complex and requires some head-scratching.  Stack overflow is where I found the best answer to troubleshooting this issue:

aws-error-error-during-url-validation-check-url-and-try-again

My next problem gave an error “The type initializer for ‘Microsoft.Web.Deployment.DeploymentManager’ threw an exception.” which was just as cryptic.  As it turned out there are registry entries that SQL Server doesn’t remove when uninstalling older versions of SQL Server that interfere with the deployment software in Visual Studio.  The keys are:

HKLMSoftwareMicrosoftIIS Extensionsmsdeploy3extensibility
HKLMSoftwareWow6432NodeMicrosoftIIS Extensionsmsdeploy3extensibility


They both should be removed.  I also found that information from stack overflow:

Web deployment task failed. (The type initializer for ‘Microsoft.Web.Deployment.DeploymentManager’ threw an exception.)

At that point I was able to deploy my application and get a “Hello World” program running.  Once this capability is in place you can focus on the development process and not deal with configuration details until you need more capabilities.


Real World Application

Now that I have the basics down, I still need to test some of the other features of AWS (like their EC2 virtual servers).  However, I have enough knowledge to actually use AWS for a production system.  If you’re analyzing this service as a migration of an existing system, then there are a lot of things you still need to consider.  The first thing you’ll need to do is find out how much it’ll cost to store the amount of data that you already use.  How much web traffic are you using?  How many servers do you currently use?  These are going to go into an equation of cost.  When you compute those costs it should be lower than what you are currently paying for your equipment, data connection and facility.  If not, then you should not move your system.

If you are contemplating a start-up, you’ll have other factors to consider.  First and foremost, assuming you haven’t created your software yet, you’ll need to decide which web platform and database engine you’ll use.  If you’re not experienced with working at a company that has a large database system, you might not realize how much licenses can cost when you need to scale out.  In the early stages of development priority might be placed on how easy it is to get the site up and running.  This will haunt you in the long run if your user base grows.  I would seriously consider using free or open-source software where you can.  AWS has MySql and Apache with Java, Python or PHP.  Ruby is another option.  If you lock yourself into IIS and SQL Server, you’ll need to pay the extra licensing fees when your application outgrows the Express edition.  Once you have created thousands of stored procedures in SQL, you’re locked in, with a re-development cost that is astronomical or license fees that are almost as bad.

Another factor to contemplate in a start-up is the cost of getting your business going.  If you have seed capital, then you’re probably set for a fixed period of time.  If you are doing this on your own, then you’re probably worried about how much it will cost until you get enough customers to cover your fees.  You’ll need to compute this information ahead of time.  You need to ask yourself: “How many paying customers do I need in order to break even.”  If you are providing a two-tier website that has a free component (which is a great way to hook people) and a paid component that has powerful features, you’ll need to figure out what the ratio of paid vs. free customers there will be.  If you’re conservative with your figures, you’ll come out ahead.  I would start with a 5%/95% and compute what you need.  That means you’ll need to pay for 100% of your customer’s data and bandwidth usage, but you’ll only collect money from the 5% that are paying.  If you plan to sell advertisements, you’ll need to compute that.

Now you’re probably thinking “how do I know what these numbers are going to be?”  Well, that’s where this free AWS service is handy.  If you’re clever, you’ll get your application up and running before you sign up for AWS, or if your application is expected to be small and easy to build, you can build it directly on AWS.  When you’re ready to do some usage testing, you can put it on line and get it into the search engines.  At first you’ll end up with 100% free users.  Your traffic should increase.  You’ll have to take an educated guess at what to charge for the advanced features.  Too much, and nobody will see the value.  Too cheap and you’ll go broke.  The ideal price point would be something that seems cheap for what the customer receives, but enough to cover costs and earn a profit.  What that price point is, depends on what your application does.

AWS has a system for taking credit care information and keeping track of accounting information.  You’ll need this type of system in order to keep track of who has paid and how much they have paid for.  This service is called DevPay.  The goal is to automate the process of collecting payment information, activating accounts and deactivating accounts.  That’s a task that can overwhelm a person in no time if your product becomes successful.  Here’s the basic information on DevPay:

What is Amazon DevPay?


Other Considerations

Once you launch your application and it becomes established, you’ll need to consider your growth rate.  If your income is large enough, you can plan for new versions of your software according to how many developers you can keep on staff or contract.  In the cloud scenario, there is no need to pay for office space.  Technically, you can run the entire operation from your home.  Avoid adding the cost of an expensive facility until you really need it.  

Keep your eyes open on other cloud providers.  Google or Microsoft (and others) can provide equivalent services.  If their pricing structure makes your product cheaper to operate, consider porting to their cloud.  If you keep this in mind when you’re small, you can keep your application in a format that can be re-deployed quickly.  If you build in too many Amazon specific features you might be stuck until you can redesign a feature (Yes, I mentioned this fact after I talked about DevPay in the previous paragraph).  Another option is to use a cloud provider specific feature long enough to design your own non-cloud provider specific feature.  In other words, use DevPay for your application until you can hire developers or put in the development time to write your own (or possibly use another 3rd party product).  Always keep your application capable of being moved.  Otherwise, you’ll be hostage to a provider that someday may become hostile to your business.

Deployment tools are another feature you should get familiar with.  Automate your deployment as much as possible.  AWS has deployment tools that allow the developer to clone a production web server in isolation and to deploy a development version of your application for testing purposes.  If you need to do a lot of manual steps to get your application tested and deployed, you’ll be wasting valuable developer time.  Time that is very expensive.

Get familiar with the security features.  If you hire outside contractors to perform maintenance or development tasks, you’ll need to be able to shut off their accounts quickly if something goes wrong.  Make sure you understand what capabilities you are giving to another person.  Don’t allow a rogue programmer to put in back-doors and open holes to the internet that you don’t know exist.  Always monitor what is going on with your system.

I could go on all day, but at this point you should go to the AWS site and sign up for free usage.  Get some experience.  Click here.  When you get a “Hello World” program deployed and working, try some new features.  I would also recommend seeking out other cloud products from other vendors.  Google and Microsoft come to mind but there are others like AT&T, EMC, IBM, etc.

  

 

Leave a Reply