Today, let me pass on to you some observations on how to transition a desktop oriented development team to the cloud.
Today is Ascension Day and a holiday in Neuchâtel, giving me a bit of time to clear some of my todo list items, and this article was one of them.
Before getting to that, I'll just briefly mention that I returned safe and sound from the Dubai hackathon and have been pretty busy with Revit stuff since, e.g., how to retrieve dimensioning references, editing and debugging a Revit add-in without restarting and a Share Bar. I reported on the Dubai hackathon during the weekend, discussing hackathon preparation in general, the View and Data API workshop and the hackathon projects presented.
The desktop to cloud transition was completed by an internal Autodesk development team, whose experiences are noted here for other teams wishing to follow suit.
The mental shift needed to move to the cloud, and beyond
Forget about the RTM date. In the cloud, your modus operandi is to release every day (OK, every week or couple of weeks). Your deployment does not even require “manufacturing” anymore. Be prepared to routinely support, fix and upgrade your service after the release. Deployment process has to be non-interrupting, automatic and inexpensive. Your service should have sufficient logging and monitoring tools to check the health of the service 24X7.
OS, middleware and runtime hold the key to success
Linux is the de-facto cloud operating system standard. But for some tasks, Windows could be a better option. Choose the right flavour and version of the operating system. Usually it is CentOS. Then choose the right type of Amazon Elastic Compute Cloud (EC2) – the virtual hardware that will host your service. Spend time understanding EC2. Learn how to deploy your images and how to name, boot, suspend, stop, terminate, monitor and troubleshoot your service. Make really sure you choose your infrastructure right.
Policy, Identity, Information and Infrastructure
If you spend 5% of development time on security in the desktop world, you may spend up to 25% on the different aspects of cloud security. You have to understand the notion of public and private keys and basic principles of public-key cryptography. They are an essential element of trust between services and clients of those services. You mostly need to set up systems for identification and authentication of users, managing your compute tasks (jobs) and storage. Amazon AWS provides a set of mechanisms around security and permissions for users and groups. Read about Identity and Access Management (IAM). You may have to use the IAM to manage access for your team as well as for the other roles to automate processes dealing with Amazon APIs.
Developing and monitoring services in the cloud
If you choose to use Linux you have to embrace a completely different set of habits. Even if you choose a familiar language (for example, C++) your development environment and tools will likely be different – from the virtual computer (VMWare or Oracle Virtual Box) to the source code editor. Also, even if you use C++ for some of your coding it is unlikely that you will use C++ for the interfacing part of your project. One popular choice is Python for server side (but for some tasks NodeJS is better suited) and obviously JavaScript for the client side. These scripting languages offer lots of free components and libraries. For example, one of the popular install packages, npm, gives access to over 100,000 modules. Why so many? This is mostly because those modules do only one thing, giving you exactly what you want and nothing else. If you are a front-end developer you have to become a friend of HTML and CSS. Familiarize yourself with Kafka for logging and Splunk to know a little bit about the engine behind the analytics. You should also evaluate whether Perforce, Team Foundation or Git is the best tool for your source code control.
Automatic, non-interrupting and inexpensive
You will need a process that automatically builds and deploys images once the code is reviewed and submitted. Developers push fresh code to the dev stream and the continuous integration system constantly produces new images. After testing the dev configuration changes to a devprod stream that contains changes available for beta customers. When devprod accumulates enough features and stability it gets deployed to staging and finally prod. The dev configuration is similar to the main code stream in the desktop world. Devprod is similar to the beta stream. Staging is similar to release candidate and prod is similar to release.
That's it, in a nutshell.
Easier said than done, of course.
I hope this is useful for you and your team as well.