Top > Joyent

What is Cloud Computing?.

We went to the Web 2.0 Expo and asked “What is Cloud Computing ?”. YouTube has a high definition version of What is Cloud Computing

Check out what the following people had to say:

What do you think Cloud Computing is?

Triathlon Experience with Fellow Joyeurs.

This past Sunday four of us from Joyent (and one wife) participated in a sprint distance triathlon (half mile swim, 15 mile bike, 4 mile run) at Lake Berryessa east of Napa valley. We all finished. We all had a great experience. Some of the experiences included getting into the cold lake water at 8 in the morning with 125 other people in our wave (there were five waves) and immediately thinking a horrible mistake had been made. Oh, this is what the sinking of the Titanic must have been like, from a participant perspective. To finally getting the rhythm of the swim. Riding like a banshee on the bike. Getting off the bike and not being able to bend over to put on running shoes. And then 4.0 miles. 3.94 miles. 3.93. 3.92. 3.915. The view of the finish line was lubricant for sore muscles and achy joints. The manhattan that night, even better.

We all extend congratulations to Linka Watridge, the wife of our CFO Peter Watridge, on her winning time bettering all of us by more than three minutes.



click for larger version

From l to r: Rod Boothby, Peter Watridge, David Young, Blake Burris

Peter won the bet, if you care.

Cloud Nine: Specification for a Cloud Computer. A Call to Action..

What is cloud computing? We recently asked a number of people in our industry, and got back a range of interesting, and sometimes self-referential, responses. You can see them here. According to our respondents, cloud computing means anything from a single-tenant, multi-user application cloud (also known as software-as-a-service or “Saas”) to multi-tenant, general purpose, on-demand clouds (sometimes called platform-as-a-service or “PaaS”). Joyent provides an example of the former in our Connector product. We also do the latter in our Accelerator product.

I think the world of computing, generally, is moving away from a do-it-yourself approach to accomplish “shared” computing (and by computing is meant anything having to do with servers, in general) towards embracing or, better, stepping into the cloud for most computing the isn’t on the edge of the network. The migration has begun from dedicated, collocated servers to the cloud. Buyers don’t want to take possession of servers, routers, switches, network drops, racks; they want this from the cloud.

But what is the cloud?

What sort of cloud computer(s) should we be building or expecting from vendors? Are there issues of lock-in that should concern customers of either SaaS clouds or PaaS clouds? I’ve been thinking about this problem as the CEO of a PaaS cloud computing company for some time. Clouds should be open. They shouldn’t be proprietary. More broadly, I believe no vendor currently does everything that’s required to serve customers well. What’s required for such a cloud? I think an ideal PaaS cloud would have the following nine features:

1) Virtualization Layer Network Stability

Cloud computers must operate on some sort of virtualization technology for many of the following features to even be feasible. But as general purpose computing moves from dedicated hardware to on-demand computing, one key feature of the dedicated model for web applications is a stable, static IP address. If the virtualization layer borks (and this happens), when the cloud has recovered the cloud instances of compute, the developer should be able to rely on the web application just working without having to re-jigger network settings.

2) API for Creation, Deletion, Cloning of Instances

Developers should be able to interact with the cloud computer, to do business with it, without having to get on the phone with a sales person, or submit a help ticket. In other words, the customer should be able to truly get on-demand computing when they demand, whenever they demand. Joyent only began to offer this recently through Aptana and their Aptana Studio product. However, the API is only available to Aptana at this point. The API needs to be publicly available to everyone. Provide a credit card (that works and is yours) and you should get compute, storage, and RAM on-demand. The challenges for cloud computing companies is to figure the just-in-time economics that allow us to provide on-demand infrastructure without having lots of infrastructure sitting around waiting to be used. I think this means that cloud computing companies will, just like banks, begin more and more to “loan” each other infrastructure to handle our own peaks and valleys, But in order for this to happen we’d need the next requirement.

3) Application Layer Interoperability

Cloud computers need to support a core set of application frameworks in a consistent way. I propose that cloud computers should support PHP, Ruby, Python, Java and the most common frameworks, libraries, gems/plugins, and application/web servers for each of these languages. Essentially, a developer should be able to move between Joyent, the Amazon Web Services, Google, Mosso, Slicehost, GoGrid, etc. by simply pointing the “deploy gun” at the cloud (having used the API mentioned above to spin up instances) and go. Change DNS, done. But, no cloud computing company is innovating by providing better application layer solutions. We ought to support the most popular languages and move on. However, for a developer to truly have cloud portability, we need to support another requirement.

4) State Layer Interoperability

