The overall vision of the book is to use one sample application and perform the following:

• Automated build: Using build tools such as Ant or Maven
• Continuous Integration (CI): CI using Visual Studio Team Services (VSTS):
  • Compilation
  • Unit test execution: JUnit test cases
  • Code analysis: Using SonarQube
• Cloud platform resources
• CD using VSTS: Utility tasks for WAR deployment
• Continuous deployment using VSTS: Utility tasks for WAR deployment with governance and an approval workflow for the deployment
• Continuous monitoring and security: By configuring notifications in the Azure portal and using role-based access

We will integrate Eclipse IDE with the VSTS for repository-related tasks and perform all end-to-end automation operations as described in the preceding diagram. Every chapter is a building block for the next chapter and at the end of the book, we will be able to visualize the technical implementation and high level design in line.

Evolution is the step-by-step process to reach better alternatives of something that already exists and is adopted. If we observe closely, then evolution is a driving force behind path breaking innovations. And what is the core of any process of evolution? Change! With this background, if we consider evolution in infrastructure in information technology, then cloud computing is the most talked about in recent times and it has opened doors for many path-breaking solutions and innovations.

Charles Darwin was wise enough to say this:

This is very apt for cloud computing and its adoption. Let's understand what cloud computing is! There are many good definitions available in the market, but I will discuss here what I understand and what I have experienced.

Cloud computing is a type of computing that provides multitenant or dedicated computing resources such as compute, storage, and network to cloud consumers on demand. It comes in different flavors that includes cloud deployment models and cloud service models.

Cloud deployment models describe the way cloud resources are deployed, such as behind the firewall and on-premise exclusively for a specific organization, and this is called the private cloud; or cloud resources that are available to all organizations and individuals, and this is called the public cloud; or cloud resources that are available to a specific set of organizations that share similar types of interests or similar types of requirements, and this is called the community cloud; or cloud resources that combine two or more deployment models, and this is known as the hybrid cloud.

Cloud service models describe the way cloud resources are made available to cloud consumers. It can be in the form of a pure infrastructure, where virtual machines are accessible and controlled by a cloud consumer or end user, and this is called Infrastructure as a Service (IaaS); or a platform where runtime environments are provided so installation and configuration of all software needed to run application are already available and managed by a cloud service provider, and this is called Platform as a Service (PaaS); or Software as a Service (SaaS), where a whole application is made available by a cloud service provider with the responsibility of infrastructure and platform remaining with the cloud service provider.

Cloud computing has a few characteristics which are significant such as multitenancy, pay-as-you-use (similar to electricity or gas connection), on-demand self-service, resource pooling for better utilization of compute, storage; network resources, rapid elasticity for scaling up and scaling down resources based on needs in an automated fashion, and measured service for billing.

Over the years, usage of different cloud deployment models has varied based on use cases. Initially, the public cloud was used for applications that were considered non-critical while private cloud was used for critical applications where security was a major concern. Hybrid cloud usage evolved over time with experience and confidence in the services provided by cloud service providers.

In a similar way, there was a usage pattern for cloud service models too. As we usually do in a normal traditional environment, it was easier to adopt IaaS as there is complete control. Over time, organizations realized the cost of managing resources in the cloud as the efforts are the same in managing resources, considering security configurations, and other configurations. Hence, IaaS was becoming difficult day by day with the evolution of PaaS. PaaS has evolved over the years and its approach is much wider, and its services include multiple programming languages such as .NET, Java, PHP, Python, and Ruby.

In simple English, PaaS provides infrastructure as well as a runtime environment to deploy an application. The difference is the end user doesn't have control on infrastructure while we can configure a runtime environment and debug an application remotely and troubleshoot issues to some extent. There are PaaS offerings where you can have dedicated infrastructure resources for application deployment, but even in that case, control of infrastructure is in the hands of cloud service providers. In short, we as cloud users need not to worry about downloading different web servers, database servers, and other required software and install them on a machine and maintain them. We don't even need to worry about updating them to newer versions. Cloud service providers are responsible for maintaining availability of the application and its resources. However, as users, we need to follow best practices to configure applications to have a highly available application considering different services provided by the cloud service provider.

