Cloud Hosting

Most application architects and development teams often turn to their application lifecycle management tools and...

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

processes to deal with the challenges of the cloud app development, but they often fall prey to common misconceptions about cloud ALM. In this tip, we'll examine the commonly held beliefs about cloud ALM that can hamper app development efforts.

There are three common myths about cloud ALM:

ALM works to stabilize IT by creating a framework in which applications can be added and changed without risking security, compliance and even functional problems. The fundamental principle of ALM is to enforce that framework through the entire cloud app development and deployment process. The cloud -- and cloud ALM -- complicates this in two specific ways: it abstracts resources and it leads inevitably to continuous delivery pressures.

ALM is meaningless if the hosting of applications and components, and their integration, is based on different resources and connections than will be used in production. That's a basic truth of ALM; yet, in the cloud, the location and connectivity of applications and components is never certain.

Most users will try to address this uncertainty by refining their cloud ALM processes, but the problem with that is that it increases ALM complexity, reduces its responsiveness to business problems and eventually creates a lifecycle process so difficult and expensive that its failure is a given.

Continuous delivery is aimed at improving application responsiveness to business needs, and the cloud encourages that by reducing or eliminating the normal capital equipment inertia associated with deploying IT resources. If I can spin up a server in minutes instead of taking a month's worth of procurement and installation time, why wouldn't that make IT more responsive? The only way to have that happen is to accelerate the application lifecycle, which argues against adding extensive accommodation to cloud hosting.

ALM alone can't solve the cloud problems. You need to have two new dimensions of management: virtual resource management, and service and microservice management. A cloud-ALM approach absolutely must deal with the cloud by establishing a consistent way of viewing virtual resources. If all hosting, cloud or data center, is considered virtual, and if management processes are suitable for any hosting option that's adopted, then ALM can be made independent of hosting. Similarly, if the services and microservices used for multiple applications are lifecycle-managed as a group, then applications that use them aren't impacted nearly as much by the cloud-driven trend toward shared services.

Another destructive misconception about cloud ALM is that adopting DevOps will fix everything. DevOps tools are wonderful ways of enforcing structure and consistency on ALM practices, but they can't frame those practices.

Even adopting virtual resource and service/microservice management is best handled if there's a specific IT model that you're managing to secure. That model can come only from tighter integration between enterprise architecture (EA) and ALM. EA practices must feed ALM with the business goals and the operational framework in which application lifecycles are managed. That is true not only for traditional ALM, but also for virtual resource and service/microservice lifecycle management.

EA integration is the starting point for effective definition of service/microservice sharing policies, because common business practices that are evolving in harmony are the very place where service/microservice componentization will benefit most. EA business requirements also set the resource availability constraints that both cloud and data center must meet. Getting ALM extended across the EA boundary to capture this information is critical, and will require some work on both sides to accomplish.

DevOps could change, based on this EA integration, into something more broadly useful for cloud ALM. If DevOps tools are used to structure resource management and service/microservice lifecycle management, along with ALM, the result can be an automated and responsive process for continuous delivery that works at cloud speed. Making this happen demands a revision in some DevOps methods; it's important to use modular features and event-driven behavior more, no matter what specific DevOps product you adopt.

Perhaps the most critical of all cloud ALM misconceptions is that "there will always be ALM." The truth is that every trend in cloud app development is taking us to a place where there is no such thing as an application in a monolithic sense.

Applications are evolving into a set of event-driven microservices connected through a loose specification of business requirements, almost a cloud-centric form of an enterprise service bus. In this model, the number of applications and the variations on each are enormous, and no testing of all the possible combinations could ever hope to succeed.

ALM today has to work against the tendency, common in all technology concepts, to enshrine itself in practices and become a goal rather than a means to a goal. A model of the future where EA defines the component relationships based on functional needs of business activities, and where resources are managed against an experience-driven vision of responsiveness and availability, fits the trends we can already see. That model would have to recognize the decreasing value of an application-centric view of IT.

The problem is that while it's technically reasonable to look at the future as a set of event-driven, business-composed components using abstract resources, it's a lot harder. Neither current tools and practices nor the experience of DevOps personnel prepare a business for this cloud app development evolution. They never will, though, if we continue to see that future through monolithic-colored glasses. ALM has to break out and redefine itself in terms of how it integrates certified classes of resources and tools -- not how static tools support dynamic business processes.

Planning application lifecycle management in the cloud

Explore new technologies for cloud ALM

What are application security concerns in cloud-based ALM?

Continued here:
Misconceptions about applying ALM to cloud app development processes - TechTarget