Let’s face it, when you think about cost aware applications and the cloud, the traditional IT approach just won’t cut it. That’s because when you run an application in a traditional data center, you allocate servers to it and plan for maximum capacity. For the most part, the servers do nothing, and are simply preparing for the day, hour, or minute of high capacity demand.
That same type of capacity planning is possible in the cloud, but it’s not scalable, is extremely expensive and really, just doesn’t make sense. That’s because planning in advance for the highest possible capacity means you will pay for idle and redundant resources. Unlike traditional on-premises IT infrastructures, where you buy a server and it sits on the rack costing you virtually nothing, in the cloud, you pay per use. An application in the cloud needs to have a lean cost model, allocating exactly what it needs for its current state, provisioning more resources, as needed. That’s where the concept of elasticity comes in. The difference between cloud and traditional IT thinking is that in traditional IT, you provision for the worst, whereas in the cloud, you provision for immediate need.
Building a cloud native application (CNA) in the AWS cloud and moving enterprise workloads to the cloud are two completely different scenarios. Not every application is able to take advantage of the cloud’s elasticity. A traditional 2-tier application with one server and one database, for example, won’t scale for a very simple reason. In order to scale, you need to be able to either have several databases with replication, several web servers that allow you to move or save sessions between them, or you need to provision some kind of load balancing mechanism.
5 Cloud Cost Aware Considerations
1. Tightly tie cloud costs in with your business
You need to be able to tell whether a cost change is justified by your business.
Depending on what your application does, especially in a SaaS environment, the application’s cost needs to reflect the cost of whatever it does. Let’s take a web site with two servers that cost you ‘X’, for example. Now, suppose the number of hits it generally receives doubles, requiring you to double its number of servers. That will obviously increase costs, but since your business has also grown, you can handle the additional costs. Next, you decide to roll out a new version of your application that is more resource demanding causing your costs to grow by 50%. In this case, the cost growth is unjustified, because you do not have the added revenues. In addition to architecting and building your system, you also have to measure the number of business transactions that are performed for your costs. It is vital to align income with your operational costs.
2. Automated elasticity
Allocate whatever you need and release what you don’t.
Think cloud. As mentioned above, provisioning for the worst case scenario, as they do in traditional IT, does not work in this realm. It is also important to keep automation in mind. If you are planning and building an application from scratch, cloud architecture plays an integral role. Autoscale is an important feature to leverage. Horizontal and vertical auto scaling are the main cloud features that align capacity based on demand. In addition, it’s important to leverage the cloud’s flexibility to build test environments, when needed, and deploy an optimized SLA. For example, it is also imperative to plan for redundancy and failover, so that when you start your service, you can leverage another region offline, until it’s needed, without immediately impacting costs.
3. Be granular
Do you need multiple small or one large?
Suppose you have a server that becomes 70% loaded. When you add a single large server to handle the newly acquired bigger load, you will end up having very little load on the second server, yet still pay the price for its size. This is not a very elastic approach. On the other hand, you could use multiple smaller servers that provide the same capacity as a single large one.
According to our benchmarks, using two smaller servers, with the exact same CPU units, renders about 30% more compute capacity than using one large server. This is due to several reasons. First, just because a medium instance is smaller than a large instance does not mean that it is half the size of a large instance. A medium instance’s I/O does not equal half of a large instance’s I/O, which is one of the limiting factors. The same goes for the network. If your instance is network intensive, you will probably be better off with two medium instances than one large. When you start scaling with smaller machines, you may be much more accurate because large instances provide large chunks of capacity, which means they will be utilized much less than their potential when scaling up. On the other hand, if you scale with smaller machines, you may be much more aligned with what you actually need. So, be granular.
There are limitations to being granular, of course. Certain applications do not work well on small instances. For example, a large NoSQL database, like MongoDB, that is extremely memory intensive, actually works best on the largest possible instance. This shows us how important It is to test your architecture. Nonetheless, granularity is much more effective for simple applications.
4. Be portable
Clouds change – and quick adoption could not be more important.
The cloud is extremely dynamic with conditions constantly changing (e.g. pricing, SLA, convenience). For example, Azure may be coming out with new features that improve deployment next month, and Amazon could have a plan to enhance application efficiency six months from now. You need to be very agile and treat the cloud as an infrastructure and not as a lock-in factor. Looking at the industry’s current situation, almost everyone is starting to provision Docker containers, which are very good vehicles for application virtualization. The same Docker environment will serve you in Amazon cloud, Google cloud and others in the near future. So, if you plan in advance, you could move your application from one cloud to another, then leverage the better cost, SLA, or conditions. If you lock your application in with one provider, when something goes wrong with that provider, you’re stuck. Then what happens if your provider decides to overcharge you?
While there are caveats, such as large amounts of data, that make moving between providers very expensive, containers generally make moving between providers virtually effortless. That way you can leverage whichever one gives you a better bang for your buck.
Learn more: Multi-cloud vendor comparison tutorial
5. Plan your cloud cost monitoring
You can’t be aware of anything unless you measure it.
This is extremely important, because most people tend to forget about cloud monitoring. But, to reiterate my point, if you do not monitor your costs, you cannot be cost aware.
Start by planning your cost monitoring. Measure each application separately, tag resources, be able to identify the impact of each application so you can measure a single application, and monitor the costs on a daily basis (otherwise you could be in for quite an unpleasant surprise at the end of the month).
Learn more: How to Monitor Your Instances with Cloudyn
The screenshot below illustrates a real case of the daily transaction distribution in a business. It shows the capacity before a certain event occurred and where the new version of the application was deployed, which suddenly increased capacity. For the same number of transactions, you can see that there is a much higher capacity, and therefore cost, but no increase in margins.
The application’s architecture has an immediate cost savings impact on your cloud invoice. For example, using a caching layer could reduce the amount of data transactions by 70%. The cloud puts cost at the forefront of IT utilization and usage. Therefore, the right cloud architecture should keep cost in mind and must prove to have efficient usage right from the start, avoiding cloud sprawl and aligning actual demand with capacity.
Using AWS Cloud? Ensure that your AWS deployment is properly priced, appropriately sized and optimally utilized – Check out Cloudyn’s Tools for the AWS Cloud