Posts Tagged ‘chef’

Solving the pressing need for Linux talent…

September 17, 2013 Leave a comment

The Linux Foundation shared the below infographics recently.  Click on it and you get the associated report. The short message is, if you are an expert in Linux you are in high demand because companies don’t find enough experts due to the Cloud and Big Data boom.

Unless cloning machines are discovered later this year, quickly expanding the number of Linux experts is unlikely to happen. This means total cost of ownership for enterprises is likely to rise. This is ironic since Linux is all about open source and providing some of the most amazing solutions for free.

The obvious alternative is to focus on Microsoft products. They are relatively cheap in total cost of ownership since licenses are “payable” and average Windows skills can be easier found.

However Microsoft is loosing the server war, especially in the web application space. So this is not a winning strategy if you are going to do Cloud.

How to solve the pressing need for Linux talent?

The only possible strategy is to lower the number of experts needed per company. Larger companies always will need some but they should be focused on the “interesting high-value tasks”. This concept of interesting and high-value is key. With the number of cloud servers exploding, we can not expect the number of experts to explode.

Open source products like Puppet and Chef have helped to alleviate the pain for the more “skilled” companies. One DevOp was able to manage more than ten times as many machines as before. Unfortunately these server provisioning tools are not for the faint of heart. They  require experts that know both administration and coding.

It is time for the next generation of tools. Ubuntu, the number #1 Cloud operating system, is leading the way with Juju. If Linux wants to continue to be successful then the common problems, the boring problems, the repetitive problems, etc. should be solved. Solved by Linux gurus in such a way that we, the less IT gifted, can get instant solutions for these common problems.

We need a Linux democracy in which the lesser skilled, but unfortunately the majority, can instantly reuse best-in-class blueprint solutions. Juju is a new class of tools that gives you instant solutions. For all those common problems: scaling a web application, monitoring your infrastructure, sharding MongoDB, replicating a database, installing a Hadoop cluster, setting up continuous integration, etc. Juju can offer solutions. The individual software components have been “charmed”. A Charm allows the software to be instantly deployed, integrated and scaled. However the real revolution is just starting. Juju will have bundles pretty soon. Technically speaking, a bundle is a collection of pre-configured and integrated Charms. In lays speak, a bundle is an instant solution for a common problem. You instantly deploy a bundle [one command or drag-and-drop] and you get a blue-print solution. Since Juju is open source, the community can create as many instant solutions as there are common problems.

So if you want to scale your IT solutions without stretching neither your budget or cloning your employees and without the lock-in of any proprietary and expensive commercial software, then you should try Juju today. Play with the GUI or install Juju today.

Juju: Deploy, Integrate and Scale Services Instantly on Multiple Clouds

It used to be hard to deploy hardware in a data centre. The Cloud changed all of this. You are literally minutes away from booting a 100 instances. This however has brought other problems. Applications, clusters, software stacks, etc. need to be able to work on many instances that are dynamically scaled up and down. All of them need to be integrated, even if IPs are changing continuously.

The first generation of solutions focused on automating server provisioning. You wrote a receipt of how a web server needed to be provisioned. You then assigned a role to each instance and it would be automatically set-up.

The problem is that server provisioning is only part of managing a complete service stack. Different services need to be able to communicate with one another. Services need to be monitored, backed-up, asset managed, “syslogged”, performance analysed, etc. Each new element in your stack would need single sign-on and to be integrated with your Nagios, Ganglia, Logstash, etc. Each Service scales differently. Some need a shared file system. Others need a high-available proxy or database. Yet others rely on P2P broadcasting which does not natively work in the Cloud.

There is now a second generation solution that promises to deploy, integrate and scale instantly on all major Public Clouds as well as Private Cloud. Instead of focusing on the servers, it focuses on the services that run on top of these servers. Its name is Juju, which means magic. Juju’s magic is called a Charm. A Charm encapsulates a service. A Charm exposes standardized interfaces towards the embedded service allowing other Charms to easily integrate. A Charm also  scales the embedded service transparently.

