SlipStream Use Cases

Case studies and use cases of real applications of SlipStream.

Enterprise App Store / Self-Service IT

Provisioning applications inside an organisation should be as simple as installing an app on a mobile device. Too often, the enterprise process for deploying an application triggers a chain reaction of hardware and software procurement processes that can take weeks, if not months. This drastically affects the ability of any organisation to be reactive and agile. And puts the organisation at risk of failing to meet Service Level Agreements, missing financial targets and exposing the system to security breaches.

What if we could deploy applications via an enterprise app store? These applications would have been vetted by the right department to ensure that once deployed they are configured in a secure manner and deliver the right level of service. Teams could contribute and publicise their work to the rest of the organisation via this app store, reducing duplication and costs, while increasing cohesion and awareness.

This is why we created SlipStream and included at it’s core an Enterprise Open App Store, so that provisioning applications is simple and safe. The ability to deploy with 1-click ensures that the application is provisioned automatically, minimising human intervention, risks and delays. The SlipStream multi-tenant capability means that different users can access different apps, with different privileges. The open part of the Enterprise Open App Store stresses the fact that SlipStream is an open system, where users can augment it themselves, within set parameters,sharing what they want to share, and keeping private what should be kept aside.

As a result, CIOs can avoid the shadow IT phenomenon, where teams prefer to circumvent the organisation’s infrastructure, often out of frustration, and use their own credit card to purchase VMs in public clouds. Thus SlipStream ensures a higher level of governance, policy and security. Meanwhile, CFOs can better control costs since provisioning is performed via a controlled process. But using the SlipStream app store feature doesn’t prevent organisations from taking advantage of public clouds. On the contrary. Look at the Hybrid Cloud Provisioning use case for details on how the app store works perfectly in a multi-cloud and hybrid mode.

Hybrid cloud is an integrated cloud service which uses both public and private cloud infrastructures to perform different jobs within an organisation. In other words, choose the best cloud for the job. In a hybrid environment, when the same PaaS can support both public and private services, organisations greatly benefit from this level of flexibility and agility. By providing a homogenous platform, workloads can easily be moved from a private cloud to a public cloud for deployment and efficient scaling. This allows users to have a high degree of control over where a particular application is running.

However, many organisations already struggle with the complexity of managing their own cloud infrastructure, and can’t contemplate taking on board a hybrid cloud model.

SlipStream makes this step easier, by providing a simple tool able to abstract the difference between private and public clouds, allowing users to provision on either or both without being exposed to the complexity and differences of each. Users can choose which cloud to target and SlipStream ensures that each application is deployed in the same way on each cloud, delivering the same result to end-users.

With the ability to deploy applications across several clouds in 1-click, hybrid deployment is now within reach of all cloud-user organisations, allowing them to significantly increase robustness and availability of applications, without compromising on security.

Mangers can ensure the right infrastructure is used to host the right applications, providing an agile infrastructure for their organisation, whilst maintaining control and governance.

If you want to see how this works, ask for a demo. It takes just 30 minutes and will save you hours.

The current cloud landscape is busy with solutions that allow users to manage virtual machine life cycles. While this is an important building block, it falls short in terms of delivering on the full cloud potential. What most organisations want is the ability to reason in terms of application or even sets of interrelated applications working together to deliver certain functionality, or value. For example, a stateful web application, CRM system, WordPress or management application. Several of these applications are built on a n-tier architecture, such as a LAMP stack.

In most cases, such deployment will require the involvement of several hosts, which in cloud terms translates to different virtual machines. Deploying such an application is complex and error prone, calling for an automated solution. Indeed, being able to automate the installation, configuration and start of the different components, clients and services would deliver significant value in the software development and operations pipeline. Furthermore, such deployment should be as representative as possible of (pre-)production conditions, to avoid rollout issues. This automation capability is key and enables several higher level use cases, such as the ability for:

  1. End-users to provision applications in 1-click from the Enterprise App Store / Self-Service IT capabilities of SlipStream.
  2. IT experts to deploy applications on several clouds at once, taking advantage of Hybrid Cloud Provisioning SlipStream feature.
  3. DevOps engineers to deploy more often to more easily test, break and stress their applications, knowing that they can easily reset the application if broken by a set of tests. This feature is detailed in the DevOps use case.

To illustrate the ability of SlipStream to manage complex deployments, we have created a demo LAMP model. This model includes the following layers:

  • Load balancer: configured for round robin between the Apache2/PHP nodes. We use the open source HAProxy solution for this layer.
  • Apache2/PHP: cluster of state-less Apache2/PHP applications. For demonstration purposes, we have included in the PHP layer a simple application running on the default port 80. The PHP scripts running behind the scene are configured to connect to the MongoDB layer. The configuration also includes failover logic in case of database node failure, including switch over to the next healthy node.
  • MongoDB: the database cluster configured by default with a majority replication scheme.

By default these layers run in the same cloud, but users can assign each layer to a different cloud. Further, the number of VMs assigned to each layer is parameterised, such that users can define the number of VMs forming, for example, the MongoDB database cluster or the Apache/PHP servers. Best of all, this is only an example. Any user can create its his/her own configuration, using the LAMP example as a starting point.

Another interesting feature included in this example is SlipStream’s ability to provision extra disks. In the case of the database layer, this means that users can define at provisioning time the size of data assigned to each cluster node. The MongoDB cluster in the LAMP example can also be used in a stand-alone mode or used in other deployments, encouraging sharing and re-use.

DevOps platform

