Evolution of a Cloud Start-Up: From C# to Node.js

Steve JamiesonLead Developer at ComputeNextsteve@computenext.com

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.

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

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?

Components (6)

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

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

Step 1 – All C#

FEDERATIONSERVER

PROVIDERGATEWAY

C1

INTERNAL REST API

REST WCF WCF

SQL

P1HTTP

BILLING

RESOURCES

C2 P2HTTP

C3 P3HTTP

WEB UI ASP.NET

C# Windows ServiceC# IIS Web Service

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

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”

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)

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)

Step 2 – C# and some Node.js

FEDERATIONSERVER

PROVIDERGATEWAY

C1

WEB UIWP 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 ServiceC# IIS Web ServiceNode.js

M MongoDB

M

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

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

Step 3 – Mostly Node.js!

INSTANCE PROVIDER

C1

WEB UIMAGENTO WORKLOAD

P1HTTP

GATEWAY

BILLING

RESOURCES

C2 P2HTTP

C3 P3HTTP

ROLESAUTH

TIMING &INVENTORY

MYSQL

SQLUSER

RABBITMQ

MM

M M

M

M C# IIS Web ServiceNode.jsRabbitMQOther

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

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

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)

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"• }• }

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

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• }• }• }

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"• }• }• }

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

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

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)

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)

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”

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

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