---

What is a cloud?

People look at the cloud in different ways.

• Some say any virtualized environment is a cloud
• Some say any multi-tenant infrastructure is a cloud
• Some say as long as I’m not hosting my application internally it’s on a cloud.

Ok the last one may be a bit far-fetched, but on the whole there are many definitions of what clouds are that are floating around there. It’s fair to say that the cloud means different things to different people, since everyone looks at the problems and benefits in their own way. But, defining a platform by its benefits is a bit misleading. At the heart of it, we at TBW define a cloud as:

Any scalable infrastructure available on-demand and billed on a utility-like metered basis

Not very complicated, but at least it’s a generic definition that explains what the cloud is.

Things could get crazy

Just having infrastructure on-demand is not enough. From what we’ve seen, the biggest mistake new cloud adopters make is that they very quickly succumb to the “kids in a candy store” syndrome. I’ll admit that when you work with the cloud, you feel like have you god-like powers since you can launch thousands of servers with a few mouse clicks. And since you don’t have any up-front costs, and you can instantly turn on and off servers, there is very little stopping you from going a bit crazy with servers. Need a new fleet of servers? No problem. Running out resources and need to upgrade to a larger server quickly? No problem.

But as with all good things, it comes at a cost. At the end of each month, you’ll get your bill and if you’re not careful, you can easily end up blowing your budget just because you went a little crazy. We call this phase “Cloud remorse” (cheesy but its still a fact).

Remember (as many a Hollywood flick tells us)

With Great Power Comes Great Responsibility

Don’t be a kid in a candy store

I can’t tell you the number of times I’ve got a call from one our clients asking “Why is my bill so high? Is there any way to reduce our costs?”. The answer to this question is “Most likely”. There are times that you can’t escape a somewhat expensive bill, since your application requirements dictate a certain minimum set of resources. That minimum can cost a fair amount, but the tradeoff is that usually the user traffic that you can handle on such an infrastructure is higher than what you’d be able to handle on a smaller infrastructure footprint. But very often after we’ve faced these calls, upon closer analysis, we find that costs can be reduced, in some cases drastically, by changing the way you handle scaling.

Often, the biggest hangover of moving from traditional to cloud environments is that we’ve been trained to ask the question, “What happens if my traffic grows? Should I have additional capacity to handle that? How much should I have? Isn’t it better to have additional capacity just in case I become super successful?”. As a result, we often find that the scale of infrastructure deployed is excessive for immediate needs, and there’s a lot of wasted, idle capacity just sitting there sucking up huge chunks of the monthly budget. When lead times for provisioning infrastructure run to weeks, and you don’t have the ability to get rid of infrastructure once provisioned, this kind of thinking makes sense. But, when you have instant access to additional capacity, and you can release unnecessary resources and not have to pay for them, why would you keep thinking old-school?

Just ‘cause you can deploy a large number of servers, or servers with more resources doesn’t mean you have to deploy them. If you’re going to need that extra capacity 6 months down the line, why deploy it today and start paying for all that extra capacity now which isn’t being used? Why not save that money and make your operations leaner and more in line with your cashflow? Why don’t you setup your infrastructure to react to your traffic and add or remove resources as you need it?

You need to refresh your thinking. What you need is Elasticity.

So what’s Elasticity?

Elasticity

The automated ability to instantly scale your resources to meet your load requirements and release excess resources when not required, thereby achieving scalability, performance, and cost-efficiency. - The Binary Workshop

If you ask us, Elasticity is what the cloud is all about, or at least should be about. Every service, resource, and capability that we leverage has to be put to work as part a master plan designed to make any infrastructure elastic. If you need to add capacity, add it. If you’ve got idle capacity or you don’t need so many resources, get rid of it. Why pay for what you don’t need?

It’s this kind of thinking that we bring to the table with GoElastic. We help you plan your infrastructure requirements for short, medium, and the long term, and at all times strive to make sure that you aren’t wasting money on resources. We help you automate your infrastructure to react to sudden surges or drops in traffic by adding and removing resources as needed. We help you design your application over time to leverage Elasticity to the maximum. And most importantly, we work to make sure that you enjoy the best experience working with cloud infrastructure in terms of cost, performance and reliability.

Introducing GoElastic

GoElastic is a complete lifecycle suite of cloud support services from The Binary Workshop designed to help you get the most of out of the Amazon Web Services (AWS) cloud platform. Our goal is to ensure your maximize the elasticity of your infrastructure when running on AWS.

When you work with AWS, flexibility is key. Your needs can vary from evaluating the feasibility of running or building an application on the AWS cloud, to managing the AWS infrastructure that powers your application, to even requiring assistance in architecting and developing your application on an ongoing basis. Also, what you need today will not necessarily be what you need tomorrow. So it’s vital that you work with a partner who can adapt to your needs and ensure the smoothest transition and operation of your AWS cloud now and moving forward.