Let's visualize how the process workflow is executed in terms of a traditional model or in IaaS, and then we will compare it with PaaS. In a traditional environment, the infrastructure provisioning process takes place in a different manner than the acquisition of a virtual machine in a cloud subscription.

While in the case of PaaS, the flow has less complications than the traditional or IaaS process.

However, the approval process in the cloud environment too has costs associated with it, so organizations keep their own sets of e-mail approval processes to create a virtual machine or to provision any PaaS offering.

Over the years, PaaS has gained its momentum and many organizations have realized that there are less complexities and less management overhead involved in it. Hence, many customers are leaning towards the PaaS offering, as they don't wish to manage virtual machines and apply security policies in the cloud and maintain all of them. In IaaS, as users, we need to configure high availability and scalability, and it is more complicated compared with PaaS.

PaaS offerings manage load balancers and high availability with little configuration and hence save a lot of time, and the architecture is more clear. We need to remember that most of the control is available with cloud service providers and hence we have less things to manage. Cloud service providers have more control and they implement all the best practices and a standard pattern to fulfill the SLAs attached with PaaS offerings. Governance wise, PaaS is less flexible in terms of applying policies as it is a shared environment and is standardized as well. Managing PaaS is also less costly compared with IaaS. In the case of IaaS, we need to manage everything the way we manage on-premise.

In short, those who know better about infrastructures and platforms manage them with efficiency so we have less overhead.

An Application Platform as a Service (aPaaS) provides features to design, develop, deploy, and manage an application life cycle, enabling effective resource utilization, agility, and faster time to market. It is getting popular now-a-days as it has less overhead and less complexities of managing resources for the application life cycle management. Usage of thick clients is an old story now and PaaS providers have realized the trend. Developers want offerings all in once place where they can develop, compile, package, and deploy at them. PaaS is accessed through web browsers such as Firefox, Chrome, or Internet Explorer. Most PaaS providers have come up with offerings to support developers within browser IDEs to develop applications. In recent times, DevOps has also gained momentum and PaaS along with the DevOps culture is breaking a lot of barriers in the traditional culture of IT. In the next section, we will discuss DevOps and then we will see benefits of PaaS in DevOps.

DevOps is more about the culture of an organization, processes, and technology to develop communication and collaboration between Development and IT Operations teams so as to manage the application life cycle more effectively than the existing ways of doing it. We often tend to work based on patterns to find reusable solutions from similar kind of problems or challenges.

Over the years, achievements and failed experiments, best practices, automation scripts, configuration management tools, and methodologies became an integral part of the culture. This helps to define practices for ways of designing, developing, testing, setting up resources, managing environments, managing configuration, deploying an application, gathering feedback, performing code improvements, and doing innovations. It helps to train people to think that drive the DevOps culture at every stage.

The DevOps culture is considered to be an innovative package to integrate the Dev and Ops teams in an effective manner that includes components, such as continuous build Integration, continuous testing, cloud resource provisioning, CD, continuous deployment, continuous monitoring, continuous feedback, continuous improvement, and continuous innovation, to make application delivery faster as per the demands of the agile methodology.

Considering the way we have been doing things to manage applications over the years, it is a challenge to change the culture. Mr. David Gleicher created the formula for change, and later it was refined by Kathie Dannemiller. This formula is still relevant as it provides a model to assess the relative strengths affecting the success possibilities of organizational change initiatives.

As per the formula, three factors must be available for a meaningful organizational change to take place. I just tried to classify different things in these three factors:

• D = Dissatisfaction with how things are and how cumbersome they are! (Manual Processes + Repetitive work + Rigidness of processes + No flexibility + Huge CapEx + No visibility)
• V = Vision of what is possible and what is the opportunity available with disruptive innovation in recent times (Cost benefits -> Pay as you Use + Automation + Agility + Scalability + Increased efficiency and productivity + Continuous improvements + Continuous innovations)
• F = First concrete steps to achieve the vision (Continuous Integration + Continuous Testing + Cloud Provisioning + Configuration Management + Continuous Delivery + Continuous Deployment + Orchestration + Continuous Monitoring + Continuous Feedback);