This is the most difficult problem to solve when scaling a web application, and, consequently, the area in which cloud computing companies are innovating while sacrificing interoperability. It’s not simply a question of deciding that we should all support MySQL or Postgres because we will find that the needed requirement (“Automatic Scaling”) is practically impossible to achieve with these tools. Amazon is innovating with SimpleDB, Google has BigTable as solutions for the problem, but developers can’t leave either cloud because neither SimpleDB nor BigTable are available anywhere else. What is needed, and I’m looking ahead to the next requirement when I say this, is an XMPP-based state-layer that can flush out to some SQL-y store. Think open-source Tibco. The financial markets fixed these problems years ago. This datastore needs to speak SQL, be built using open-source and free software, and be easy for developers to adopt. The value cloud computing companies provide to developers is running the state layer for them, without requiring developers to use some proprietary state layer that may or may not provide scalability upon success and represents lock-in.

5) Application Services (e.g. email infrastructure, payments infrastructure)

A cloud computer should provide scaled application services consumable by developers in developing and delivering their own applications. There are two types of application services. The first group is delivered using open protocols/formats. Examples would be IMAP/SMTP, LDAP/vCARD, iCAL/ICS, XMPP, OpenID, OPML. All clouds should offer these open protocols/formats so that developers can move between clouds without having to rewrite their application. The second group is delivered as web services, are often proprietary to the cloud (therefore a means of differentiation), and include services such as payments, inventory.

6) Automatic Scale (deploy and forget about it)

All things being equal, a competent developer should be able to deploy to a cloud and grow to five billion page views a month without having to think about “scale”. Just write the code, the cloud computer does the rest.

Is this achievable? Today, no. No cloud computer automatically scales applications. Part of the problem lies in the state layer. Part of the problem lies in what it means to scale. What is the measure of scale? Responsiveness? Scaling the state layer (e.g. the database) is a black art. Scaling the application layer or the static assets layer relies, in part on load balancing and storage.

7) Hardware Load Balancing

The cloud computer should provide the means to achieve five billion page views a month. I picked that number because it is big. If you’re writing an application, and you want to be able to achieve tremendous scale, the answer shouldn’t be to move off the cloud onto your own “private” cloud of dedicated servers. Of course, if the cloud computer is open as we’ve described, you can build your own cloud. It’s also true you can generate your own electricity from coal, if you want to bother. But why bother? Software load balancers will get you nowhere close to the throughput required to achieve 5 billion page views per month. The state of the art is hardware load balancers.

8) Storage as a Service

Storage should be available to developers as a service. Where this is done today, it is done using a proprietary API and represents lock-in. The storage service should allow customers to consume endless amounts of storage and pay for only what is used. Objects on the storage service should be accessed by developers as objects rather than as nodes in a hierarchical tree. This way developers don’t have to understand the hierarchy.

WebDAV could be an open protocol version of the storage service, but fails to provide the abstraction of treating objects as objects rather than nodes in a hierarchical tree. At present, I don’t believe there is a reasonable solution to the problem that isn’t also proprietary. We need to develop one that is open and free.

9) “Root”, If Required

The cloud computer vendor can’t think of everything a developer or application might need or want to do. So the cloud needs to be hackable and extensible by the developer and that means an administrative account of some sort that allows the developer to shape and mold the cloud to their specific needs. By definition, cloud computers must be built on top of some sort of virtualization technology, so the developer never has “root” to the cloud, only “root” to the developer’s part of the cloud.

Operating Systems Don’t Matter for Cloud Computing

People often confuse the “userland” with the operating system. An operating system provides the means for the userland to interact with hardware. The userland, especially in a (virtual) server context is “where stuff lives”. Where is the document root for Apache? Where do plug-ins get installed?

At Joyent, we use Solaris Express as the basis for our distribution of Solaris. It has a radically simplified userland designed for web applications, not for laptop computers, graphical user interfaces, mp3 libraries. Developers care about the userland, not the operating system. Wouldn’t it be great if you logged into your cloud and you saw:

/code
/frameworks
/binaries

How do we extend this so that the cloud is entirely “RESTful” and everything is just a URI? :)

The choice of the operating system (and the consequent virtualization technology) is critical to the cloud computing service provider. Whether we choose Solaris Zones or Xen or VMWare ESX or Linux KVM or Windows Server 2008 tells you about the ability of the cloud computer to scale reliably. Developers should care about the choices their cloud computing vendor makes because it speaks, in part, to the ability of the cloud to scale. But for using the cloud, deploying an application, it makes no difference.

Business Models

I’ve left aside talking about the business model of a cloud computer, since that is best left up to the vendor. The issues of whether there are contracts or not, whether one can pay with a credit card, is there hourly or monthly billing, these things don’t matter for the definition of a cloud computer. It is in these areas that vendors can innovate and differentiate.

Introducing CloudScore

The nine factors that make up a cloud computer can be applied by you, the buyer, to any cloud computer out there to determine a “CloudScore”.

Joyent’s Accelerator offering currently scores a CloudScore of 7 out of 9. We are working hard to achieve a Cloud 9.

Google Friend Connect Site on Joyent Accelerators.

Want to play around with a site already using Google’s Friend Connect? Head over to BibleApps running on Joyent Accelerators. The “Sign In” infrastructure is part of the gadgets available from Google Friend Connect. God bless them.

Amazon Web Services or Joyent Accelerators: Reprise.

