Avoid these app design mistakes to save a cloud budget
Certain oversights during app design can increase cloud costs. Dive into the details of four often-overlooked mistakes, and learn how to avoid them to keep your budget in check.
Most cloud users have already learned -- some painfully -- that many applications can't simply move to the cloud. Cloud infrastructure generates costs differently than data centers, so developers have to design applications to avoid certain tasks that are unusually expensive in the cloud.
Specifically, there are four common elements that can stand in the way of a cost-effective cloud application: overcomponentization, unnecessary overhead, overlooked cloud platform borders and overloaded databases. Any of these can make it difficult to stay true to a cloud budget.
Overcomponentization
Application componentization is a popular development trend, as it enables applications to more easily scale. Overcomponentization happens when developers break an application up into too many separately hosted components. Each component means a separate hosting instance and a separate fee, which can cause an organization to exceed its cloud budget.
Sometimes, this problem occurs because developers design applications with data center hosting in mind, and then those apps are later targeted for cloud deployment. Other times, it's because teams are focused on their own efficiency or on the value of component reuse.
Today, however, it's microservices that create the most risk. When a company goes too far to encourage microservices deployment, the result is an excessive number of hosing instances. To address this problem, use containers instead of VMs in the cloud, and review and justify every decision to create a separate component.
Unnecessary overhead
Cloud providers charge for the applications that run on their platforms based, in part, on the size of the machine image. It's easy to end up with unnecessary elements in a machine image, such as middleware that's no longer referenced. In an attempt to standardize application platforms, many companies will try to pick a common OS and middleware, but that could cause cloud costs to climb.
App containerization will go a long way to address this problem. If you need VMs, divide applications by platform class, with each class representing a specific middleware/OS combination. Assign applications to the lowest, smallest class where they'll run.
Overlooked cloud borders
When you plan for scaling and overlook cloud platform borders, it can wreak havoc on a cloud budget.
Many architects separately break out application components that need to scale to accommodate larger loads or require high availability. Sometimes, the deployment process for these components involves scaled instances that burst onto another cloud platform or from the cloud to the data center. These types of border crossings generate traffic charges.
To address this problem, map out workflows to see how data moves between application components. Look for places where the workflow intercepts components that need to scale under load or will redeploy to a different cloud or data center. Red-flag these components, and communicate the potential cost implications to the operations team.
Overloaded cloud databases
A software pipeline starts with architects and ends with operations, and everywhere along that line, smart decisions can be reinforced or undone.
Cloud providers charge users for the total number of database instances, storage, access, I/O bandwidth, licensing and other fees. In hybrid or multi-cloud deployments, there may be additional traffic charges to access a database outside the cloud or data center where it's hosted. Depending on how these various costs work out, some designers might push all their data into a common database to reduce the number of instances. However, this can hammer a cloud budget with other increased database costs.
Never design an application that extensively accesses databases across cloud and data center boundaries or across multiple clouds. If the database is in read-only mode, it may be cheaper to host it in multiple places. If it's a write-mode database, consider a single hosting point.
Also, weigh the relative costs of hosting multiple databases with a limited number of data elements vs. one database with a large number. Remember that each time any component reads/writes a database, you'll likely be charged for I/O bandwidth for the entire record, including fields the component doesn't really need.
Open communication lines
A software pipeline starts with architects and ends with operations, and anywhere along that line, smart decisions can be reinforced or undone.
The solution to that is communication. Clearly communicate any assumptions about the four issues mentioned above in the documentation that accompanies a software release. Also, if you use DevOps or orchestration tools during testing -- then transfer to operations -- include how application design dealt with these issues. Otherwise, a lot of good design work can be undone.
Dig Deeper on Cloud infrastructure design and management