With that in mind, GoElastic is delivered as a flexible service offering to complement the level of engagement you require at any time.

How it works

GoElastic services are available through a tiered subscription model, with each tier tailored to cater to a specific level of engagement. Each tier defines the specific features and services that TBW can perform for you related to your AWS cloud requirements. Within each tier, you can select a support subscription that indicates the number of hours of committed service you will receive that you can use for the various services available in the selected tier.

In GoElastic, the engagement is primarily driven by specific requests for support or “tickets” raised by clients with relation to their cloud platforms. Clients can raise tickets on practically any service included in their subscription, such as tickets for conducting a penetration test, provisioning new hardware, preparing platforms and machine images for application deployment, tuning performance parameters on existing platforms, resolving infrastructure problems, consulting regarding application architecture, etc.

Any time spent responding to these issues is tracked and deducted against the total number of hours available to the client during the subscription period. Our client support portal provides a detailed summary of work done in resolving tickets, and also a breakdown of how time was spent.

Apart from these client raised tickets, some plans include services that we perform automatically as part of the service. For services such pro-active administration, we will raise tickets regarding this issues in the ticket management system, as close to the time of issue identification as possible, to inform all persons involved of the problem, and the status of the resolution in a streamlined manner. Time spent in resolving these issues will be deducted against the number of hours currently available to the client during the subscription period.

Certain services such as live monitoring, scheduled maintenance, and periodic optimization offered in subscriptions are performed automatically by us and not treated as tickets, therefore any time spent on these services is included as part of the subscription and not deducted against available hours.

In cases where the resolution of a problem might involve the deployment of added infrastructure, changing existing architecture, and/or results in a sustained non-availability of service, we can escalate to the client to decide on a plan of action to resolve the issue as needed, based on prior discussions on what scenarios require explicit client approval before implementation. Subscriptions are active until all available hours are exhausted or the term of subscription expires, whichever occurs earlier. Clients will need to purchase a new subscription before the previous subscription is expires in order to enjoy uninterrupted service. Subscriptions are purchased in advance of their active period and are active from the day that payment is received by TBW for the service.

Why work this way

If there is one thing that we have learnt by working on clouds, it’s that customer requirements can shift very quickly, both in terms of scale as well as the type of assistance and support they need. This trend is mainly due to the reduction to almost-zero of lead time in infrastructure provisioning, which means our customers work learner, meaner and smarter in terms of managing costs against performance. So, the kind of involvement that is required of us would vary in a very short time-frame. In some cases, our role is purely advisory, while in others we end up partnering our customers and take on primary responsibility for clouds, including provisioning, ongoing maintenance, and architecture consultancy.

Over time, we found that we could classify the nature of our involvement into general service categories, which allowed us to package these categories in levels of support. Also, we established a direct relationship between the the amount of resources involved and the complexity (or simplicity) of the infrastructure requirements and the amount of actual time spent by us in support these requirements.

What we wanted was a business model that met the following conditions:

1. Allow for clear transparency between us and our customers into the nature of services that we offered, and the associated costs of those services.
2. Allow for flexibility for our customers to increase or decrease the nature of services we provided them on a monthly, quarterly, bi-annual or annual basis, to align with the actual project requirements, and trim their operating budgets.

Based on our requirements and findings, we realized that the best model that met these criteria was already in use by mobile companies offering prepaid mobile services. You select a plan with certain features/services, select the number of units you want to buy in advanced and pay the amount upfront. The units have a validity for a certain period, and if you renew your plan before the units expire, your plan is reactivated and extended for the duration of units you just purchased, and any units you haven’t previously used get added to your new balance. If you choose not to renew, your plan is activate until your units expire.

So with GoElastic, what’ve done is we’ve created support tiers or “plans”, and within each plan you can opt to purchase in advance a certain amount of support hours. Support hours are valid for the duration of your chosen subscription, and if you renew your subscription, any unused hours are carried forward and added to the newly purchased hours. Each plan specifies the kind of services your request from us upfront, and you are free to allocate your available hours against these services as you need it.

Why we like this approach is that:

1. Our customers can manage risks and experiment with various plans before settling on the plan most suited for them.
2. At any point in time, our customers know exactly what they’re getting and what their costs are.
3. No uncertainty regarding long-term commitments for both sides. At all times, everyone is clear as to the nature of services, engagement and duration.
4. For us, we know exactly what we have deliver, so we are able to standardize on processes and SLAs and optimize our internal operations.
5. We are able to cater to wider variety of customers as the cost of engagement is transparent and caters to all budgets and projects.

originally posted at: http://www.thebw.in/blog/2012/05/23/announcing-goelastic.html

---