To understand the difference between service orchestration and server provisioning let’s look at some Charms. Where service provisioning tools would be just installing WordPress on a virtual server, Juju also does integration. So when the WordPress Charm is integrated with MySQL, automatically all tables and data are created in the database. A Charm also knows about security, so when you expose WordPress to the world, automatically the right ports are opened. When scaling the MySQL Charm, the Charm knows the concept of Multi-Master Cluster and Read Slaves, so you are able to deploy a very complex MySQL cluster instantly.

The Juju basics

Using Juju is very easy. There are only a hand-full of commands that you actively use: deploy, add-relation, add-unit, expose.

# Bootstrap the Juju environment according to your preferred configuration, e.g. AWS,
# HP Cloud, Open Stack, Local, etc.
juju bootstrap
# Deploy mysql and wordpress
juju deploy mysql
juju deploy wordpress
# Create a relationship between wordpress and mysql and
# assures the wordpress schema is installed inside Mysql
juju add-relation wordpress mysql
# Open ports hence wordpress is publicly accessible
juju expose wordpress
Read more…

Cloudify, an Open Source PaaS from GigaSpaces, is making Big Data Clouds easier to manage

May 24, 2012 2 comments

Cloudify, from the scalability experts GigaSpaces, is still its early stages. Unlike Google App Engine, Azure, Heroku, etc. this PaaS is more focused on the application life cycle and not on being a “transparent” application server and database.  The main focus is automating application and services deployment, monitoring, autoscaling, etc. The closest competitor would be Scalr.

Unlike Scalr, Cloudify’s focus is on Cloud-neutrality. Cloudify is not focusing on using specific Amazon services for scalability but instead to make a neutral Cloud platform. The advantage is that every possible Cloud being it private or public can be used and scenarios like hybrid clouds with Cloud bursting from private to public cloud are possible. The deep understanding of large-scale architectures in a company like GigaSpaces is a guarantee that Cloudify will scale in the future.

Cloudify is still missing some important functionality like security, multi-tenancy, integrations with lower-level automation frameworks (e.g. Chef and Puppet), complex upgrade management [e.g. rolling upgrades, MySQL schema upgrades, A/B testing of new features, etc.], etc. However the roadmap is pointing towards most of these items.

Software architects should understand the possibilities Cloudify, Scalr, etc. bring. By having a reusable automation framework companies are able to spend more development and operations time on bringing new business features and less on reinventing the wheel.


Scalr, how to simplify cloud operations beyond Puppet and Chef

In previous articles I wrote about automating cloud operations as a key to successfully and quickly launching new services.

You can use Chef or Puppet to automate the deployment of servers. However neither solves some of the other problems with cloud operations: autoscaling and disaster recovery.

Scalr is relatively new and still a bit rough around the edges. However it has great promises to simplify deployment, automate scaling and quickly recover from server outage. Scalr uses the out-of-the-box functionality from Amazon to quickly bootstrap an environment via AMIs. Afterwards it implements an alternative autoscaling that does not rely on Amazon’s. Disaster recovery depends on the type of server but it can automatically recover from master database failure and other elements in a typical scalable web architecture.

Work on extending Scalr towards other providers like Eucalyptus and Rackspace seem to be work in progress.

Scalr is  not only a good sample of the 80-20 rule in which they focus on the most common scenarios. However via a plugin mechanism it is very easy to extend. I expect other public cloud providers to contribute plugins in the near future.

At the moment Scalr is still rough around the edges but definitely with the right push of some startups and public cloud providers it should quickly mature. With some custom plugins a telecom operator that is thinking about IaaS and private clouds should definitely look at it and inspire themselves…


How to avoid becoming a bad Amazon-clone when doing IaaS?

February 17, 2011 Leave a comment

In previous posts I already expressed my doubt about telecom operators getting any real benefits from offering virtual servers and other IaaS aspects to their customers. It looks like “a 2000 déjà vu” in which operators started to offer hosted email after Yahoo and other showed them the way…