In the Fall of 2006, I wrote a piece On Grids, the Ambitions of Amazon and Joyent, and followed up with Why EC2 isn’t yet a platform for ‘normal’ web applications and the recognition that When you’re really pushing traffic, Amazon S3 is more expensive than a CDN.

The point of these previous articles was to put what wasn’t yet called “cloud computing” into some perspective and to contrast what Amazon was doing with what we were doing. I ventured that EC2 is fine when you’re doing batch, parallel things on data that’s sitting in S3, and that S3 is economically fine as long as you’re not externally interacting with that data to a significant degree (then the request pricing kicks in). Basically it is incorrect that each are universally applicable to all problems and goals in computing, and that they’re cost-effective. An example of a good use case is a spidering application: one launches a number of EC2 instances, crawls a bunch of sites, puts that information into S3, and then launches a number of EC2 instances to build an index of that data and further store it on S3.

Beyond point-by-point features and cost differences, I believe there are inherent philosophical, technical and directional differences between Joyent and Amazon Web Services. This is and has been our core business, and it’s a business model, in my opinion, that competes directly with hardware vendors and customer taking direct possession of hardware and racking-and-stacking it in their own datacenters.

Cloud computing is meant to be inherently “better” than what most people can do themselves.

What’s changed with S3 and EC2 since these articles?

For S3? Nothing really. There are some additional data “silo” services now. SimpleDB is out and there has been some updates to SQS, but I would say that S3 is by far the more popular of the three. The reason is simple: it’s still possible for people to do silly things when storing files on a filesystem (like put a million directories in one directory), but it’s more difficult to do things as silly with a relational database (you still can, but they’re ultimately handled within the RDMS itself, for example, bad queries).

I’m consistently amazed by how many times I have to go over the idea of hashed directory storage.

For EC2 there’s been some improvements.

Annotating the list from “Why EC2 isn’t yet a platform for “normal” web applications we get:

1. No IP address persistence. EC2 now NATs and EC2 instances are on a private network. That helps. Are you able to get permanently assigned, VLAN’ed network address space? It’s not clear to me.

2. No block storage persistence. There is now an option to mount persistent storage in a “normal” way. Presumably it’s block storage over iSCSI (there’s not many options for doing this), hopefully it’s not a formalized FUSE to S3. We’ll see how this holds up performance-wise, now there’s a bit more predictability in data stored in EC2 but experience has shown me that it only takes one really busy database to tap out storage that’s supposed to be serving 10-100 customers. Scaling I/O is still non-trivial.

3. No opportunity for hardware-based load balancing. This is still the case.

4. No vertical scaling (you get a 1.7Ghz CPU and 1 GB of RAM, that’s it). There are now larger instances but the numbers are still odd. 7.5GB of RAM? I like powers of 2 and 10 (so does computer science).

5 & 6. Creation and handling of AMIs. Experience like this is still quite common, it seems.

Structure of modern applications

The three tiers of “web”, “application” and “database” are long dead.

Applications that have to serve data out (versus just pulling in like the spidering example earlier) are now typically structured like: Load Balancers/Application Switches (I prefer the second term) <-> Cache <-> Application <-> Cache <-> Data. Web and gaming applications are exhibiting similar structures. The caching tiers are optional and either can exist as a piece of middleware or as part of the one of the sandwiching tiers. For example, you might cache as part of the application, or in memcached, or you might just be using the query cache in the database itself. And while there are tiers, there are also silos that exist under their own namespaces. You don’t store static files in a relational database, your static assets are CDN’ed and served from e.g. assets[1-4].yourdomain.com, the dynamic sites from yourdomain.com and users logged-in at login.yourdomain.com. Those are different silos.

How to scale each part and why do people have problems in the first place?

Each tier either has state or not. Web applications are over HTTP, an inherently stateless protocol. So as long as one doesn’t introduce state into the application, the application layer is stateless and “easy” to horizontally scale. However, since one is limited in the number of IP addresses one can use to get to the application, and network latency will have an impact at a point, the “front” has state. Finally, the back-end data stores have state, by definition. We end up with: stateful front (Network) <-> stateless middle <-> stateful back. So our options for scaling would be: Load Balancers/Application Switches/Networking (Vertical) <-> Cache (Horizontal or Vertical) <-> Application (Horizontal) <-> Cache (Horizontal or Vertical) <-> Data (Vertical).

The limit to horizontal scale is the network and its latency. For example, you can horizontally scale out multi-master MySQL nodes (with a small and consistent dataset), but you’ll reach a point (somewhere in the 10-20 node range on a gigabit network) where latency now significantly impacts replication time around that ring.

Developing and scaling a “web” application means that you (or someone) has to deal with networking and data management (and different types of data for that matter) if you want to be cost-effective and scalable.

The approach one takes through this stack matters: platform directions

With the view above you can see the different approaches one can take to provide a platform. Amazon started with data stores, made them accessible via APIs, offered an accessible batch compute service on top of those data stores, introduced some predictability into the compute service (by offering some normal persistence), and has yet to deal with load-balancing and traffic-direction as a service. Basically they started with the back and should be working their way to the front.

