« June 2009 | Main | August 2009 »

July 23, 2009

Announcing the Kynetx Developers Conference

Kynetx Logo

Kynetx will be holding a developer's conference on October 21-22. The conference will be in Utah, although the exact venue hasn't ben nailed down yet. Some of the topics on the agenda:

  • Building Apps with KRL
  • Advanced Rule Programming
  • Action Cards and Information Cards
  • Data and Rules
  • The KNS API

We are also lining up some great keynotes.

If you're curious about Kynetx and what we're doing, this will be a great way to immerse yourself for a few hours or a few days in learning about our services and what you can do with them to build applications that augment the Web across all platforms and browsers.

11:31 AM | Comments () | Recommend This | Print This

Sam Rides 1000: Kynetx and Google Docs

Milk churns being carried on bicycles, Kolkata...

Image via Wikipedia

Sam Curren, who works at Kynetx set a goal to ride his bike 1000 miles this summer. And because he's a geek, he instrumented the whole effort so that we could all follow his efforts. The way he created a dashboard of sorts for his riding using a combination of Google Docs and a Kynetx App.

Sam's first task was data collection. He uses a Android-powered G1 for his phone. He installed the My Tracks application to record the data for his ride and then uploaded the data to Google Spreadsheets.

Creating his "dashboard" involved using Yahoo! YQL to convert the data from CSV to JSON and then building a small application using KRL, the Kynetx Rule Language, to grab the JSON and display the results on his blog. He also has a card that will put the results in Google if you don't go to his blog all that often, but still want to keep up with his riding.

Google with Sam

Sam's process is automated and once he's done with his ride the dashboard is updated with in a few hours (depending on the data caching). Not bad.

While the audience for data about how far Sam has riden his bike is probably pretty small, I like this application because it shows the use of KNS (Kynetx Network Services) to use data--even data from a phone--to augment and customize Web pages.

If you have an idea for a Kynetx App, you can get started now. It's free.

9:35 AM | Comments () | Recommend This | Print This

July 20, 2009

Starting a High Tech Business: Only the Employees Will Care

Kynetx Logo

I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the twentieth installment. You may find my efforts instructive. Or you may know a better way--if so, please let me know!

Businesses have all sorts of constiuencies: shareholders, customers, employees, and so on. And for one reason or another you might argue which is most important. When you're on a board of directors, for example, you work for the shareholders and, except where required by law, put their needs first. In this post, however, I'm going to make a case that when you're in startup mode, you ought to pay careful attention to the employees.

My reasoning is pretty simple. One of the critical observations I've made about iMall, almost 10 years after we sold it to Excite@Home is that only the employees care anymore. In 2009 the investors--those who made money and those who lost it--rarely think about iMall. The customers certainly don't give it a second thought. But the employees are a completely different matter. They made friendships there and gave important parts of their lives to making iMall a success. They learned things there that they use in their careers even now. There's even an active mailing list of former iMall employees.

One of the primary reasons for starting a business is that it's a lot more fun and exciting than getting a job. Part of the fun is that you get to pick the people you'll work with. You get to build a team and create a culture. If you succeed in creating a team that works everyone on that team will remember it as a highlight of their lives. I remember reading somewhere that when people are part of a successful team they spend the rest of their lives trying to recreate that experience. I think that's one of the reasons that most entreprenuers do it over and over again. They love the social side of starting a business.

There are too many aspects of building company culture to go over in a single blog post, but a few stand out in my mind:

  • Lead. Good teams need good leaders. If you've started a business you need to lead the employees. This is different, if you wondering, from managing them. They need that too, but not nearly as much as they need leadership.
  • Celebrate wins. Don't try to divide up credit too finely. When the company gets a sale, everyone gets credit. I'm a big believer in concrete "thank-yous." They don't have to be big--in fact they are better if they're not. We bought a developer a radio-controlled plane once. He wanted it but wouldn't buy it himself. He appreciated it much more than a $200 check.
  • Feedback. Make sure people know where they stand. What are they doing well and what needs more effort. I'm not very good at this--so I made sure I had a partner who's excellent at it.
  • Be social. We have a company lunch every Friday. Over time the exact nature of the lunch has evolved, but the purpose hasn't: get people together for some less formal interaction.

