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.
Changing the Mindset
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.
Choosing the right Infrastructure
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.
Managing Security, Identity and Permissions
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.
Building the Service
Developing and monitoring services in the cloud
Continuous Integration and Deployment
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.