Windows azure released three major updates in one breath over the past two weeks, including dozens of feature points, mainly focusing on the improvement of development tools and virtual networks:
- Webmatrix 3 release: http://weblogs.asp.net/scottgu/archive/2013/05/01/announcing-the-release-of-webmatrix-3.aspx
- Azure SDK 2.0 for. net release: http://weblogs.asp.net/scottgu/archive/2013/04/30/announcing-the-release-of-windows-azure-sdk-2-0-for-net.aspx
- Virtual Network Improvement: http://weblogs.asp.net/scottgu/archive/2013/04/30/announcing-the-release-of-windows-azure-sdk-2-0-for-net.aspx
The sub-functions that I personally think are most useful include:
-
- Software-based site-to-site VPN: you no longer need to use physical VPN devices to remotely establish a VPN channel to a Windows azure virtual network, instead, you can directly use the route and Remote Access Service (RRAS) feature provided by Windows Server Enterprise as a VPN endpoint to encrypt the Intranet of the local data center and the Network on azure.
-
- Software-based point-to-site VPN: if a single computer only needs to connect to a VPN, it is not required to connect to a Windows server, you only need the built-in VPN function on Windows PC to implement the encrypted connection from the client to the Windows azure virtual network. Allows multiple clients to connect to a virtual network at the same time.
- Ruby SDK release: Currently there are six programming modes supported by Azure SDK:. net, Java, PHP, Python, node. JS, and Ruby. These languages can call azure functions, such as storage, service bus, and virtual machine control, using the APIS provided by azure. Of course, the vast majority of azure functions are open through the rest interface. Even if the above six languages are not used, developers can start to construct their own rest requests for azure calls. With the SDK of the language, the development efficiency will be greatly improved.
-
- Visual Studio can display the output of the azure website in real time: one feature enhancement of azure last month is to support real-time output of azure website logs to the local console using the command line tool. Now, this feature has been inherited from development tools, saving the trouble of configuration. As a result, there are no obstacles to the development, release, and debugging of the azure website. If someone else uses tail-F to monitor the log information, you can tell him: you are out.
-
- Supports concurrent upgrades of cloud services: to avoid service interruptions during a previous upgrade of a cloud service, azure uses a rolling upgrade method, that is, based on the upgrade domain, upgrade the Virtual Machine instances owned by the service one by one, and the upgrade process of each virtual machine is refined into: offline-> stopped-> Reset-> deploy new version-> re-launch. If a service has five upgrade domains, and each virtual machine upgrade takes 10 minutes, the entire upgrade process will last for 1 hour. In fact, rolling upgrades are not required in all circumstances. The cloud service itself provides two environments: production and transition. Rolling upgrades are not required when a transitional environment is deployed, all nodes can be upgraded at one time, which is more efficient. Now, when you deploy cloud services, you can choose to perform concurrent upgrades. After that, azure will ignore the restrictions of upgrade domain and upgrade all nodes at one time. However, this capability is only available in Visual Studio. This option is not available on the azure interface.
- Enhanced cloud service debugging capabilities. I personally think that the most lacking capability of azure cloud services is diagnosis and debugging. Because azure puts usersCodeIt is fully managed, and users cannot see how code is packaged, deployed, and run. If the code is okay, everything is fine. However, once the code goes wrong, the cloud service will become a black box. It is difficult for users to view logs or debug logs through traditional means. This weakness has finally been greatly improved in azure SDK 2.0. During code deployment, the developer can specify the log output location. After deployment, the developer can directly open the log tool for viewing. The only deficiency is that such log viewing is based on the azure diagnostic module, and there is a certain delay (depending on the log transmission interval) based on Asynchronous log copying ), it cannot perform real-time monitoring like a website. However, this is even better. If you can view the log directly on the azure portal, it would be better.
Next, I will share several articlesArticleThese functions are described separately.