At Joyent, we had different customers, customers making the choice between staying with their own hardware, or running on Joyent Accelerators. We started with the front (great networking, application switching), persistence, we let people keep their normal backends (and made them fast) and we are working for better solutions (horizontal) for data stores. Solving data storage needs weren’t as pressing because many were already wedded to a solution like MySQL or Oracle. An example of solving problems at the outermost edge of the network would be the article, The wonders of fbref and irules serving pages from Facebook’s cache. This is an example of programming in application switches to offload 5 pages responsible for 80% of an application’s traffic.

Joyent product progression is the opposite of AWS’s. We solved load-based scale with a platform that starts with great networking, well performing Accelerators, Accelerators that are more focused to do particular tasks (e.g. a MySQL cluster). We are working on data distribution for geographic scale, and making it all easier to use and more transparent (solve the final “scale”, administrative scale).

The technology stack of choice does matter: platform technology choices

Joyent Accelerators are uniquely built on the three pillars of Solaris: ZFS, DTrace and Zones. This trio is currently only present in OpenSolaris. What you put on metal is your core “operating system”. Period. Even if you call it a hypervisor, it’s basically an OS that’s running other operating systems. We put a solid kernel on our hardware.

Accelerators are meant to be inherently more performant then a XEN-based EC2 instance per unit of hardware, and to do so within normal ratios: 1 CPU/4GB RAM, utilities available in 1,2,4,8,16,32,64 gb sized chunks. The uniqueness of DTrace adds unparalleled observability, it makes it possible for us to figure out exactly what’s going on in kernel and userland and act upon it for customers in production.

ZFS lets us wrap each accelerator in a portable dataset, and as we’ve stated many times before, it makes any “server” a “storage appliance”.

Add to this Joyent’s use of f5 BigIP load-balancers, Force10 networking fabric, and dual-processor, quad-core, 32GB RAM servers.

Open and portable: platform philosophy

At Joyent, I don’t see us having an interest in running large, monolithic “services” for production applications and services. Things need to remain modular, and breakage in a given part needs to have zero to minimal impact on customers. Production applications shouldn’t use a service like S3 to serve files, they should have access to software with the same functionality and being able to run it on their own set of Accelerators.

We want software that powers services to be open, available, and enable you to run it yourself here on Accelerators, or actually anywhere you want. We develop applications ourselves exactly like you do, we tend to open source them and this is exactly what we would want from a “vendor”. This route also minimizes request (“tick”) pricing. We don’t want to entirely replace people choices in databases, instead Accelerators have to be made to be a powerful, functional base unit for them. Want to run MySQL, PostgreSQL, Oracle, J-EAI/ejabberd, … then by all means do that. No vendor lock-in.

For both platforms, we have our work cut out for us.

Touch a Joyeur: Upcoming Events.

Taco Tuesday (San Francisco, CA): May 27, 2008 – CANCELLED. Sorry, look for us in June.

Tacos. Beer. Good conversation. Need we say more?

———

Google I/O (San Francisco, CA): May 28-29, 2008

Keep an eye out for Jason Hoffman, Blake Burris, Rod Boothby and Kristie Wells.

UPDATE: Jason Hoffman will be speaking on the ‘Building an OpenSocial Application in the cloud” that happens Thursday, May 29th at 10:15am.
———

RailsConf (Portland, OR): May 29-June 1, 2008

Several of the team members will be floating through the halls of the Oregon Convention Center, and we will also be sharing booth space with our buddies over at Sun, so stop by on one of the breaks and say hello. You know there will be some ‘mixers’ as well. More information to follow shortly.

UPDATE: We are hosting a pub night on Thursday (5/29) at the Lucky Lab. Come on by between 6pm-8pm if you need to wet your whistle.

———

Social Media Business School (Los Angeles, CA): June 5, 2008

Rod will be leading as session on Application Hosting Options where folks will learn about the options and economics associated with running your apps in-house versus outsourcing.

———

Enterprise 2.0 (Boston, MA): June 9-12, 2008

Rod will be Breaking Down Cloud Computing and Its Relationship to Enterprise 2.0 on Wednesday, June 11th at 2:15pm.

———

Velocity (Burlingame, CA): June 23-24, 2008

We might be making a showing here, will add more information once available.

———

Social Media Business School (New York, NY): June 25, 2008

Making sure Rod keeps busy, so we have scheduled him to lead another session on Application Hosting Options where folks will learn about the options and economics associated with running your apps in-house versus outsourcing.

———

Structure 08 (San Francisco, CA): June 25, 2008

Blake Burris, David Young and Kristie Wells will be on hand to watch Jason Hoffman participate in a panel around Cloud Computing: Infrastructure for Entrepreneurs. It starts at 9:20am so make sure you get to the conference early if you like to hear the Hof speak.

———

Joyent Developer Days (San Francisco Bay Area, Portland, Los Angeles, Dallas, Chicago, Boston, Philadelphia, and New York City): Dates TBD in July and August

