Cloud computing is the set of technologies and infrastructure capabilities offered in a utility-based consumption model. Microsoft Cloud Computing offers Microsoft Azure, previously known as Windows Azure, to help its customers realize the benefits of cloud computing.
Applying existing development ideologies to Microsoft Azure is not straightforward, as direct one-to-one conversion is rarely possible. How should you alter your methodology and what Microsoft Azure development best practices should you use?
Key Features of Cloud Computing
- On-demand self-service. Less capital investment is required of businesses.
- Measured service. The pay-per-use model aligns IT investment to operational expenses.
- Broad network access. Cloud computing improves business agility and the ability to innovative with reduced barriers to entry.
- Resource pooling. Securely separating resources on a logical level represents a key architectural principle used to minimize interaction points and achieve high cohesion/low coupling between the layers of the software solution.
- Rapid elasticity. Cloud computing allows businesses to be flexible when they need to scale. Businesses can meet their needs more dynamically and provision resources on-demand or with an automated process using parameters and triggers.
Cloud computing that replaces the traditional on-premise (locally built and deployed) software is broadly divided into three categories:
Azure Development Lifecycle
The development lifecycle of software that uses the Azure platform mainly follows two processes:
During the application development stage the code for Azure applications is most commonly built locally on a developer’s machine. Microsoft has recently added additional services to Azure Apps named Azure Functions. They are a representation of ‘serverless’ computing and allow developers to build application code directly through the Azure portal using references to a number of different Azure services.
The application development process includes two phases: 1) Construct + Test and 2) Deploy + Monitor.
Construct & Test
In the development and testing phase, a Windows Azure application is built in the Visual Studio IDE (2010 or above). Developers working on non-Microsoft applications who want to start using Azure services can certainly do so by using their existing development platform. Community-built libraries such as Eclipse Plugins, SDKs for Java, PHP or Ruby are available and make this possible.
That said, Visual Studio provides developers with the best development platform to build Windows Azure applications or consume Azure services.
Visual Studio and the Azure SDK provide the ability to create and deploy project infrastructure and code to Azure directly from the IDE. A developer can define the web host, website and database for an app and deploy them along with the code without ever leaving Visual Studio.
Microsoft also proposed a specialized Azure Resource Group deployment project template in Visual Studio that provides all the needed resources to make a deployment in a single, repeatable operation. Azure Resource Group projects work with preconfigured and customized JSON templates, which contain all the information needed for the resources to be deployed on Azure. In most scenarios, where multiple developers or development teams work simultaneously on the same Azure solution, configuration management is an essential part of the development lifecycle.
Tools to Build and Deploy an Application with Microsoft Azure
Microsoft Azure provides a number of different ways to build and deploy an application. They can be grouped in several categories by Azure cloud service type:
Azure App Service
Azure App Service can be used for easy publishing of web-based projects in one of the following categories:
- Web Apps: Websites or web applications written in .NET, Java, PHP, Node.js and Python
- Mobile Apps: Projects that provide support for mobile devices and enable authentication with social providers and with Azure Active Directory (Azure AD); Projects that provide backend storage and integrate with Azure Notification Hubs for push notifications
- API Apps: Securely-exposed APIs in the cloud with Swagger metadata so clients can easily find out how to consume them
- Logic Apps: Powerful integration solutions that can be built quickly using the numerous connectors — The connectors can be custom-built or out-of-the-box. If out-of-the-box, they are already prepared to work with data and devices anywhere — on premise or in the cloud. Some of the currently available SaaS and cloud-based connectors include Salesforce, Office 365, Twitter, Dropbox, Google Services and more.
Azure Web Apps are built with continuous integration and delivery in mind. They support various tools like GitHub Webhooks, Jenkins, Visual Studio Team Services, TeamCity, etc.
Azure Virtual Machines
Azure Virtual Machines are a well-known standard in VMs with a large collection of pre-configured Windows or Linux Servers. VMs allow full control over machine configuration along with responsibility for support, updates, software installations and administration. Basically, they offer the Azure IaaS layer (infrastructure-as-a-service).
Azure Functions are the ‘serverless’ style response to business’ needs and developers’ demands to be able to write code directly through the web portal. With Azure Functions, a team can consistently and securely connect each function to different Azure services.
Azure Service Fabric
Azure Service Fabric is used to package, deploy and manage scalable and reliable microservices.
Azure Cloud Services
Azure Cloud Services is the PaaS layer of Azure, lying between App Service and Virtual Machines. Cloud Services employ the App Service approach to deliver various capabilities that enable developers to build n-tier cloud apps with more control over the OS.
Azure Container Service (Docker)
This Azure feature functions as a kind of OS virtualization allowing teams to deploy applications in a more efficient and predictable way. The containerized application approach works the same way in development, in test and in production systems. Azure Container Service supports standard Docker tools to manage containers.
Microsoft has dramatically extended their source control solutions in the cloud by adding Visual Studio Team Services — a wide range of tools and services to support DevOps work for continuous integration and delivery. With support for a range of tools including Jenkins, GitHub, Puppet, Chef, TeamCity, Ansible and VSTS for Azure services, a developer can work with existing tools enabling productivity and maximizing his/her experience.
After the application development is complete, development teams can move on to the quality assurance stage. Unit testing of the code is normally completed locally by the developer using different types of testing tools, such as automated unit tests and web tests. Azure Developer Tools contain emulators for some of the Azure environments, including cloud services and storage. These tools are provided for developers to unit test their application code before deploying it to Azure.
To ensure a smooth transition of the application to the cloud, I recommend using the following method:
Microsoft has implemented remote debugging for Visual Studio. The remote debugging process can be attached to any App Service (web or running in background) through the Visual Studio UI using Server or Cloud Explorer abilities. I recommend a hybrid approach to ensure our code will run on Azure — test locally using emulators and then move the application to cloud.
Microsoft Azure Development Best Practices to Deploy and Monitor
There are a few steps to take in order to do an Azure deploy. First the code is tested and then synchronized with the source code manager. Then the engine and versions are added to all assemblies. And finally after the code is compiled, a package is created so it can be uploaded to the Azure platform.
Preparing the Application for Publishing
All applications are prepared for a release and published at some point in their lifecycle. Uploading to the environment though is different in our case. We need to validate our Azure hosting environment first. Then, we need to focus on the host, management and execution of our cloud application. After that, we purchase a subscription, and finally, we can manually upload our deployment package to our staging or production environments.
Azure Tools to Optimize, Automate and Monitor
Microsoft provides several tools that can help optimize and automate the deployment process. Some of them are well-known: MSBuild scripts and the Azure Service Management API. The API can be used to interface with the management portal and create a package (one config file and one package file) directly from a VS project. That package can then be uploaded to the specific cloud environment (Azure Service). An alternative method to do that is using some of the DevOps tools I referred to above in order to deploy to Azure.
With your application up and running in Azure, you need to be able to monitor performance, watch for issues and see how customers are using your app.
Azure provides several monitoring options:
- Visual Studio Application Insights — An Azure-hosted extensible analytics service that integrates with Visual Studio to monitor your live web applications
- Azure Monitor — A new service created to help development teams visualize, query, route, archive and act on the metrics and logs that are generated by your Azure infrastructure and resources
Using the Azure Management Portal
Finally, a developer can use the Azure Management portal to manage an already deployed application. Each Azure service provides access to a few managed environments — the so-called deployment slots. They can be used for Staging, Production or any other environment we want to deploy to and use in the Azure cloud. There is no rule dictating the environments we must use. We can deploy our application directly to the production environment or deploy it to staging.
Microsoft provides a SWAP procedure that will do a transition (switch) between one deployment slot and another one. It is important for the production environment IP address to stay the same. That is the Virtual IP address on Azure. Any change to the Public IP Address will lead to changes in all DNS records and name servers. Microsoft tries to set as standard practice using CNAME records when we configure our DNS servers. Azure provides a DNS service (DNS Zone) as well.
As a part of some teams’ Microsoft Azure development best practices, the SWAP process can be automated to run each time new code is pushed as part of the continuous delivery procedure. It can even be used in preview mode so we can be absolutely sure that it will work after the SWAP process has finished.
From a development perspective, I recommend deploying the package first to the staging environment, so the application can be tested in a separate QA-like environment. Then, promote it to production for release. This approach will ensure the tested release of the application is ready for public use.
According to Microsoft Azure development best practices, the Deployment & Release stage involves the following two key phases.
System Testing. In this phase, different application tests are carried out. The tests can start with a basic “Smoke Test” to ensure that all basic functionality of the deployed services is running as it should on the cloud. This can be followed by “Integration Testing” to ensure that all external touch points to the services are functioning as expected. Subsequently followed by a “User Acceptance Test”, the services would be tested by a sample set of the application users. These are a representative set of tests that can be carried out as a part of the development lifecycle on the Azure platform, which an enterprise can run as a part of their standard project delivery practices.
All of these tests are carried out on the Azure platform without any investments required for procuring or setting up separate test environments on-premise. These tests can be carried out in the default staging environment, as discussed previously, or separate environments, in the case of larger projects, to carry out each test.
Production Release. After all of the test cycles have been completed, the tested Azure Service’s code can be released into production by promoting the services from the Windows Azure portal. The promoted services will execute from the production regions of the Azure data center fabric. As a part of the promotion process, the hosted services will have a public facing URL like “http:// [project].cloudapp.net”, where [project] is the name of the project defined at the time of creating a new hosted instance. In the production stage, the services are configured, managed and monitored from the Windows Azure portal.
Some of the activities an administrator can control and manage are:
- Configuring the number of running instances of the hosted service
- Starting/stopping service instances
- Upgrading or deleting deployed service packages
- Monitoring the usage of the hosted services
Control in Cloud Management
Unlike traditional on-premise systems, Azure does not provide full control of the computing environment and resources to administrators. Azure’s datacenter is fully managed and controlled by Microsoft. Users are only provided with private virtualized instances, packaged as services, as the unit of computation and storage for hosting their apps.
This will require a shift in the IT support operations. The Azure of today does not permit administrators to deploy some of the custom or third-party tools, utilities, agents, etc., that might be in use extensively with the existing operational processes to support and administer. Administrators use these tools to investigate production-related issues such as poor performance and crashes.
Sensitivity in the Cloud-Based Applications
A cloud-based application can run into different problems related to environments and architecture. Microsoft works consistently to avoid most of the problems by creating and proposing specific patterns to be used during the application development process. They are grouped in following areas.
The time that the system is functional and working. It will be affected by system errors, infrastructure problems, malicious attacks and system load. It is usually measured as a percentage of uptime.
A key feature of most cloud applications is the ability to manage data under different conditions. Data is typically hosted in different locations and across multiple servers for reasons such as performance, scalability or availability, and this can present a range of challenges.
Design and Implementation
Microsoft Azure development best practices for design considerations should include consistency and coherence in component design and deployment, maintainability to simplify administration and development and the reusability of components and subsystems. Decisions made during the design and implementation phase have a huge impact on the quality and the total cost of ownership of cloud-hosted applications and services.
Cloud-based applications need a reliable communication channel that connects components and services ideally in a loosely coupled manner in order to maximize the scalability of distributed applications. Asynchronous messaging is widely used and provides many benefits, but also brings challenges such as the ordering of messages, poison message management and idempotency etc.
Considerations in Managing Cloud Solutions
Most cloud applications use the PaaS layer of the cloud. It brings great flexibility, scalability and expense reduction in development and administration efforts but can make management and monitoring more difficult than an on-premises deployment. Applications must expose runtime information that administrators and operators can use to manage and monitor the system, as well as support changing business requirements and customization without requiring the application to be stopped or redeployed.
Performance and Scalability
Performance is an indication of the responsiveness of a system to execute any action within a given time interval, while scalability is the ability of a system either to handle increases in load without an impact on performance or increase available resources. Cloud applications typically encounter variable workloads and peaks in activity. Predicting these, especially in a multi-tenant scenario, is almost impossible.
Resiliency is the ability of a system to gracefully handle and recover from failures. The nature of cloud hosting, where applications are often multi-tenant, 1) use shared platform services, 2) compete for resources and bandwidth, 3) communicate over the Internet and 4) run on commodity hardware. This means there is an increased likelihood that both transient and more permanent faults will arise. Detecting failures, and recovering quickly/efficiently, is necessary to maintain resiliency.
Security is the capability of a system to prevent malicious or accidental actions outside of the designed usage and to prevent disclosure or loss of information. Cloud applications are exposed on the Internet outside the trusted on-premise boundaries. They are often open to the public, and may serve untrusted users. Applications must be designed and deployed in a way that protects them from malicious attacks, restricts access to only approved users and protects sensitive data.
Useful Cloud Design Patterns
Rather than sharing final comments, I’ve added the most-used design patterns for the cloud.
Circuit Breaker Pattern
This pattern can improve the stability and resiliency of an application — handling faults that may take a variable amount of time to rectify when connecting to a remote service or resource.
Competing Consumers Pattern
Enable multiple concurrent consumers to process messages received on the same messaging channel. This pattern enables a system to process multiple messages concurrently to optimize throughput, to improve scalability and availability and to balance the workload.
Federated Identity Pattern
Delegate authentication to an external identity provider. This pattern can simplify development, minimize the requirement for user administration and improve the user experience of the application.
Index Table Pattern
Indexes are a key feature of database management. Currently, they are presented in a new light for the cloud-based solutions.
Materialized View Pattern
The pre-populated view has returned to support the performance of the cloud data services. When the data is spread over couple of data tables it is better to combine it in a special view for the actual application needs.
Queue-based Load Leveling Pattern
Communication between the application in the cloud or an app in a hybrid environment is of high importance for the stability, the performance and the quality of the solution. To achieve better scalability and loose coupling, one can modify the project architecture by organizing the communication between the different layers of the solution through a message queue-like communication channel. Implementing messaging communication can minimize the impact on availability and responsiveness for both the task and the service in peak traffic situations.
To create a stable cloud application, the pattern must be applied on almost every layer of the application that communicates with external services. For example database or storage access, web services access, etc.
Static Content Hosting Pattern
This pattern can reduce the requirement for potentially expensive computing instances. With the Static Host Couple Pattern, static content is deployed to a cloud-based storage service that can deliver the resources directly to the client.
This blog was originally published on February 6, 2013. It has been updated to reflect the evolution of the featured technology and use techniques.