In 2006, Amazon Web Services flashed brilliance with a “light bulb moment” that sparked the imaginations of leading edge technologists and entrepreneurs. Literally overnight, “The Cloud” had arrived. The cloud offered the ability to create, launch and operate SaaS applications in a way that was never possible. Using simple and secure API’s, a software engineer could harness vast quantities of compute and storage services on-demand and with no up-front costs...all without touching a single physical atom. The cloud allowed small, efficient teams to build an application that could serve a large world-wide audience.

The core requirements for every SaaS application are scale-up, reliability and efficient infrastructure utilization. Scaling in the cloud means harnessing the on-demand capabilities. Reliability in the cloud means designing for failure by making software mirror what “physical” hardware used to supply in the co-located world. Operating cost-efficiently means “gaming the cloud” to find every place where you can process more work with less compute resources.Sonian has created innovative technology, architectures and processes in three major categories to be able to harness the cloud for enterprise information archiving and analytics.1. Effective Budgeting with a Cost Control SystemCompared to a traditional dedicated data center environment, it’s way too easy to spend money in the cloud. “Purchasing” in the cloud is psychologically different with the duality of two mindsets (using purchase orders to buy everything up-front versus consume small bits at a time) have to reconcile with the vastly different operating styles of dedicated compared to cloud. In the dedicated environment, big capital expenditures get multiple approvals and are on many people’s radar. But in the cloud, most teams start their cloud relationship with a credit card and pay monthly for the previous 30 days of small micro-charges for gigabytes of storage and hours of cpu time consumed.As the project grows and more people cycle onto the team, and the march to launch pushes faster and faster, it’s natural to consume more and more infrastructure. This is when a cost control system needs to be implemented.The are several ways to implement a budgeting and cost framework. A simple spreadsheet can be useful in the early days, along with once a month review to ensure the billed amount is close to the projected budget. But more often than not, there is a startling “gotcha” moment. A monthly bill comes in with a dramatic unexpected uptick in CPU or storage expense. This is “the canary in the coal mine” early warning to implement a more automatic and vigilant cost control system.In the cloud, tremendous amounts of computing horsepower is easily available, and at an hourly cost that seems minuscule (just dimes per hour), but when extrapolated out over 30 days, the expense can add up quickly. A hypothetical $0/68/hour compute instance, running 24 hours a day for 30 days, will cost $489 at the end of the month. Multiply that by 10 compute instances, and the compute fee is close to five thousand dollars. If the 10 compute instances are doing valuable work, then that’s a great deal. Because when the work is complete, the compute instances get turned off. And these compute instances probably didn’t need to run for the full month in the first place. Maybe just a couple hours per month is all that is required. The less positive scenario is that the 10 compute instances were started, did some work, but someone forgot to make sure they were turned off. The surprise five thousand dollar up-tick is the tipping point to the realization all these positive cloud upsides need a governing structure to ensure costs do not quickly spiral out of control.To solve the cost control problem there are third-party commercial cost management systems available, which is what we did at Sonian. We built a system tailored to our needs. Each cloud ISV has different use cases that will determine the best path. The downside to using a commercial package is the “one size fits all” approach, and the fact you will need to give the third-party access credentials to your cloud account control panels. (n.b. access control granularity is improving to appropriately restrict third-party cost analyzers from doing harm to the infrastructure.)The “do it yourself” approach uses cloud API’s to scrape data for infrastructure utilization and billing. With a reasonable effort, you can build a custom cost analyzer that is designed more tightly into your software stack. The advantage for a do-it-yourself approach is a system that solves your unique use case, and the downside is more code to maintain. But since cost management is critical to cloud computing success, the custom implementation ensures tight integration to the core technology.2. Scale Beautifully with a Systems Monitoring and Automation FrameworkThe next area to focus on is achieving reliable operations with monitoring and deployment automation. In some cases the cost management system described above should be an extension of the automation and monitoring framework, since all three will benefit from being tightly coupled together. In the old pre-cloud world there was no need for a real-time cost management system. The adjunct technology and systems surrounding the core application was mostly monitoring and alerting in nature. But in the cloud, systems automation is as critical as cost management and monitoring.In order to take advantage of cloud on-demand scaling, automation needs to be responsible for provisioning new infrastructure and keeping track of what is running so you can efficiently turn it off later. Automation removes “human hands” and potential errors. And while cloud automation is required to start and stop infrastructure, a monitoring system is needed to keep vigilance on the running infrastructure and alert when a server or process fails. Cloud architectures tend to be dynamic, distributed, and highly complex, which means an effective monitoring system is a "must have" in order to know when a component is trending toward failure.The current state of the art is to have a separate automation framework focused on scaling infrastructure up and down, while monitoring is its own set of technologies with the mandate to alert and report on the live environment.Each of these areas needs near custom implementation to graft into your project. Cloud-based software stacks, by their very nature on how distributed software works in the cloud, need custom automation and monitoring. There are many great frameworks (Sonian’s open source Sensu project for example) which support extensive customization capabilities. Cloud ISV’s should use one of these as the foundation to create a monitoring and automation framework that meets your unique needs.3. Game the Cloud with Elastic ApplicationsA simple fact proven through real-world experience: “Net new” software stacks, designed with cloud operating principles firmly rooted in the core design, are a “must have” to take advantage of cloud computing economics and reliability. In fact, the dual goals of economical operation and non-stop reliability can be achieved with the same architectural principles. Building for the cloud is all about “fluid designs” of discreet components that can be woven into cloud computing fabric. The days of rigid architectures are behind us.The prevailing conventional enterprise software design and architecture patterns are not adequate for today’s new cloud infrastructures. Traditional architectures assume client/server, PC-based building blocks. The era of an assemblage of Windows or Linux compute nodes combined together in different component roles is falling behind us. And that is a good thing. When thinking about building software for the cloud, design patterns that were previously commonplace for mainframe thinking are more appropriate for the cloud, than trying to retrofit the old client/server model onto the cloud.The cloud should really be thought of as an enormous mainframe computer. Embracing this notion is a big leap in design architectures from where we are today, because our conventional modern thinking has been heavily influenced by the building blocks of yesteryear: Cheap hardware running Windows and Linux operating systems, custom software, client/server and Web 1.0 architectures, all wired together to form various clusters of functionality.There are three primary reasons to use the cloud versus a traditional co-located data center:

Your use case has dynamic, shifting, variable work loads

Your use case has a very high up-time SLA requirement (at whatever cost)

Your building a prototype and scale and cost are not important… for the moment

Not every SaaS application has these requirements. It’s easy to get caught up in the “cloud hype” du jour and the desire to harness the cloud because it’s the “in thing” right now. But seriously look at your needs because maybe the cloud is not the best place to host your software. If you are running a web application that manages light-weight user generated content for a predictable number of simultaneous people, then the cloud probably offers no economic advantage. But if your app needs to be 99.9999% available, and your audience will pay for this up-time SLA, then the cloud is the right infrastructure. No other hosting platform has the ability to be economical, scalable and reliable all at the the same time. To be all three requires elastic applications.In 2007 Amazon introduced their Elastic Compute Cloud (EC2) service, which complimented the very reliable Simple Storage Service (S3). EC2 is flexible compute on demand, with no upfront costs. EC2 allows you to build applications that can be both fault tolerant and economical at the same time. Without elastic software EC2 is a very expensive hosting platform for non-elastic software stacks.The majority of enterprise software is not elastic. Traditional enterprise software created during the client/server of the last decade, or the more recent Web 1.0 era, didn’t know about cloud computing. You would need to look back in time toward mainframe design principles to get a feel for a software architecture with compute efficiencies baked in. But cloud, and the ability to take a step back and design differently, what was old (mainframe) seems fresh and new.Take for example Microsoft Exchange Server. Used by hundreds of millions of people on a daily basis, it’s one of the most common examples of traditional non-cloud architectures. The Exchange Server software requires a dedicated amount of hardware, regardless of the “in the moment” usage patterns. Now envision a scenario where Exchange Server was re-built with elastic capabilities. Back-end and front-end Exchange components could dynamically scale up and down based on time of day or other usage patterns. Instead of dedicated compute resources for front-end services, data stores, gateways, etc. a re-architected Exchange Server could dynamically allocate compute to the component most under load. For evenings and weekends capacity could be pared back (saving money). During peak activity periods, such as at the start of the work day when everyone is checking their email, compute capacity could be added for a few hours, then scaled back and the same cycle could repeat after lunch. When the software has elasticity at the core it’s possible to operate at peak efficiency around the clock.Elastic application characteristics include:

Enterprise service bus architecture patterns

Loosely coupled modules that scale independently of one another

A design that evokes “fluid” concepts as opposed to rigid constructs

Design to Survive an Earthquake and Save the Planet at the Same Time

The big data cloud needs applications that are flexible and pliable. Just as you would design a building to withstand an earthquake, structures need to sway and balance gracefully when the ground trembles. In a metaphorical sense the cloud has similarities to geographies with consistent seismic activity. Rigid structures won’t endure an earthquake’s potential to cause catastrophic destruction. The same can be said for software running in the cloud. A “rigid” application like Microsoft Exchange Server will suffer greater damage in the cloud compared to software written to be fluid and flexible.In the cloud, like in an earthquake zone, the software gets no advance warning before calamity strikes. In the cloud, the software can’t “peer” beneath the virtualization layer to see pending doom. In the cloud you need to expect failure and be resilient. Being resilient doesn’t mean being rigid, it’s actually just the opposite. To enable software to endure an infrastructure failure in the cloud requires a fluid design that can adapt in real-time to a rapidly changing environment.The dual goals of cost efficiency and resiliency are accomplished with the same design. To be resilient is to be a collection of loosely coupled services that are woven together and flex to accommodate a dynamic cloud environment. To be cost effective is to be a collection of loosely coupled services that can optimize every transaction and near 100% compute utilization. The closer to 100% utilization means less waste.A Cloud Customer Success Story - Dollar Tree StoresSonian, operating in the Amazon Web Services cloud, has been providing information archiving services for US-based Dollar Tree Stores (DTS) for over 10,000 employees and thousands of store locations. DTS has an IBM Domino/Notes environment and needed a new way to manage long-term archival, search, and e-discovery requirements. DTS also wanted to move their on-premises legacy archive data to the cloud in order to take advantage of better econmics and ROI for their IT budget.