We are working on a series of one-day developer events to be held around the U.S. (to start), that will include seminars and plenty of opportunities to hack on a few things.

The day itself will vary in format from location to location, but the goal is the same: bring the Joyent developer community closer together, provide the tools you need to build a successful web application and meet some fun people in the process.

———

LoneStar Ruby Conference (Austin, TX): September 4-6, 2008

Look for Blake Burris roaming the halls…

Joyent Pint Night (at RailsConf2008).

We are hosting a pub night on Thursday (5/29) at the Lucky Lab.

Come on by anytime between 6pm-8pm if you need to wet your whistle.

And if you sweet talk David or Jason, they might just do it again on Friday. And Saturday.

Joyent Official Sponsor of the Django Dash Competiton.

Django Dash is a chance for Django enthusiasts to flex their coding skills a little and produce a killer application within 48 hours. Of course, they want you to have a little fun in the process.

We here at Joyent loves ‘the Django’, and are happy to support the competition that officially kicks off this Saturday, May 31st. We will be awarding the winning teams with a shiny new Accelerator so they have somewhere snazzy to put that winning application once the contest is over.

Keep a watch over at the contest site, and we can’t wait to see what the teams are able to kick out in such a short amount of time.

Good luck!

Things I'll Need in iPhone 2.0. Or, the iPhone Review That's Nearly One Year Old.

I stood in line at an AT&T store last summer the day the iPhone first became publicly available. I thought the local Apple store would be mobbed. Four hours later the AT&T store was out of phones. With not much hope, I drove to the Apple store. Within 15 minutes I was inside buying two iPhones. So my relationship with the iPhone started out well, on balance. But I kept on using other phones on the side.

The virtual keyboard of the iPhone has been the cause of many near automobile collisions. Don’t believe in guardian angels? OK, but I don’t think I’m that lucky. I don’t have the fingers and toes to count the number of times I’ve been accelerating into the car or truck in front of me when I look up from http://m.twitter.com or Mail just in time to stomp on the brake. Honestly, I’m not that stupid to be trying to do actual work while driving. But I would like to check voicemail without unlocking the phone > touch phone icon > touch voicemail icon > grok the visual in visual voicemail (i.e. who called, and who do I want to listen to?) > touch the voicemail. And that’s about the time when I’m startled into an emergency braking procedure. Not to mention typing emails. Some at Joyent claim to be just as proficient on the touch keyboard as, say, a Blackberry Curve (one of the phones I kept using this past year). Has this claim been tested? Your mileage may vary, sure, but would any of us want to put up with this on a laptop keyboard? Touch to me implies physical. Gesture, now that’s where the iPhone excels. I say all this, but will also admit, in the end, I left the Curve. I really didn’t want to carry two devices. And Grandcentral SMS messages for voicemail reduced the number of touches required for voicemail.

While we’re on the subject of tactile interfaces, can we talk about the simple issue of object selection? I’m not Andre the Giant, but I find myself repeatedly frustrated trying to pick out the right item in a list on the iPhone. I want to call Mary, but I dial Mark. End Call. Try again. Dialing Marla. End Call. The Blackberry is brilliant for the little wheel that allows one to whiz through a list then press to select. There are up/down buttons on the iPhone that only seem to control sound volume. When I’m in a list, couldn’t those buttons be used to navigate?

It would be nice to have a bluetooth phone that does more than just wireless headsets. This was a shock to me last summer. That’s all for bluetooth? So, I was carrying around a Verizon EV-DO card for a while this past year, then saw the Nokia N95. I dumped the EV-DO card. The N95 is nearly perfect. Except for the operating system and the awful web browsing experience. But there was QIK and the 5 megapixel camera that would be great if photos didn’t take 5 seconds to click. That’s right. The take a picture workflow is: “OK, let’s take a picture. Smile! 5. 4. 3. 2. 1. Snap.” Doesn’t work with kids. But the N95 just works as a 3G modem practically out-of-the-box with my MacBook Pro. And there’s bluetooth synching for contacts, photos, music, calendar. I’ve become a fan of the slider form-factor of the N95, too. The N95 sits behind my Grandcentral account, too. That allows me to choose which phone to roll with. However, practically speaking, it’s almost always the iPhone. Unless I need GPS turn-by-turn. The N95 does that, too. And internet radio (remember: 3G). And Skype. And I could turn my phone into a wi-fi access point.

I abandoned the iPhone as an iPod within a week after purchase. The recessed plug was bone-headed design (if we can call it design). Is it just me or does “iPhone compatible” mean “works if nothing moves”? For this reason, the current iPod Nano is a better iPod for my needs than the iPhone.

The iPhone is the best mobile web browsing experience bar none. Nothing comes close. I’ve used Mobile Firefox on a Nokia N810 (another dalliance this past year) and it’s not close. Maybe it’s not the rendering that’s the problem so much as the absence of the incredible pinch gesture on the iPhone. Pinch and Flick are the killer apps on the iPhone.

