The DevOps Approach for Web Applications

The DevOps approach for web application development follows the traditional model of requirements management, version control, branching and merging strategy, and continuous integration and deployment. Sometimes, this gets extended further into a continuous monitoring and feedback loop as well. In addition to the base components, most of the time the tool integration required in each process step varies from application to application.

The tools and technologies integrated across the DevOps pipeline are based on the technology stack and the requirements of the customer. XebiaLabs publishes a list of the leading DevOps tools used across the pipeline (https://digital.ai/periodic-table-of-devops-tools), categorized by different usages. This is a great reference for DevOps architects.

This is just the basic setup for modern application development, and the list of tool integration varies based on the customer requirements.

Microservices

Adapting a microservice architecture enables companies to release small independent units of work to production environments quickly. Specifically, Azure DevOps lets you create multiple release pipelines to automate the deployment of microservices in parallel and independent to each other. Figure 8-1 shows a high-level view of a microservices deployment approach.

The DevOps Approach for Databases

There are a number of data platform tools and technologies, such as Oracle Database, Azure Data Lake Store, SSIS packages, Azure SQL, and Cosmos DB, dealing with various data requirements. To store data, there are multiple data stores, both SQL and NoSQL based. Azure DevOps supports various types of databases and associated platforms such as SSIS packages, data lake deployments, and so on.

SQL Server database

SQL Server database DevOps starts from the database project creation using Visual Studio. Visual Studio supports the development of schema files and the unit testing of the SQL schema. Moreover, proper version control using Azure Repos will be handled through Visual Studio. The database project supports the configuration of the pre-conditions and post-conditions required at deployment time. These conditions will be used to execute the cleanup activities, user creation, and other common environment-specific configurations.

DACPAC packaging is used by Azure DevOps to package the SQL builds and releases. DACPAC is a file format that contains the database objects and has an extension of .dacpac. Both the task-based build pipeline and YAML-based build support DACPAC-based database project handling. See Figure 8-2.

Moreover, MySQL deployment supports using MySQL tasks and YAML scripts in the Azure DevOps pipeline. SSIS packages are supported in Azure DevOps, and the package generated is similar to DACPAC with an extension of .ispac. Azure offers another pipeline called the Data Factory Pipeline for Azure Data Factory with all the required support for data cleaning, transformation, etc.

The DevOps Approach for Machine Learning Models

Machine learning models , are an integral part of modern application development. Machine learning models have different process steps compared to a normal application life cycle. In general, an ML life cycle will be defined using the steps shown in Figure 8-3.

Manual deployment requires developers to package and deploy the model to Azure services. This is not a recommended option. Azure DevOps and Azure ML Workspace Pipeline are the two options recommended based on the target users.

If the user is a data scientist, then use the end-to-end ML pipeline via Azure Machine Learning Pipelines. This approach is called machine learning operationalization (MLOps).

Machine Learning Operationalization

Figure 8-4 shows the MLOps using Azure ML Pipelines.

The orchestration step is important; it deals with the core activities of data injection, data cleaning, transformation, training, and so on. “Create Docker image” will create a Docker container that the user can deploy to a compute target. Under “Compute target,” the user can select either a CPU-based virtual machine or a GPU-enabled virtual machine. If the models are based on a neural network or require GPU capability, then select the GPU-based compute target. Mainly, this flow is used by data scientists, who deal with the ML life cycle.

Azure DevOps

Azure DevOps provides more control and a streamlined process to handle ML model development and deployment. Similar to any other programming language, ML models can follow the same DevOps process starting from the requirements in Azure Boards, code versioning using Azure Repos, and deployment using Azure Pipelines. Figure 8-5 depicts a high-level DevOps architecture using Azure DevOps and AKS.

Azure DevOps Pipelines stores the container image in Azure Container Registry and deploys it to AKS using the release pipeline. To implement further security, we can configure ingress controllers to handle the security and routing for the models. In general, models will be protected using internal IPs and exposed for external consumption through APIs. In this case, the APIs will be configured in the ingress controller. Additional layers for the API management and app services will be added based on the system requirements. It is not recommended to expose the ingress controllers outside the Azure, instead configure API Management in front of Ingress controller to handle the incoming requests and apply security validation.  

The AKS setup is used to train ML models; please refer to the reference architecture from Microsoft at https://azure.microsoft.com/en-in/solutions/architecture/machine-learning-with-aks/.

The DevOps Approach for COTS Applications

Commercial-off-the-shelf (COTS) applications are software products that are ready to use for a specific purpose. For example, SAP, Salesforce, and CRM are some COTS applications. The DevOps implementation in COTS applications is different from a traditional application, meaning an application specific to one customer’s need.

Figure 8-6 shows the use of Azure DevOps along with Project Piper from SAP for implementing end-to-end DevOps for SAP platform applications. Project Piper is SAP’s open source solution for continuous integration and delivery. For more details, please refer to https://sap.github.io/jenkins-library/.

DevOps for COTS depends on the application support for implementing DevOps. In general, implementation of end to end DevOps for COTS is not possible completely. Currently, most of the COTS development and deployment involves few manual tasks, which will not be handled by the DevOps tools. Some of the major COTS players like SAP and Saleforce, changing the process for custom implementation and deployment to align with DevOps. We can implement some aspects of DevOps but still involve some manual elements to accomplish the complete release cycle.

The DevOps Approach for the Support Team

DevOps is defined as the collaboration of people to release value in a faster way using appropriate processes and technology adoption. The main concept of DevOps is people, especially the team culture. DevOps eliminates silos between dev and ops using practices such as smaller, much more frequent releases and blameless post-mortems, in combination with technologies and tools that empower transparent communication and cooperation across teams.

There are many variations of DevOps implementations in terms of team formations, tool usage, agile methodologies, and so on. One such variation of DevOps is BizDevOps, where the business is added to the context of DevOps and extends the boundaries. See Figure 8-7.

The DevOps team without a support ecosystem may be able to deliver value faster to the client. But client satisfaction mainly depends on how quickly the issues or challenges are addressed. If you deliver hundreds of amazing features to the client but take more time to fix bugs and release, fail to respond to a production outage in a timely fashion, or make an effort to reduce application downtime for the business, this will impact the client satisfaction inversely.

Most of the time, the traditional support model fails to address client satisfaction in an effective manner. See Figure 8-8.

Intelligent Swarming Support Model

The intelligent swarming support model is derived as a service innovation to address the traditional support model. The Consortium for Service Innovations (https://www.serviceinnovation.org/intelligent-swarming/) defines the intelligent swarming support model as a new support model that removes the tiered support model. It offers “improvement in operational efficiencies, employee engagement, and customer satisfaction and loyalty, and it brings with it a host of questions around practices and measurements.” See Figure 8-9.

In the swarming support model, expert teams are formed as swarm teams. There may be one or more swarm teams to handle the support tickets. If the L1 support is not automated fully, then there may be one swarm team to support the L1 tickets and help in automation. The L2/L3/L4 areas will be handled by a single team of experts who understand the application functionality and technology.

Figure 8-10 shows a normal swarming support setup with a single swarm team in rotation with the development team. The automation of repeatable operations and ticket handling will enable the team to cross-skill and be part of the swarm team, which works with dev and support teams in rotation.

The following are some of the benefits of the swarming support model:

• Swiftness in solving tickets

• Flat team

• Quick collaboration

• One owner

• Experts handle the tickets

• Single team; swapping with core team

• Higher team satisfaction

• Proper skill utilization

• Culture and process change

• Rotation between support and core team

• Proper team combination for successful implementation

Summary

The DevOps approach and architecture vary from application to application, but the basic components are the same. More and more COTS applications are starting to support external DevOps tools to integrate with the core deployment model. A proper DevOps architecture helps manage the release of value quickly in an agile manner.