The realisation that the agile practices traditionally focusing on software development activities could also apply to operations gave birth to the DevOps movement. Or, as we like to call it, common sense. DevOps is a way of combining software engineering, technology operations and quality assurance. In order to deliver a DevOps environment, teams need to be able to fluidify their development and deployment process, allowing software and configuration changes to be deployed in the (pre-)production stage in the most efficient way. It is of fundamental importance to capture operational issues early and integrate them as first class citizens when considering architecture and design. The best way to do this, is to deploy and operate as early and as often as possible. This generates a natural feedback flow, ensuring that operational issues (e.g. monitoring, troubleshooting, configuration, performance) are addressed early and effectively.

What if we had an environment where different teams and/or team members could deploy each others components, clients and services? What if this deployment process was as convenient as clicking a button (or executing a single command at the prompt)? What if the resulting deployment was as representative as a (pre-)production environment and as complete as the final system? What if a team member could capture an automated procedure in a tool for deploying his/her software (including all its dependencies) so that others could reuse them? Oh and what if this process was version controlled, multi-tenant and cloud agnostic? These things are no longer out of reach, due to SlipStream.

SlipStream provides a simple and powerful automation engine in which simple and complex deployments can be captured. SlipStream targets Infrastructure as a Service (IaaS) endpoints, but in a cloud agnostic manner. This means once captured in SlipStream, the same deployments can be applied to any configured cloud endpoint. Even better, deployments are built out of parts, which means they can be re-used and modified in modular ways, to maximise re-use.

Used via its simple API, the provisioning process can be integrated into a complete build/test/deploy/feedback process, so that, for example, code commits into a version control system can trigger a complete software deployment procedure, including end-to-end test execution. The same can apply to production deployment, once a given release has been stamped for production.

As a result, fewer manual, boring and error prone tasks are required, freeing expensive engineers to focus on more creative work. Time to market is significantly reduced with the ability to push to production more often with fewer defects, thanks to more rigorous and regular testing.

Cloud offers are continually growing, providing an increasing level of choice and hopefully creating a healthy marketplace which will keep prices low and quality high. However, CIOs are rightly under pressure to make the correct choice, since changing cloud provider is an expensive business. Each cloud has its own API and value proposition and it isn’t easy to switch. So how can you take advantage of this world of choice without risking important changeover costs? And how can you take the time to reach such a difficult decision without causing a delay in implementation? Having the possibility to federate several clouds under the same broker or facade would alleviate the risk of choosing the wrong cloud.

Furthermore, being able to use a wider range of cloud providers can be a smart strategic choice to ensure optimum up time. Indeed cloud services are not infallible, therefore using more than one basket is a sensible solution to alleviate the risk of breaking all your precious eggs. Being able to use different cloud providers can also mean having better geographical coverage in terms of application placement. For example, being able to deploy applications in specific countries or regions can be important.

Another important benefit is scale. A federated cloud resource is much more likely to scale better than a single provider, allowing peaks of demand to be more easily be absorbed, even with a very short-notice request.

What if you could provision to many different clouds, using the same interface? What if you could describe application deployment logic in a cloud-neutral way, allowing applications to be deployed on any or many clouds in exactly the same way? What if selecting a cloud provider was as simple as selecting a roaming mobile operator?

This is exactly why the Helix Nebula public/ private partnership chose SlipStream to implement its federated provisioning engine for its Helix Nebula Marketplace (HNX). Users, such as CERN, ESA and EMBL, now describe their application deployments in SlipStream, using simple scripting, and simply choose the cloud to which they want to deploy . HNX currently includes cloud offers from Atos, Interoute, Ultimum, Exoscale, DEAC and T-Systems, with several cloud providers expected to join the service.

With a simple, yet effective, service catalogue feature, SlipStream users can easily compare cloud capabilities, capacity and pricing, and then select the cloud service they want to use. On their side, cloud providers can regularly update their service catalogue, to ensure their service remains competitive.

Finally, the Helix Nebula collaboration re-skinned SlipStream, providing an integrated user experience, including colour, logos and documentation.

Get in touch with the SixSq team if you want to know more about the cloud connector licensing scheme and how web UI re-skinning can be done to suit your organisation’s branding.

Being able to automate complex deployments is important in order to reduce time to market, improve quality and security, and of course reduce costs. However, even simpler applications would benefit from being able to use a variable amount of resources. For example, based on user activity, web applications can have a surprising variations in the level of load. Database applications can be stressed when important consolidation activity takes place or when rebalancing actions are required. Further, applications could also take advantage of moving with their users such that they can redeploy themselves to be closer to the users, as the Earth rotates, for example.

SlipStream has already the ability to automate parameterised deployments. For example, users can deploy a WordPress template including user parameters such as the WordPress name, the password of the administrator and which cloud to target. But these deployments are static once provisioned - i.e. once the user has clicked the run button.

The SixSq team is currently working on the ability to support mutable deployments, a key feature that will open the door to full auto-scale capability. This first step allows users to change the number of virtual machines used for a given layer (see LAMP and complex application provisioning for details) after the initial deployment. For example, the number of web nodes in a n-tier application can be increased or removed, at the click or a button, a CLI call or a API call. In turn, SlipStream’s automation logic will kick-in to ensure that each layer is being notified, so that, for example, the load balancer layer updates its list of web nodes to forward work to, or that the database cluster rebalances itself taking into account new or old nodes.

Following from this mutable feature, monitoring and custom KPI definitions will complete the full auto-scale feature.

What's next?

Interested and want to know more? We'd be pleased to provide you with further information. Get in touch.

Contact us »