Speaking of apps, I recently jailbroke my iPhone using ZiPhone. The experience has been great. I am sceptical about Apple’s plan to drive all application installs for the upcoming iPhone 2 through the iTunes music store. We’ll see how that works out. I’m sure we’ll see some great applications.

Do we have to wait in line for iPhone 2?

SysAdmin Job at Free Software Foundation.

Our friends at the Free Software Foundation are looking to hire a
systems administrator and Python developer. If you’re a GNU/Linux
systems administrator keen to work for the organization that sponsors
the GNU project, publishes the GPL, and fights for software freedom,
take a look at the job.

More information can be found here.

Joyent Presents Application Hosting Options at Upcoming Social Media Business Schools.

SocialMedia Networks is hosting several one day conferences, focusing on passing on real information about what’s going on with social platforms for advertisers and developers.

The next one will be held in Los Angeles on June 5th and will feature deep talks on analytics, marketing, brand advertising, performance advertising, and business planning. The conference will leave you with a real sense of the latest information on how the platforms work and techniques for success.

Joyent will be on hand to lead a session on Application Hosting Options where folks will learn about the options and economics associated with running your apps in-house versus outsourcing.

If you are developing applications for Facebook, OpenSocial, etc – this is a must attend event. Tickets are now available and we hope to see you there!

There will be Business Schools in Seattle, New York City and London as well coming in June. Check the SocialMedia Networks website for more details.

Plurk.

I just signed up for Plurk. Proves there’s still room for innovation in the SMS-sized multicast messaging arena. It’s a mashup of Facebook and Twitter with the different concepts of Friends (a la Facebook) and Fans (a la Twitter). There’s the idea of “Karma” which you get from your own and your friends’ activity on the service. This provides Plurk the virality of a Facebook application. Nice. Now they need to make it easy to suck from Friends and Fans from FriendFeed, Twitter, Pownce, etc. etc.

Beat Email Bankruptcy in Three Easy Steps.

Step One: Take a Flight Somewhere

I recommend Southwest with a couple drink coupons. More laptop room, somewhat mentally lubricated. But get on a plane and go somewhere for around two hours. This gives you enough time to order the double-cocktail, lubricate the mind, and work yourself out of bankruptcy. Let’s get started.

Step Two: Open Your Email Client and Sort by “From”

Most of your email bankruptcy is on account of poor email management. You answer email, but you don’t move it out of the inbox. Those 1,276 messages are mostly answered email. Also, you can safely ignore co-workers. Scan and move. Especially if a message is more than a month old. Someone you talk with every day? Move all that mail automatically. Most of your mail falls into this category. With those messages culled, you can focus on “Who is the message from” and answer accordingly.

Step Three: The Mail You Do Answer, Try to Move the Ball Back Into Your Correspondent’s Court

Example:

From: correspondent@gmail.com
To: david@joyent.com
Subject: Agreed, let’s partner
Blah, blah, but what’s the 17th prime number after 3, blah, blah, blah?

This one is going to make you work. Don’t. Here’s your reply:

From: david@joyent.com
To: correspondent@gmail.com
Subject: re: Agreed, let’s partner
Is the 17th prime number the issue? Or the millions we’re going to make? FTW.

Optional Fourth Step

To: team@joyent.com
From: david@joyent.com
Subject: If you need something
I accidentally deleted all the mail you sent me. If you need something from me, please ask again.

It’s not bankruptcy, friends. It’s leverage.

Joyent Summer Sale.

Now’s a great time to get awesome pricing on Joyent Accelerators during our Summer Sale. Accelerator commits of one or two years are discounted 40%. For example, a typical 1GB Accelerator goes for $125 per month. If you commit to 12 months, you can the same Accelerator for $75 per month. And every Accelerator gets to burst to 95% of the CPU resources of a given machine node in the Joyent cloud.

Click here to get started now.

We have customers doing more than 1 billion page views a month on Joyent Accelerators. Joyent offers you clear and unmatched advantages:

  • Joyent’s compute cloud provides a highly scalable on-demand infrastructure for running Web sites, including rich Web applications written in Ruby on Rails, PHP, Python and Java.
  • Joyent Accelerators are built on OpenSolaris, multi-core (8+), RAM-rich servers (32GB+ each) and vast amounts of storage.
  • Joyent Accelerators are deployed in the best routing and switching fabric (Force 10) and the best load-balancers (F5 Networks) available.
  • Joyent Accelerators are next-generation virtual computers that can grow and multiply (or shrink and consolidate) – that means you’re not locked into inflexible contracts.

Convinced? Sign up is fast.

Still need some more details? Shoot us an email at support@joyent.com to set up a consultation.

1 Billion Page Views a Month.

Here’s a video detailing how LinkedIn built an application (Bumpersticker on the Facebook platform) using Rails (and C Ruby!) that serves up more than 1 billion page views a month.

