Global Azure Bootcamp, London

When I found out about the bootcamp from Meetup announcement, it was too late to get a seats there as all of them were booked out in no time at all. Luckily, just a couple of days before it, I could get my pass from someone who changed his plans for that Saturday.

The meeting took place in New Zealand House, just steps away from Trafalgar Square. The office had a creative look-n-feel and had enough space for all participants. Morning tea and lunch were nice and quite filling. Speed of wifi connection and visibility of slides projected on a big white wall were just excellent.

Unfortunately, we didn't do as many labs as it was planned in the beginning of the meeting but nevertheless presentations were informative and comments, based on personal experience of the presenters (Richard Conway and Tiberiu Covaci), were very interesting and valuable.

Below there are some notes that I took there:

1. Microsoft started offering Nano Server - a minimal footprint installation of Windows Server that is highly optimized for the cloud, and ideal for containers. Basically, it's a bare minimum operating system good (and fast!) enough to run C#, Java, Python, Node.js and PHP applications on the cloud.
2. Azure REST API is clearly versioned when Amazon's is not. This means that if you run your application on Azure, you could stick with a certain version of API and avoid any surprises after its possible upgrade. On the other hand, upgrades on AWS may come out of the blue and most likely affect (usually negatively) your application.
3. It was mentioned that Visual Studio Online (VSO) is not exactly a proper environment for a serious product development. In fact, VSO is a TFS Online with Git integration (users could choose either Github or Bitbucket). For those who love TFS, VSO could be useful if they embark on Agile (Scum) development.
4. There were two interesting comments about Microsoft Azure Marketplace:
1. This is a good place to publish your server-based app and start selling it to the world, and
2. Current workflow for publishing your app there is somewhat cumbersome. The whole process is described in a 700+ pages manual and it may take up to few months to move your app over there. Good news is that Microsoft would like to compress this process to two weeks, bad news is that at the moment it's not clear when exactly that compression would happen.
5. Deployment to Azure could be completely automated. JSON (deployment) file may contain a complete script for creating the whole infrastructure (boxes, VPNs, connections, etc, etc).
6. Microsoft product range include IaaS, PaaS and SaaS. Interestingly, it was noted that majority of people still think that Azure services are too expensive. Well, I thought the same. According to my personal experience last year one box on Azure cost me around $80/month and I could run exactly the same set of apps on DigitalOcean for $20/month when I migrated there. I guess, I should check Azure again (Nano Server!), maybe it did become cheaper since then.
7. On Azure application services could perform Web Roles and Worker Roles. Web Roles come with IIS7 (or IIS8) and different versions of .NET libraries. Worker Roles could be responsible for queues polling, event listening, external process management, etc. Basically, a system that requires extensive parallel processing (like CVA calculations on a compute grid) could be compiled using such roles without the need of multi-threaded programming. Roles are defined in a Hosted Service. At runtime each Role will execute on one or more instances.
8. Integrated development experience powered by Visual Studio and Azure SDK includes .NET, Java, Node.js, Python and PHP.
9. Deploying on a Cloud requires a different mindset:
1. It comes with unusual (at first) errors, and
2. Design for availability, reliability and scalability would differ from ones done for apps that run on local machines.
10. Azure scaling consists of:
1. Up scaling - choosing different VM sizes
2. Out scaling - adding more instances
3. Auto-scaling - built-in functionality in application blocks
4. Out scaling - by using multiple service entities
5. Caching to offset server workloads
11. Data Management on Azure
1. There various data storage engines available:
1. SQL Server
2. DocumentDB (NoSQL)
3. Redis
4. Etc, etc.
2. Available plans:
1. Basic
2. Standard, and
3. Premium
3. Non-distruptive replication is provided
4. Data retention in Azure cloud backup is for 7, 14 and 35 days
5. Data storages could be accessed via REST API, PowerShell or Azure Portal
6. Azure SQL Server doesn't provide:
1. Profiler
2. Native Encryption
3. SQL Agent
4. CLR
5. Service Broker
6. Distributed transactions and
7. Distributed Views
7. Azure SQL Database Management Portal is a web access for Azure SQL Server.
8. There are readily available images for a range of standard SQL products, such as SQL Sever, Oracle, MySQL, etc that could be quickly and easily deployed on a cloud VM. This combines the power of cloud VMs with full features of SQL engines. It's good for enterprises (multiple DBs on the same box for different environments, etc) but not really needed for eCommerce websites. Ideally, one needs to compare SQL database vs SQL IaaS, there are (+)s and (-)s for different solution designs (research more about FullText Search, Windows Authentication for VMs joined to on-premises domain, large databases, etc).
9. There is a fully managed, scalable JSON document database service. It took 18 months for Microsoft to release this long awaited service!
10. DocumentDB has certain advantages over MongoDB:
1. MongoDB is not not easy to scaleable for an existing apps.
2. There are problems with migration of MongoDB (I'm not sure what use cases it is for).
11. Machine Learning. Although on Azure it was originally meant to be used on a single VM, soon it would be possible to scale it out with help of Revolutionary Analytics. I really liked this part and would definitely try it as soon as come across a proper task for it. The features are:
1. No coding required.
2. It's possible to use your own or open source analytic libraries (for example R or Python).
3. Briefly the workflow steps look as follows:
1. Get connected to a data source (some database with tables);
2. Select columns that you are interested in;
3. Define input parameters;
4. Build your path (you can call it a Model);
5. Train your Model (feed it with as much historical data as possible);
6. Evaluate the Model (85% is way better than 30%);
7. Deploy your Model as a web service with just one click.
12. Microsoft Azure Customer Connection Program (CCP) could be useful for those who would really like to get more intimate connections with this cloud (ECGCC@microsoft.com)

Overall I liked this meeting and look forward to get onto similar ones that might take place in London in near future.