If the product of these three factors is greater than R = Resistance, then change is possible. If any one factor is absent (zero) or low while D, V, and F are multiplied, then the multiplication will be zero or low and therefore it may not overcome the resistance. Even without numerical values, the outcome of this formula is very much in the favor of change considering the values.

To bring an organization-wide change, we must consider the possibility of dissatisfaction in people and try to bring the change in mindsets by sharing industry trends, leadership ideas, best practices, and competitor analysis to identify the necessity for change. Hence, to ensure a successful change, it is the need of the hour to use influence and think strategically to create a vision and identify the basic steps toward it. To change the culture of an organization effectively, we the people need to bring in an agile, standardized environment, uniform automation processes orchestration, and DevOps enablers. Essentially, it means the combination of people, processes, and tools to achieve efficiency.

In other words, the DevOps culture is not much different than the organization culture, which has shared values and behavioral aspects. It needs adjustments in mindsets and processes to align with the new technology and tools.

At the end of the day, the ball is in our court and we should remember that we can't make an omelette without breaking a few eggs. To be more precise, the early bird catches the worm.

In the next section, we will describe in detail about the role and benefits of PaaS and aPaaS in DevOps.

We saw in the earlier section that PaaS provides flexibility to deploy an application without an overhead of management of resources. As users, we can deploy an application and control its configuration to some extent. Resource management is the responsibility of cloud service providers. Cloud service providers manage servers, operating systems, networks, or storage. They also manage load balancing, scalability, and monitoring of resources. Users only need to configure them properly.

Cloud has a shared responsibility model and that changes based on the cloud service model we use. PaaS is just a perfect mix of flexibility and less overhead.

Now let's understand the difference between using DevOps with IaaS and DevOps with PaaS.

One of the main factor is the speed with which resources are available in PaaS compared with IaaS. Within minutes, we have the environment ready to deploy an application. The reason is simple, we need not to install and configure a runtime environment. It is already available. As a user, we only need to configure it based on the suitability of our application. Consider these examples:

• Programming language
• Web or application server
• Stateless or stateful application
• Application settings as environment variables
• Connection strings as environment variables that can be utilized to facilitate backup
• Virtual directories

Because the deployment environment is available in minutes and we can automate the creation of that environment using commands or scripts, it is very flexible to integrate it in the automation process. Even if the resource provisioning process is not automated, it becomes very easy to integrate the platform into automated deployment scenarios.

The recent trend in the market is Application Platform as a Service (aPaaS). This is a service offering that provides development and deployment environments for application life cycle management.

The aPaaS service model offerings generally provide the following services:

• Agile scrum user stories management
• Code editors in a browser
• Repository as a Service
• Build as a Service
• Testing as a Service
• Release Management as a Service
• Cloud platforms to deploy an application
• Monitoring as a Service
• Security as a Service
• Identity Management as a Service

The question is, how are PaaS and aPaaS different from each other?
The following are the important points that bring out the difference and make aPaaS more suitable to manage the application life cycle:

• Agile scrum user stories management
• Code editors in a browser
• Repository as a Service
• Build as a Service
• Testing as a Service

In today's age, aPaaS is driving toward continuous improvements and continuous innovations. It drives for rapid application development and rapid application delivery. The Microsoft Azure application platform services provide application development, repository services, application deployment services, performance testing, security, and governance. The Microsoft Azure App Service is a PaaS used to rapidly build an application that may be web- or mobile-based that can be highly available, scalable, and flexible. Microsoft Azure provides other PaaS offerings—DBMS, App Insights (preview), and so on.

In the next section, we will cover all Microsoft Azure PaaS offerings that we will discuss in this book.

In this book, we will use PaaS offerings of Microsoft Azure such as App Service, database services, and storage services. We will also utilize other services such as Azure Active Directory, App Insights, and Traffic Manager. We will use all these services for managing the application life cycle for tasks such as application deployment, databases authentication, monitoring, and high availability.

