ComputeNext started 3 years ago to develop the first open marketplace for cloud computing services. We started by using the technologies we were most familiar with - C# and SQL Server, and our initial architecture and implementation was based on these technologies. Over time, we have progressively introduced more open source elements, including MongoDB, RabbitMQ and Node.js. Now we are at the point where most of our back-end services rely on Node.js. The talk will talk about why we did this, how we did this, and discuss our experiences - both good and bad.

1. Evolution of a Cloud Start-Up:
From C# to Node.js
Steve Jamieson
Lead Developer at ComputeNext
steve@computenext.com

2. Overview
• ComputeNext started 3 years ago to develop the first open
marketplace for cloud computing services.
• We started by using the technologies we were most familiar with -
C# and SQL Server, and our initial architecture and
implementation was based on these technologies.
• Over time, we have progressively introduced more open source
elements, including MongoDB, RabbitMQ and Node.js.
• Now we are at the point where most of our back-end services rely
on Node.js. The talk will talk about why we did this, how we did
this, and discuss our experiences - both good and bad.

3. What do we do? (vision)
• Provide a marketplace for Cloud resources
• Choices in resource types (VM/VS etc.)
• Choices in level – IaaS/PaaS/SaaS
• Choices in providers & regions
• Able to search for what you need
• Able to buy what you want

4. How do we do it? (challenges)
• How to define all these different cloud resource types from
different sources in a normalized way?
• How do we provide the appearance of a single cloud over multiple
different cloud providers & regions?
• How do we provide a single interface (API) to multiple cloud
providers?
• How do we manage accounts and keep track of billing?

5. Components (6)
• Web UI
• User Management
• Billing
• Search/Catalog (resources)
• Fulfilment/Provisioning
• Infrastructure & Monitoring

6. Step 1 – C#
• Web UI – ASP.NET & C#
• Users – ASP.NET & SQL Server
• Billing – C# & WCF, SQL Server
• Search – “semantic web” – C/RDF/SPARQL
• Provisioning – C# & WCF, SQL Server
• Federation Server (FS)
• Provider Gateway (PG) - connector model
• REST API – Service Stack
• Infra – Windows services & tracing
• Service restart

7. Step 1 – All C#
FEDERATION
SERVER
PROVIDER
GATEWAY
C1
INTERNAL
REST API
REST WCF WCF
SQL
P1HTTP
BILLING
RESOURCES
C2 P2HTTP
C3 P3HTTP
WEB UI
ASP.NET
C# Windows Service
C# IIS Web Service

