Part 2: Designing for the Cloud with an ISV Mindset
AppLogic’s Fabric-based Private Cloud model helps ISVs move towards true Agility
For ISVs, Agility is not simply the ability to move quickly but it is also the ability to react and change directions quickly. Many ISVs are operating to a 3-month development planning horizon, without knowing what direction their service will take in the future, or which 3rd party cloud services they’ll eventually want to integrate with. They need a platform that is going to give them the ability to react to market evolution, customer demands and they 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 infrastructure design if required. Large upfront investments in high-end dedicated hardware platforms simply doesn’t make sense for them.
Agility requires adoption of an iterative, incremental Continuous Delivery approach to service design that is informed by KPI-driven feedback. This approach, in the long run, improves ROI for our customers by adding flexibility to the development roadmap. It also opens the doors for future integration with an ever-expanding marketplace of 3rd party services allowing them to model, launch, expand on their own private cloud platform and then spin off appropriate services to ‘the Public Cloud’.
These 3rd party services and systems are also a vital component of enabling SOA on cloud. To achieve true agility on any cloud platform, you still need a way to manage the service components (e.g code & configurations) that have been decoupled from the underlying delivery mechanism (e.g. infrastructure). In practice this means being able to manage code and stateful configuration changes with automation systems (e.g Bonita or CA’s Cloud Automation Suite). One of AppLogic’s key strengths is that if you need a coupled approach, then it allows you (out-of-the-box) to manage your entire service as a single entity (workloads, content, configurations and connections). If, however, your service demands full decoupling , then AppLogic can and does work with most 3rd party automation systems to help complete your SOA enabled set-up.
At DNS Europe we believe that this is a key development area that AppLogic should be focusing on going forward. ISVs would be better able to improve Agility throughout their service development process if such decoupling capabilities were a native feature of the platform.
Intelligent use of Tiered Storage
One of the real value propositions of the fabric-based private cloud platform is direct attached storage (DAS). It provides a low-cost entry point, incremental scaling plus the benefits of enhanced performance due to locating both applications and data on the same physical machine.
AppLogic’s default storage system utilises the platform’s built-in mirrored DAS. With this model, the Compute and Storage layers have been “collapsed”, that is they both exist on the same low-cost commodity x86 hardware. This model allows an AppLogic grid to automatically recover application & data availability in the case of a physical node failure.
DAS is not however a viable solution for all storage requirements due primarily to volume size limitations, lack of thin provisioning and issues with volume sharing across multiple private clouds. And so, in addition to DAS, AppLogic also allows for connections to external SANs using the IP-based Network File System (NFS) protocol.
With both DAS and SAN storage tier options available to system designers, intelligent use of multi-tiered storage means that both each can be utilised where and when it makes sense to do so, either from a big-data performance or infrastructure economics perspective.
At DNS Europe we believe the platform lends itself naturally to multi-instance, multi-component, service-oriented architectures where the service design plays to the core strengths of the platform. Additionally, when you consider developments in solid state drives, 10G networking and distributed database architectures (such as database ‘sharding’, or ‘horizontal partitioning’), it can be argued that the number of use cases where central storage is a fixed requirement is decreasing while the number of use cases where DAS is appropriate is trending upwards.
At this point its worth reiterating the core message of the ISV Mindset, that effective use of the Cloud begins with software architecture planning. Only with such a ground- up approach can a system achieve lowest-possible-costs and still deliver the Agility, scalability and performance required from all tiers of the service including application, storage, database and infrastructure.
Cloud HA means designing smartly for failure
In addition to the ability to deploy a smart mix of DAS and SAN storage, AppLogic’s use of simplified x86 grid- connected infrastructure makes it possible for ISVs to deploy a starter-system that is both failure-tolerant and cleverly robust. Building on the concept of ‘availability tiers’ introduced earlier in this article, achieving high- availability in the Cloud is less about expensive duplication on the heavy-lifting infrastructure layer and more about converting ‘service outages’ into ‘reduced capability periods’. With a Service-Oriented-System-Engineering approach, combined with AppLogic’s Cloud Fabric features, ISVs are able to leverage a platform that will keep their service ‘alive’ even during catastrophic physical infrastructure failures.
Decisions need to be taken at the design stage about which services should be failure-tolerant and to what degree, and which should not due to excessive cost. What user capabilities, that if they remain available during an outage incident, will sufficiently negate the impact of the outage for the user or the majority of users? Which core system components should be extremely robust in terms of availability and how should that be achieved – in the cloud? using a hybrid model? or back to old-school technology?
These are the types of thought and decision processes that typify the SOSE-CLOUD design approach.
AppLogic delivers a degree of high availability natively out-of-the-box with its 1-to-1 volume mirroring of data volumes across 2 (or more) physical nodes. In the case of a node failure, applications can then be re-instantiated automatically on the mirrored node in as much time as it takes to spin up the app.
All well and (very) good, but what about catastrophic failures of physical infrastructure or loss of connectivity to the grid(s)? Smarter Disaster Recovery & Business Continuity Planning takes on board the principle that ‘everything fails sooner or later’ and the Cloud is not a silver bullet that solves this fact of IT life. Where Cloud differs from the traditional IT infrastructure model is that, together with automation, it becomes more practical and cost effective to blend DR capabilities into the service design from the get-go.
Designing service redundancy with AppLogic requires moving away from the expectations (and limitations) of a purely infrastructure-focused replication solution. Instead, it requires embracing an application architecture approach to designing for your expected failure scenarios and service availability tiers.
AppLogic’s speed, ease and low-cost of deployment means that there are a number of physical infrastructure models that can be adopted including centralised, clustered and distributed, or more likely, dynamic combinations thereof. This allows for geographically dispersed physical infrastructure solutions that can form the basis of a smarter HA design.
However, for a complete solution, when architecting with a SOSE-CLOUD approach, traditional replication strategies are not necessarily appropriate (or cost-effective) since dispersed service components may also be grouped together to provide additional redundancy. For example, one might architect multiple service components, some of which are designed to provide for low-cost redundancy by offering a reduced service feature set in the case their ‘primary counterparts’ become unavailable.
Combined with AppLogic’s upcoming (and eagerly awaited!) ability to span application architectures across geographically dispersed grids, service vendors now have a powerful and low-cost platform on which to architect and deploy their Service-Oriented architectures to the Cloud. Furthermore, with smarter redundancy planning they can significantly reduce costs for physical infrastructure outlay and on-going maintenance operations.
Also worthy of note related to cloud uptime availability is that, In our experience, the majority of time (we’re talking 80% and upwards!) that a cloud service is ‘down’ has little to do with infrastructure recovery and much to do with poor communication and lack of defined processes between the infrastructure and application teams. Putting in place shared TechOps procedures is therefore critical to minimizing interruptions as well as enhancing the business’ overall agility.
- Read previous Part 1
The term ISV is in the process of evolving from "Independent Software Vendor" to "Independent Services Vendor", reflecting a new approach that developers are taking towards cloud-based architectures.
- Read next Part 3
Working with the unknown (or unknowable), means that strategy is in a constant state of adaptation in reaction to market evolution, so design for uncertainty & focus on service-oriented architecture.
Download full free PDF
© 2013 Stephen Hurford