App Service is one of the most popular offering from Microsoft Azure. It is a PaaS. There are four kinds of applications that are created in App Service:

In this book, our focus is on Web Apps. Web Apps are a PaaS offering that have computing resources and runtime environments managed by Microsoft Azure while the user is only responsible for the application and configurations related to Web Apps and high availability.
The following are some quick points about Azure Web Apps:

• Web Apps runs on virtual machines – virtual machines are managed by Microsoft Azure
• Five pricing tiers are available – Free, Shared, Basic, Standard, and Premium
• Web Apps support applications written in Java, ASP.NET, PHP, Node.js, and Python
• We can integrate Web Apps with Visual Studio or GitHub
• We can create Web Apps from the Azure portal and also from the command line using PowerShell commands; thus it is easier to automate the creation process
• We can set CI and CD or deployment using Build and Release of VSTS
• We can configure autoscaling and make it available across the regions; we can set high availability as well

Let's see some basic difference between Azure Virtual Machines and Azure Web Apps:

To have a quick hands on, follow these steps:

1. Go to https://tryappservice.azure.com. Select Web App:

2. Select a template, in our case it is a Java template. Click on Create:

3. The web app is ready. Note the URL given to access it:

4. Visit the web app at a given URL:

This is how we can create a sample Azure web app.

The Microsoft Azure SQL Database is a RDBMS in the cloud. It supports the SQL Server engine and hence we can use existing SQL Server tools, libraries, and APIs to manage the SQL Database in the cloud. It comes in different pricing tiers such as Basic, Standard, and Premium service tiers that have different capacities for different workloads.

Microsoft Azure Storage is a cloud storage offering that is highly available, scalable, and durable. Microsoft Azure Storage services provide Blob storage, Table storage, Queue storage, and File storage:

• Blob storage (Object storage): This is used to store unstructured object data such as documents, media files, and binary data
• Table storage: This is used to store structured data such as NoSQL key-attribute data
• Queue storage: This is for reliable messaging
• File storage: This is used to store file data that can be used by Azure virtual machines and cloud services

Azure Active Directory (Azure AD) is a cloud-based, multitenanted, and highly available identity management service from Microsoft. It can manage users, groups, and multi-factor authentication; add an application organization that is developing for authentication; add an application from the gallery for authentication; add a custom domain; add role-based access control; and so on.

To access Azure AD from the Azure portal, go to https://portal.azure.com and click on Azure Active Directory.

Verify the Overview details with Users and groups, App registrations, and Azure AD Connect.

The application Gallery supports 2,771 applications for Azure AD integration at the time of writing this chapter. Categories include Business Management, Collaboration, Construction, Content management, CRM, Data Services, Developer Services, E-commerce, Education, ERP, Finance, Health, Human resources, IT infrastructure, Mail, Marketing, Media, Mobile Device Management, Productivity, Project Management, Security, Social, Supply Management, Telecommunications, Travel, and Web Design and Hosting.

Major applications supported are Office365, Salesforce, ServiceNow, Google Apps, and so on.
Go to https://manage.windowsazure.com to access Azure AD from the classic portal:

One of the biggest benefits that we will utilize in this book is the way we can provide authentication to access Azure Web Apps. We can configure Azure Web Apps with Directory so only specific users can access the application hosted on Azure Web Apps.

Visual Studio Application Insights is a flexible analytics service. It helps us to get the insights of performance and usage of an application. It can be used for .NET- or J2EE-based applications that are hosted on-premise or in the cloud. We will cover only a few important features that come with this service in this book.

Create a sample application and go to its MONITORING section. Click on Application Insights. Select Create new and click on OK:

We can create a web test for testing the availability of applications from multiple regions. We can select a ping test or multi-step test to check the availability. The alert criteria can also be configured.
Performance testing is also a very interesting feature available in App Insights. It is more of a load testing based on the number of users for a specific duration.

We will see the how to of both in this book where we intend to cover monitoring.

Microsoft Azure Traffic Manager provides a feature to distribute user traffic to different endpoints. These endpoints can be Azure App Service (Azure Web Apps), cloud services, Azure Virtual Machines, and external endpoints. It is a DNS-based traffic routing. Azure Traffic Manager supports three traffic routing methods to decide how traffic can be routed to different endpoints. In simple terms, it is a way to decide which endpoint should serve the DNS request.

There are two different deployment models in Microsoft Azure—the classic deployment and Resource Manager deployment models. Microsoft Azure Traffic Manager uses different terminology for traffic routing methods (known as the load-balancing method in the classic deployment model):

• Priority method (Failover method): Select the Priority or Failover method for traffic routing when you need resources in a specific region to serve all the traffic and only use other endpoints if the main endpoint is unavailable.

Often this method is cost-optimized and the usage of the application is very well known and specific to a region.

• Weighted method (Round-robin method): Select the Weighted or Round-robin method for traffic routing when you need resources to serve in a different region or across a set of different endpoints.

Let's say we know that our application hosted in Azure Web Apps is going to be equal or in a specific ratio, then the Weighted method can be more appropriate.

• Performance method: Select Performance for the traffic routing method when we want to provide equal performance to the user of the resources hosted in Azure.

So, in simple terms, users will be redirected to the nearest endpoint to serve the response.
Some benefits of Microsoft Azure Traffic Manager are as follows:

• Easy to use and configure
• Easy learning curve
• Configuration is available from Azure Portal as well as Azure PowerShell 
• DNS level traffic routing
• Helps in high availability of the business critical application
• Provides automatic failover
• Supports multiple endpoints: Microsoft Azure and external endpoints
• Helps to support the scenario of planned maintenance
• We can combine hybrid applications as it supports multiple endpoints

Microsoft Azure comes up with some core concepts that are important to understand before we go ahead and work with it. These core concepts help to manage resources and help to understand the pricing structure as well.

Microsoft Azure services are available in 34 regions around the globe and more regions are continuously planned to be supported. The more regions, the more it allows customers to achieve better performance with cost optimization. It also helps in scenarios where data location is legally restricted.

To verify WEB + MOBILE products available by region go to https://azure.microsoft.com/en-in/regions/services/ and check the WEB + MOBILE section:

Azure is generally available in 34 regions and 12 geos around the globe. It has already announced plans for six additional regions and two additional geos. For customers, it is extremely important to have legal compliance in the context of a storage location of their data. There are two different possibilities/authorities in this scenario:

• The customer may copy, move, or access data from any location

• Microsoft may replicate data in other regions of the same geo for high availability:

Resource groups in Microsoft Azure is nothing but a logical container. It can be used to group all different resources such as App Service, SQL Databases, and Storage Accounts, available in Microsoft Azure. We are going to consider services that we will use in this chapter for most of the examples. Resource groups provide a simple way to manage resources together. One of the biggest advantages is to manage the role-based access on the resources in an easy manner.

For example, we need to create resources such as Azure Web Apps, SQL Database, and Storage Account in the West US and provide access to all of them to some users. It is painful to assign a user to individual resources. Rather, it is more manageable if we can provide group access to all resources. This way resources can be managed in a better way.

To create a resource group, click on Resource groups in the left-hand sidebar menu. Click on the +Add button to create a resource group. Provide the Resource group name, select Subscription, select Resource group location, and click on Create:

Wait until the resource group is created.

Once the eTutorialsWorld resource group is created, click on it and verify the Overview section.

As of now, there are no resources in the resource group; hence there are No deployments in the Overview section—No resources to display:

As there are no resources, there is no cost available in the Resource costs section of the eTutorialsWorld resource group:

We will use this resource group in the coming chapters as a logical container for different resources such as Azure Web Apps and Azure SQL Database.

An App Service Plan (ASP) is a set of capacities (the instance size and instance count on which the application is hosted) and features. Capacity is directly linked to cost and hence it is similar to choosing a pricing tier. There are different capabilities and limits within ASPs.