8. V1 Provisioning
• Workload and Transaction Model
• Declarative model of a workload in JSON
• Workload is a collection of workload elements
• Transaction is a “running workload” (collection of running VM or VS instances)
• V1 API
• WCF first, then REST (ServiceStack)
• Design: AWS and OpenStack, workloads & transactions
• Workload & transactions immutable (cannot be changed after execute)
• Federation Server – C#/WCF
• SQL access via Data Access Layer (DAL)
• Event driven model, graph for dependencies
• Resource types hardcoded (C# class)
• Provider Gateway – C#/WCF
• Connector Model

9. Why Node.js?
• Deployment Flexibility
• Platform independent
• Might need to deploy services anywhere
• We heard it could scale…
• Small footprint
• Fits well with our new proposed architecture (REST services)
• Lots of packages
• Good fit with NoSql (MongoDB) - JSON
• Good “word on the street”

10. Step 2 - Hybrid
• Web UI – Wordpress & PHP
• Users – SQL Server
• authentication service (Node.js + MongoDB)
• roles (authorization) service (Node.js + MongoDB)
• Billing – C# & SQL Server
• Search – Node.js & MongoDB
• Infrastructure
• iisnode + Nagios + tracing
• Other
• insight service (Node.js)

11. V1 Node.js services (4)
• authentication
• usernames/passwords/cookies/tokens/apikeys
• passwords salted & hashed
• roles (authorization)
• roles based on REST API, nested roles
• GET /workload > get.workload
• insight
• execute prepared SQL queries on demand
• run “sqlcmd” as XML, convert to JSON, REST API
• resources
• “triples” in MongoDB (subject/predicate/object)

12. Step 2 – C# and some Node.js
FEDERATION
SERVER
PROVIDER
GATEWAY
C1
WEB UI
WP PHP
INTERNAL
REST API
REST WCF WCF
SQL
P1HTTP
EXTERNAL
REST API
BILLING
RESOURCES
C2 P2HTTP
C3 P3HTTP
WCF
ROLESAUTH
INSIGHT
M M
C# Windows Service
C# IIS Web Service
Node.js
M MongoDB
M

13. Step 3 (V2) – Mostly Node.js!
• Web UI – Wordpress, PHP & Magento (MySql)
• Users – SQL Server & authentication & roles (Node.js)
• Billing – Node.js & MySql, still some C#
• Search – Magento/SOLR, plus resources for API
• Provisioning – Node.js & RabbitMQ & MongoDB
• Infrastructure - iisnode & Nagios & tracing

14. V2 Node.js services (10 + 3)
• instance – requests & instances, MongoDB
• provider – JavaScript connector model (simplified from V1)
• workload – plan/execute model
• insight (V2) - timing & inventory
• gateway – external API
• billing
• resources – catalog and search
• chef – deploy Chef cookbooks (to VM)
• archive – stores data for analytics
• upload – upload private images to regions

15. Step 3 – Mostly Node.js!
INSTANCE PROVIDER
C1
WEB UI
MAGENTO
WORKLOAD
P1HTTP
GATEWAY
BILLING
RESOURCES
C2 P2HTTP
C3 P3HTTP
ROLESAUTH
TIMING &
INVENTORY
MYSQL
SQL
USER
RABBITMQ
M
M
M M
M
M C# IIS Web Service
Node.js
RabbitMQ
Other

16. Migration
• Instances
• Migrate all the instances from V1 to V2
• Export all active instances from SQL Server
• Import instances into MongoDB
• Solution: Node.js scripts, JSON
• Connectors
• V1 (C#) wants to use the new V2 (JavaScript) connectors
• V2 (JavaScript) wants to use the old V1 (C#) connectors
• Solution: C# and Node.js can talk over RabbitMQ

17. V2 REST API (1/2)
• /resource (resource service)
• query for & find resources
• /request (instance service)
• fully async (requestId)
• requestStatus (in-progress, completed, failed)
• /instance (instance service)
• resourceType: vm, vs, kp, sg, image, ip, snap, lb, mp, obs
• resourceUri: /vm/hpcloud/nova/standard.small
• actions: CRUD –
• vm.create
• vm.retrieve
• vm.retrieve.all
• vm.update.start
• vm.update.stop
• vm.delete

18. V2 REST API (2/2)
• /workload (workload service)
• CRUD for workload definition, workload elements
• activate > plan (list of steps, serial & parallel sections)
• execute (plan) > transaction
• deactivate > plan
• execute: polling model with timeouts
• /transaction (workload service)
• status (in-progress/completed/failed/cancelled)
• steps (transaction log)
• errors
• API test tool: runcws (NPM package) (slightly better than curl…)
• ReadTheDocs.org (search for ComputeNext)

19. Workload Element
• {
• "name": "VM 1",
• "uri": "vm/hpcloud/nova/standard.small",
• "parameters": {
• "imageUri": "image/hpcloud/nova/ami-0000bd61",
• "keyPair": "KP 1",
• "securityGroups": [
• "SG 1",
• "SG 2"
• ]
• },
• "metadata": {
• "description": "hello world - my first virtual machine"
• }
• }

20. Workload Step
• "parallel": [
• {
• "step": {
• "id": "0005_vm_create_vm1",
• "action": "vm.create",
• "uri": "vm/hpcloud/nova/standard.small",
• "parameters": {
• "imageUri": "image/hpCloud/nova/ami-0000bd61",
• "keyPairId": "*0002_kp_create_kp1",
• "securityGroupIds": [
• "*0000_sg_create_sg1",
• "*0003_sg_create_sg2"
• ]
• },
• "metadata": {
• "description": "hello world - my first virtual machine",
• "name": "VM 1"
• },
• "sourceElement": "VM 1",
• "timing": {
• "min": 1,
• "max": 1800,
• "avg": 901,
• "default": true

21. JSON-Schema: vs.update.attach
• {
• "type":"object",
• "properties":{
• "virtualMachineId":{
• "type":"string",
• "required":true,
• "minLength":36,
• "maxLength":36
• },
• "deviceName":{
• "type":"string",
• "required":true,
• "minLength":2,
• "maxLength":128
• }
• }
• }

22. Data Driven Example: runcws.json
• {
• "instance":{
• "createi":{
• "description":"create instance from resource",
• "endpoint":"resource",
• "verb":"post",
• "call":"callInstance"
• },
• "getr":{
• "description":"retrieve request",
• "endpoint":"request",
• "parameter":"requestId"
• },
• "listr":{
• "description":"retrieve multiple requests",
• "endpoint":"request",
• "query":"cleanup=true"
• }
• }
• }

23. What we’ve learned
• A good tracing system is critical
• End-to-end JSON (Node.js + MongoDB + JavaScript) makes life a
lot easier
• Small self-contained services with well defined REST interfaces are
quick to write/change/fix (but lots of communication)
• Async – takes some getting used to - single threaded but highly
concurrent
• Data driven design pays off (esp. if data is JSON)
• Separate concerns (workloads/instances/plan/execute)
• File system is a pretty good database

24. What we’ve learned about clouds
• Lots of diversity in cloud object models (connectors)
• normalization is not straightforward
• concepts don’t line-up exactly
• easier for some resource types than others
• error handling is key
• not always well documented
• things change very fast!
• Diversity across cloud implementations (providers)
• “standard” clouds… are not!
• lots of data to manage and keep up to date
• performance – test, monitor & track
• Relationships with cloud providers are key
• marketplace helps providers understand their customers
• Futures
• beyond virtualization & images – Chef/Puppet/Docker

25. Favorite Node.js packages
• express (REST API)
• async (flow control)
• json-schema (input validation)
• JSONPath (like XPath for JSON - used to parse JSON from connectors)
• string (C# like string functions – startsWith/endsWith)
• request (simple HTTP client)
• node-yaml-config (YAML for config files)
• cjson (JSON with comments, great for data-driven code)
• underscore (useful functions)
• datejs (expire dates)
• xml2json & xml2js (XML to JSON conversions)
• mongodb/amqp/mysql
• tracer (customized)
• node-cache (better than do-it-yourself)
• edge (call C# from Node.js)

26. Great things about Node.js
• NPM – lots of packages
• Version control - it doesn’t break!
• End-to-end JavaScript & JSON
• Single thread eliminates whole class of bugs
• Single thread – no locks, easier to program
• REST is easy (with express)
• No compile
• It’s a scripting language too!
• “functions” beat “objects”?
• Platform independent (Windows or Linux)

27. Not so great…
• Miss tools integration & easy to use debugger, IntelliSense
• Miss C# AppDomains – not so good in Node (Domains)
• Service model limited (iisnode - web services only)
• Error handling & exceptions can be confusing
• No binary model – everyone sees source code
• JavaScript/JSON – no schemas, so forget!
• JavaScript – beware gotcha’s
• Because not compiled, can get silly runtime errors
• Async - can get no callbacks, or multiple callbacks!
• Packages – some are Linux only, some don’t work “as advertised”

28. Where are we now?
• www.ComputeNext.com
• ~ 40 providers
• ~ 145 regions
• ~ 25 connectors
• 10 resource types: vm/vs/kp/sg/ip/image/lb/mp/snap/obs
• www.MediaPaaS.com
• External REST API, tools & docs

29. Questions?
• www.ComputeNext.com
• Try us! Coupon code: NODE14
• REST API documentation: ReadTheDocs.org
• npm install runcws
• Slides on SlideShare.net
• We’re always hiring…
• Contact: jobs@computenext.com