Helder Almeida - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Don't let your cloud components become a DIY disaster

DIY is good for remodeling a house, but it might not be right for your enterprise. Answering five questions can prevent your cloud from a DIY disaster.

Infrastructure as a service (IaaS) providers, such as AWS, Microsoft and Google, increased their services for the cloud application stack. Now, search, caching and messaging services are available in the public cloud. But should enterprises use those services or launch their own cloud components? Answering these five questions can help them decide.

Does the cloud service meet functional requirements?

Before committing to a cloud service, read the fine print in the documentation and FAQs. Cloud services, especially relatively new ones, may have limited functionality. If you need to send messages between applications running on Amazon Web Services (AWS) Elastic Compute Cloud (EC2) servers, consider using its Simple Queue Service (SQS).

However, SQS will not help if your app requires messages to be delivered in their queue order. SQS does not guarantee first-in, first-out delivery. In this case, you might want to use RabbitMQ.

Cloud services are continuously evolving. A service that doesn't meet your needs today may meet them tomorrow. For example, AWS CloudSearch added integrated identity access management services to improve access controls. AWS also started supporting 33 languages and added support for highlighting and autocomplete features, along with enhanced availability features.

Can cloud services and do-it-yourself (DIY) approaches meet nonfunctional requirements?

Cloud providers have proven to deliver high-availability services, despite occasional outages. Companies that design for failure, such as Netflix, often shift workloads to other data centers to avoid data center outages.

Scalability has a similar pattern. Autoscaling services can help maintain a necessary number of machine instances to meet the demands of varying workloads -- without overpaying to maintain peak demand on a numbers of servers.

Which costs more: a cloud service or a DIY approach?

Estimating application costs can be a challenge. You probably will have to make assumptions about average workloads, peak demands, and staff resources dedicated to configuration and maintenance. But estimating the costs of cloud services is less complicated than estimating the cost of a DIY method.

Cloud costs are typically based on the amount of resources consumed, which could be the number of messages sent or queries submitted to a search service. AWS and Microsoft offer cost-estimating tools to help model multiple scenarios with varying levels of usage.

Cost estimates for a DIY approach likely will be more accurate and precise if you have a version of the application running in-house and plan to move it to the cloud. You'll need to know how much time is required to install and configure the apps, in addition to the staff hours needed to maintain it.

If you are working with a new stack component, building a prototype and load testing offers insights into required resources. For example, if you're working with a new search engine, test how long it takes to index the number of documents you expect to add each day. In addition, measure the latency of responses to user queries under varying loads.

Do you have the necessary skills to DIY?

A DIY approach may be appealing if it offers the features you need and is cost-effective. But the whole project suffers without the necessary expertise to pull it off. If you find a contractor to help with a prototype, what will happen once you move to production? It can be helpful to work with a vendor that supports the tool you'll implement. In either case, weigh the costs of keeping a contractor on the project or purchasing a support contract.

And be careful when introducing new functionality into your applications. If you need a NoSQL database, don't assume the database administrator managing your relational database will tune the NoSQL database properly on Day 1. Instead of running your own instance of MongoDB, you might opt for Microsoft Azure's DocumentDB.

Will DIY cloud components save you time?

Consider what you could do without having to manage another piece of the application stack. If the software meets both functional and nonfunctional requirements, it's cost-effective, and your staff has the necessary skill set to install and maintain it, you may want to run it yourself. Does DIY make sense? Not necessarily.

Are there other tasks your staff could spend time on -- instead of maintaining a stack component? Will one of your most skilled engineers have to spend hours each week maintaining a piece of middleware instead of developing a new end-user-facing application? If you have limited resources, choosing a less-than-ideal cloud service can be a better choice in the long run.

About the author:
Dan Sullivan holds a Master of Science degree, and is an author, systems architect and consultant with more than 20 years of IT experience. He has had engagements in advanced analytics, systems architecture, database design, enterprise security and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail and education. Dan has written extensively about topics that range from data warehousing, cloud computing and advanced analytics to security management, collaboration and text mining.

Next Steps

Finish line nowhere in sight for IaaS cloud race

How CloudSearch stacks up against DIY search tools

Crunching DIY DR costs vs. cloud DR

Dig Deeper on Cloud application migration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.