Designing For The Cloud With An ISV Mindset

The emergence of the Independent Services Vendor: For DNS Europe, the term ISV is in the process of evolving from "Independent Software Vendor" to "Independent Services Vendor". This reflects, in our experience, the changing approach that software developers are taking to software and infrastructure architecture to capitalise on the benefits of both the Service Oriented Architecture (SOA) and Cloud Computing paradigms. That is, the development of "loosely coupled" distributed services within a cloud framework which augments the benefits of SOA with cloud features such as rapid virtual infrastructure deployment, virtualisation and dynamic resource allocation, utility pricing models and hybrid platform integration.

What we are seeing is a true distinction emerging between Cloud Services and the precursor SaaS Hosting model. With the former, particularly where Private Cloud Platforms are concerned, customers are now benefiting from more than simply an outsourced application hosting arrangement. What they now have access to is a full range of tools which allow them to design and deploy the precise virtualised infrastructure they require to support their applications, within an environment which is entirely under their own control.

This exploitation of both the SOA and Cloud paradigms, sometimes referred to as Services Oriented System Engineering (SOSE) serves well as an example of how distributed software (or Service) architecture lies at the heart of being able to truly maximise the long-term success and eventual payback from investments in cloud initiatives.

Four key principles and advantages of the SOSE approach are:

• Service components are architected as independent entities with a "modular" approach to service composition.

• Standardised protocols & interfaces lend a high degree of inherent agility to the development roadmap by maximising integrability capabilities with 3rd party services.

• Use of virtualised application components, web, app, db, storage servers (as well as network devices such as load-balancers, switches, firewalls etc) with dynamic resource allocation helps deliver a predictable end-user experience at a minimum price point.

• By segregating 'core' and 'peripheral' services, the evolution of hybrid systems, utilising the best of both public cloud services and private cloud platforms can facilitate both improved security and leveraging of scaling cost benefits, provided they are correctly implemented with an holistic plan.

Realising the full benefits of the SOSE approach however requires the adoption of what we call the "Cloud ISV Mindset" and in our experience, the extent to which a customer is able to adopt this approach, is the exten to which they are able to benefit from the use of cloud technology in general.

Characteristics of the "Cloud ISV Mindset"

First and foremost is the understanding that cloud planning begins with software architecture planning. All too often we are seeing the "square peg into a round hole" phenomenon where, due to the constraints of an existing software architecture, a cloud platform is being utilised in a sub- optimal way that ultimately is never going to deliver on the full value and efficiencies the cloud platform is capable of delivering. Planning for the cloud requires a new approach to software architecture and ergo successful cloud deployments require appropriately architected software.

Architecting for the Cloud doesn't necessarily imply a too-radically different approach than more traditional design methodologies, however it does impose a greater focus on identifying each function that constitutes the business goals of the application which are then mapped into discrete services. While defining these services within a distributed system, the following aspects (amongst others) become more critical to fully consider at the early design stage:

• Geographies. Will this system be global, or regional?

• Data segregation. Multi-instance or Multi-tenant?

• SLAs. Availability, latency, throughput, consistency, and durability.

• Security. IAAA (identity, authentication, authorization, and audit), data confidentiality, and privacy.

• Usage tracking. Necessary for at minimum day-to-day operations, capacity planning, billing and governance.

• Deployment and configuration management. How will updates be deployed with minimum/zero downtime?

• Cloud infrastructure platform. What are the necessary (or available) capabilities of the IaaS/PaaS layer?

This holistic approach to cloud infrastructure and service design will allow the system as a whole to fully leverage the cloud's core advantages such as rapid deployment, resource efficiency, modular expansion, elasticity and, perhaps most importantly, roadmap agility.
Perhaps one of the characteristics of the current phase of IT evolution which has moved rapidly from traditional hosting, through virtualised, to cloud-based systems is that of uncertainty. Any business that needs to act now, rather than wait, is by necessity going to have to learn how to work with the unknown (or unknowable) either because their strategy is constantly developing in reaction to market demand, or because their ideal technology platform is not yet available.

The ISV approach to this is to design uncertainty into the roadmap strategy, avoiding developmental dead-ends and building systems that can more easily adapt to new techno-logical advances. In most cases our ISV customers don't know what their service, market or customer profile will look like in 6 months let alone 5 years so they need a flexible platform that allows them to kick-off within extremely tight budgets and expand on demand with incremental and predictable costs.

Our customers share a common requirement for their cloud platform: Control. It's more than a 'nice to have', it's a business critical requirement. While all of our customers could have deployed their service on Amazon, for example, the structure imposed by Amazon on the platform architecture would inevitably lead to compromise and inefficiencies. These Public Cloud restrictions, as well as concerns over privacy and security, are leading many ISVs to go down the Private Cloud path, at least during early service evolution phases.

Amongst ISVs you will also see pragmatism around the issue of Cloud SLAs with realistic expectations and acceptance of responsibilities. Effective cloud users understand that it is not, by default a 5x9s proposition, whether you're talking about Public or Private. 5x9s can be engineered (in theory), in much the same was as redundancy and fail-over is used to achieve (in theory) 5x9s in the traditional infrastructure world. However, to achieve the cost-benefits of using cloud in the first place, the smart solution is to design availability tiers into the system design so that outages are avoided in favour of periods of 'reduced service' - in other words the system breaks gracefully when an infrastructure component is lost.

Wrapping up the typical characteristics of the cloud ISV Mindset is something that ISVs live or die by, the principles of Continuous Delivery. Where market competition is strong, staying ahead and responding quickly to market opportunities and customer requirements dictates that flexibility must be embedded in the entire service lifecycle. Typically an agile cloud service ISV will look at rolling out updates and improvements on a monthly basis so they need a platform that is going to give them that kind of Agility. They also need to know that any investments they make in hardware and cloud platform is going to be flexible enough to be repurposed to a new service design if required. Large upfront investments in high-end hardware-based platforms doesn't make sense to them from a cost and infrastructure lock-in perspective.

Download the full free PDF document here:

http://www.dnseurope.net/designing-for-cloud