Evolution of a cloud start up: From C# to Node.js

Editor's Notes

• #4: You need to be able to search for what you need across all provider and regions. You need to be able to have one account and one bill for all the resources you use across any providers and regions.
• #7: WCF = Windows Communication Foundation The Provider Gateway (PG) implemented a “connector model” by which we could independently develop multiple connectors and load them into the PG as required. This allowed us to develop our various connectors more quickly. FS and PG were Windows services, which gave us some restart capabilities if the service crashed for some reason.
• #8: Circles are essentially process boundaries. Blue = Windows Service, C# Yellow = Web Service running under IIS, C#
• #9: We developed our V1 API using as WCF interfaces first, then extended it to REST using ServiceStack.
• #11: We moved away from ASP.NET to gain more speed & flexibility in the UI development. Having done that we lost the user management capabilities of ASP.NET so we had to develop authentication & authorization (roles) services – this became our “proof of concept” for using Node.js.
• #12: Adding our own authentication service allowed us to add new capabilities that we needed such as supporting “apikeys” for our REST API authentication. The “insight” service was added to allow us to do simple queries on our SQL Server database. At this point the Node.js driver for SQL Server was not available, so Node.js would run “sqlcmd” as a separate process, get the output as XML, and convert to JSON to be made available through a REST interface for our UI.
• #13: The “M” indicates that the service uses MongoDB. Unlike V1, where we shared one SQL database across multiple services, in V2 each service uses a separate MongoDB database, so every service is “self contained”.
• #14: Magento – open source e-commerce platform Apache SOLR – open source search engine iisnode is a Node.js package from Microsoft that allows Node.js services to run as IIS web services managed by IIS. This gives us process pooling, process recycling and restart.
• #15: Unlike V1, in V2 we now split the API between the “instance service” and the “workload service”. The “instance service” is what you might expect from AWS or OpenStack – an API that allows single instances of particular resources to be provisioned. The “workload service” is similar to what we had in V1, a collection of declarative workload elements that specifies what you want. In V2, the workload service calls the instance service to provision each individual resource. Also, in V2 the workloads are a lot more flexible – you can add things to them, remove things from them, and deactivate and re-activate them again, unlike in V1 where you basically got one shot at it. For V2, The insight service, although it has a similar name, is quite different from the insight service in V1. The V2 insight service now provides timing information and inventory for the workload service and the UI.
• #16: This slide shows our transition to mostly Node.js services. The connectors are now JavaScript. The red arrows show our use of RabbitMQ – you can see that the timing & inventory services (in the V2 insight service) and the billing service “listen-in” on the queue between the instance service and the provider service. This makes communication between services simpler.
• #29: As of June 2014. Adding more providers and regions every month! vm = virtual machine vs = volume storage kp = key pair sg = security group ip = IP address image = image lb = load balancer mp = MediaPaas snap = volume snapshot obs = object storage