The Technology behind Codenvy. An Interview with Tyler Jewell, CEO

Posted by Abel Avram on Jul 07, 2013 |

Along with Eclipse Orion, Cloud9 and others, Codenvy is one example of the new breed of IDEs that attempt to transform the way developers create software by offering a front-end interface running in any major browser and a back-end running on a server or in the cloud, doing all the heavy lifting – compilation, code analysis, building, staging, deploying, etc.

Codenvy can be used to develop online in a number of languages - Java, JavaScript, HTML5, CSS, PHP, Python, Ruby, XML – but work is underway to add support for more and to provide the community the necessary tools to add more languages as desired. The same goes for frameworks, Codenvy currently supporting Spring, Node.js, JSP, Rails, GWT and Django. Support for Android development was announced at Google I/O 2013.

The applications can be deployed from within the IDE to several PaaS: Amazon (Elastic Beanstack), CloudBees, Cloud Foundry, GAE, Heroku, OpenShift, AppFog, and Tier 3.

When it comes to code repositories, Codenvy initially supported GitHub and Bitbucket, the later providing Git and Mercurial repos, but has recently added support for Assembla, Beanstalk, Codebase, Deveo, GitEnterprise, Gitorious, PikaCode, ProjectLocker, and Unfuddle. It uses Jenkins, Hudson, or CloudBees for continuous integration.

Codenvy includes support for pair programming having incorporated real-time multi-cursor collaboration capability. The code editor has syntax highlighting, code completion and refactoring.

We have interviewed Tyler Jewell, CEO of Codenvy, in order to find out more details about the technologies powering this IDE.

InfoQ: What is Codenvy built with? What are the technologies behind it, server and client side?

TJ: Codenvy is a cloud system with multiple nodes to handle routing, load balancing, identity management, IDEs, builders, runners, and analytics.  The core IDE itself is authored in Java, using GWT to generate optimized client-side JavaScript.  We use WebSockets for most communications between the browser and the server.  Other technologies used extensively throughout the system include Apache Web Services, CloudFoundry, Gluster, CodeMirror, Collide (collaborative editor), Hadoop, and Apache Pig.  The core of Codenvy is a platform for building cloud IDEs.  Internally, we ship a runtime framework that manages the discovery, loading, coordination and activation of layered extensions.  Extensions are authored as packaged plug-ins that provide language, framework, editor, file management, builder instructions, and runner instructions.  We then create an IDE framework that links together plug-ins, and deploys onto a cloud framework that provides tenancy, elasticity, logging, identity management, and isolation controls.   We built our own multi-tenancy IP that lets us run up to 250 IDEs in a single JVM, while also preventing the IDEs from having any block conditions while executing build and runner processes.  We have built our own extensions to OAuth to allow for inbound authentication requests and to also propagate identities outward to clouds downstream to simplify user workflows.  We use puppet and a variety of bash scripting to handle devops related issues.  Our Web site, which is considered a product on a lifecycle independent of our cloud, is authored using JavaScript, Yeoman, Grunt, and Jekyll.  For tooling, we use GitHub, Jira, Confluence, and Selenium significantly.  The original bits of Codenvy were authored using Eclipse and IntelliJ, but now most of Codenvy is getting authored using Codenvy.  

We use over 100 open source libraries to create the various elements that run Codenvy today.  

InfoQ: Where do you run Codenvy? On your own servers? In a cloud? Which one?

TJ: We run different environments for development (acceptance test), staging (full environmental test), pre-production (finalized releases to allow for marketing, support, and docs to engage), and production.   We operate production at AWS.   Pre-production runs on top of Eucalyptus within our own datacenter that is located in Europe.  We run our staging environment at AWS to allow for devops configuration, testing a variety of cloud APIs not accessible internally, and to execute large scale tests.  Our development acceptance server environments are all single server packaging of Codenvy that can operate in 1-2 VMs depending upon the configuration.  We use our development environments (we run up to 6 simultaneously) to drive acceptance criteria from PM and users on individual features.  Acceptance servers house individual features during a sprint and operate within our own datacenter.  After a sprint completes, staging and pre-production are updated through automated Puppet procedures.  

