Anyone who has built applications understands that applications designed specifically for the platform on which they'll run will perform better and are more resilient and easier to manage. Developing for public or private cloud platforms is no exception.
However, few people understand exactly how to go about designing and building a cloud application architecture for private or public clouds. This lack of skills and experience has led to poorly designed applications for cloud-based platforms. These applications don't deliver the value on the cloud platform that enterprises expect.
Here's how to build a cloud-ready application, and the application architecture concepts you'll need to succeed. The process presented below represents a step-by-step approach that mixes traditional software development concepts and reviews what's new with the cloud. It is a collection of best practices, concepts, and procedures for success.
Design the application as a collection of services
Cloud applications are best deployed as a collection of cloud services, or APIs. You build up from the data to the services and then combine those services into composite services or complete composite applications.
This is service-based or service-oriented architecture, at its essence. While many understand the concepts, developers still have a tendency to create tightly coupled applications that focus on the user interface, rather than expose the underlying functions as services they can leverage independently.
When developing an application architecture for the cloud, you deal with complex distributed systems that can take advantage of loosely coupled applications built on many services that can also be decoupled from the data (see "Decouple the data" below). You can separate the application services physically, executing on the proper machine instances, and service/API managers and governance technology that provide services directories can help track the many services that make up your application.
Additional benefits may include service reuse from other applications or more coarse-grained services. You can break up applications into hundreds of underlying services that have value when used by other applications. In this way, you're not reinventing the wheel each time you build an application. Consider the example of a credit-check service that many applications use. Combine these into a single service and the application becomes much more efficient.
Decouple the data
If you tightly couple the data to the application, it won't find a good home in the cloud. Private and public clouds are complex distributed systems that work best with application architectures that break out processing and data into separate components.
You decouple the data for the same reason you want to build the application out of services. Once decoupled, you have the option to store and process the data on any public or private cloud instance. For example, many enterprises insist that their data remain on local servers but want to take advantage of the commodity virtual machine instances within a public cloud.
You must consider performance. Database reads and writes across the open Internet can cause latency, and database communications may determine how close your data sits to the services and applications that need to leverage it.
Consider using caching systems. These provide additional database performance by locally storing commonly accessed data, thereby reducing all database read requests back to the physical database. Those are best built into the application, however, and they should be tested with the application data to determine how efficient the cache will be. Systems that are constantly reading new data don't benefit as much from database caches.
Consider communications between application components
Decoupling applications, both data and services, doesn't mean your application is properly architected for the cloud. Chatty application components that constantly communicate with each other will lower the performance of the overall application, given that they're typically distributed over a network or the open Internet, where tolerance for high latency is desirable.
Focus on designing applications that optimize communications between application components. For example, combine communications into a single stream of data or a group of messages, rather than constantly communicating as if the application components reside on a single platform.
Model and design for performance and scaling
Extend considerations around how application components communicate to include overall performance as well. This includes understanding how the application will scale under an increasing load.
Designing for performance means first building a model that represents how the application behaves under an increasing load. If 1,000 or more users log on at the same time, how will the application handle the increased traffic on the network, the increased load on the application servers, and the load placed on the back-end databases? You need to understand how application components handle the load as the number of users increases to 1,000 or more users.
This example might increase the load on the application servers by 80 percent, the load on the network by 10 percent, and the load on the database by 40 percent. Given that, adding 1,000 more users will likely saturate the application servers you've provisioned, and you'll need to spin up more application server instances. The network capacity might remain the same, but the number of database instances may have to increase to handle any additional load.
Armed with this model, you can figure out how best to scale the application by automatically spinning up resource instances that are needed. In some cases, cloud service providers offer auto-scaling capabilities, where provisioning occurs automatically. The most efficient path, however, lies in understanding the application's workload profile and defining the path to scaling the application, as well as putting mechanisms in place to ensure that it will, indeed, scale.
Finally, monitor overall application performance using application-aware performance monitoring tools, and create interfaces within the application to better enable performance monitoring. How the application provisions and de-provisions resources should be innate to the application as well.
Make security systemic within the application
For most people who build applications, security is typically an afterthought. When hosting an application in the cloud, however, security should be a high priority. Your cloud-based application architecture should make security systemic to the application—it should be designed and built into the application architecture.
Pick a security approach and technology prior to building your application that will be effective for the type of application you're running and that will address any compliance or other data-level security issues. If you're in healthcare, for example, you must consider personally identifiable information as well as the Health Insurance Portability and Accountability Act (HIPAA) in the US. You'll need to store data in a certain way, on clouds that are HIPAA-compliant. Moreover, the application will need to handle sensitive data in specified ways, with required levels of security, such as encryption.
Generally speaking, cloud-based applications should leverage identity and access management (IAM). Enterprises that develop mature IAM capabilities can reduce their security costs and, more importantly, become significantly more agile at configuring security for cloud-based applications. Indeed, IAM will be a part of more than 50 percent of existing applications that migrate to the public cloud and nearly 90 percent of new applications built on clouds.
What's more, the use of IAM within cloud application deployments will backfill into the enterprise, as these organizations modernize security approaches and technologies to align with the use of public clouds. In many cases, IAM will be provided as a service to the enterprise. This concept of cloud-delivered IAM quickly leads to the concept of centralized identity management. As you build more cloud-based applications using IAM, each application should become significantly more secure and more cost effective.
Your core objective is to design security into the application and take advantage of the native features of both the cloud and the IAM system you use. However, each application has its own requirements based upon the needs of the business, and security always differs from one enterprise to another.
Building a cloud-ready application architecture requires that you pay attention to a few new things, but many of the traditional concepts are still important, such as sound design, testing, and learning from your mistakes. Most developers who deploy applications on private or public cloud platforms will make some blunders, but as long as they recognize, correct, and learn from those mistakes, they'll be well on their way to finding a more effective path to building applications in the cloud.
Understand that approaches such as service orientation should be given priority, even if it means longer initial application development lifecycles and bigger budgets. Even though you'll pay more for application development in the cloud than you did for traditional application development, the investment in services pays huge dividends year in and year out. It's a smart investment.
Image source: Flickr
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
