As you contemplate using cloud computing architecture this year, there are certain lingo you need to know. As with any new and innovative technology, buzzwords abound and cloud computing is no different. Most folks have heard about it but few know they are actually using it every day. Even fewer know there is much more to the cloud than Google Docs or Gmail. It’s easy to get lost in all the hype and misinformation going around so here is a list of buzzwords explained about cloud computing to help you sort out what is all the rage these days.
Infrastructure as a Service (IaaS)
IaaS is what started it all. IT departments were looking for ways to lower their data center costs because every time they needed to add more processing power for their applications, it was very expensive and time-consuming to implement. Third-party vendors were aware of these issues and began to offer computing infrastructures for rent. This way, IT shops would not have to hassle with physical machines, data center floor space, cooling requirements and physical security. They would simply rent what they needed from someone else.
IaaS has evolved significantly since its inception with players such as Amazon, Rackspace, Microsoft, GoGrid and others. Each offers something unique but in the end the core services are storage, operating systems, network components such as firewalls and load balancers, and the capability to provision and monitor these resources.
Platform as a Service (PaaS)
PaaS was born out of the need to provide a consistent and inexpensive platform with which to develop enterprise applications upon. It combines IaaS with software and tools so developers can have the freedom to build innovative web applications and services offered entirely over the Internet.
By using PaaS, IT shops no longer struggle with all the environments required to develop applications, such as testing and quality assurance infrastructures. They simply provision these resources via cloud management tools and deploy their applications to them. If a mistake is made, environments can be deleted and the developer can start over easily, all with little downtime.
Software as a Service (SaaS)
Often used interchangeably with PaaS, SaaS is actually a subset of PaaS, providing an on-demand delivery model for applications that are accessed over the Internet using a web browser. Typical applications include customer relationship management (CRM), content management and collaboration apps found in most medium to large enterprises.
Other familiar SaaS applications the general public uses everyday are Gmail, Google Docs, Amazon, WordPress, The Weather Channel, etc. All of these apps use the cloud to store data and expose services that developers can use to integrate features and functions into their own applications, resulting in innovative apps at a much lower cost than if they were built from scratch.
This term is used to describe a whole slew of cloud computing buzzwords such as architecture, hosting and services. It simply means that there is a single application running on a server and multiple clients, or tenants) are able to use the app as if they were the only one using it.
This is a giant leap forward from the days where a vendor would use many instances of the same application and each client would have their own instance. A multi-tenant application drastically reduces computing resources and makes upgrades and ongoing maintenance much easier on everyone.
A public cloud is a set of resources offered by a vendor that provides data storage and applications to the public over the Internet. Some resources are free such as Google Docs while others charge by how much you use them. Information is not really public per se, just publically available to subscribers and is usually accessed with a username and password.
A private cloud is a set of resources that are typically behind a firewall, such as in a corporation. These resources are available in a limited fashion because of information sensitivity or corporate security policy. An example of a private computing cloud is a Human Resource application that might provision some server computing power on-demand (IaaS), use some software components (SaaS) and a proprietary database that only the HR app is allowed to use.
A web service is a component of software that provides a standards-based interface to a function exposed by an application. In other words, it lets a user have access to part of an application that normally would never be available to use. For example, if you want to display the current temperature in your city on your website, you can use a web service from a weather provider to get the temperature. This way, you do not have to provide a weather station in the area you want the temperature for.
Even More Buzzwords
There are many more cloud computing architecture buzzwords and new ones seem to be invented every day. This list covers the major ones that should allow you to hang with cloud computing crowd. Consider yourself armed and dangerous now and your boss will be impressed with your new-found wisdom.
As more and more applications begin to leverage the cloud as a major part of their architecture, it makes sense to take a step back and understand just what is going on in terms of cloud computing basics. Much of the cloud is abstracted away from both the app developer and especially the end user. But it is a good idea to explore exactly which services the cloud is providing and how. Here is what every user needs to know about their cloud app.
Building Your App Is Much Easier
When you use cloud services, your app automatically becomes easier to build and maintain. Why? Because pre-built services mean you have less code to not only write but also less code to test. Cloud services tend to be mature and robust offering good documentation as well as error handling and a standardized interface. These are the things in life developers tend to struggle with or don’t enjoy doing.
Having the ability to pick and choose best of breed cloud services, your app becomes less of a monolith and more flexible, giving you the ability to change things around without having to re-work or write new code. You can get more accomplished in a shorter period of time, something IT managers will praise you for.
Testing Your Application Is Faster
With the ability to spin up a virtual testing infrastructure in the cloud literally in minutes, you gain a tremendous advantage in testing speed. Moving code through the various testing environments is no longer a tedious and burdensome task that requires three or four people to validate. You simply create (provision) what you need from pre-configured templates using cloud infrastructure management tools and voila, instant infrastructure and near-instant testing.
Once your testing infrastructure is set up and you have your testing process honed in, future testing becomes almost a joy since all the baggage that comes along with a traditional environment is gone. You can get something into the end user’s hands quickly and be able to validate requirements, functions and features more efficiently.
Your App Becomes Location Aware
Why is this important? The Internet has no set route that data is transferred by. It does its best to route traffic in the most efficient manner possible but sometimes it’s not the fastest route. Using a CDN ensures that the best opportunity for data to travel the least distance and therefore arrive faster is achieved. Your app appears faster and more responsive to your end users.
Your App Requires Careful Attention to Security
By moving to the cloud, it is imperative that you know exactly how the cloud provider handles security, both physically and with data. Using storage services is one thing, but knowing how the data is stored and what steps are taken to ensure ongoing access integrity is paramount. If your app stores and retrieves sensitive data using cloud services, then your app must take additional measures to secure transporting and storage of the data.
Your App Relies Heavily on an Internet Connection
Building an application that consumes cloud resources over the Internet means your app is dead in the water without an Internet connection. This may seem obvious but many apps don’t degrade gracefully when a connection becomes unavailable. The app simply times out without allowing the user to do anything else.
If your app is mission critical, it should allow for reduced functionality when a connection is unavailable and sync back up with the cloud when the connectivity is restored. This way, your users can still be productive and you don’t look like a buffoon even though it’s not your fault.
But Wait. There’s More.
Now that you know cloud computing basics, you know that cloud computing is just a fancy term for using someone else’s computing resources. With the future evolution of the Internet is leaning heavily on cloud computing, you must take a step back and take in just what this means. The way apps are built is changing rapidly and forever. The more you know about how your future as an app developer will change, the better you can be at meeting ever-changing business demands.
Online marketing managers put a lot of trust and faith in those who make it possible to do business online. Without web applications, there would be nothing online to market save for the plethora of awful affiliate marketing scams that clog the Interwebs these days. Many marketing campaigns start off with grandiose promises of instant wealth which often fail. Why? Because sometimes web app developers tell little white lies that online marketing managers blindly trust. What are these lies?
Lie #1- I Don't Know Anything About Marketing
Perhaps the biggest lie told by web app developers is that they tell marketing managers that they don’t know anything about marketing. While this may be true on the face of it, developers often think that marketing isn’t that hard, certainly not any more difficult than the complex work they are doing.
Since developers design and implement their apps to reach a certain audience, they think marketing is something they can just “build in” to their app and they tell marketing managers that all the promotion functions they need are built right in. But how would they know?
Lie #2 – It's Easier to Start From Scratch
When marketing comes up with the next big idea for their online strategy, they want it implemented quickly and as cheap as possible. To make this happen, a web app developer will sometimes tell marketing that it will be easier to start from scratch rather than try and retrofit new features in an existing web app. It might be quicker but it is rarely cheaper.
This lie is merely a façade to mask the fact that the current app wasn’t written in a way that is easily extendable and the developer doesn’t want management to know about it. Instead, the developer will say that if they build it from scratch, it will use the latest technology so future changes will be much easier. However this is usually just an excuse to play with the latest and greatest development tools.
Lie #3 – Features for No Reason
When a marketing manager asks why there are certain features in their new product that weren’t on the feature list, a developer tells an innocent lie that since our competition has it, so must we. I’m just looking out for you guys long-term he says.
What he really means is that he can’t understand why marketing didn’t come up with these extra features during their competitive research. Because he is smarter than a marketing manager, he feels the need to right this wrong and put in the features anyway.
Lie #4 – The App Will Handle Huge Traffic
Every online marketing campaign has one goal in mind: drive traffic to the website and once they are there, funnel them down the desired path and make them into a customer. A successful campaign can tax even the most scalable infrastructure so designing an app to hold up is paramount.
Asking a developer if their app will handle the predicted traffic spike is like asking your wife if the pants she is wearing make her butt look big. Of course you are going to say no, else reap the wrath. And so it is true for a developer. He will say of course my app will hold up. I spent a lot of time designing it for just that reason. Chances are that little consideration was given to how scalable the app really is.
Lie #5 – My App Works in Every Browser
Online marketing managers want to reach the widest audience possible and therefore their web application must be compatible with the broadest range of web browsers that is feasible. The look, feel and speed should be the same for every user experience regardless of browser version.
When asked by marketing what browsers are supported, often a web developer will respond by saying something like all those that matter. This is a catch-all lie that really means they don’t really know since they haven’t tested on all browsers. Every developer has their favorite browser and is biased toward its capabilities. As such, it is the version that is recommended and others are merely broken.
Lie #6 – We Don't Need Documentation
Before going live with a website, online marketing managers should be trained on the web apps they intend to promote so they have an inkling of what their customers will see. Usually with a training guide or basic documentation will suffice but often it never gets written.
Documentation is the bane of all web developers. They hate doing it and think it’s a waste of time. They will say that the code is well documented and that if anyone needs to know how something works, they will show you how. In reality, no documentation exists, especially a training guide. While not typically a developer’s job, training docs can only be written effectively if a developer works with marketing from the beginning.
While developers tell little white lies typically to justify the presence of a bug or the absence of some feature or function, they are likely not being malicious or intentionally deceiving. They are probably just framing the lie to online marketing managers so they gain their confidence. As with any lie, white or otherwise, they always comes back to haunt you. But in this case it’s the customer that eventually suffers.
The last thing you need is to have your website break in the first few hours of high-profile launch. Your customers are relying on you to make their experience using your website a memorable one — one they won’t forget, one that keeps them coming back for more. But if the website breaks, they will remember only the failure and likely won’t be using your website again. How can you avoid this? Test your website thoroughly so your customers don’t break it for you.
Step 1: Create the Test Plan
Begin with a test plan that covers the basic test coverage areas of requirements testing, unit testing, functional testing, system testing, user testing, security testing and performance testing. These test types may be called different things by different IT departments but the end result is that should you have end-to-end coverage that is both measurable and repeatable in the event you have several test cycles.
Step 2: Choose a Testing Tool
The testing tool you choose will have a big impact on how you test your website. Depending on the size and scale of your website, you should carefully consider a tool that will grow with the complexity of your website ecology. The goal is to have total test coverage that doesn’t hinder the pace of development but also is formal enough to integrate into development tools and workflow, i.e. bug fixes and reporting.
There are numerous test automation tools, both open source and commercial. Arguments for each abound but the bottom line is that you should choose a testing tool that fits into your IT website development tool’s long range strategy as well as the skill level of the testers.
Step 3: Test Early, Test Often
A website is tested much differently than a desktop application. A typical desktop application will have a predictable level of usage such as fat client like Microsoft Outlook in a corporate setting. A website is quite the opposite with sporadic usage with occasional spikes in traffic. This is where the architecture and design must be validated to determine if it can scale to meet demand.
Prototyping, unit and performance testing part of the website that will see the most use will provide early indications of scalability and thus the ability to re-design if performance standards fail to be met. Better to find out during the foundational design rather than at launch.
Step 4: Bake in Quality Testing
Often, quality testing is the first thing to get whacked from a project in order to save time yet there always seems to be time after launch to fix your broken website. Why not just bake in the needed time to QA test at the beginning of the project?
During this step, begin building reusable scripts with your testing tools that help you test components and modules in a repeatable way. Record quality metrics such as input validation requirements, error messages, input field order, workflow ordering, etc. This will help you build up a test suite so as the website becomes more complete, you can easily test new functions along with finished ones to see how they work together.
Step 5: Help Your Users During Functional Testing
Many websites are functionally tested by simply handing the website over to a group of users who are asked to “just do a run through and see how it works.” Save that for user acceptance testing. It is not enough to toss the app “over the fence” and see what gets tossed back.
Functional testing ensures that every functional requirement is tested according to specification, both independently and as a collection in the case of a workflow. You can dramatically improve the quality of your website by taking an active role in functional testing. As a web developer, you know best how a function was implemented. Work with your users to ensure it’s what they are expecting and solicit feedback.
Step 5: Conduct a System Test
Once the website is far enough along that all the major components have been through a functional and quality test, it’s time for a system test, which often includes a performance test. Why? Because not only are you testing to ensure each component in the website infrastructure is working in unison properly, but also to determine how the website will behave under various conditions, such as spikes in usage.
This is where your testing tools will help you tremendously. Create scripts that will run your website through all sorts of usage scenarios, from random usage to highly concurrent users working the most often used parts of the website. Measure and record baselines so you have a benchmark for follow-on testing and tuning.
Step 6: Conduct a Security Test
This step is often skipped because there is reliance on the website developer to provide security measures in their code. But that is only half of the picture. While in-code measures are implemented, unforeseen vulnerabilities can only be uncovered through penetration testing, a test that attempts to discover vulnerable parts of the website and then exploit them, rendering the website unusable or to expose data.
If your website collects or processes sensitive information, you cannot skip this step. Your customers rely on you to secure their personal information. Grave consequences are a given if there is a breach because of a website security hole. Perform the test in an environment as close to the production configuration as possible. This means firewalls, HTTPS certificates, user permissions, etc.
Step 7: Perform a Production Validation Test
This step is where your users can help greatly. After the website is launched, solicit feedback from your users. Offer them some gizmo or gadget for their time. Also monitor the website continuously for the first 30 days of usage so you can baseline usage for later tuning.
While these steps are not a one-size-fits-all for every website you build, it does represent a typical approach taken for testing medium to large scale websites where quality and performance are woven into the fabric of the software development process. If you only use just a fraction of what is outlined here, you will be much further along than most. And you will have fewer customers complaining about a broken website.
Website load times are the key factor in how visitors form a first opinion of your website. And now since the recent revamp of Google’s indexing and ranking algorithms, it’s imperative that your website load as fast as possible. Slow websites translate eventually to lower search engine rankings, something that is hard to reverse in a short time. When every click counts, you need ways to make your website load faster so your visitors are happy and your ranking improves. If your website is slow to load, here’s how to fix it.
Speed Secret #1 – Reduce HTTP Requests
Every script file downloaded has to be executed sequentially, which means certain portions of your page may not render until the script load and execution completes as there is no style instructions to render the page yet. This is also true for inline script as well. If possible, try and put all scripts (including inline) after all CSS files in the head portion of your page.
Speed Secret #3 – Use Gzip or Deflate to Compress Pages
If your web server is Apache 2.0 or greater, then enabling the mod_deflate module in Apache’s http.conf file will result in Apache compressing content when requested to do so by the browser. All modern browsers will automatically send a content compression request in the header of the HTTP request. If the server is configured for it, compression happens on the fly. This is true for any web server with Gzip or Deflate enabled.
Speed Secret #4 – Use a Content Delivery Network (CDN)
A CDN is a way to spread out resource requests over a number of host names and serve them up from the closest server to the requester. Web browsers are limited to the number of parallel connections to any one hostname at a time. Remember that downloading resources in parallel increases page load speed as in the case of CSS files. So to get around the parallel connection limitation, using multiple file servers with different hostnames helps a browser use more parallel connections.
CDN providers such as Amazon’s CloudFront, provide the infrastructure and simple tools to help you serve content from servers around the world. Once configured, you replace the URL to your server that would normally be used for say an image or script file and replace it with a unique URL of the CDN provider. That’s it. Instant CDN and browsers can now take advantage of parallel downloads from multiple servers.
Speed Secret #5 – Reduce the Number of Queries to Render a Page
When you have exhausted all other approaches and your site still loads slower than you would like, it’s time to look at how the database is queried. No matter how tuned up your queries are, on a busy website with a lot of queries performed to render pages, it’s going to result in progressively slower load times.
A little known technique is to combine queries where possible. Combining means taking several queries required for generating page content and making a single query that generates all page data needed, eliminating multiple queries that result in the same information collectively. Sometimes this isn’t possible when different portions of the page have completely unrelated data. Think about where you can combine queries and you will notice a substantially faster page load time and a less resource hungry database.
While not an exhaustive list of page loading speed secrets, following these suggestions will absolutely result in faster load times. Other areas to look at are combining images using CSS sprites, minimizing URL redirects, minimizing DNS lookups and hosting provider bandwidth limitations. Infrastructure plays a huge role in page generation and serving speed so if you have a friend in the infrastructure department, pay him a visit and work together to optimize your website.