January 22, 2015 | Written by: Gary Zeien
Share this post:
Should I move my application to a hybrid cloud? This is the question of the day. As hybrid cloud becomes the client and server, or service oriented architecture (SOA), of the 2010s, everyone is asking about trying cloud.
As I covered in some previous Thoughts on Cloud blog posts, there are some fundamental structural aspects that need to be considered. As any engineer knows, understanding the structure of something is key to determining the ability to change or move it. Another perspective involves knowing why something works, rather than the what or how.
If, after architectural analysis, you find that you can move an application to a cloud, or better yet a hybrid cloud, the next logical question to ask should be why. What is the value of spending the effort and the money to do this?
As stated in other posts, there are structural application types that show how the hybrid cloud was designed and built. There are also lifecycle characteristics of applications that affect the choice of moving to a hybrid cloud. Think of it this way: when you look at your block you may find that house where the owner does little more than the necessary upkeep or a house where the owner just can’t seem to stop remodeling, and everything in between. How the heck does this relate? Let me show you.
(Related: 10 questions to ask when moving applications to hybrid cloud)
Applications can be as different as the houses on your block. Let’s look at a few.
1. Some applications can be very static
The code base for some applications changes little over time. The scaling characteristics of the application are also very consistent. Rarely is more infrastructure required to support capacity needs.
Often, these are existing applications with static business logic (if logic is embedded in the code), and they just work, meaning that no one is especially familiar with how they functions. Over time, there are fewer and fewer people who know how the systems really work.
This is the house on the block that is maintained and isn’t necessarily an eyesore, but no one really knows much about it. It’s not a problem, so people don’t worry about it—until it goes up for sale.
2. Some applications can have a static code base but flexible configuration parameters
In this case, the scaling characteristics vary; in certain situations it could be static, but more commonly the application can scale based on loads.
This case frequently occurs when a business purchases a package that is tailored based on certain parameters. The code and runtime environments, or both, don’t change much, but by using a parameter approach, the configuration of the application can change.
So this is similar to the house on your block that is kept up, painted regularly and newly furnished often, but the basic footprint doesn’t change much.
3. Some applications may have select portions of the application logic that change frequently as the business dictates
This is commonly found in multitier applications. Usually what is presented to customers will change more frequently than the core business logic or database structure. The scaling characteristics typically vary based on tiers, with some tiers scaling differently than others.
Think of it this way: a new porch is added, or rooms are converted to bedrooms as children arrive. The adaptable nature of the house is used to change as the family changes.
4. Some applications change very frequently or are apps with short lifespans
In this case, the applications are often tactical, short-term applications created with a specific purpose or for a particular user community. Often, these are created by the business for a specific unit. In today’s world, they are usually known as systems of engagement applications.
As a result, these applications have very dynamic scalable characteristics that can change based on the lifecycle phase (like test), number of users, traffic load and more.
Think of the neighbor that is constantly remodeling, adding rooms, restructuring floors or removing garages to suit the family needs.
(Related: Hybrid clouds: Should you bring on the moving van?)
So, what do all these options mean for me?
As you can see, there is a range of options, but not every type of application is suited to be deployed in a hybrid cloud. It is important to consider the lifecycle. The cloud is especially good at hosting applications that are very dynamic both in terms of changes and scaling characteristics. That’s where the flexibility of a cloud platform can be applied to its advantage.
Dynamic applications need the ability to quickly and easily add and remove infrastructure. This is where the cost and benefits of a cloud environment really come into play. Why pay for the infrastructure, networks and storage if you don’t need to? These applications, or partitions, that change the most are good candidates for a cloud or hybrid cloud environment.
In addition, the capabilities of a platform as a service (PaaS) environment, such as IBM Bluemix, allow you to add rooms to your hybrid house quickly, but this works only if the underlying application can support the extensions.
However, the flip side is also true. If an application is very static and doesn’t change much, then the structural and financial benefits of moving applications to the cloud become more questionable. Yes, expenses do move from capital expenditure (CAPEX) to operational expenditure (OPEX), but if you step back and think about it, all you are doing is moving something that doesn’t change much from one platform to another. It’s like moving the first static house I mentioned to a new foundation, on a different lot. The property taxes may be lower, but you still have the same house.
The bottom line here is that you need to consider not only if an application can be moved to the cloud or a hybrid cloud, but should it be moved. The more an application aligns to the types I discussed, the greater the benefits that can be obtained from the cloud ecosystem.