In my opinion, this ends the debate about whether Rails scales. Rails is a component, it is how the components are architected and delivered that comprises the magic. LinkedIn did amazing work taking advantage of Joyent’s technology stack including innovative ways of leveraging Joyent Accelerators and our BigIP load balancers.

Congratulations to the LinkedIn team. Great accomplishment! You can read more about the how LinkedIn scaled bumpersticker on Joyent in a post on their blog entitled Web Scalability Practices: Bumper Sticker on Rails

View the video.

Update: ZDNet writes about the story.

A Loving Cloud.

Yesterday several members of Joyent’s team attended Structure ’08. Jason Hoffman was on a panel that produced some interesting debate about whether clouds should aim to be open. The story was even picked up by the Wall Street Journal’s Don Clark in an article entitled Finding A Friendly Cloud

Jason Hoffman, founder and chief technology officer of a cloud-computing specialist called Joyent, was particularly pointed in warning that Google’s App Engine could represent a lock-in to developers. It is possible to build “a loving cloud,” he argued, that would make it easier to create applications that could be easily moved among different services. Other panelists kept calling Google’s App Engine “proprietary,” which to many techies is equivalent to labeling it both evil and outdated at the same time.

Here’s video of the exchange Jason had with Google’s Christophe Bisciglia

Joyent is Hiring.

We are excited to be opening a development office in Seattle, WA next month. If you are a world class web applications developer in the Seattle area and would like to work on some disruptive cloud computing technologies, please send a note to jobs [at] joyent [dot] com. In your note give a sense of your past, your present, and your future as a developer. Tell us what you would like to see from a cloud computer as a developer. If we like what we see, we’ll reach out to you. No recruiters, thanks.

iPhone 3G Review.

The touch display of my iPhone EDGE stopped working a couple of weeks before the launch of the iPhone 3G, and, who am I kidding, I was going to get one anyway, so I stood in line three times July 11. By 8PM I had the iPhone 3G 16GB (black) and was on my way.

I composed a list of things I was hoping to see remedied in the iPhone 3G back in May. The touch interface continues to annoy, but I’ve jumped into learning how to type on the virtual keyboard and I’m getting the hang of it. But it does take time.

The iPhone 3G still does not serve as a modem either wired or via bluetooth (yes, I’m aware of NetShare). But who cares, one discovers, with the iPhone 3G, that 3G isn’t a feature. The 3G reception is awful. I’m sitting here with one to two bars on the iPhone 3G is 3G mode. My Nokia N95 has 5 3G bars. And the iPhone 3G consistenly drops calls when flitting between 3G mode and EDGE mode. The 3G is not reliable. So I don’t use it.

Let’s talk battery. Maybe the awful 3G reception on the iPhone 3G is why the battery life sucks. This is the worst device I’ve every owned when it comes to battery life. With normal use, the battery of the iPhone 3G needs to be charged twice a day. What’s normal use? Just talking, playing a bit of Dizzy Bee. Nothing dramatic. I’m not using the 3G network, for goodness sakes. My iPhone EDGE needed a charge every day and a half. If I turn off the 3G and only use EDGE (therefore rendering the phone the iPhone ersatz 3G), the battery life still sucks. I’m using the word “suck” on purpose. You can almost watch the battery drain in real time.

I have seen people claim that 3G phones have awful battery life in general. Anecdotally, I can’t see how this makes any sense. I’ve turned off the 3G and it doesn’t seem to improve battery life. Besides, my Nokia N95 is in 3G mode all the time and lasts for two days on a single charge. Yes, your mileage may vary.

Synching the iPhone 3G with my Macintosh can sometimes take 45+ minutes. Most of the time seems to be in “backing up”.

The App Store is great. I don’t know why I bought the “Slots” game, but there are a number of very nice applications. I recommend:

Apple has done a great job helping to keep applications up-to-date on the phone. However, whenever I update applications, the arrangement and order of the icons on the iPhone 3G is changed.

The iPhone is a great platform. The iPhone 3G remains the phone in my pocket because of the browser and now the applications. SMS is excellent. But the phone functionality, well, to misquote Mr. Jobs out of context “[should] not have been delayed without consequence”. Can the modem functionality, the bad 3G, the battery life be fixed in software. I hope so.

Apple's MobileMe and Joyent's Connector.

When we open sourced Joyent Connector last year, one thing we hoped to see was the beginning of some usability standards for web applications. Application design is not page design.

So, with that said, when I saw the design of Apple’s new MobileMe service, I smiled:

And here is Joyent’s Connector:

Nice. This is not a rip-off. It is rationality. Pure text-based interfaces must be “read” every time:

EC3: Enterprise Class Cloud Computing.

Yesterday I talked with the head of Enterprise Architecture for a Fortune 500 company. Late last week, it was the VP of Operations for a Fortune 100 company. And, every day, I talk with many CTOs from Web 2.0 style start-ups. They are all interested in Cloud Computing.

What is new is the number of “traditional” companies that are starting to take a serious look at Joyent Cloud Computing .

The attention around Cloud Computing

