satis egitimisatis egitimitengda.pro

Open@Blog

Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login

Next Generation High Density App Servers Don't Require Scrapping Your Hypervisor

Recently, I sat in a conference session extolling the seemingly endless virtues of Linux Containers.  I heard claims that hypervisors were old hat: ancient bloated engines which rely on inefficient replication of a large operating system stack in order to serve up applications.  The speaker painted a picture of a future where hundreds of applications are virtualized on each piece of hardware.  "What is really needed," glowed the speaker, "is a lightweight, efficient means of serving up application: containers."

Containers are cool, but not a panacea

Containers share the same kernel as the host, so they are not burdened with the extra memory and CPU cycles it costs to replicate a full operating system stack in a hypervisor scenario.  Compared to hypervisor-generated virtual machines, containers can be fast and lean.  But they are also limited.  

Since Linux containers share the same kernel as the host, it is impossible to run Windows.  Or FreeBSD. Or NetBSD.   Or another version of the Linux kernel.  Or another Linux distribution which requires a different kernel.  All of those scenarios are best handled by a real hypervisor.  And the security aspect of hypervisors is huge, worthy of a separate blog entry of its own.  Still, if you need an environment within your organization where many workloads can leverage a single kernel environment, containers can be a viable solution.

However, some of the most vocal container advocates insist that these problems relating to containers are really application problems in disguise.  Issues about kernel support and security are the results of improper application design, they claim.  When we raise the bar on applications so that they are based solely on access to application servers, then the objections to containers will melt away -- and so will hypervisors, for the most part.  Or that's what some of these advocates claim, at least.

The death of the hypervisor is greatly exaggerated

But is there another scenario which could answer the call for highly responsive and lightweight virtual instances which does not use the container solution?  Maybe one that can actually leverage the flexibility and security which is part and parcel with most hypervisors?

...
Hits: 1130
Rate this blog entry:
0
Continue reading Comments

ApacheCon approaches

Posted by on in Open Source

It doesn't seem possible, ApacheCon is less than a week away. CloudStack Collaboration Conference follows shortly. I am excited about seeing ApacheCon this year, the schedule is huge and contains a ton of interesting content. That actually may be a detriment - so much content it will make deciding what talks to see difficult.

Particularly interesting to me is the ton of big data talk. There are plenty of big data projects at the ASF, and those projects have managed to bring 5 days worth of big data content to ApacheCon, coupled with 3 days worth of Lucene/Solr content. Keeping in mind that the ASF is the home for the majority of open source big data projects and ApacheCon becomes a must-attend event if you care about big data.

But ApacheCon is more than just big data, there are tracks for cloud and mobile development, as well as perennial favorites like Traffic Server, and Tomcat. 28 tracks in total.

All of this content is great; and I look forward to learning a lot while I am at ApacheCon, but it ignores the most valuable reason that I am attending: the hallway track. Being able to converse with  many members of various Apache project communities is invaluable.

I hope to see you there.

Hits: 878
Rate this blog entry:
0
Comments

Migration from Publican to Sphinx and Read The Docs

When we started with Cloudstack we chose to use publican for our documentation. I don't actually know why, except that Red Hat documentation is entirely based on publican. Perhaps David Nalley's background with Fedora influenced us :) In any case publican is a very nice documentation building system, it is based on the docbook format and has great support for localization. However it can become difficult to read and organize lots of content, and builds may break for strange reasons. We also noticed that we were not getting many contributors to the documentation, in contrast, the translation efforts via transifex has had over 80 contributors. As more features got added to CloudStack the quality of the content also started to suffer and we also faced issues with publishing the translated documents. We needed to do something, mainly making it easier to contribute to our documentation. Enters ReStructured Text (RST) and Read The Docs (RTD).

Choosing a new format

We started thinking about how to make our documentation easier to contribute to. Looking at Docbook, purely xml based, it is a powerful format but not very developer friendly. A lot of us are happy with basic text editor, with some old farts like me mainly stuck with vi. Markdown has certainly helped a lot of folks in writing documentation and READMEs, just look at Github projects. I started writing in Markdown and my production in terms of documentation and tutorials skyrocketed, it is just a great way to write docs. Restructured Text is another alternative, not really markdown, but pretty close. I got familiar with RST in the Apache libcloud project and fell in love with it, or at least liked it way more than docbook. RST is basically text, only a few markups to learn and your off.

