justinkendra - Fotolia
Since cloud computing began, its focus has primarily been on the migration of applications to the cloud. Implicit in that goal is the notion that there's no functional difference between the cloud and the data center -- only a cost difference. We now know that's not true; the largest sources of cloud revenue for providers are cloud-based apps built specifically for the technology, so architects need to understand what that means. Understanding starts with assessing the impact of cloud business trends on cloud service models and visualizing how cloud features will enable new applications. The next steps are learning to design for the cloud and mixing application design with evolving cloud features.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
For software architects, the most important truth about cloud business trends is that infrastructure as a service (IaaS) isn't enough to drive the cloud to its full potential. Simply hosting current underutilized services in the cloud doesn't create enough benefit for users or profit for providers. Amazon, which leads the world in cloud services, is already moving beyond IaaS, adding Web services that offer special features like caching, HTML acceleration, identity management and data flow management. These features are the things Amazon thinks will bring the best combination of buyer value and seller profit, so architects should think of their own applications in similar terms.
When they assess which features could be available as cloud-based apps, the first step for architects should be to audit the major cloud providers to discover what is being offered. In particular, they should look at the trends that the cloud service offerings illustrate. Amazon is going to address the big cloud service opportunities first, and Amazon competitors are likely to dodge the cloud giant's market power by finding new and valuable niches. When companies find the right direction, they can plot cloud applications that take advantage of the feature trends.
Cloud service tools should encourage cloud service evolution from providers and cloud-specific applications built without specialized cloud services. The cloud is all about distribution -- of users, resources, data and processing. It follows that the most useful cloud applications and services will be distributed effectively.
Distribution support breaks down into three pieces: support for a highly variable and diverse user base, collection of information from a wide variety of dispersed resources, and application processing that could be anywhere from nondemanding to something that needs almost supercomputer power to accomplish. The cloud can provide any or all of these things, and most current and emerging cloud Web-service offerings will fit into one of these categories.
The common thread in all these distribution models is the critical role that workflow plays. Architects today tend to build applications for agility and functionality. Exclusively cloud-based apps are built around workflows, and each of the three distribution areas has its own workflow management issues and opportunities.
For user distribution, the cloud architect should look for Web-like support for individual users, with work requests aggregated back to a common transaction or processing flow. Think of the whole application front end as an elastic set of elements (some Web servers and some applications servers) deployed when and where needed, in any quantity. This model should be followed for any application, and supporting those applications' functionality within this model is the cloud architect's first goal.
Cloud data collection is often linked with user support because the user may be both the source of information and the target for results delivery. Where that's true, the same model for the application can apply. Where it's not true, there is the Internet of Things (IoT) model. Cloud IoT is about collecting information from distributed sources and aggregating it into two streams: one designed to be used in real time for process or business control, the other designed to be used in collected form (big data) to drive analytics and knowledge applications. Keep IoT principles and characteristics in mind when you build a cloud data collection application.
Most architects find it easy to adapt to a cloud-specific model when they're conceptualizing user support or data collection and IoT. It is more difficult to distribute the process because process elasticity is a response to variable workloads within a fixed-functions model of an application. It's up to the architect to make that work.
The critical step in making an application process distributable is designing its components correctly. Generally it's difficult to manage component scaling where updates to databases are generated; the databases' update and integrity protection techniques are a point of congestion difficult to alleviate. That means you should look for functional areas of your cloud applications that are compute-bound or that access data tables in read-only mode. Find these functional areas and make each into a component that can be horizontally scaled as work grows or contracts.
The final step for architects is to fit cloud-provider Web services, current and evolving, into the three distribution areas mentioned previously. Caching of content and HTML acceleration, for example, are both useful in serving a diverse population of application users, and flow management is a critical element in IoT or distributed data collection. Staying within the architectural constraints described for each area, fit cloud tools in by mapping the tools into the appropriate place in the workflow. Architects should always wrap external tools and APIs in company logic so they can easily change the code if the Web service changes or if they find another cloud provider with better capabilities.
Cloud workflows can become inefficient very easily because of the network overhead associated with component integration. It's smart to build pilot applications that test the workflows even before completing the logic, so architects can adapt the application to the performance characteristics of their cloud providers. This will keep their leading-edge applications from falling over that edge.
Understanding cloud-specific security technologies
Mobile cloud apps vs. native apps: The developer's perspective