I have read the article and this thread with keen interest. I am curious to solicit community feedback on our choices as we faced the Node vs. Java choice in 2012. In particular, does our business ultimately suffer long term consequences by our stack choice? We think we ultimately have strong advantages vs. any competitor built using Node.JS, but the beauty of HN is that we can open up the thoughts for everyone to contribute.
I am the CEO and founder of Codenvy. We make SAAS developer environments, and have been working as a team since 2009. Starting in 2012, we recognized the limitations of our initial system and needed to rebuild the entire system from the ground up. We had three criteria: performance, security, and modularity (of our core base and an ability for ISVs / enterprise to plug-in their own customizations). We raised $9M in Jan 2013, so we now have big investors and aspirations equally large. Our target market is primarily enterprises and ISVs that build Eclipse plug-ins. Individual developers and consultants are a secondary audience.
We chose to go with a pure Java stack, after a careful evaluation of Node.JS vs. Java. We wanted to provide some of our thoughts, as we continually ask ourselves whether there are downsides to the approach we chose. For the record, we have competitors like Eclipse Orion and Cloud9 that are pure JavaScript / Node implementations, but we are - as far as I have seen - the only Java implementation in our market.
Our team is currently 40 people, with 35 or so in R&D. Our engineers have experience with Java, Scala, JavaScript, AngularJS. Prior to this project, most engineers were working on server systems for content and document management firms. The hard stuff: sync, versioning, correlation, and so on. As for myself, my career started as a Java engineer in the 90s, but for the most part have been hands off as a technologist for a decade. My skills may have faded, but as a CEO, I am conversant.
We did 2 prototypes on Node.JS where the client and server were combined systems. We ran a battery of performance tests and did conclude that we could probably run a large scale system on fewer physical nodes with Node.JS than with Java, but the gains were not enough to justify the choice.
Our long term architecture was different from our competitors. Most SAAS dev environments provision each user / group their own VM, give you root access, and let you control that system. We chose an approach that would optimize overall system density by by offloading builds, debugs, and editing onto separate clusters. User environments will be virtualized and routed to the appropriate cluster on-demand. The user will feel like they have a personal VM, but our elvish helpers route traffic between the nodes across performance queues.
After offloading LDAP (for identity), event / log management (for analytics), and cloud administration, the only core systems left was our API services (account / builder / runner / auth) and editing. These core systems would be subject to heavy iterative development, and Node's architecture could offer higher density of requests / users than Java, but by our tests the comparison was 10-20% difference, not 300%.
By way of scaling, for every 10,000 concurrent developers, we average 20 editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5 builder nodes (CPU constrained). A similar TS / VDI implementation would require nearly 5,000 nodes of the same shape / size to service the same population.
So, we saw a disadvantage to Java as we could have reduced our editing node even further. But we chose Java because:
a) The library selection. Broad and mature. In particular, it's data structures, file management, REST services.
b) GWT. This library gave us cross-browser portability of code written in Java.
c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in developers and saw the Orion project as optimized for Web dev, leaving a gap in Eclipse. We saw it as a business gamble that Eclipse devs who needed to move their plug-ins would find a pure Java plug-in architecture that was similar to RCP more attractive than a newer (but have to learn new tech & rewrite) approach.
d) Our history. We did a straw poll of our engineers before we started. We asked them if they felt that they would rather do Node or Java, and 75% said that they would enjoy Java more. When asked why? They had tool familiarity, were confident in the maturity of maven, and better job prospects. This last one completely surprised me.
e) JVM. The number of optimizations of the JVM would give us advantages for enterprise deployment. We built our system to be automatically installable on-premises. We do so with Puppet, but recognized that we would be encountering many IAAS and PAAS standards internally. Enterprises had security and performance tested the JVM, so we saw an opportunity to win hearts and minds of system admins, datacenter architects, and security specialists by our choice of architecture.
So, we carried forward. Since we started working on our next generation architecture, we have focused hard on the best practices associated with agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each focused on a different aspect of our stack. We are able to release any Jira issue at any point in the day. Each team can push into acceptance, staging or production without coordinating with the other teams. At the same time, we have achieved modularity and a rapid development tempo. While we haven't released our new system to the market yet, we find that the performance of the environment is similar to a desktop environment, and it scales cleanly with simulated load tests. We have also been able to give out our SDK (github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse plug-in developers, who are able to code, build, test, integrate, and publish their plug-ins without complicated dependencies to our core team. Their feedback was that the port of their plug-in took about 1/2 the time of the original development. And there is no real way to estimate what the effort would be to do the same in a Node-based offering like Orion.
What we can't measure is whether our competitors are able to release faster & more functionality than we are. It seems like a crap shoot. One other variable we can't account for is the cost to maintain legacy. The system we have Codenvy.com is legacy for us, and will be retired in Q3. We have to continually allocate 3-5 people to work on bugs, special partner projects, or other related items to keep that system live while we also work to roll out the new system. We know this is a drag, and some of our engineers think we may more than double our productivity once we consolidate to a single architecture. I am a bit skeptical at that - but I find that it's unwise to disagree with my engineers. I tend to lose.
So at this point, we feel like we made the right choice. But time will tell - we begin selling our enterprise offering earnestly once we ship our new system in Q2.
I thought CodeBox was using the ACE editor as part of their system like Cloud9. And I believe Orion and Codenvy (my company) use CodeMirror. Looking forward to trying out Atom. I can see many advantages already of it as an editor.
Here is an unusual one. I have followed this similar strategy for the past 4 years on a more aggressive plan, and have returned 36%, 28%, 33%, and 6% for the past four years. The strategy heavily shorts the market, and goes partially long in a way that 99% of the time generates reliable, steady returns, and in the 1% extreme cases offers adjustment techniques to handle what the market is giving you. The aggressive nature of my approach causes the high volatility in the returns, but a much safer approach can be taken which would have nearly a 99.9% assurance of the 5%.
Sell calls and puts on the SPX index on a weekly basis. You need to generate $1K of income each week. On an account that uses Portfolio Margin at a broker like IB, $1M would allow you to open nearly 100 contracts on both the call and put side.
To appropriately manage risk, at the SPX trading at $1840, you could open up 50 calls at $1935 with 1 week to expiration for $.05. This will generate $250 of income as long as the stock market doesn't climb >6% in a single week. This has happened in the past, but only after the market has crashed the day before. 3% climb in a single week on a broad based index would be a once in a generation blue bird event, so the risk on this money is incredibly low. And even if the market did climb up steeply suddenly, there are many options adjustment techniques where you give yourself more time, generate more income, and create additional buffer to stay away from the market.
By selling 50 calls for $.05, you still need to generate $750. You do this by selling puts on the offsetting side. Markets have a tendency to crash downward, so you want to sell far fewer contracts and buy some insurance for the rare case of a market crater situation. You could sell 15 puts at $1730, again 6% below where the market is currently. A 6% drop in a single week is a rather rare event. And to hedge against a flash crash event, you buy $.10 puts at $1515. In the rare event that the market crashed or the market did drop >5% in a single week, then the same sort of adjustment techniques available in the call scenario exist here. There would be a side benefit of while you have to adjust the trades to wait for the profit, the market's volatility would have skyrocketed and the potential to gain more money is really high. Essentially, you could make your $1,000 of income by being 10-15% away from the market with high volatility instead of being 6%.
This technique requires weekly trades to be opened, which is a bear. And you have to learn the adjustment techniques, but once understood and accounted for, things are pretty regular and consistent. There is a side benefit of these options being 1256 contracts in the US, so there is beneficial tax treatment. Even though your trades are 1 week long, 60% of the gains are long term cap gains treatment.
So this isn't entirely low risk, but in all of the scenarios where is a bond / stock mix, there is inherent market risk as well. Even bonds that payout 5% can drop in value, so the principal isn't $1M anymore. So finding a great balance is a lot of work.
Selling strangles on broad indexes is a type of diversification, just of a completely different nature.
I have a fairly involved white paper that I have drafted that outlines the strategy for anyone that wants to review it.
The size of the market in monetary measures depends upon how you define the market itself. If your definition are companies that provide Web-based editors or specifically IDEs with functionality specifically around edit / build / run / deploy, the market is very small today. But if you look at the broader cloud development market that includes code hosting, test, and some other functions that can sometimes be associated with IDEs, then that market is $465M and it's growing rather fast.
The Monaco project form Visual Studio is exciting. We (Codenvy) have tracked nearly 50 web-based editors that have emerged in the past 2 years. A few of them have transitioned into full businesses with venture backing. Most of them have remained side projects or experiments.
With Microsoft's project related to Monaco and their VP's statement in the TechCrunch article that this style of development is where the future is vectoring towards, this is the first major platform vendor that has indicated that they see these sorts of cloud environments as not only as supplemental to core development, but potentially displacements.
Of course, there are years of engineering ahead before cloud systems can offer true displacement, but some of the early adoption scenarios are getting well defined. We attempted to capture the market size and early adoption drivers of cloud browsers in this quora post.
From looking at Codenvy's logs, about 3,000 of our recurring users access the system using a chromebook or tablet. It's only single digit % overall, but it's a number that is larger than we would have thought it would be.
It was a study done by 1200 engineers on LinkedIn and Electric Cloud. I think it was February 2013 when the results came out.
This does have a tendency to happen in various degrees in larger enterprise environments where configuration problems of the IDE and the systems you are building become costly to maintain. The way we think about it is that organizations have invested in DevOps technologies to automate the entire release process post-commit of the code. But that once the changes make their way out into complex staging / production environments, there are config + code changes that do not synchronize cleanly back into the developer's workspace. So, as the number of commits increases, and the size of the team increases, there are many more synchronizations that need to occur to keep development systems ready for the coders.
So the time suck shows up in mysterious ways:
1) Maintenance of the IDE install, especially with Eclipse which has had plug-in versioning & interoperability challenges at times.
2) Synchronizing configurations across teams, commits, and machines.
3) Collaborative / human costs, from the time spent in having large teams figure out the best way to operate & use their development workbenches consistently.
4) The environment problem, which is partly due to the production environment configuration is not exactly identical to what can be run on the desktop, so managing that in an automated way poses time issues.
I am the founder of Codenvy, a type of Web IDE that is more focused on enterprise apps. We have found that the value of cloud workspaces has been around instant access and centralized control (for groups of workspaces). So, it is possible to offer on-demand, temporary workspaces without login (some vendors provide that including Codenvy). It tends to be a vendor choice as to whether requiring authentication before gaining project access is important. Most vendors do require authentication as it allows for saving important properties, user configurations, and some security settings.
To see some of the use cases around why cloud IDEs are used over desktop IDEs, we have listed them on our site. https://codenvy.com/why/cloud-ide/. The early uses have been around scenarios where configuration / setup of desktop are burdensome: pair programming, hackathons, training events, or partner integrations. We have some demos with Google, Intuit, and WSO2 that show what IDE on demand might be like, but those are special case scenarios.
As for the concept of downloading the IDE itself. Some cloud vendors do offer offline mode, and packaged chrome apps which do give that very behavior. It's first inning sort of stuff, but it will be possible in the future to allow offline sync of the development experience. Some cloud providers offer both build / debugger runtimes, so downloading offline, means also having a way to synchronize the project's files, and the underlying infrastructure necessary to execute the code. In a pure Web app sense, where it's HTML / CSS / JavaScript, this is fairly easy. But if you need to have synchronized access to dependencies, libraries, or runtimes, then the challenges are more pronounced.
Yes, good points. There is some missing context. We did contact them, but I failed to point out that the conversation developed over a number of pre-cursor setup calls. And that before there were substantive acquisition talks, there was discussion between the parties on the general areas where each of our businesses were claiming strategic importance along with tacit acknowledgment to generally vector away from those segments. In our case, we provided deeper insights around the specifics of how we intended to pursue our unique strategy after the initial discussion.
With any acquisition or potential partnership with a company that has the potential to compete, whether on the edges or directly, there are unique challenges to figuring out what information you should share and at what time.
But the take away for us was that we had a reasonable expectation that this particular vendor would not behave this way based upon our pre-cursor discussions.
I have a couple of stories that I want to share. One of which has taught me a lesson about being too trusting.
I am both:
1) A venture partner (Toba Capital) where I manage existing investments, do diligence on potential new ones, and make decisions regarding how capital is allocated; and:
2) A founder / CEO (Codenvy), a development cloud with a browser IDE front-end, often times called a cloud IDE.
This article resonates with me as I can see the perspective from both sides of the coin. As a rule, in venture capital, myself and my firm does not sign an NDA. The basic rationale is that it's virtually impossible to resolve all of the potential conflicts that are associated with the NDA from both firms. So, we go with the basic principle is that we need to trust the people we are talking with and vice versa. Our reputations and history of deals / interactions are the best guide and we openly tell people up front that if there is information that is secret for themselves, they should withhold it until they have a chance to do background checks on us. In some cases, there are startups that are so secretive that we cannot infer anything at all, and we just have to politely decline and move forward.
A couple of interesting scenarios playing for me recently. I sit on the board of Sauce Labs, a cloud test company. But my venture firm recently inherited a stake in Smart Bear, a QA vendor where there are edges of competition. While neither vendor sees the other as competitive, the optics of the situation to an outsider could suggest otherwise. So in this case, we have opted to create a chinese firewall inside of Toba where I do not listen in on core data provided by Smart Bear, even though their CEO said this wasn't an issue.
Another scenario that came up recently was a referral to explore a pre-funded startup idea around making database querying easier for non-SQL expects. The referral was a warm one to the founder. We asked for the usual background information to make a surface area assessment. The input given was a very limited sales presentation with a couple screen shots and a few accompany statements from the founder that they presented to a VC and that the VC recited their entire pitch to them. And then that person stated they would only work with people who had their same vision. When probing for more thorough information, the founder became a bit squirrely, which is probably due to some sort of discomfort around sharing stuff. But there wasn't an NDA requested, and we could only conclude that maybe their claims of awesomeness were slightly exaggerated.
Now for the story around trusting too much. With my Codenvy CEO hat on in January we had recently closed our Series A for $9M in January. It was a great feeling as it took us over 6 months of raising to close it. And let me tell you, just because you a valley VC doesn't make it any easier to close your own firm's financing. Post funding we were looking at strategies for how we could grow faster. We came across a likely competitor that had 2 people part of the business and based in Europe that had raised a small amount of seed funding (<$300K). It was obvious to us that there was some great talent in the team and their focus on the market was complementary to our own. We felt that it would cause both companies to grow much faster if we could merge and join forces. They were interested and we all met together to discuss what a game plan might look like. Of course, in that conversation, we shared specifics around how we were envisioning the next 12 months to look like. We made an offer and they opted to pass. No big deal. But where we learned our lesson was that about 5 months later, this summer they released a number of features that were -- somewhat -- reflections of the vision we had shared with them, all the way down to them calling the features the same marketing brands we had ear marked. At the time, we felt foolish and anger around their ethics of the situation, and it was particularly irritating to our own engineers that they were beat in the market. There were many discussions around this, and it raises the question of how you discuss potential plans around an acquisition / investment, if you are afraid they may steal the ideas.
In the end, it's all good as we have learned some stuff:
1) The acquisition would have certainly failed. How could we have worked with people who have thin ethics?
2) We have subsequently released everything they heard from us, and our approach to everything is a) more mature, b) more scalable, c) better received. We learned that while they could take the surface area ideas, they haven't been able to exploit them to their true meaning the way they were intending.
3) Our engineers found a new form of competitive motivation that didn't exist before these - trusted - individuals decided to pawn some of their ideas. The entire culture, motivation and mindset within our (rather large) engineering office has developed into a killer instinct. And as a leader I find this trait as crucial to long term success. I am unsure if this killer instinct would have developed as quickly without this incident.
So, the issues in the article are real, and they show up when you least expect them. I think, going forward, I am just going to keep thinking about being truthful, keep my ethics high, and work with people who are the same. I'll sleep easy at night as a result.
Codenvy is a cloud IDE. We let you code, build, test, deploy and share all in the cloud. We use Factories to create on-demand, customizable workspaces for project types. We have solutions for developers, teams, enterprises, ISVs, and publishers. www.codenvy.com.
Hi: I valued this post. I participated (lightly) at a Hackathon a month ago where the were some monetary prizes offered by sponsors at the end of the event. There were two entries that seemed to have a lot of substance for a single day event, so the question tickled in my brain a bit as to whether there was a way to validate the efforts of the team from start to finish.
We have been wondering about the value of using a cloud IDE (disclaimer, I am CEO of Codenvy) as a type of quarantined project workspace that is managed by a 3rd party for the duration of an event, like a hackathon. The workspace would be structured & owned by the organizer and not the hackers. And this way the organizers could place assets like keys into the workspace, and also monitor what code is authored and / or imported into it throughout the duration.
We'd value the community feedback to see if there is value in such an offering. We may want to hack one up ourselves :)
I am the CEO and founder of Codenvy. We make SAAS developer environments, and have been working as a team since 2009. Starting in 2012, we recognized the limitations of our initial system and needed to rebuild the entire system from the ground up. We had three criteria: performance, security, and modularity (of our core base and an ability for ISVs / enterprise to plug-in their own customizations). We raised $9M in Jan 2013, so we now have big investors and aspirations equally large. Our target market is primarily enterprises and ISVs that build Eclipse plug-ins. Individual developers and consultants are a secondary audience.
We chose to go with a pure Java stack, after a careful evaluation of Node.JS vs. Java. We wanted to provide some of our thoughts, as we continually ask ourselves whether there are downsides to the approach we chose. For the record, we have competitors like Eclipse Orion and Cloud9 that are pure JavaScript / Node implementations, but we are - as far as I have seen - the only Java implementation in our market.
Our team is currently 40 people, with 35 or so in R&D. Our engineers have experience with Java, Scala, JavaScript, AngularJS. Prior to this project, most engineers were working on server systems for content and document management firms. The hard stuff: sync, versioning, correlation, and so on. As for myself, my career started as a Java engineer in the 90s, but for the most part have been hands off as a technologist for a decade. My skills may have faded, but as a CEO, I am conversant.
We did 2 prototypes on Node.JS where the client and server were combined systems. We ran a battery of performance tests and did conclude that we could probably run a large scale system on fewer physical nodes with Node.JS than with Java, but the gains were not enough to justify the choice.
Our long term architecture was different from our competitors. Most SAAS dev environments provision each user / group their own VM, give you root access, and let you control that system. We chose an approach that would optimize overall system density by by offloading builds, debugs, and editing onto separate clusters. User environments will be virtualized and routed to the appropriate cluster on-demand. The user will feel like they have a personal VM, but our elvish helpers route traffic between the nodes across performance queues.
After offloading LDAP (for identity), event / log management (for analytics), and cloud administration, the only core systems left was our API services (account / builder / runner / auth) and editing. These core systems would be subject to heavy iterative development, and Node's architecture could offer higher density of requests / users than Java, but by our tests the comparison was 10-20% difference, not 300%.
By way of scaling, for every 10,000 concurrent developers, we average 20 editing nodes (I/O constrained), 75 debugging nodes (memory constraining), 5 builder nodes (CPU constrained). A similar TS / VDI implementation would require nearly 5,000 nodes of the same shape / size to service the same population.
So, we saw a disadvantage to Java as we could have reduced our editing node even further. But we chose Java because: a) The library selection. Broad and mature. In particular, it's data structures, file management, REST services. b) GWT. This library gave us cross-browser portability of code written in Java. c) Eclipse Plug-Ins. We knew we wanted to target Eclipse plug-in developers and saw the Orion project as optimized for Web dev, leaving a gap in Eclipse. We saw it as a business gamble that Eclipse devs who needed to move their plug-ins would find a pure Java plug-in architecture that was similar to RCP more attractive than a newer (but have to learn new tech & rewrite) approach. d) Our history. We did a straw poll of our engineers before we started. We asked them if they felt that they would rather do Node or Java, and 75% said that they would enjoy Java more. When asked why? They had tool familiarity, were confident in the maturity of maven, and better job prospects. This last one completely surprised me. e) JVM. The number of optimizations of the JVM would give us advantages for enterprise deployment. We built our system to be automatically installable on-premises. We do so with Puppet, but recognized that we would be encountering many IAAS and PAAS standards internally. Enterprises had security and performance tested the JVM, so we saw an opportunity to win hearts and minds of system admins, datacenter architects, and security specialists by our choice of architecture.
So, we carried forward. Since we started working on our next generation architecture, we have focused hard on the best practices associated with agile, devops, and continuous delivery. We have 7 teams of 4-6 people, each focused on a different aspect of our stack. We are able to release any Jira issue at any point in the day. Each team can push into acceptance, staging or production without coordinating with the other teams. At the same time, we have achieved modularity and a rapid development tempo. While we haven't released our new system to the market yet, we find that the performance of the environment is similar to a desktop environment, and it scales cleanly with simulated load tests. We have also been able to give out our SDK (github.com/codenvy/sdk) to 6 different partners, some of which are Eclipse plug-in developers, who are able to code, build, test, integrate, and publish their plug-ins without complicated dependencies to our core team. Their feedback was that the port of their plug-in took about 1/2 the time of the original development. And there is no real way to estimate what the effort would be to do the same in a Node-based offering like Orion.
What we can't measure is whether our competitors are able to release faster & more functionality than we are. It seems like a crap shoot. One other variable we can't account for is the cost to maintain legacy. The system we have Codenvy.com is legacy for us, and will be retired in Q3. We have to continually allocate 3-5 people to work on bugs, special partner projects, or other related items to keep that system live while we also work to roll out the new system. We know this is a drag, and some of our engineers think we may more than double our productivity once we consolidate to a single architecture. I am a bit skeptical at that - but I find that it's unwise to disagree with my engineers. I tend to lose.
So at this point, we feel like we made the right choice. But time will tell - we begin selling our enterprise offering earnestly once we ship our new system in Q2.
Looking forward to the discussion.