ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Part 2: Designing for the Cloud with an ISV Mindset

Updated on November 14, 2013

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.

Figure 3: AppLogic virtual storage appliance mirroring
Figure 3: AppLogic virtual storage appliance mirroring

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.

Figure 4: Database Sharding, Scale Out, Horizontal Partitioning
Figure 4: Database Sharding, Scale Out, Horizontal Partitioning

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.

Figure 5: Versatile AppLogic Micro Unit (AMU) deployment scenarios
Figure 5: Versatile AppLogic Micro Unit (AMU) deployment scenarios

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.

© 2013 Stephen Hurford


    0 of 8192 characters used
    Post Comment

    No comments yet.


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)