There are five pricing tiers, namely Free, Shared, Basic, Standard, and Premium. Each ASP can be used for different purposes and they are different in providing features too. SLAs for Basic, Standard, and Premium are 99.95 percent. Autoscale, geo-distributed deployment, VPN hybrid connectivity, deployment slots, and automated backups are available only in the Standard and Premium tiers. In the Standard tier, five deployment slots are available, while in the Premium tier, 20 slots are available. Another major difference is the maximum instances, as they are directly associated with scaling. Hence, it is important to pick the proper tier or ASP to gain the desired performance. The Basic, Standard, and Premium tiers allow up to 3, 10, and 50 instances respectively.

The following are some important points regarding ASPs:

• ASPs can be shared by multiple applications
• Deployment slots are usually deployed on the same ASP
• Azure Web Apps configured with an ASP are changed and these changes affect all applications hosted on the ASP
• By default, an ASP comes with a single instance. If we increase the instance count, then applications hosted on a single instance will be hosted on other instances too
• The number of instances in an ASP is directly associated with the price of the Azure Web Apps

Let's consider the Azure calculator and understand how the pricing works. Go to https://azure.microsoft.com/en-in/pricing/calculator/. Click on +Add items and click on App Service in the Featured category:

Select REGION, TIER, INSTANCE SIZE; by default, the instance size is 1 and the hours are 744. Verify the cost estimate:

Now change the instance count and verify the cost:

As the instance count directly affects pricing, let's see from where we can change the instance size as we need to be careful while doing it.

Let's create an ASP and verify the instance count. Go to the left-hand side menu bar, find App Service plans, and click on +Add.

Select the eTutorialsWorld resource group we created; select Operating System, Location, and Pricing tier. Click on Create:

Once the ASP is created, verify its Overview section. Verify the Apps / Slots count. It is 0 / 0 as no app or the slot is using the ASP:

Go to the Scale out (App Service plan) section in APP SERVICE PLAN, and verify the default number of instances. As we kept the Basic pricing tier, it allows us to scale up to three instances only:

If we want to cancel the changes, click on Discard.

Scaling resources is a significant part of making an application highly available and having good performance. There are two types of scaling:

• Vertical Scaling (scale up and scale out): We can increase or decrease the size of the instance by choosing different pricing tiers. We can do it manually:

• Horizontal Scaling (scale in and scale Out): We can increase or decrease the number of instances that are used to host web applications.

Horizontal scaling is the most commonly used as we can schedule it also. It is important to understand what will impact on the performance and availability of an application and accordingly we can decide the scaling part:

There are three types of scaling out supported in Azure Web Apps:

• Scale instances manually
• Scale instances by the CPU percentage
• Scale instances by schedule and the performance rule

We can configure a number of instances manually based on the existing patterns and usage and these will serve the application hosting. We cannot change this dynamically. We need to change the setting in the ASP:

We can automatically or dynamically scale up or down instances based on the performance of the CPU we have configured. We can also configure the number of instances too.

Based on multiple rules, we can increase or decrease the number of instances used in an ASP. This is the most flexible and widely used scale out option out of the three:

In this first chapter, you learned the basics of cloud computing, its service models, and deployment models. We covered PaaS in depth and also provided details of the new trend of the modern day and that is aPaaS.

We discussed the role and benefits of PaaS and aPaaS in DevOps by explaining the services that each one provides and what is the difference between both of them. The next step is to know about tools or services that we are going to use in end-to-end automation for the application life cycle management. We covered brief details on App Service: Microsoft Azure Web Apps, Azure SQL Database, Storage Services, Azure Active Directory, App Insights, and Traffic Manager with its routing methods.

It is also important to understand the basic concepts related to Microsoft Azure Cloud so we can easily create and manage resources in Microsoft Azure Cloud. The basic concepts have covered topics such as regions, resource groups, ASPs, and autoscaling.

In the last section, we covered the overall vision of the book. We provided glimpses of the high-level design that we want to implement in the coming chapters.

In the next chapter, we will cover VSTS and how to check in code into VSTS using Eclipse.