I will post some Developer content from now on, with a focus to some easy but helpful tasks when working with various Cloud Platforms. These tips will be named after the service (e.g. Amazon Web Services for AWS, …)
The first tip I want to show is how to retrieve the full queue URL when you already have the queue name:

sqs.getQueueUrl(new GetQueueUrlRequest().withQueueName("myqueue")).getQueueUrl();

The function “getQueueUrl()” already returns a String-representation and not a URI itself (this is what I would rather expect in that case)

In this post, I will describe success factors and inhibitors for self service IT. I will evaluate how the impact of each factor might be. There are three possibilities: high, medium and low.
The first table will display the success factors:

Factor Description Impact
Process Knowledge Self Service IT involves a lot of automation. Automation is not only done in terms of technology automation but also for processes. Therefore, it is necessary to be informed about processes in place within the enterprise. If the IT department is not aware of processes within the enterprise, knowledge about processes should be established, which involves time the employees have to invest. This is also associated with costs. Medium
Integrated Platform Users should easily adopt the platform and should get what they are already used to. This means that the platform should be integrated into existing services. This will significantly drive up the speed how users accept the new platform. High
Work with the Users It is especially necessary to work with the end users that are targeted to use the platform. This is an important way to find out what the users really need. Because the users eventually have to use the platform and if they don’t accept it, the platform might fail. High
Internal Service Charges Self Service IT Platforms are built with internal service charges. This has a great benefit to the enterprise since managers can see costs where they actually occur. The IT department might even be cost-neutral instead of expensing money. Top Level managers can have quick reports about the IT usage and costs of each department such as marketing or finance. On a self Service platform, departments only pay for what they need and the costs are accounted to the department itself. High
Change management A distinctive process for Change management helps the enterprise to introduce new platforms such as a self Service IT platform. This also includes not only implementation but also training. Medium

In the next table, I will describe inhibitors for self service IT:

Factor Description Impact
No Process Orientation Processes are important aspects for self Service IT implementations. Automation often requires processes that show the path to the automation. If the company has no process orientation in place, the entire corporate organization might need some distinct changes. This is a significant problem for self Service IT Platforms. High
Lack of IT awareness Providing self Service IT also means that users have more responsibility. More responsibility leads to more knowledge users need to have about technology and the platforms. Especially in IT, we see some sort of age gap  (Deal 2007), where young people learn IT-related topics faster and old people have problems. This could broaden the gap, if the platform is not easy to understand by all users. Medium
Lack of IT acceptance in the enterprise To implement self Service IT platforms, the IT department should play an important role in the enterprise. The IT manager (CIO) should probably also be integrated in the Board or extended Board to have access to enterprise decisions and strategies. If the IT department only plays a supportive role instead of a strategic role, it might be hard to cooperate across different departments and processes. Medium
A “one size fits all” approach Users in an enterprise are different and so is their knowledge. Some users might be will trained in IT, others not. Delivering a standard tool that all users in an enterprise have to use will affect the adoption of the system in a negative way. Unskilled users will have to call the IT support more often, which will create costs. Therefore, it is important to built self Service platforms specific to the needs of different user groups. Medium

Header Image Copyright by trickmonet.

In this post, I want to sum up what is all necessary for self service IT. In the two tables below, you will find the different requrements.
General requirements:

Need Description
Scaling and Elasticity Platform is built to scale to a specific quota. Elasticity is built-in.
Pay-per-use Platform provides the ability to charge the departments/users on their usage.
Device independence Easy tasks and monitoring should be possible; platform should be built on internet standards
On Demand Instances and Applications should be available once the user needs them
Simple to use Users must only see what they need to work on. Provide a simple and clear interface.
Quota configuration and User Roles Each department gets a specific quota of IT resources; departments can also set quotas on projects, applications and websites. Different user roles are necessary.

Technical requirements:

Requirement Description
Resource Automation Offer possibilities to automate resources and processes; usually done in Infrastructure platforms.
Simple API Provide an API to interact with the platform. The API should support: launching, controlling and stopping applications.
Service Orientation Service orientation is a key factor for Datacenter Integration. The concept has these aspects: services, interoperability through an Enterprise Service Bus and loose coupling.

Since there are many cloud providers out there and I often come across the problem to switch between different platforms (such as Google AppEngine, Amazon S3, …) I have decided to write a single client that will work with all different platforms – or at least as most as possible. I’ve created a project on Google Code here and I will start to write a first draft of interfaces. In the first step, I will include Amazon S3. I hope that more people will join this project and help me creating a great project 😉

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

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.


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

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

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 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

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