So if you don’t want to be a bad clone of Amazon AWS what can you do?

Alternative 1: The Mobile IaaS

Operators are all about mobile communication. However creating mobile applications is hard. Testing them is even harder. Let alone testing them on different hand-sets in a continuous automated testing approach.

This is exactly the type of services that a mobile operator can offer:

  1. Mobile hardware virtualization – instead of virtualizing an x86, why not virtualize the phone hardware, e.g. Nvidia Tigra2. A mobile operating system (MOS) developer could choose which hardware to virtualize: the amount of ram, which sensors, which CPU, which graphics card, etc. Afterwards different flavors of operating systems can be ran on this hardware: iOS, Android, Blackberry OS, Symbian, Windows Phone 7, etc.
  2. Mobile operating system virtualization – For less experienced developers they can already pick a pre-configured phone, e.g. iPhone 4. Afterwards a developer can launch applications on the phone.
  3. Automated mobile phone testing – After installing the application on the phone or using the build in browser to access a remote application, a developer should be able to run automated tests. This would allow for a continuous testing approach whereby a new version of a mobile app or an HTML5 application can be automatically tested by a whole set of mobile devices.

The business model would be the same as virtual servers: you pay by the hour.

Alternative 2: Telecom Infrastructure as a Service

Why not offer telecom infrastructure as a service instead of pure virtual servers? Admitted, the boundry between IaaS, PaaS and SaaS might be thin but ideas can be the following:

  • Billing as a Service: this can go from offering a complete billing system as a service to MVNOs or other industries that need real-time billing capabilities. To the other extreme whereby you would only offer APIs for partners and developers to charge.
  • Numbering Plan as a Service: more then just offering DIDs, you should be able to create services and associate them to a number formed by shortcode+mobile phone+app id => 12367012345601 => calling this number would forward the call to the application 01 belonging to the mobile subscriber 670123456 and 123 means the owner pays the call. 234 could mean caller pays. 345 could mean caller pays premium call and gives revenue share to owner. This could allow every subscriber to have multiple applications without having to pay €1-€5 for a virtual phone number.

Alternative 3: Mobile Development IaaS

Different from the mobile IaaS in the sense that we focus on facilitating the development and hosting of applications for mobiles. Developers would find tools to develop mobile application interfaces very easily. You write it once and run it on a large set of different mobile devices. Services like mobile push notification, device detection, charging, etc. should also be available. Also the hosting is optimized for mobile applications in which you have very strict low-latency and unreliable connectivity requirements.

Alternative 4: Beat Amazon AWS at Bootstrapping, Configuration Management, and other cloud operation automatization

If you are going to offer virtual servers, focus enormously on the bootstrapping and configuration management. Amazon and others have virtual images that allow a quick deployment of an existing configuration. However that is good if your application is stable and your software stack needs few modifications. Real-life applications and business solutions need a lot more flexibility. Setting up a database cluster, a webserver/proxy/memcache farm, a high-availability loadbalancer, an application server cluster, etc. are very manual tasks on most public clouds. True you can get an image with an apache, tomcat and mysql pre-configured, but you do not get a multi-node cluster image. To solve this you could use software like Chef or Puppet for provisioning and ControlTier or Capistrano for command & control. See my other blog post

Alternative 5: Be the Salesforce for Telecom & Mobile Applications

This is more PaaS then SaaS but being a Telco PaaS in which in a style you can use Web 2.0 and drag-and-drop to create mobile and telecom applications. Instead of having to code, people can create application via visual designers.

Alternative 6: alternative for quick web & mobile front-ends combined with custom protocols and on-site systems is PaaS for applications written in Node.js a javascript language that allows for massively scalable applications to be quickly developed.

Heroku is a PaaS for Ruby applications.