Why are all these new types of companies reaching out to Joyent? I think some of it has to do with people hearing about how companies like LinkedIn have scaled applications up to a Billion page views a month on us. A lot of the interest also comes from articles like these:

3 Patterns of Enterprise Adoption of the Cloud

At Joyent, we are seeing three patterns for enterprise adoption of cloud computing.

  1. Approx. 65% of our large enterprise clients are Light Engineering Development Teams that jumped at the chance to quickly deploy new solutions on Joyent’s cloud. These L.E.D. teams are turning to Joyent for two reasons. First, they do not have to go through the process of getting approval to run an experimental application inside a legacy data center. Getting that approval from a large company IT organization is especially difficult when the legacy data center also runs things like the company’s general ledger and email system. Second, the L.E.D. teams often tell us that Joyent is significantly cheaper than the internal transfer costs they would be charged by their own IT departments.
  2. Approx. 20% of our large enterprise clients are brought to us by top tier outsourced development shops such as SolutionSet. Large enterprise users hire SolutionSet to build them everything from marketing / brochure sites to Facebook applications to core e-commerce sites. Depending on their clients’ needs, and especially in instances where their clients require flexibility, SolutionSet might end up recommending Joyent.
  3. Approx. 15% of our large enterprise clients come to us directly through the office of the CIO / CTO. The interesting thing here is that 1 year ago, this percentage was much smaller.

Now, it is growing, and it is growing quickly. CIOs and CTOs are turning to Joyent Cloud Computing because they realize that they have the same problem we do. They realize that they have multiple internal tenants who all require flexible malleable infrastructure.

Addressing the Issues that CIOs have with Cloud Computing

A lot of the discussion around enterprise adoption of cloud computing misses the real issues that we typically discuss with clients before they decide to use Joyent’s cloud.

  • Security questions are easily addressed Generally, while our clients ask about security issues, we typically find it easy to allay their fears. An enterprise-class cloud like Joyent does not force people into monolithic centralized storage solutions. No shared database means much less risk. Beyond that, Joyent takes a unique approach to virtualization. Fundamentally, we use the same Solaris kernel that banks, insurance companies and health care providers have used and trusted for years. Amazon’s EC2, for example, relies on a completely different “hypervisor” technology based on XEN. In Amazon’s approach, each time you bring up an EC2 instance, you get a new IP address. While you can map a static IP address back to the EC2 instance, you still fundamentally have a server behind the scenes that has a random new IP address. With Joyent’s approach, each time you bring your Joyent Accelerator back up, you get the same static IP address. From a security point of view, this means that Joyent can lock down access to these specific IP addresses via a Tagged VLAN that is defined and controlled in our Force 10 routers. That means that on Joyent, when our clients are concerned about security, we can set it up so that Client A can’t even see the IP addresses associated with Client B. Beyond this, Joyent can provide enterprise clients with all the other security features of Solaris. Because they get full root access, and because they know how to lock down their own systems, Joyent clients can be just as secure as if they were running their own data centers.
  • CIOs don’t want to have to re-write apps when they move to the cloud Google App Engine, for example requires that you completely rewrite large sections of your code before you can run on them. When CIOs talk to us about using Joyent’s cloud for a new or existing application, they always ask if they are going to have to rewrite any of their code. The answer is always “no problem”. If it is a JAVA, PHP, Python, Ruby, Ruby on Rails or Erlang application, it can run on Joyent straight out of the box. CIOs often tell us that they like knowing that they can leave Joyent if they want to. If you don’t have to re-write your app to move onto Joyent, you don’t have to re-write your app to move off. So one major advantage of our approach is that it reduces the risk of adopting a cloud solution.
  • CIOs are concerned about operational management overhead Whole companies, such as RightScale, have sprung up to try and help users deal with the complexity of running ethereal virtualized servers on Amazon’s EC2. For example, Amazon forces you through a range of complex steps when an instance needs to be rebooted. These steps include emapping IP addresses and drives back to failed AMIs, porting data back from S3. These “extra” operational hurdles simply do not exist at Joyent. Cloud computing promises flexibility, but it shouldn’t force enterprise users into an expensive tradeoff where they have to deal with additional operational costs simply to gain that flexibility.

Enterprise Class Cloud Computing has already begun

There definitely are issues around enterprise adoption of cloud computing. However, it is important to understand that not all cloud computing vendors are the same. When people concern about enterprise use of cloud computing, they often point to down time experienced by large monolithic systems like S3. While it is reasonable to express concern about large monolithic systems, not all clouds work like that.

Large enterprises are starting to adopt Joyent cloud computing. And so far, it looks like we have been able to achieve our goal of delivering a cloud that is addresses the needs and concerns of both small developers and large enterprise CIOs.

Going forward, we still expect a large percentage of our growth to come from small developers who hit it big. Hopefully these smaller teams will be happy to know that if and when their system becomes the next big thing, our growing experience with large enterprise users means that we will be ready to support them.

       Click here to see the XML version of this information.
8/27/2008; 9:53:45 PM Eastern.
Refresh.