InfoQ: Do you plan on supporting other languages? Which ones?

TJ: As far as I am concerned, you can never have too many languages supported.  There are really two vectors to pursue here: entirely new languages that require specialized build and runtimes to execute, and languages that can run in VMs like those that can operate within a JVM.  We believe that there are too many environments for our team to support entirely ourselves, so we are moving to get the community involved.  We have been working on finalizing the SDK we use internally to publish to the public for use to create their own extensions and plug-ins.  It'll be similar to how the Eclipse plug-in architecture works, only a bit broader.  Inside of Codenvy is a full build subsystem and a runner environment operating Cloud Foundry.  So, a developer who wanted to add a new language, such as C, to the system would need to add the usual IDE parts (file, syntax, debugger, refactoring, macros), but would also need to give Codenvy instructions on how to execute the build system (make) and the runtime.

Our first priority is to ship this SDK, which will be this year, and then our second priority will be to organize the community around ownership of varying frameworks and languages.  We have outside interest from people wanting to help with C, C++, Objective C, Go, Scala, Play, and so on.

InfoQ: How about framework/PaaS/CI support?

TJ: We (attempt) try and add in something new with each sprint.  We operate in two week sprints, so this list is always changing.  We became popular early on because we had a broad set of integrations, and do not see us slowing down in this regard.  The latest list is broadcast here and here.  We are proud about the level of depth that we provide for GitHub, Bitbucket, AWS, Google App Engine, Heroku, Cloud Foundry, OpenShift, CloudBees, Tier 3 and AppFog.   We also just completed a certification of 10 or so git providers, so we'll be updating all of our specifications and how-tos on how to work with various vendors.

As for CI support, today we enable post-commit hooks, and the ability to make Web service calls to CI providers directly.

InfoQ: What does the SDK provide? I understand a developer could add support for his own language or platform with it. And when are you releasing the SDK?

TJ: The SDK provides an API for writing layered extensions; an API that separates the UI, data (files), and event model into separate concerns; API documentation; a set of example plug-ins such as what we have created for Java; and a specialized SDK cloud that will allow developers to upload plug-ins for testing.  Plug-ins themselves will be authored in Java and GWT.  GWT takes 11 minutes to compile unless it operates in dev-mode.  We are going to port GWT to have a dev mode for Codenvy, but initially to simplify the creation process we'll have developers upload their plug-ins into a Codenvy partner cloud where we will compile, package, and integrate into our runtimes.

The initial release of this SDK cloud will happen this summer.  We have signed up quite a few ISV partners that are waiting for it, so it's our top priority internally.

After our initial ship, we will then create a WAR file packaging of Codenvy.  Developers will be able to run a single server version of Codenvy in Tomcat along with being able to build and deploy plug-ins locally.  This version is a bit tricky as it will have everything but our runner support.  Since we use Cloud Foundry to execute our runners, there is no simple way to package in a runner into the single server format.  We'll allow developers to map their "cloud runners" executing in Tomcat to processes on their localhost system.  So executing "Run" in your browser running on localhost, will trigger a process command that you specify also running on the same machine.

InfoQ: Does Codenvy work offline? If not, what are your plans about it?

TJ: We do not operate offline.  We believe that this topic is a red herring in some ways.  It's the #4 or #5 requested feature we get on UserVoice, but when we ask developers why they need it, their answers vary widely.  On one end of the spectrum there are those that are worried about plane travel, where they are completely offline.  Others have just general concerns about partial connectivity and wonder what would happen.  In many cases not having this capability isn't seen as a deal breaker, but it does seem like a topic that is a very natural one to inquire about.

Part of providing offline support is determine what is offline.  We could easily provide a file editor, but there wouldn't be any support for git commands, build, debug, run or deploy.  So, at the most basic level, it seems to make sense to allow developers to have a read-only mode initially when they are offline.  This is fairly easy to provide in the future.  And then beyond that, there would be varying levels of offline capability depending upon how much technology you either can, or are willing to allow installed on the client side.  If it's entirely a browser-based system we can synchronize the git repository and offer editing functions.  If we are allowed to install software onto the desktop, then we could create a completely synchronized build and runner locally as well.

We are still evaluating what we want to do here, and want to talk to our community more about it.

InfoQ: Could you provide details on Codenvy’s integration with JRebel, Rally Dev, and Tasktop?

TJ: We provide JRebel to appropriate Java projects.  We set up a single, permanent runner and then activate JRebel between the builder and runner clusters.  

We will be talking more about what we are doing for Rally and TaskTop towards the end of this year.

InfoQ: Currently only the Community edition is available. When are you planning to open the other pricing plans already announced?

TJ: Actually, we do have some of our Premium services available for sale now!  Today, we offer an Early Adopter Program that offers a 66% discount off of the Personal tier.  This price will steadily increase as the year unfolds and we become more confident and complete with the premium features that we are shipping in each release.

InfoQ: What’s included in the Enterprise edition?

TJ: Codenvy Enterprise is a cloud that can be installed behind the firewall to manage large populations of developers.  The customers that have adopted this so far are those with regulatory, compliance, security, or offshore management needs.  We ship all of the features that are available in our public cloud, but also add in some special capabilities: a) LDAP & identity integration, b) Clustering, load balancing, and HA policy control, and c) Analytics & reporting to measure acquisition, engagement, and virality of developers, workspaces, and projects.  Today, customers provide their own hardware and can run on Tier3, AWS, Eucalyptus, or OpenStack.

Interestingly, a lot of the early adopters of Codenvy Enterprise do not see it as a displacement for Eclipse.  Rather, it's an auxiliary system.  In many cases, we'll displace slow running VDI or TS environments for offshore developers.  In other cases, we are becoming the training ground for new hires, interns, or partners where it's more important to spend time coding in a limited window vs. taking the time to teach people how to configure a development environment.  In auxiliary use cases, developers can still promote themselves off of the cloud, but they take individual responsibility for managing their desktop and IT takes responsibility for managing Codenvy.

InfoQ: What plans do you have for the future?

TJ: We are fortunate to have about 30 engineers on our development team.  They are phenomenal systems engineers and have a history of building large, complex systems.  I think much of this thinking is what drives their efforts, so a lot of the projects that are being developed are designed to help automate complex workflows for developers.  Our efforts are broken into various categories:

1) Supporting Developers.  More languages, frameworks, cloud integrations, and other cloud services.  I'd like to have 250 technologies integrated into Codenvy by the end of the year.  Also, we have publicly committed to adding Android and iOS development through partnerships with Trigger.IO and Google.  

2) Supporting ISVs.  We are going to deliver in Q3 a variety of ISV packages that allow them to customize templates, promote sample applications, and onboard/measure/track developer activity.  We eventually want to allow every ISV to have a customized, on-demand IDE that is configured online.  This, in many ways, is combined with their SDK efforts.

3) Supporting Enterprises.  We are pursuing more POCs and installations in large enterprises.  We have done a few big ones now - but want to do another 25 or so before we declare Codenvy Enterprise GA.  If there are any organizations interested in running their own development cloud, we would love to hear from them.

About the Interviewee

Tyler Jewell is CEO of Codenvy and a venture partner with Toba Capital where he focuses on middleware and application development investments. He sits on the board of WSO2, Exo Platform and Codenvy along with making investments in Cloudant, ZeroTurnaround, InfoQ, and AppHarbor.



Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Why GWT? by Ralph Prescott

An interesting follow on article might be why GWT was chosen to implement the IDE.

Re: Why GWT? by Tyler Jewell

Abel has invited us to do a white paper on our architecture, and we have agreed to write that. We will probably publish it in a couple months, as he wanted us to do a deep dive on various subsystems.

But the reason on GWT was a few points:
1) Our engineering staff of 30 has an avg of 10 years Java experience, so the affinity was desirable.
2) The JS rendered from GWT showed impressive responsiveness and optimizations that we wanted to maintain.
3) There are certain benefits to enabling plug-in development with 3rd parties vs. using a pure JavaScript approach. We can enable ISVs to create plug-ins in the future that get packaged & installed & compiled & verified similar to how Eclipse / IntelliJ handles it, and this is a bit easier with a Java / classloader approach vs. a pure JavaScript approach.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Editorial and all content copyright © 2006-2013 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy