ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Part 3: Designing for the Cloud with an ISV Mindset

Updated on November 14, 2013

AppLogic: facilitating Continuous Delivery

As previously mentioned, working with the unknown (or unknowable), means that strategy is, by necessity, in a constant state of adaptation in reaction to market evolution.

Our approach, and the advice we give to our clients, is to design for such uncertainty – and that’s why we focus so heavily on service-oriented architecture when helping our customers to map out their cloud strategy. We focus on (i) how to avoid developmental dead-ends, in other words building systems that can more easily adapt to new technological advances, we focus on (ii) the use of private cloud to model the entire service architecture in the real world, with real customers, before breaking out (if appropriate) into the public cloud, and (iii) we encourage customers to take on board that the platform they’re using today, may or may not be what they’ll need to use 5 years down the road.

AppLogic’s “secret sauce” is its capability to abstract & manage not just simple virtual machines but instead full service architectures, (including all of the application & database servers, storage, networking appliances and accompanying configuration metadata). This allows service engineers to rapidly prototype and deploy services through an intuitive visual canvas that provides access to reusable, pre-built catalogs of components that can simply be dragged and dropped into the service design. AppLogic- based services can then be deployed, copied, branched and migrated to any other AppLogic grid, irrespective of the underlying hardware or geographic location.

Figure 6: AppLogic Service Design Canvas
Figure 6: AppLogic Service Design Canvas

Achieving this level of agility in the service design roadmap requires (i) leveraging a flexible service development & deployment platform and (ii) promoting the importance to the DevOps role within the business.

The agility that this lends to the service development and operations teams is extraordinary. Development teams can build new services and new features in far shorter iterations, Operations teams can roll out and upgrade new service features as quickly as they are developed.

Figure 7: The DevOps difference
Figure 7: The DevOps difference

Both in DNS Europe and in our ISV customer’s businesses, AppLogic has helped nurture and enable the emergence of individuals who share a willingness and ability to cross the development and operations divide – the so called “DevOps” role. With Continuous Delivery demanding

a rethink of the traditional linear development-to- deployment process, developers are required to be far more infrastructure-savvy and infrastructure and operations teams are having a far greater input at the beginning of the service design process. Without this shared-ownership of the whole service development lifecycle process, adopting a successful Service-Oriented-System-Engineering model would be beyond reach and instead lead to an inefficiently designed system with little, if any, benefits over a traditional architected system.

By architecting applications correctly with a Service- oriented approach, the choices for future development and integration directions are maximised. By designing-in integrability from the start, a system is better able to take advantage of dynamic ‘loose-coupling’ of API-connected service relationships. And that, more than anything, is what is going to allow businesses to evolve rapidly based on evolving customer demand.


Fundamentally the issues surrounding security with private cloud platforms are extremely well understood, after all, they are exactly the same issues that have been around for a decade or more. Any business that has offered externally- accessible services themselves or in combination with 3rd party service providers know that to be confident about security, they need to have policies and technology in place that secures physical infrastructure, network, application, data (at-rest and in-motion), identity and access control.

When mapping such policies to the SOSE-CLOUD model, the question of Access Control emerges as one of the forerunners in terms of up-front system architecture planning. Access control impacts on so many different levels of the distributed service-oriented architecture model including development, maintenance, operations (lets call that DevOps), end-user privileges, service consumer and publisher components, legacy/cloud hybrid integration, in-house/out-sourced providers, right down to the interactions between the code, hypervisor and underlying OS.

We believe that the most prudent course of action during the service design phase is to assume, just as you know that one day your physical infrastructure will break, that one day your security measures will be compromised. In order to accommodate this reality without destroying value, agility and innovation, it is necessary to consider carefully the concept of ‘Trust Tiers’ within service architecture.

One way of looking at this is to think about the “crumple- zone” engineering principle in the automotive industry where sections of the system are designed to fail in predictable ways to protect core assets.

Figure 8: The SOA lifecycle with Security
Figure 8: The SOA lifecycle with Security

The key message here about security in the cloud (in general) is really that it is not a bolt-on afterthought. To achieve efficiency and scalability, security planning must begin at the outset of system architecture planning.

This is particularly relevant when designing a system to span multiple service providers. An ISV must take ownership of their data security ‘at rest’ and ‘in motion’ not just on their own systems but also on those hosted by third parties. The Cloud-savvy ISV understands that a service provider cannot sign up to any wider security obligation (beyond the default physical security protocols) without an adequately tiered security model designed into the service (software & infrastructure) from the ground up.

Keeping pace with IT Consumerisation

Any discussion around agile and continuous delivery requires consideration of emerging consumer trends, of which BYOD and the Consumerisation of IT are prime examples.

“The Consumerization of IT” basically means that IT has become a consumer product. Previously the main consumer of IT was an employee or department but today, access to business services has extended beyond the desktop to mobile consumer devices. And thus the development roadmap is now being driven more directly by the consumer.

Consumer-driven demand and new consumption models are changing the way that software is architected for the Cloud and a number of key technology developments are enabling this:

Mobile Computing, the ability to extend services out to any device, any OS, anywhere, any time. HTML5 for example, enables rich-clients on the user device with API calls to the application, replacing the traditional server-based code rendering client information. This degree of agility in the end-user-device domain is creating unprecedented demand for functionality and information but also introduces business risk around data and identity security. To meet this challenge, ISVs require a cloud platform that provides capabilities for rapid prototyping & evolution of user-facing apps, seamless delivery & distribution plus the capability to accommodate a comprehensive multi-tiered security model.

Federated services directories and the ability to discover and compose services depending on the required workflow is perhaps one step beyond the current “App-Store” business model. Rather this is more like a “Services-Store” that one day may facilitate easier on-demand expansion of system’s capabilities, reach and additional revenue- generating potential. Highly-dependent on standardised interfaces, this model of re-usable modular service components may not have matured yet, but its worth considering while designing your service architecture.

We’ve also noticed a move towards hardware agnosticism and not just with consumer devices. ISVs today care far less about the brand of the underlying hardware and more about the cost line item on the balance sheet. Low cost commodity hardware seems to be the order of the day.

The challenges facing ISVs in keeping pace with IT consumerization include Agility, Security & Cost. However the benefits to the consumer are significant in terms of anytime, anywhere accessibility to data and functionality at the point and time of need.

According to Gartner, the “Consumerization of IT” will be the most significant trend affecting IT for the next ten years. This applies not only to the BYOD domain but also, and perhaps more importantly, to the evolution of cloud management platforms, such as AppLogic, that are providing the cornerstone infrastructure management features that are enabling the explosive growth of IT Consumerization including:

  • Accelerated service provisioning – automating the service delivery process based on end-user demand

  • Customer service management – providing controllable access to various customer types to manage their own resources & services.

  • Hybrid service visibility – allowing user to interact with multiple systems/service components

  • Configure & reconfigure the end-user experience – retain fine grained control over customer capabilities as the service evolves.

  • Manage the networking – taking the man out of the networking management loop
  • Resource sharing for multiple services – using the same physical infrastructure for any service type or variation
  • Simplified support & maintenance operations – automate, delegate and empower, reduce admin workload and lag.

A well-executed AppLogic-based SOSE approach to system design provides, in our view, an extremely accessible solution for ISVs of all sizes to deliver their software as a cloud services with confidence that they have invested in a platform and methodology that will be flexible enough to accommodate the ever-changing nature of their customer’s demands. As discussed, AppLogic fulfils the requirements for low cost of entry, SOSE design methodologies, agility, scalability, resource efficiency, rapid prototyping and deployment, distributed architectures and hybrid cloud integration.

Closing thoughts

The key take-away message from this paper should be one of methodology rather than technology. For us, success in the Cloud starts and ends with Mindset. Tools and platforms should therefore be judged not simply by their technical feature set, but instead by their ability to support this Mindset.

At the core of the Mindset is business agility. This is not merely the adoption of a particular software development methodology, but rather the harnessing of the best business practice innovations and then co-opting technology platforms to support them.

Cloud is about processes and services. When you couple an ISV mindset with a service engineering framework and a complimentary cloud platform, you have the substrate for success.

The ISV mindset requires a deep understanding of the business service fundamentals. It requires a Lean focus on adding value for customers, that includes taking a pragmatic approach to providing service levels that are sufficient, but not excessive. By embracing the unknown and accepting the unknowable, time and effort is not wasted on plans that serve only to reassure the planners. The emphasis is on using reliable feedback, combined with operation excellence and speed of execution, to rapidly adapt to emergent realities.

It is only once the Mindset is firmly embraced that the full potential of any Cloud platform can be unlocked by driving true value through innovative thinking rather than simply through use of the tool.

Further Reading

Some interesting background reading on the subjects covered in this series of articles:

The views outlined in this series of articles are, in part, achieved by standing on the shoulders of giants. Thanks and credit to the authors of the above linked material.


    0 of 8192 characters used
    Post Comment

    No comments yet.