Self service IT Requirements: service orientation

Self Service Platforms often provide a lot of possibilities and features, but not all of them are necessary to end users in all situations. Therefore, it should be possible to disable features if they are not required. Disabling features should not affect the platform itself. This approach is also described as Service Oriented Architecture (SOA). (Jossutis, 2007) defines SOA as the following:
 

“Service-oriented architecture (SOA) is a paradigm for the realization and maintenance of business processes that span large distributed systems. It is based on three major technical concepts: services, interoperability through an enterprise service bus, and loose coupling.” –  (Jossutis, 2007)

 (Jossutis, 2007) describes 3 main aspects of SOA: services, interoperability and loose coupling. A service can handle different things such as providing simple read or write operations or more complex functionality that might be used in workflows. Services are normally described in an abstract way, which should help bridging the gap between IT and Business. In a self Service Platform, different services enables us to simply disable services that are not necessary, add new services to the platform or enable existing services. As stated earlier in this section, adding or removing services should not affect the platform in any kind. To achieve this, it is necessary to decouple the services.
Another key concept of SOA is loose coupling, which basically states that services should continue to work even if other services are missing and that services might not know about other services. Loose coupling also means that dependencies should be removed. If one service is updated to a new version, all other services that might interact with the now updated service should still be able to work without any modifications. This requires a very abstract way of communication: messaging. Messaging via an Enterprise Service Bus improves interoperability for system integration. Services now simply don’t communicate with each other directly but they rather post messages to an Enterprise Service Bus. The Enterprise Service Bus keeps the message alive until someone (typically a service) processes the message. Services usually don’t know about the service they are interacting with since it is like in a fabric: Person A leaves a message that the new tools are ready for pick-up. Person B that is in charge for picking up tools sees the message and brings the Tools to another department. The communication is much more asynchronous now, since the service simply doesn’t know when the task will be processed. This type of communication is very similar to the communication used by people on smartphones/mobile phones. Person A sends a text message to Person B and Person B will eventually reply (or maybe not) to Person A. Synchronous communication would now be if Person A simply phones Person B.  (Miller & Cardoso , 2012) also describes SOA as a key driver for Internet-based self Services in their work on SEASIDE.
Image Copyright: Intel Free Press

CloudStack: Networking and Multi-Tenancy

This post is part of the Open Source Cloud Computing series. For an Overview, please click on the Tag.

Networking with CloudStack

Networking with CloudStack can be achieved with two topologies: the first topology is handled like with Amazon Web Services (AWS). This enables guest isolation via IP-Filtering. More networking possibilities are delivered with the “advanced” networking options. The advanced option allows multiple networks in a zone. Each individual network in an advanced setup needs to have a specific network type. They can be guest mode, management mode, public mode and storage mode.

Multi-tenancy

CloudStack provides multi-tenancy with the concept of Accounts, Domains and Users. An account is typically a tenant. Each Account may contain more users. A Domain allows the datacenter provider to group similar account types and to ease management of them. CloudStack may be extended by LDAP services such as Active Directory. Another concept is the “Project”. A project is a group of users working on similar tasks. Within a marketing department might be different project such as “product launch web site”. Several users might need to work on this project. Billing can be based either on the user’s consumption or on the project consumption, which allows even more detailed billing on a project basis. Project can also be limited in resource usage.
Header Image Copyright by Horia Varlan

Self service IT Requirements: simple API

In the last chapters, it was often mentioned that especially one thing is important: a simple UI and administration. Since this should be integrated in existing platforms, the platform should offer an API that allows handling these steps. API stands for “Application Programing Interface” and allows system integrators to access the platform via API Calls. The API should basically be independent from the implementing language (e.g. Java, PHP or .NET), what suggests the use of web standards such as ReST or SOAP (Gudgin, et al., 2007), (Fielding, 2000).
Each platform and level (such as SaaS, PaaS and IaaS) might need different API Calls. For Infrastructure as a Service self Service Platforms, the following possibilities should be included:

  • Possibility to start/stop Applications. This is abstracted from starting instances as this rather deals with starting/stopping templates. Platforms usually allow to start/stop different instances. Most of the time, we want to start or stop a set of instances. When we focus back at the WordPress example listed above, we have to start a frontend Server, a Database Server and adjust a load balancer. The platform should support to launch templates instead of single instances.
  • Possibility to control Applications. The Platform should support a way to control instances in their behavior. This basically means that triggers for elasticity can be set on different parameters such as average CPU Load. The platform may even decide on it’s own how it scales their applications. If this is the case, it is only necessary to set a minimum and maximum instance count.
  • Get System Performance Data. Application Administrators usually want to know how their application performs. This Data should also be integrated in existing platforms or even e-mailed to the person that launched a specific application.
  • Set Alerts. If the application performs bad, application owners should be informed about this. The platform should allow users to set the way they want to be informed (e.g. by e-mail or by short messages). This should reduce the time to react to an outage or bad performance of the platform.

 
A major challenge for self Service Platforms is to provide the possibility to ease the way on how applications are delivered to end-users. The IT department should work on providing templates that users can launch. Departments such as the marketing department should not work on launching instances with a specific application on it (such as WordPress or SharePoint) but they should rather launch the application itself without knowing what type of resources are used under the hood. Therefore, it is very important for the IT department to provide easy tools that integrate in existing platforms. If a simple API is provided the platform, this API can either be reused or extended by the IT department.
Header Image Copyright by: Alquiler de Coches

CloudStack: Components

This post is part of the Open Source Cloud Computing series. For an Overview, please click on the Tag.

The Management Server

The Management Server is the entry point to the CloudStack Cloud. It manages all nodes and it exposes the API as well as the graphical user interface (GUI). Typically, the Management Server runs on a dedicated machine or virtual machine. The Management Server uses Tomcat and a MySQL Database for persistence. The Management Server also assigns public and private IP addresses and it also deals with the allocation of storage to the guests as virtual disks. CloudStack allows the management of snapshots, templates and ISO images, which is also provided by the Management Server.

Cloud Infrastructure

The Cloud Infrastructure consists of several layers. The lowest level is the host itself, which is a node where virtual instances run on. Nodes usually get added to a cluster. A cluster contains several nodes and has a primary storage attached. Clusters are part of a Pod, which is typically a hardware rack including a layer-2 switch and a secondary storage. Pods are now part of a “Zone”, which represents a datacenter.

CloudStack Organisation

CloudStack Organisation


Zones are the largest entity in a CloudStack deployment. A zone normally represents a datacenter. Building various zones has the same benefits as building more datacenters: it enables replication and redundancy. CloudStack distinguishes between public and private zones. With this concept, it is possible to provide a public zone to all users and several private zones to specific users like the marketing or accounting department. When a new instance gets started, the user must select in which zone it should be launched. Clusters provide the ability to group similar nodes. They normally share the same or a very similar hardware, the same hypervisors, are in the same subnet and they share a primary storage. In large datacenters, clusters can be built for different hardware groups such as nodes with high memory, others with high CPU and or GPU-based Nodes. There are plenty of possibilities to distinguish between different hardware with the concept of clusters. ISCSI or NFS servers provide primary Storage and it is shared within a cluster. The primary storage stores all disk images of running virtual machines within the cluster. Secondary storage is associated with the zone and it’s purpose is to store templates, snapshots and ISO images.
Header Image Copyright by marya

CloudStack: Overview

CloudStack is currently available in the Version 4.0 and was usually initiated by Cloud.com, which was later acquired by Citrix. The source code for CloudStack is available open source and it is maintained as an Apache Project. The target of CloudStack is similar to the other 3 described projects: provide an Infrastructure as a Service Software. CloudStack supports both commercial hypervisors as well as open source hypervisors. From the commercial side, CloudStack currently implements Citrix XenServer and VMware vSphere and as for open source hypervisors there is support for XEN and KVM running on Ubuntu or CentOS. CloudStack is built to run tens of thousands of virtual Servers in geographically distributed regions. There is one managing server for all clusters, which makes cluster-wide management servers unnecessary. CloudStack configures each node automatically regarding storage and networking. Internally managed virtual appliances take care of firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. CloudStack also offers a graphical user interface (GUI) to ease configuration. The CloudStack API also supports Amazon Web Services (AWS) EC2 and S3. CloudStack provides an extensibility API, allowing solution providers to extend the capabilities of CloudStack. CloudStack consists of two major components: the Management Server and the Cloud Infrastructure. The Management Server controls the Cloud Infrastructure and there is typically one of that kind. The Cloud Infrastructure consists of various nodes running virtual Instances and the Management Server manages each of them. The Cloud Infrastructure consists of one or more dedicated Servers, but in a minimal installation it can also be run on the same machine as the Management Server.

CloudStack Overview

CloudStack Overview


Header Image Copyright by Alexandre Dulaunoy

Self service IT Requirements: how to automate

The easiest way to implement a self Service Platform is to provide an IaaS-Platform. Some IaaS self Service Platforms that are available open source are described and evaluated in Chapter 2. Infrastructure as a Service often serves as a foundation for Platform as a Service or Software as a Service Platforms. There are also some Platform as a Service Implementations available such as ConPaaS  (Pierre & Stratan , 2012). Software as a Service Applications usually needs a lot of customization to make them available as self Service Applications.
To transform the IT to a self Service IT, there are some possible process optimizations available: IT departments could start with the most manual, the most time critical or the most error-prone process. If a process is manual and there are a lot of repeatable tasks, there is a good chance that this process can be transformed into an automated task. Time critical processes also have huge potential in automation since it might be possible to save money by reducing time-to-market.
Once the processes automated are identified, there are some other steps the enterprise might execute:

  • Break down high-level processes. Processes, which are defined as high-level processes can now be split into smaller, granular components. It is also possible to include sub-processes if needed.
  • Create abstract processes. Identify locations where lower-level processes can be „packaged“ and reused in multiple high-level components. This reduces process complexity and improves maintainability of processes.
  • Identify process triggers and end-points. Process Triggers are End-user requests, time events, … and end-points are Notifications, validation actions…
  • Identify linkages and interfaces between steps of each process.
  • Codify any manual steps wherever possible. Manual steps can be automated by adding custom code.
self service storage

self service storage (C) Seth Anderson