Publishing Platform

A new format is one thing but you then need to build documentation in multiple formats: html, pdf, epub potentially more. How do you move from .rst to these formats for your projects ? Comes in Sphinx, pretty much an equivalent to publican originally aimed at Python documentation but now aimed at much more. Installing sphinx is easy, for instance on Debian/Ubuntu:

apt-get install python-sphinx

You will then have the sphinx-quickstart command in your path, use it to create your sphinx project, add content in index.rst and build the docs with make html. Below is a basic example for a ff sample project.


 
 
 

What really got me sold on reStructuredText and Sphinx was ReadTheDocs (RTD). It hosts documentation for open source projects. It automatically pulls your documentation from your revision control system and builds the docs. The killer feature for me was the integration with github (not just git). Using hooks, RTD can trigger builds on every commit and it also displays an edit on github icon on each documentation page. Click on this icon, and the docs repository will get forked automatically on your github account. This means that people can edit the docs straight up in the github UI and submit pull requests as they read the docs and find issues.

...
Hits: 1349
Rate this blog entry:
0
Continue reading Comments

An Open Source Conference Remembers the Origins of the Movement

Later this week, I will be in Los Angeles to speak at the Southern California Linux Expo, better known as SCALE.  While my speaking at a conference is nothing unusual (I did it more than a dozen times last year), the conference itself is remarkable in its adherence to the spirit of Open Source.

I still have vivid memories of some of the Open Source conferences I attended 15+ years ago.  Geeks gathered together on a weekend to talk about Linux and the great software they were creating.  It is important to remember that back then, Open Source coders had no corporate backing, so coding and conferences had to be done on personal time.

I remember the conversations which took place at the evening get-togethers.  I can still see the fire in the eyes of attendees as they eagerly described the cool stuff they were doing writing or using Linux-based software.  I can still hear the excited voices extolling the qualities of their newest project.  You could feel the enthusiasm in the air.  You could almost taste it.

It wasn't the process of creating Free Software that excited people.  And it wasn't the jobs which drove them to create the software; Open Source jobs were the elusive "brass ring" many hoped for, but few had.  No, the excitement was from a sense of empowerment.

If you were in the IT industry prior to 1995, you probably recall the role of the geek.  Software geeks were power tools wielded by the hands of others.  Geeks rarely decided things for themselves.  If they had a good idea, they were likely to see it shot down by some manager up the food chain with the words, "That's not in the project plan." Or, "That's great, but we can't afford to waste time on that."

...
Tagged in: open source
Hits: 11641
Rate this blog entry:
0
Continue reading Comments

Thoughts from FOSDEM

Posted by on in Open Source

I had the pleasure of attending FOSDEM, the Free/Open Source Developers European Meeting this year. There are always interesting folks in attendance, and getting to meet folks you only know via IRC or or a mailing list is great. I also always pick up lots of interesting information.

 

In short, if you can make FOSDEM, you should do so. That isn't really what I wanted to write about though. FOSDEM always has a lot of related conferences; this year they included the CentOS Dojo, CfgMgmtCamp, and Infra.next. Each of those could easily fill several blog posts, but the most poignant thing in my trip this year happened at Infra.next.

 

 I often cite John Vincent with his 'Monitoring sucks' tagline. Not because monitoring sucks as a practice, but because the tools for monitoring are generally comparatively archaic, and painful to use. As a recovering sysadmin, I understand the pain behind 'Monitoring Sucks' well; and thanks to a conversation from Kris Buytaert I realized that many of John's complaints around monitoring, aren't monitoring specific at all, and that caused me to go back and reread John's original post from 3 years ago. These truths should be evident, but I think it's all too easy to forget them, and see plenty of software that ignore them. Specifically, any systems management software should keep these items in mind and avoid them:

...
Hits: 3810
Rate this blog entry:
0
Continue reading Comments

Open@Citrix

Citrix supports the open source community via developer support and evangeslism. We have a number of developers and evangelists that participate actively in the open source community in Apache Cloudstack, OpenDaylight, Xen Project and XenServer. We also conduct educational activities via the Build A Cloud events held all over the world. 

Connect