These are language specific PaaS that are similar to Google App Engine (GAE).  Where GAE allows Java and Python, has Javascript and Heroku has Ruby. Developers can very easily create applications. However GAE falls short writing front-end applications: Web GUI/Mobile HTML5 quickly. Also integration with non-HTTP protocols is not offered. Although the Internet lets you believe HTTP and FTP are the only protocols out there, there are literally thousands of binary, alternative standards and proprietary systems that large enterprises can not do without. Examples in the telecom industry are RTSP, SS7, etc.  If you can combine the speed of developing modern front-end together with the integration with legacy systems, binary protocols, on-site systems, etc. then you can have a large advantage when corporations want to move their back-office to the cloud.

Alternative 7: The Zoho/37 Signals for Telecom Applications

Zoho and 37 Signals are companies specialized in creating one-purpose mini applications for small and medium enterprises. Instead of a Siebel, Zoho will give you a basic CRM that works out of the box and has virtually no learning curve.

Zoho allows others to build applications on their infrastructure as well and resell them.

The same concept could be applied to telecom. Mini telecom applications like a PBX in the Cloud, SMS marketing, etc. are build on a common infrastructure. Externals can extend the application portfolio and resell them.

Alternative 8: Hosted PaaS

Instead of offering PaaS you offer a hosted PaaS infrastructure for enterprises. Each enterprise gets their own PaaS. Companies like Longjump and WSO2 are in this market. Be sure to add in some telecom assets…

Puppets on the wire – Automatic Cloud Operations

January 29, 2011 2 comments

In the past automatic deployment of software was something that a handfull of data center specialists dominated. However the cloud is changing this needs. If you need to deploy a battery of web servers, application servers, database clusters, nosql farm, etc. then you need to think of automatic software deployment from day one. Additionally you might have to deploy applications on Google App Engine, Azure, Amazon EC2/S3/etc., Rackspace, GoGrid, etc.

The three core areas to automate are:

  1. Cloud Provisioning
  2. Configuration Management and Automation
  3. Monitoring

Cloud Provisioning

The main advantage of the Cloud is its capability to autoscale. If you get more requests during the day, you turn up more machines. If you get less during the night then you switch some off. You can even do autoscaling by the hour or less. Since you pay by the hour, your costs will match your revenues.

There are many tools available to provision a Linux machine: Cobbler, Kickstart, OpenQRM (includes Windows), Spacewalk, Viper, xCat, Fully Automated Installation (FAI), etc.

These installers can be handy when we are talking about a private cloud. However in case a public cloud is used, we are more likely to want to use the public APIs offered by public Cloud providers to provision machines. Unfortunately there are no standard APIs in public Cloud land yet. The best option is to use tools or APIs that can handle multiple clouds: e.g.  Openstack, JClouds, Fog, Deltacloud, etc. Using one API to deploy on multiple clouds is key to avoid vendor lock-in.

The truth to be said, there is no clear winner in this space yet because most solutions have limitations and customization will be required. However expect very active development to happen in the coming months.

Configuration Management and Automation

The clear marketleader in this area is Puppet, which becomes even better when combined with mCollective. Puppet is a client/server configuration management solution that allows you to describe what you want to install and configure in a abstraction language. mCollective adds real-time notification. The whole solution is very powerful, although some learning will be required before you are up and running.

Other solutions in this space are: AutomateIT, bcfg2, cfengine, chefSmartFrog, etc.

Additionally there are tools whose focus is not on the software installation but instead on the deployment of applications once the main software stack is installed. Examples are: ControlTier, Capistrano, Fabric, etc.


With multiple servers, solutions and applications spread over multiple cloud providers, you need to monitor. Monitor to see if they are available, but also monitor to see if you need to switch on extra capacity or if it is safe to switch off some capacity.

The main solutions in this domain are: Nagios, Zenoss, OpenNMS, Zabbix, etc.

Other thoughts

Creating an automatec stack of tools to provision, deploy and monitor is an initial investment that will pay itself back very quickly. Other systems could be added to the stack like inventory and asset tracking, software version control, build automation, etc. In general there is no easy solution that gives you everything and this is where open source communities should focus their attention: bringing it all together and simplifying so we do not need experts…

%d bloggers like this: