This course features a combination of lectures, design activities, and hands-on labs to show you how to use proven design patterns on Google Cloud to build highly reliable and efficient solutions and operate deployments that are highly available and cost-effective. This course was created for those who have already completed the Architecting with Google Compute Engine or Architecting with Google Kubernetes Engine course.

Prerequisites:
To get the most out of this course, participants should: ●Have completed Architecting with Google Compute Engine, Architecting with Google Kubernetes Engine, or have equivalent experience ●Have basic proficiency with command-line tools ●Have systems operations experience, including deploying and managing applications, either on-premises or in a public cloud environment
Objectives:
●Apply a tool set of questions, techniques and design considerations ●Define application requirements and express them objectively as KPIs, SLO’s and SLI’s ●Decompose application requirements to find the right microservice boundaries ●Leverage Google Cloud developer tools to set up modern, automated deployment pipelines ●Choose the appropriate Google Cloud Storage services based on application requirements ●Architect cloud and hybrid networks ●Implement reliable, scalable, resilient applications balancing key performance metrics with cost ●Choose the right Google Cloud deployment services for your applications ●Secure cloud applications, data and infrastructure ●Monitor service level objectives and costs using Stackdriver tools
Audience:
●Cloud Solutions Architects, Site Reliability Engineers, Systems Operations professionals, DevOps Engineers, IT managers. ●Individuals using Google Cloud Platform to create new solutions or to integrate existing systems, application environments, and infrastructure with the Google Cloud Platform.
Course Outline
The course includes presentations, demonstrations, and hands-on labs.
Module 1: Defining the Service

Describe users in terms of roles and personas.
Write qualitative requirements with user stories.
Write quantitative requirements using key performance indicators (KPIs).
Evaluate KPIs using SLOs and SLIs.
Determine the quality of application requirements using SMART criteria.
Module 2: Microservice Design and Architecture

Decompose monolithic applications into microservices.
Recognize appropriate microservice boundaries.
Architect stateful and stateless services to optimize scalability and reliability.
Implement services using 12-factor best practices.
Build loosely coupled services by implementing a well-designed REST architecture.
Design consistent, standard RESTful service APIs.
Module 3: DevOps Automation

Automate service deployment using CI/CD pipelines.
Leverage Cloud Source Repositories for source and version control.
Automate builds with Cloud Build and build triggers.
Manage container images with Google Container Registry.
Create infrastructure with code using Deployment Manager and Terraform.
Module 4: Choosing Storage Solutions

Choose the appropriate Google Cloud data storage service based on use case, durability, availability, scalability and cost.
Store binary data with Cloud Storage.
Store relational data using Cloud SQL and Spanner.
Store NoSQL data using Firestore and Cloud Bigtable.
Cache data for fast access using Memorystore.
Build a data warehouse using BigQuery.
Module 5: Google Cloud and Hybrid Network Architecture

Design VPC networks to optimize for cost, security, and performance.
Configure global and regional load balancers to provide access to services.
Leverage Cloud CDN to provide lower latency and decrease network egress.
Evaluate network architecture using the Cloud Network Intelligence Center.
Connect networks using peering and VPNs.
Create hybrid networks between Google Cloud and on-premises data centers using Cloud Interconnect.
Module 6: Deploying Applications to Google Cloud

Choose the appropriate Google Cloud deployment service for your applications.
Configure scalable, resilient infrastructure using Instance Templates and Groups.
Orchestrate microservice deployments using Kubernetes and GKE.
Leverage App Engine for a completely automated platform as a service (PaaS).
Create serverless applications using Cloud Functions.
Module 7: Designing Reliable Systems

Design services to meet requirements for availability, durability, and scalability.
Implement fault-tolerant systems by avoiding single points of failure, correlated failures, and cascading failures.
Avoid overload failures with the circuit breaker and truncated exponential backoff design patterns.
Design resilient data storage with lazy deletion.
Analyze disaster scenarios and plan for disaster recovery using cost/risk analysis.
Module 8: Security

Design secure systems using best practices like separation of concerns, principle of least privilege, and regular audits.
Leverage Cloud Security Command Center to help identify vulnerabilities.
Simplify cloud governance using organizational policies and folders.
Secure people using IAM roles, Identity-Aware Proxy, and Identity Platform.
Manage the access and authorization of resources by machines and processes using service accounts.
Secure networks with private IPs, firewalls, and Private Google Access.
Mitigate DDoS attacks by leveraging Cloud DNS and Cloud Armor.
Module 9: Maintenance and Monitoring

Manage new service versions using rolling updates, blue/green deployments, and canary releases.
Forecast, monitor, and optimize service cost using the Google Cloud pricing calculator and billing reports and by analyzing billing data.
Observe whether your services are meeting their SLOs using Cloud Monitoring and Dashboards.
Use Uptime Checks to determine service availability.
Respond to service outages using Cloud Monitoring Alerts.

As today’s organizations migrate to the cloud, they expose themselves to a rapidly growing threat landscape. As if protecting on-premise data wasn’t hard enough, your team faces many new security challenges in the cloud. Now is the time to ask some tough questions. How ready is your company for the next approaching cloud security audit? Any idea what the auditors will be prioritizing? Are you confident that your security management practices are able to keep data safe in the cloud? All right, deep breath.

The good news? You’ve come to the right place, and it’s not too late. On November 19th, 2020, we hosted a webinar with Jacques Nack, CEO at JNN Group, and John Gukian, senior engineer at IBM, and picked their brains on cloud security, compliance, and, specifically, how to audit your cloud environments to suss out potential vulnerabilities. This article will discuss industry changes, what many organizations currently do to keep their cloud data safe, and what your team can do to better prepare for your next security audit. There’s a lot to learn, so let’s get started.

Industry changes
Organizations have increasingly turned to cloud services in the last decade. In 2010, worldwide spending on public cloud services was 76.94 billion with projected growth to 362 billion by 2022. Keep in mind, 67% of enterprise infrastructure will be cloud-based and a whopping 82% of workload will be in the cloud by the end of 2020. Cloud services offer organizations increased agility, flexibility, and speed, but many aren’t prepared for the increased security and compliance challenges of using cloud resources.

Security risk has grown exponentially with the arrival of remote workforces. Cloud data is being accessed from anywhere and everywhere, attackers have more vulnerabilities to target, and the job of safeguarding data is more challenging than ever. Companies now realize security and compliance in the cloud requires ongoing, relentless effort.

Addressing security in the cloud

Securing data in your cloud environments comes with unique challenges and raises a new set of questions. What’s the appropriate governance structure for an organization’s cloud environment and the data that resides within them? How should cloud services be configured for security? Who is responsible for security, the cloud service provider or the user of that cloud service?

Cloud compliance is becoming front of mind for organizations of all sizes. Smaller companies with limited staff and resources tend to rely more on cloud vendors to run their businesses and to address security risks (we’ll get into why this is a bad idea later in this article). Often roles will overlap with team members wearing many hats in smaller operations. Larger enterprises frequently keep more security and compliance duties in-house, using vast resources to create individual teams for threat hunting, risk management, and compliance/governance programs.

Regardless of size, the challenge of balancing security and business objectives looms large for all companies. Security must be built around the business, and Jacques accurately describes the nature of the relationship: “Security is always a support function around your business.”

Many teams seeking to build assurance while managing cost rely on Governance, Risk and Compliance (GRC) frameworks to keep their data secure in the cloud. There are many available, such as the Cloud Security Alliance Cloud Controls Matrix (CSA CCM), NIST 70053, and ISO 27001, which can help your team better understand cloud-specific compliance considerations and prepare for IT compliance audits.

Which one you choose should depend on your organization’s unique circumstances, preferences, and partners. For example, the Cloud Security Alliance Cloud Controls Matrix is specifically designed to provide fundamental security principles to guide organizations in assessing the overall security risk of their cloud environments. FEDRAMP would be a sensible choice for companies doing business with the federal government. Jacques recommends taking the time to thoroughly understand your business environment, risk tolerance, and maturity level to implement controls before finalizing your risk framework.

Key Security and Compliance Considerations When Operating in the Cloud

When assessing the security posture of your cloud environment, the first question both you and your auditor need to ask is, “Where is your data going?” “Your data’s journey—how it’s received, stored, handled, and treated by third parties—will determine your cloud security and compliance agenda,” says Jacques. All security controls and processes must align with your data’s flow around business objectives. Keep in mind that security’s role is supportive but must never become secondary.

Security by design

During the age of legacy systems, security was often “bolted on” as an after-thought. This doesn’t fly today as cloud systems demand a renewed awareness and commitment from the top, embedding security into the company culture and daily operations.

With this new security by design mindset, all departments share responsibility and empowerment in the decision process. Security by design is the only way modern enterprises can achieve the agility and flexibility needed to face the cloud’s continually evolving threat landscape.

Building your cloud compliance program

Both of the experts we interviewed agree that today’s organizations need an established cyber program to help prepare for cloud compliance audits. If your company doesn’t have established security management processes, you will struggle when it comes to passing cloud audits.

So, what does your organization need to do to ensure compliance? Below are some key steps to create a compliance program:

Determine your level of risk tolerance
Assign critical roles like security and privacy officers
Select the compliance framework that you will build around
Design your controls in alignment with business objectives
Adopt a privacy policy to govern how data is shared
Draft an administration contract to document your data handling policies
Adhering to these steps will help you create a solid foundation for maintaining information security in your cloud environment.

Key Compliance Considerations for Cloud Environments
One of the most important things to focus on is asset management. You need to document all the cloud services within your cloud environment as well as the data that resides within them. Organizations should define how all cloud services should be securely configured, to prevent them from becoming exploitable.

Knowing What Regulations Apply to Your Data

This can be tricky because you’ll need to keep up with region-specific and sometimes overlapping privacy regulations. For example, you’re doing business in Italy and must adhere to GDPR, but Italy may also have its own set of required laws.

Cloud Strategy & Architecture

Organizations should clearly define their cloud account structure, ownership, and accountability.

Change Control

The agility, speed, and flexibility of cloud environments make changes difficult to control. Change processes in traditional on-premise environments typically involve multiple roles and approvals and could take days or weeks. With the cloud, infrastructure is software, and their entire lifecycle may only last minutes or seconds. Companies should use automation and leverage cloud services to continuously monitor configurations and immediately remediate issues.

Signs of success

How do you know your organization’s cloud security and compliance program is positioned for success? Besides getting a thumbs up from auditors, there are other ways to gauge your program’s effectiveness.

John Gukian suggests looking at a company’s onboarding process and how new staff is introduced to security policy. Is there a well-understood set of policies and procedures to guide the onboarding process? How is access control handled? What is taught during the initial training period regarding security? Are awareness and best practices emphasized in the daily routine out of the gate?

Speaking of training, are there continuous education programs to keep staff current on rapidly changing cloud threats and remediation tactics? Hopefully so, because in the final analysis, training can make the difference in driving high levels of security awareness.

Passing your compliance audit is the crowning act of affirmation that pleases stakeholders—feel free to take a deserved moment to jump in the air and fist bump your teammates. However, remember cloud compliance results from a program of well-documented policies and procedures built on a continuous pattern of disciplined habits and company-wide awareness.

Conclusion
Securing cloud environments today comes with unique challenges, and verifying compliance is an ongoing quest for organizations and external auditors. Securing your cloud environment starts with understanding all cloud services in your environment and the flow of data between various services and applications. You’ll also need to pay close attention to who gets access to that data and who is authorized to make changes to configurations. It is only then that your team can create the proper processes and controls to ensure safety and compliance in the cloud.

Compliant organizations have established, well-documented cyber programs modeled on appropriate risk management frameworks. Their leaders embed security awareness into daily operations. They continually ingrain security awareness into their culture with robust awareness training.

So, do you feel better prepared for your next cloud compliance audit? We hope so; at the very least, you know the steps secure and compliant organizations take to keep their data safe in the cloud, and that’s what we call a good start.

Breaking business actions into their smallest possible units through microservices seems like a wonderful idea. However, in business-critical scenarios, the architecture needs to align and coordinate a half-dozen different distributed services and systems. If any step fails, an entire business process may need to roll back and remediate, much like a failed database transaction.

Microservices, by default, have no coordinating or controlling function: Individual services should inherently have no knowledge of the others outside of them. As such, maintaining smooth process flows between systems is much easier said than done without some kind of supervising controller mechanism. Fortunately, we can accomplish this through an architectural design known as the saga pattern.

What is the saga design pattern?
Picture an electronic data interchange (EDI) system interface that takes orders from customers and passes it to a product ordering system. That ordering service then sets off a chain of service calls that alert downstream manufacturing and shipping systems to finish the transaction. The diagram below shows a sample pattern illustrating this, where services call each other in a “round robin” style. Once the entire transaction chain is finalized, shipping sends a message to the product order service to confirm its completion. This can be thought of as a service choreography method.

Typically, the application will perform each one of these actions one at a time. If both the manufacturing order and the shipping order go through, but the payment transaction fails, either a team member or system must send the preceding services an alert to roll back.

Unfortunately, things get a little more complex when large-scale business transactions span significant periods of time. If any of those systems fail along the way, or the order is cancelled, we need a system that can perform a logical rollback and reset all those systems and transactions. For instance, a single failure during the payment transaction could very well require teams to roll back dozens of previous transactions that were completed by dozens of separate systems.

Airline ticketing systems are a perfect example of this problem. An unexpected event can cause people to cancel a trip minutes before the plane takes off. That single cancellation will cause ticketing systems to adjust seat availability, luggage to reroute, payment systems to issue any necessary refunds — and those are likely just a few of the steps involved.

As you can imagine, this system will need some way to “backwash” itself by reversing some of the earlier messages between the web services. Unfortunately, our transactions are just too complex and long-running to try to simply call all the services and commit them. This requires a controller with a little more nuance than a master program. This requires a controller that can take ownership over the entire process, which is where the saga pattern steps into the picture to deliver service orchestration.

Implementing saga for web services
To illustrate the saga design pattern, imagine that your team implements an enterprise service bus that listens for particular transaction events, and then forwards messages to the systems to start their operation. Once the bus creates message that represents the event, it is sent to any service associated with that event. In this case, the controller is a web service that is triggered by that event. That controller makes function calls to the next business web service in the queue.

Note this gives us two kinds of services:

The controllers, which receive events in the form of messages and then relay functional instructions to other services; and
The services that carry out the actual business process that needs to happen, and then communicate their completion to move the transaction along.

To implement these controller services, you can essentially create an event handler for an event-driven application, or introduce a finite state machine that simulates sequential logic. That component can then take the message, determine where it came from, analyze its status, and then process the next command. This can be accomplished simply through a switch statement, a set of nested IF commands, or even a single database lookup.

Keep in mind that implementing this design can still be tricky if the overall application demands high reliability. For example, imagine the controller service crashes after it triggers an ‘order placed’ event, but before it can pass a ‘payment complete’ event. When that service restarts, it will need to access some sort of transaction log, find the unprocessed transactions, resubmit the event (or events), and mark the work as done. This leaves the possibility that if a commit fails, a system will shut itself down after it sends the event, but before it actually confirms the commit. There are a number of architectural patterns that resolve this specific issue, but the simplest by far is to allow redundant messaging, but program the services to ignore them as needed.

Should you implement the saga design pattern?
The goal of the saga design pattern is primarily to take long-running, multisystem business processes and add the ability to roll back failed systems in an intelligent manner. However, it does add more code, which means new layers of complexity, debugging challenges, bandwidth requirements and processing power.

Put bluntly, an orchestration-focused saga pattern will usually prove to be overkill for simple application-based transactions. Unless your organization is notably struggling to manage large chains of business processes, the code complexity involved in a saga design pattern may cause more problems than it solves. But, if long-running transactions keep you up at night — especially when it comes to handling failures — the saga pattern may be the answer you’ve been looking for.

SoftServe, a leading digital authority and consulting company, announces it has achieved Premier Consulting Partner status in the Amazon Web Services (AWS) Partner Network (APN). The APN Premier Consulting Partner status differentiates SoftServe as an APN Partner that demonstrates expertise and notable success in helping customers design, architect, build, migrate, and manage workloads on AWS.

We are committed to our clients’ success in realizing the advantages of AWS to transform and future-proof their business, delivering end-to-end solutions that solve complex enterprise challenges while enhancing speed, agility, and scalability,” said Andrew Greene – Associate Vice President, Global Partnerships & Alliances at SoftServe. “We are excited to join the ranks of APN Premier Consulting Partners who have proven expertise at the highest level with the breadth of services and pace of innovation of AWS.”

To become an APN Premier Consulting Partner, companies must complete a rigorous approval process through accreditations and certifications; demonstrate a long-term investment in their relationship with AWS; and have extensive expertise in deploying customer solutions on AWS. APN Premier Consulting Partners also have a strong team of AWS Trained & Certified technical consultants and have deep expertise in project management and professional services.

SoftServe holds AWS DevOps, SaaS, Data & Analytics, Retail, and Financial Services Competencies. The company’s AWS solution areas span healthcare, financial services, retail, energy, and high-tech ISV industries; and with specialized teams of solution architects, big data engineers, and data scientists, SoftServe can guide customers to achieve Cloud success across the full spectrum of AWS Cloud services, workloads, and customer use cases.

Get the most from your AWS investments with speed, agility, and scalability to decrease time to Cloud value while ensuring your projects are deployed on time and on budget. Visit SoftServe’s AWS page to get started today.

SoftServe is a digital authority that advises and provides at the cutting-edge of technology. We reveal, transform, accelerate, and optimize the way enterprises and software companies do business. With expertise across healthcare, retail, energy, financial services, software, and more, we implement end-to-end solutions to deliver the innovation, quality, and speed that our clients’ users expect.

SoftServe delivers open innovation—from generating compelling new ideas, to developing and implementing transformational products and services. Our work and client experience is built on a foundation of empathetic, human-focused experience design that ensures continuity from concept to release. We empower enterprises and software companies to (re)identify differentiation, accelerate solution development, and vigorously compete in today’s digital economy. No matter where you are in your journey.

What Is DevSecOps?

DevSecOps—short for Development, Security, and Operations—is a methodology that integrates security practices and accountability into every phase of the application lifecycle. Rather than treating security as a separate audit performed at the end of a release cycle, DevSecOps distributes security responsibility across developers, QA engineers, security specialists, and operations teams alike.

When applied to the SDLC, DevSecOps enables continuous integration of security checks: code is continuously analyzed, tested, and validated against known vulnerabilities throughout development, not just before a production push. This approach also helps reduce the cost of compliance, since issues are caught earlier when they are cheaper and faster to fix.

Why Does DevSecOps Matter?

Vulnerabilities are discovered constantly across platforms, libraries, and operating systems. Patches are released regularly, but teams that only apply security thinking at the end of a pipeline are perpetually catching up. A single unpatched dependency or misconfigured infrastructure component can expose an entire application to exploitation.

In a fast-moving DevOps environment—where code changes multiple times per day and infrastructure is defined as code—manual, periodic security reviews are simply not sufficient. DevSecOps provides a continuous feedback loop that keeps security posture aligned with the pace of development.

Key Benefits of DevSecOps

• Reduces vulnerabilities present in application source code.
• Reduces vulnerabilities in Infrastructure as Code (IaC) definitions.
• Decreases the attack surface by limiting exploitable paths into the application.
• Improves application stability, availability, and overall security posture.
• Reduces downtime caused by security incidents or emergency patching.
• Lowers compliance costs by surfacing issues earlier in the development cycle.

How to Enable DevSecOps in Your Current Pipeline: Five Phases

Integrating DevSecOps into an existing DevOps pipeline does not require rebuilding your workflow from scratch. The following five phases provide a structured path for incrementally embedding security into your SDLC.

Phase 1: Secure Local Development

Security starts on the developer’s workstation. Most modern applications rely on open-source libraries and containerized services. If developers are using Docker images to replicate services locally, those images should come from trusted registries and be scanned for known vulnerabilities before use. Even official images from major providers can contain unpatched CVEs. Tools such as Trivy or Snyk Container can scan images during local development. Establishing a baseline of secure, up-to-date base images ensures that vulnerabilities are not baked into the development environment from day one.

Phase 2: Version Control and Static Security Analysis

When developers push code to a version control system (VCS) such as Git, automated security checks should trigger immediately. Static Application Security Testing (SAST) tools analyze source code without executing it, identifying common vulnerabilities like injection flaws, hardcoded secrets, and insecure dependencies.

Dependency scanning is equally important. Tools such as Snyk or Sonatype Nexus can automatically audit third-party libraries against databases of known vulnerabilities every time a pull request is opened. Blocking merges when critical vulnerabilities are detected prevents insecure code from advancing through the pipeline.

Phase 3: Continuous Integration and Secure Build

The CI/CD build environment itself must be hardened. Build servers should communicate exclusively over HTTPS, be isolated from the public internet where possible, and have access controls enforced. Build artifacts—container images, packages, or binaries—should be scanned for vulnerabilities before being promoted to any environment.

Common CI platforms used in DevSecOps pipelines include Jenkins, CircleCI, AWS CodeBuild, GitHub Actions, and Azure DevOps. Each can be extended with security scanning plugins or pipeline steps that fail the build when unacceptable risks are detected.

Phase 4: Secrets Management and Secure Deployment

Environment-specific configuration—database credentials, API keys, certificates—must never be stored in source code or passed as plain-text environment variables. A dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault should be used to inject secrets at runtime. The CI/CD tool retrieves and injects these values securely without exposing them in logs or pipeline definitions.

During deployment, enforce least-privilege access: the deployment process should only have permission to perform the specific actions it requires—nothing more.

Phase 5: Infrastructure Security and Runtime Monitoring

Once the application is in production, continuous monitoring is essential. An Intrusion Detection System (IDS) monitors host and network activity for suspicious behavior. Open-source tools such as OSSEC or its successor Wazuh provide host-based intrusion detection, log analysis, and compliance reporting across your server fleet.

In addition to IDS, Application Performance Monitoring (APM) tools and cloud-native monitoring services provide visibility into runtime behavior, helping teams detect anomalies that may indicate an active exploit or a misconfiguration causing unintended exposure.

No application is 100% secure after deployment. New vulnerabilities are disclosed daily. The goal of this continuous cycle is to detect, assess, and remediate issues as quickly as possible—closing the window of exposure before it can be exploited.

Essential Tools for a DevSecOps Pipeline

Tooling

• CI/CD Platform — Jenkins, GitHub Actions, CircleCI, AWS CodeBuild, Azure DevOps
• Version Control System — Git (GitHub, GitLab, Bitbucket)
• SAST / Dependency Scanning — Snyk, Sonatype Nexus, SonarQube, Semgrep
• Container Scanning — Trivy, Snyk Container, Clair
• Secrets Management — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
• IaC Security Scanning — Checkov, tfsec, KICS
• Intrusion Detection — OSSEC, Wazuh
• Runtime Monitoring / APM — Datadog, New Relic, AWS CloudWatch, Prometheus + Grafana

Core Processes

• Automated static and dependency vulnerability scanning on every commit or pull request
• Dynamic Application Security Testing (DAST) against running environments
• Automated regression and integration testing
• Automated artifact promotion gated on security scan results
• Continuous deployment with secrets injected at runtime
• Ongoing runtime monitoring and alerting

An Ideal DevSecOps Workflow

The following represents a typical end-to-end DevSecOps workflow:

1. A developer writes new code and opens a pull request in the VCS. Automated SAST and dependency scans run immediately.
2. QA or a security engineer reviews the static analysis results alongside the functional code review. Critical findings must be resolved before merge.
3. On merge to the main branch, the CI pipeline builds the artifact and scans the resulting container image or package for vulnerabilities.
4. Infrastructure for the test environment is provisioned automatically using IaC tools (e.g., Terraform, AWS CloudFormation, Pulumi), with security baselines applied via configuration management.
5. The automated test suite runs against the deployed test environment, covering functional, integration, API, and security tests (e.g., DAST scans using OWASP ZAP or a comparable tool).
6. On a successful test run, the artifact is promoted and deployed to production via the CD pipeline, with secrets injected securely at runtime.
7. The production deployment is monitored continuously using APM and IDS tooling. Alerts are routed to the on-call team for rapid response.

Common Challenges When Adopting DevSecOps

Tool Sprawl

Introducing too many security tools at once creates cognitive overload and alert fatigue, particularly for teams not yet familiar with security workflows. The recommended approach is to start with the highest-value tools—typically dependency scanning and secrets management—and add more capabilities as the team builds confidence and process maturity.

Cultural Adoption

DevSecOps is as much a cultural shift as a technical one. Developers need to understand why security gates exist and how to act on scan results. Ongoing training, clear documentation, and treating security findings with the same priority as functional bugs all help embed security into the team’s day-to-day habits.

Chasing Perfection

A DevSecOps pipeline will not be perfect from day one, and that is acceptable. Teams that try to enforce zero-tolerance policies before the process is mature often create friction that slows delivery without meaningfully improving security. Establish risk thresholds, start with critical and high-severity findings as hard blockers, and refine policies incrementally as the pipeline matures.

Conclusion

DevSecOps is not an optional add-on for mature organizations—it is the foundation of responsible software delivery in any environment where speed and security must coexist. By embedding security checks at each phase of the SDLC and distributing security accountability across the entire team, organizations reduce their exposure, improve compliance, and build higher-quality software. Start with the phases most relevant to your current risk profile, invest in team education, and iterate toward a fully automated security pipeline over time.

A People-First Philosophy Drives Award-Winning Firm

On Kenner Kingston’s desk at Salt Lake City-based Architectural Nexus sit schematic sketches that tell the story of the firm’s evolving mission. They are not renderings for a hospital wing or a research laboratory—two market segments where Architectural Nexus has built considerable expertise—but rather plans for a rainwater collection and reuse system for an off-the-grid home in Moab, Utah. The firm is collaborating with a community nonprofit that helps low-income residents construct their own sustainable straw-bale homes in the desert region.

That project encapsulates what Kingston, president of Architectural Nexus, describes as a fundamental shift in the firm’s thinking over the past five years.

“In the past five or so years, we’ve had a real shift in our thinking. It is not about the project or the building, it is about the people. We are people driven in the pursuit of meaningful experiences.”

— Kenner Kingston, President, Architectural Nexus

That philosophy earned Architectural Nexus recognition as ENR’s 2019 Intermountain Design Firm of the Year. The firm was founded through the 2003 merger of Jensen Haslem Architects and Thomas Petersen Hammond Architects, and has since grown to nearly 120 employees with offices in Salt Lake City and Sacramento, California. The firm reported revenue of $19.9 million in 2017 and $22 million in 2018, regularly ranking among the top ten design firms in the Intermountain region.

A Diverse and Multidisciplinary Design Studio

Robb Harrop, director of design at Architectural Nexus, articulates the firm’s client-centered approach succinctly: “We like projects that have a purpose and a vision. Something deeper than just keeping the rain off your head. We want to help clients find what is meaningful to them.”

That approach has produced strong results across multiple sectors. In healthcare, the firm has designed all four completed phases of the Huntsman Cancer Institute (HCI) at the University of Utah in Salt Lake City. The most recent phase—a 230,000-square-foot, $100-million research and office facility—exemplifies the firm’s patient-centered design thinking. Ben Tanner, executive director of the HCI, credits Architectural Nexus with understanding the unique needs of oncology patients.

“Their thoughtful work shows up in our patient satisfaction surveys. Patients always have great things to say about the look and feel of our buildings, and it’s a wonderful place for our clinical and research staff as well.”

— Ben Tanner, Executive Director, Huntsman Cancer Institute

A fifth phase of the HCI project was underway at the time of the award. The firm also completed a $114-million hospital in Nampa, Idaho, for the St. Luke’s Health System, which opened in fall 2017. Sandee Gehrke, vice president of operations at St. Luke’s, praised Architectural Nexus for investing time to understand the organization’s culture and brand identity before putting pen to paper.

Beyond healthcare, the firm’s Salt Lake City portfolio includes the $160-million, 400,000-square-foot Hardware Village apartment and condominium complex and a $7-million, 48,000-square-foot mixed-use residential and retail building in the city’s 9th and 9th district. In higher education, the firm completed the College Activities Center at Gillette College in Gillette, Wyoming, which features a 2,100-seat basketball arena, athlete support facilities, and flexible multi-use space.

Multiple LEED-certified designers work alongside specialists in landscape design, energy analysis, interior design, animation and visualization, and graphic design. Kingston notes that housing all these disciplines under one roof enables the firm to pursue both large, complex commissions and smaller experimental projects that push the boundaries of new technology and construction techniques.

Employee Ownership as a Cultural Cornerstone

Architectural Nexus was in the process of completing an Employee Stock Ownership Plan (ESOP) in 2019. For Kingston, what began as a leadership-transition and financial planning tool evolved into a genuine expression of the firm’s values.

“In 2014 we really had a change in mindset, and the ESOP went from being a financial tool to a culture tool, a way to align with the values of the firm… One of our partners said at one point, ‘What is more Nexus than an ESOP?’ and it just hit me that he was right.”

— Kenner Kingston, President, Architectural Nexus

Julie Berreth, vice president of operations, describes the firm’s internal culture as deliberately flat—characterized by a compressed compensation structure, a commitment to paying employees a living wage, and an extensive mentoring program designed to develop the next generation of architects and designers. The firm also joined the International Living Future Institute’s (ILFI) JUST program, which provides guidelines and external auditing on social justice and diversity performance.

To translate these values into direct community impact, Architectural Nexus launched the Nexus Builds program approximately two years prior to receiving the award. The initiative has partnered with the Seattle-based Block program to design and build tiny off-the-grid homes for people experiencing homelessness on donated urban lots. At the time of the award, employees were constructing a tiny home in a corner of the firm’s Salt Lake City headquarters parking lot, scheduled for delivery to Seattle. Director of communications Brian Cassil described the project as meaningful beyond simple volunteerism: “This is very purpose driven, but at its core it is also about mastery and how to get better at what we do.”

Beyond Conservation: Embracing Regenerative Design

Architectural Nexus has been an early advocate of sustainable design in the Intermountain region. In 2010, its Salt Lake City office became one of the first LEED Platinum certified buildings in the area. But the firm’s ambitions have since moved well beyond conventional green building metrics.

The clearest expression of this trajectory is the firm’s Sacramento office, a renovated office and warehouse building that opened in 2016 in the city’s historic district. The project was designed in accordance with the International Living Future Institute’s Living Building Challenge (LBC)—one of the most rigorous sustainability frameworks in the built environment industry. The completed building features a composting system, onsite agriculture, onsite water filtration and treatment, highly efficient electrical systems, and a solar photovoltaic array. It achieved LEED Platinum certification (level four) and was recognized in 2018 as the first Living Building in California and the 19th in the world certified by ILFI.

Berreth frames the firm’s design philosophy as anticipatory rather than reactive: “We don’t want to look at a building stuck on a site, but how it enhances the wider community and the people around it. Even if we are not putting something like PV panels on a project today, we want to anticipate they might be added one day and design space for them.”

Kingston sees regenerative design—which seeks to restore the built environment to a more natural state, treating buildings as habitats rather than machines—as the logical next phase for the industry and the firm’s greatest strategic opportunity.

“For a long time, most firms in our industry have been climbing this mountain called sustainability. Some of us who were lucky got to the top and looked across to see what was next, and we saw regenerative design, things like the Living Building Challenge… I’m excited for the next five years because I think we are perfectly positioned for oncoming growth in regenerative design.”

— Kenner Kingston, President, Architectural Nexus

From rainwater systems for low-income desert housing to one of California’s most advanced Living Buildings, Architectural Nexus continues to demonstrate that people-centered architecture and environmental responsibility are not competing priorities—they are the same goal expressed at different scales.

1. Ignoring Staffing and Workload Capacity

One of the earliest and most damaging mistakes is pushing a DevOps transformation on a team that is already stretched thin. Before introducing new processes, toolchains, or responsibilities, engineering leaders need an honest picture of current workloads and individual capacity.

Practical steps to avoid this mistake:

• Audit existing workloads — map what each team member is currently responsible for before layering on DevOps duties.
• Define clear KPIs — establish key performance indicators so progress is measurable and team health is visible.
• Balance responsibilities deliberately — use workload data to redistribute tasks fairly rather than defaulting to whoever volunteers or whoever is most senior.

Neglecting capacity planning leads to burnout, high attrition, and a DevOps rollout that stalls because the people driving it are exhausted or actively looking for other jobs.

2. Transitioning Without Adequate Planning

Competitive pressure can push organisations to announce a DevOps initiative before they are genuinely ready. The result is often engineers assigned to DevOps roles without the required depth of expertise, or small teams taking on complex projects to differentiate from competitors — only to deliver poor-quality outcomes.

A well-planned DevOps transition should include:

• Skills assessment — honestly evaluate the current expertise of everyone involved, not just their job titles.
• A phased roadmap — break the transition into stages with clear milestones rather than attempting a big-bang cutover.
• Training investment — identify skills gaps early and budget time and money to close them before those gaps become production problems.
• Realistic timelines — do not let competitive anxiety compress planning phases. A rushed plan tends to cost more time in rework than a careful one.

3. Prioritising Speed Over Quality

DevOps is strongly associated with delivery speed — shorter release cycles, faster feedback loops, and continuous deployment pipelines. This creates a tempting but dangerous assumption: that speed is the primary goal and quality is something to negotiate away when timelines are tight.

In reality, sustainable DevOps practices treat speed and quality as complementary, not competing. Automated testing, peer code review, and continuous integration exist precisely to maintain quality while moving fast. Skipping these in the name of speed typically produces:

• Higher defect rates that slow teams down later through incident response and hotfixes.
• Technical debt that compounds over time and eventually makes further acceleration impossible.
• Customer trust issues that are far more costly to recover from than a slightly delayed release.

The principle to internalise is that well-implemented automation — not corner-cutting — is what enables both speed and quality simultaneously.

4. Adopting New Technology Before Mastering the Current Stack

The DevOps tooling ecosystem evolves rapidly. New platforms, frameworks, and plugins appear constantly, and there is ongoing pressure to adopt whatever is trending — sometimes even tools that are still in beta — because competitors appear to be using them.

This approach introduces unnecessary risk. Before migrating to a new technology:

• Fully understand what you are replacing — know the current tool’s limitations, not just its shortcomings. Understand why you are switching.
• Evaluate maturity — a tool in beta carries integration and stability risks that may not be appropriate for production workloads.
• Stage your adoption — run new tooling in a lower environment first, measure the outcomes, and only promote to production when confidence is high.
• Avoid FOMO-driven decisions — the fact that a competitor is using a particular technology is not sufficient justification on its own.

Technology decisions should be driven by documented requirements and evaluated trade-offs, not by announcements at the most recent conference.

5. Failing to Get Buy-in From All Stakeholders

DevOps is not solely an engineering initiative. At its core, it is a cultural and organisational shift that bridges development, operations, security, product, and — in many cases — leadership. One of the most common failure modes is treating DevOps as something a single team implements in isolation, while other groups continue working in siloed ways.

For a DevOps transformation to take hold:

• Secure executive sponsorship early — without visible support from leadership, the cultural changes required will not happen.
• Involve all affected teams — development, operations, QA, security, and product teams all need to understand how their ways of working will change and why.
• Establish shared goals — teams that are measured on conflicting metrics (e.g., Dev rewarded for feature velocity, Ops rewarded for system stability) will naturally resist collaboration.
• Communicate changes proactively — developers introducing new features that affect the pipeline or infrastructure should communicate those changes to all stakeholders before deployment, not after.

Summary

DevOps adoption fails most often not because the underlying principles are flawed, but because organisations underestimate the organisational, cultural, and planning effort required. The five mistakes above — underestimating capacity, planning poorly, sacrificing quality for speed, chasing immature tooling, and neglecting stakeholder alignment — are entirely avoidable with deliberate preparation and honest self-assessment.

A phased, people-first approach will nearly always outperform a rapid, tool-first one in the long run. Take the time to plan well, invest in your team’s skills, and build the cross-functional trust that DevOps depends on.

Introduction
Docker Datacenter (DDC) is the enterprise container platform from Docker to be used across the entire software supply chain. It is a fully-integrated solution for container-based application development, deployment, and management. With integrated end-to-end security, DDC enables application portability by abstracting your infrastructure so that applications can move seamlessly from development to production.

What You Will Learn
This reference architecture describes a standard, production-grade, Docker Datacenter deployment. It also details the components of DDC, how they work, how to automate deployments, how to manage users and teams, how to provide high availability for the platform, and how to manage the infrastructure.

Some environment-specific configuration details are not be provided. For instance, load balancers vary greatly between cloud platforms and on-premises infrastructure platform. For these types of components, general guidelines to environment-specific resources are provided.

Understanding Docker Datacenter Components
From development to production, Docker Datacenter provides a seamless platform for containerized applications both on-premises and on the Cloud. It includes three components:

• Docker CS Engine, the commercially supported Docker Engine
• Docker Trusted Registry (DTR), a resilient and secure image management repository
• Universal Control Plane (UCP), the web-based, unified cluster and application management solution

Together they provide an integrated solution with the following design goals:

• Agility — the Docker API is used to interface with the platform so that operational features do not slow down application delivery
• Portability — the platform abstracts details of the infrastructure for applications
• Control — the environment is secure by default, provides robust access control, and logging of all operations

To achieve these goals the platform must be resilient and highly available. This reference architecture demonstrates this robust configuration.

Docker CS Engine
The building block of Docker Datacenter, the Docker Commercially Supported Engine (CS Engine) is responsible for container-level operations, interaction with the OS, providing the Docker API, and running the Swarm cluster. The Engine is also the integration point for infrastructure, including the OS resources, networking, and storage.

Universal Control Plane
UCP extends CS Engine by providing an integrated application management platform. It is both the main interaction point for users and the integration point for applications. UCP runs an agent on all nodes in the cluster to monitor them and a set of services on the controller nodes. This includes identity services to manage users, Certificate Authorities (CA) for user and cluster PKI, the main controller providing the Web UI and API, data stores for UCP state, and a Classic Swarm service for backward compatibility.

Docker Trusted Registry
The DTR is an application managed by, and integrated with UCP, that provides Docker images distribution and security services. The DTR uses UCP’s identity services to provide Single Sign-On (SSO), and establish a mutual trust to integrate with its PKI. It runs as a set of services on one or several replicas: the registry to store and distribute images, an image signing service, a Web UI, an API, and data stores for image metadata and DTR state.

Swarm Mode
To provide a seamless cluster based on a number of nodes, DDC relies on CS Engine’s Swarm-mode capability. Swarm-mode divides nodes between workers, nodes running application workloads defined as services, and managers, nodes in charge of maintaining desired state, managing the cluster’s internal PKI, and providing an API. Managers can also run workloads, in a DDC environment they run UCP controllers, and shouldn’t run anything else.

The Swarm-mode service model provides a declarative desired state for workloads, scalable to a number of tasks (the service’s containers), accessible through a stable resolvable name, and optionally exposing an end-point. Exposed services are accessible from any node on a cluster-wide reserved port, reaching tasks through the routing mesh, a fast routing layer using high-performance switching in the Linux Kernel. This set of features enable internal and external discoverability for services, UCP’s HTTP Routing Mesh (HRM) adding hostname-to-service mapping.

A Standard Deployment Architecture
This section demonstrates a standard, production-level architecture for Docker Datacenter using 10 nodes: 3 UCP controllers, 3 nodes for the DTR, and 4 worker nodes for application workloads. The number of worker nodes is arbitrary, most environments will have more depending on applications needs, it doesn’t change the architecture or the cluster configuration.

Access to the environment is done through 3 Load Balancers (or 3 load balancer virtual hosts) with corresponding DNS entries for the UCP controllers, the DTR replicas, and the applications running in the cluster.

The DTR replicas use shared storage for images. S3-compatible object storage (the default) and NFS storage are both covered in this section

Node Size
A node is a machine in the cluster (virtual or physical) with Docker Engine running on it. When provisioning each node, assign it a role: UCP Controller, DTR, or worker node so that they are protected from running application workloads.

To decide what size the node should be in terms of CPU, RAM, and storage resources, consider the following:

1. All nodes should at least fulfil the minimal requirements, for UCP 2.0 2GB of RAM and 3GB of storage. More detailed requirements are in the UCP documentation.
2. UCP Controller nodes should be provided with more than the minimal requirements, but won’t need much more if nothing else runs on them.
3. Ideal Worker nodes size will vary based on your workloads, it is impossible to define a universal standard size.
4. Other considerations like target density (average number of container per node), wether one standard node type or several are preferred, and other operational considerations might also influence sizing.

If possible, node size should be determined by experimentation and testing actual workloads, and they should be refined iteratively. A good starting point is to select a standard or default machine type in your environment and use this size only. If your standard machine type provides more resources than the UCP Controllers need, it makes sense to have a smaller node size for these. Whatever the starting choice, it’s important to monitoring resource usage and cost to improve the model.

Two example scenarios:

• One standard node size: 2VCPU, 8GB RAM, 20GB storage
• Two node sizes: 2VCPU, 8GB RAM, 20GB storage for UCP Controllers and 4VCPU, 64GB RAM, 40GB storage for worker nodes

Depending on your OS of choice, storage configuration for Docker Engine might require some planning. Refer to the Support Matrix to see what storage drivers are supported for your host OS. This is especially important if you are using RHEL or CentOS, which use device mapper with direct-lvm.

Load Balancers

Load balancers configuration should be done before installation, including the creation of DNS entries. Most load balancers should work with DDC. The only requirements are TCP passthrough and the ability to do healthchecks on an HTTPS endpoint.

In our example architecture, UCP controllers ensure UCP resiliency in case of node failure or controller reconfiguration. Access to UCP through the GUI or API is always done using TLS. The load balancer is configured for simple TCP pass-through on port 443, using a custom HTTPS health check at https://<ucp_controller>/_ping.

Be sure to create a DNS entry for the UCP host such as ucp.example.com and point to the load balancer.

The setup for the three DTR replicas is similar to setting up the UCP controllers. Again, use TCP pass-through to port 443 on the nodes, except the health check is at https://<dtr_replica_node>/health.

Create a DNS entry for the DTR host such as dtr.example.com and point it to the load balancer. It’s important to keep it as concise as possible because it will be part of the full name of images. For example, user_a‘s webserver image will be named dtr.example.com/user_a/webserver.

The application load balancer provides access to services HTTP endpoints exposed through UCP’s HTTP Routing Mesh (HRM). HRM provides a reverse-proxy to map domain names to services that expose ports and are attached to the ucp-hrm overlay network. As an example, the voting application exposes the vote service’s port 80. The HRM maps http://vote.apps.example.com to this port on the ucp-hrm overlay network, and the application LB itself maps *.apps.example.com to nodes in the cluster.

DTR Storage
The DTR usually needs to store a large number of images. It uses external storage (S3, NFS, etc.), not node storage so that it can be shared between DTR replicas. The DTR replicates metadata and configuration information between replicas, but not image layers themselves. To determine storage size, start with the size of the existing images used in the environment and evolve from there.

It’s best to use an existing storage solution in your environment so that image storage can benefit from existing operations experience. If you have to chose a new solution, consider using S3-compatible object storage, which maps more closely to registry operations.

Recommendations for the Docker Datacenter Installation
This section will detail the installation process for the architecture and provide a checklist. It is not a substitute for the documentation, which provides more details and is authoritative in any case. The goal is to help you define a repeatable (and ideally automated) process to deploy, configure, upgrade and expand your DDC environment.

The three main stages of a DDC installation are:

1. Deploying and configuring the infrastructure (hosts, network, storage).
2. Installing and configuring the Docker Engine, running as an application on the hosts.
3. Installing and configuring UCP and the DTR, delivered as containers running on the engine.

Infrastructure Considerations
The installation documentation details infrastructure requirements for DDC. It is recommended to use existing or platform specific tools in your environment to provide standardized and repeatable configuration for infrastructure components.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/docker_subscription.lic:/config/docker_subscription.lic \
  -e UCP_ADMIN_PASSWORD=password --name ucp docker/ucp install --host-address IP_or_interface \
  --san manager1.example.com --san ucp.example.com 

docker swarm join-token worker

docker swarm join \
--token SWMTKN-1-00gqkzjo07dxcxb53qs4brml51vm6ca2e8fjnd6dds8lyn9ng1-092vhgjxz3jixvjf081sdge3p \
192.168.65.2:2377

UCPID=$(docker run --rm -i --name ucp -v /var/run/docker.sock:/var/run/docker.sock docker/ucp id)
docker run --rm -i --name ucp -v /var/run/docker.sock:/var/run/docker.sock docker/ucp backup --id $UCPID --passphrase "secret" > /tmp/backup.tar

docker logs ucp-controller

docker service create --name www -p 80:80 --label com.docker.ucp.access.label=development nginx

curl --silent --insecure --header "Authorization: Bearer $(curl --silent --insecure \
     --data '{"username":"<admin-username>","password":"<admin-password>"}' \
    https://<UCP-domain-name>/auth/login | jq --raw-output .auth_token)" \
    https://<UCP-domain-name>/enzi/v0/accounts | jq .

docker exec -it ucp-auth-api sh

enzi db-status