When it's all said and done the relationships you develop by starting a business are the most important thing you'll take out of it. For most people in startups any monetary advantage they get will be temporary, but the people will be there for the rest of your life. Make sure you're building and enjoying the relationships along the way.

11:36 AM | Comments () | Recommend This | Print This

July 17, 2009

Context Automation Talk from Gluecon

Phil Windley speaking at Gluecon

My talk on Context Automation is up on InfoQ now. They've done a nice job with video and slide syncing. In this talk, I discuss the role of digital identity in context automation and web augmentation. I go through an example of building a ruleset in KRL that puts the latest tweet for a search term inside the google search results as part of the talk.

9:50 AM | Comments () | Recommend This | Print This

July 2, 2009

Automatically Building, Configuring, and Maintaining Complex Infrastructure

Servers designed for Linux

Image via Wikipedia

I've been heads down for the last few weeks getting a project out the door for a new customer. As I mentioned, this involves creating a virtual appliance. I decided, due to the circumstances of this deployment that the best option was the build an appliance factory that is capable of churning out new virtual machines at will. I'm going to describe how I did that in this post.

There are bascially three steps to creating a new image that runs the Kynetx Network Service (KNS):

  1. Create a new virtual machine
  2. Install packages and Perl libraries, create users, and otherwise configure the machine to run KNS
  3. Deploy the KNS code and test it

I was exporing Kickstart files for automatically installing Fedora and CentOS when someone pointed me at Cobbler. Cobbler is a Linux installation server that is simply amazing. It includes templated kickstart files, DHCP and DNS servers, the ability to manage multiple distros and repositories, and a database for keeping it all straight.

You start by importing distros and images, then define profiles that combine those with kickstart files, and finally create system definitions for each machine refering to profiles. I pnly needed one distro, one repo, and one kickstart, so I ended up with multiple systems hanging off of one profile. Once that's done, a command called koan (kickstart over a network) is used on the Dom0 machine to create virtual machines as defined by the system definitions cobbler.

I carefully edited the kickstart file to create just the machine I wanted with the right packages installed. At this point, I was building new VMs and taking them down 20-30 times a day as I tested this. That's the beauty of automation--tacking up a machine is just dirt simple.

I was lucky that I'd already invested considerable effort in Puppet recipes for building the environment that KNS need to run, so the second step was almost done. In fact, with just a few edits, I had Puppet building the new VMs up.

The third step was also one that I'd spent some time on. I have a custom deploy script (in Perl) that deploys KNS code based on server role and takes care of all the little details like setting up the configuration files for the various servers.

Every system is slightly different, but I think there's a definite distinction between machine setup, system configuration, and code deployment. The first creates a fairly standard environment, the second configures it to a specific purpose, and the third manages the code.

Some thoughts on all of this:

  • Some have asked "Why not put the code in Puppet (i.e. why use a deployment system)?" My answer is that code deployment is a dynamic process that I want more control of than puppet's automatic configuration provides. You could probably press Puppet into this, but it didn't seem to fit for me.
  • I had to create a simple YAML-based configuration file for KNS to pull everything together. YAML was the right answer for this. I chose to put that configuration file in Puppet, but I think I'll pull it into the deployment process in the future.
  • One missing piece is a database that everything can read system configurations from. Cobbler provides a light-weight one that may serve our purposes for a while, but something like iClassify is more flexible. Right now there's system information in Cobbler, Puppet, and the deploy script. There's a way to put additional attributes in Cobbler that we could use in other places.
  • All of this--Cobbler, Puppet, and the deploy script--were installed and running on a virtual machine that we call the factory. That one image, once installed in Xen is capable of creating as many copies of each type of machine we run as needed.
  • This can all be done on physical boxes too, of course, but I prefer the flexibility of virtual machines--even when only one will be running on the physical hardware. They can be moved, replicated, and managed with a lot more ease that physical hardware. Plus I have the ability to fire up new ones for QA or whatever without buying and installing new physical hardware. When a 8 core, 32 Gb box costs $4K, you can amortize that investment a lot with virtual machines.

Startups need to be lean. Achieving that goal in a compute-intensive business requires automation. Fortunately with tools like Cobbler and Puppet, automating the build-side of your infrastructure is not only possible, but fairly easy. We manage several dozen machines with only a few hours a week of effort. What's more, adding a new box for load or experimenting is as easy as typing a few commands and waiting 20-30 minutes.

3:14 PM | Comments () | Recommend This | Print This