Guest post originally published on Mia-Platform’s blog by Michel Murabito, Developer Advocate at Mia‑Platform.
In the ever-evolving world of software development, a new approach to developing and delivering software, called shift down, has emerged to challenge conventional methods.
The concept of shifting down to the platform instead of shifting left to the developer brings about a paradigm shift that reimagines how we optimize our software delivery process. Richard Seroter’s “The Modernization Imperative: Shifting left is for suckers. Shift down instead” is a great article that emphasizes the relevance and urgency of the shift down philosophy.
Platform engineering is a key discipline in this new era of DevOps teams shifting down to the platform. It involves designing and creating streamlined workflows and tools that make it easier for software teams to build and deploy their applications.
By embracing this new change, organizations can gift their development teams the tools to work to ensure that software is delivered with better quality and speed.
This article explores the shift left and right approaches to building and testing software, their limitations, and how shifting down helps bridge the gaps and provide a more comprehensive strategy for modern software development.
What is shift left?
The “shift left” concept coined by Larry Smith in 2001 changed how we approached software development. It involves moving the testing phase to the beginning of the software development journey. This shift represents a proactive and strategic approach where the primary focus is to test the software at its early stages and repeat the process frequently.
The significance of this approach lies in its ability to detect and address defects before they can permeate the entire application.
Although shift left’s emphasis on early testing works, it does not fully capture real-world usage scenarios and production environments. This problem highlights the importance of incorporating shift-right testing.
Understanding the traditional shift left V Model
The shift-model is a software development lifecycle (SDLC) model where the execution of processes happens sequentially in a V-shape. It is also known as Verification and Validation model.
It is a shift left approach based on the association of a testing phase to each corresponding development phase. The V-Model is an extension of the Waterfall model, as the next phase only begins after the completion of the previous phase.
Using the V-Model has its advantages. It is a highly disciplined approach, as one phase starts when the previous one has ended. It is also easy to use and understand. However, its resemblance to the Waterfall Model also brings forth some of the limitations associated with the model:
- For larger projects, the V-Model’s structured and interconnected phases might become cumbersome for testing teams to manage, leading to coordination challenges and increased complexity.
- Customer involvement is typically more concentrated toward the V-Model’s later stages of the development process resulting in reduced opportunities for early feedback and potential misalignment with customer expectations.
- The model does not inherently support rapid changes or iterative development.
The need for more advanced shift left testing methodologies, such as incremental and model-based approaches
With modern applications becoming more complex, there is a need for more advanced types of shift left testing approaches, such as incremental testing and model-based testing approaches.
Incremental testing approach
The incremental shift left testing approach is a software development process that promotes early and frequent testing of individual components or units during development. This approach works best with complex systems and helps mitigate the risks of issues snowballing into more complex problems during later phases.
Model-based testing approach
The model-based shift left approach testing helps to mitigate defects in requirements definition, architecture, and design phases. This approach tests executable requirements, architecture, and design models to eliminate 45-65 percent of errors introduced in these early phases.
The model-based approach is the newest method in shift left testing, and its major advantage is that it works in the earlier stages of the project’s development cycle.
What is the shift right model?
The “shift right” concept introduces a dynamic shift in how we approach software testing and quality assurance. Unlike traditional methods like shift left focusing solely on pre-production testing, “shift right” advocates extending the testing phase into the live production environment. This approach captures real-world user experience by conducting rigorous assessments under genuine conditions.
Shift right involves deploying our application into the real world and observing how our application responds to users, data, and the environment. By subjecting our application to authentic user loads and actual usage scenarios, shift right allows us to gain valuable insights into how our application behaves, how responsive it is, and how well it stands up to the demands of the users.
Here are some of the salient benefits of shift right testing:
- Identifying the actual workload of customer traffic and ensuring that the software can handle precise user demands and requirements in a live production environment.
- Identifying user preferences through A/B testing or Blue-Green deployments.
- Detecting and resolving potential problems in the production environment before they escalate and impact a more extensive user base.
Balancing Shift Left and Shift Right: A Holistic Approach to Application Security
Although the shift left approach served its purpose over the years, overemphasizing shift-left methodologies can present certain drawbacks. It does not encompass the complexities of real-world scenarios and production environments. This gap in testing could strain the development team and shift their attention away from essential tasks to address these issues during later stages.
This section discusses the potential security issues that may arise from a heavy focus on shift left practices and the importance of shift right testing coupled with shift left testing in minimizing risks and ensuring robust application security.
Security concerns from a heavy focus on shift left testing
Shift left security testing does not deliver the full context to secure infrastructure but rather a tiny piece of the puzzle to deepen security across modern applications.
Shift left works really well for developmental testing. However, it loses value rather quickly when applied to applications and technologies already in use within an environment, so the shift right testing approach will always be important. Another example of the inefficiency with shift left testing is the case of APIs. The shift left approach might need to thoroughly assess the potential vulnerabilities in API authentication and authorization mechanisms, leaving the API vulnerable to unauthorized access, data breaches, and malicious attacks.
A comprehensive operational testing strategy that includes shift right practices is crucial to mitigate these security risks.
Importance of balancing shift left and shift right to address security concerns effectively
The over-reliance on just the shift left testing makes us miss certain security vulnerabilities that only become apparent in real-world usage; shift right, on the other hand, extends testing into the production environment.
In essence, shift left testing brings development and testing together by including development testing in the software development cycle. On the other hand, shift-right testing encompasses operational testing. Security teams can establish a strong security framework by combining these testing approaches.
The Application of Shift Left and Shift Right in Microservices Architecture
Microservices‘ modularity and interoperability enable frequent delivery of large and complex applications, which challenges the shift left testing approach for many reasons:
- Microservices often communicate through APIs, making their interactions intricate. Shift left testing might struggle to simulate the dynamic and interconnected nature of these services accurately.
- Isolating individual microservices for testing can be challenging. Shift left practices might need to effectively address issues that arise when multiple services interact, resulting in undetected problems in the overall system.
- Microservices architecture can involve many services, making comprehensive testing resource-intensive.
- Shift left might miss security vulnerabilities specific to microservices, such as inadequate data validation between services, token propagation issues, or improper access controls.
Importance of incorporating shift right tests to ensure comprehensive monitoring and feedback
In microservices, shift right, and shift left testing approaches are vital tools for comprehensive monitoring and feedback. Shift right allows us to evaluate the entire ecosystem of different microservices under genuine conditions, providing valuable insights into how these services interact with each other, scale, and respond to user loads.
The shift right approach enables continuous improvement through iterative feedback loops. This iterative approach allows us to improve the customer experience with our application based on user feedback and real-world data usage patterns.
What is the shifting down approach?
The shift down approach leverages existing platforms and empowers less technical experienced people to solve more issues earlier in the process. With the shift down approach, we reduce the cognitive load on the software developers by taking full advantage of the available technology., and pushing more workloads down the platforms they are already using.
The shift down approach in development aims to improve efficiency and reduce cost by freeing senior developers to focus on more complex and innovative tasks. We can observe the different examples of shift down approaches in different scenarios, including:
- Empowering Tier 1 support engineers to troubleshoot and resolve issues without escalating to more senior engineers.
- Self-service tools and documentation allow users to resolve their problems without contacting support.
Advantages of compressing the tech stack and reducing cognitive load on developers
Compressing the tech stack involves strategically choosing and using a smaller set of technologies, frameworks, and tools in development. This approach aims to reduce the complexity of managing multiple dependencies and interactions, thereby streamlining development for software developers.
Compressing the tech stack and reducing the cognitive load on developers can offer several advantages, some of which are:
- Reducing the number of technologies and frameworks that a developer needs to work with
- With a smaller set of technologies and tools, developers can quickly get up to speed and start working on the project.
- Reduced cognitive load means that developers have enough time and resources to work on new projects and achieve business goals instead of struggling to understand new complex tools.
Shifting Down in the Software Delivery Cycle
With the shifting down approach moving responsibility to lower teams and platforms, it helps to promote smoother collaboration, quicker issue resolution, and improved software delivery efficiency.
Platform engineering is a discipline that shares shift down’s goal of improving efficiency in software delivery. Platform engineering is designing and building toolchains and workflows that enable self-service capabilities for software engineering in the cloud-native era.
Alongside enabling self-service capabilities, there are other benefits of embracing platform engineering across different stages of the software delivery cycle:
- Platform engineering enhances the Developer Experience by streamlining processes and offering a user-friendly environment.
- Platform engineering helps improve efficiency and accelerate development in the software delivery pipeline by automating tasks and providing standardized tools and processes;
- The standardized processes, also known as golden paths, ensure uniformity across stages, therefore, reducing errors and enhancing quality;
- Platform engineering can lead to lower costs and more efficient use of resources.
Importance of collaboration and communication in implementing platform engineering practices
To effectively implement platform engineering, we need a cross-functional effort that requires collaboration and communication between different teams. This collaboration ensures that everyone understands and works towards shared goals.
Communication bridges gaps between teams and encourages constant feedback, shared insights, and best practices, enhancing continuous improvement, learning, and problem-solving.
Challenges and Mitigation Strategies for Shifting Down
This article discussed in detail why shifting down to platform or less experienced team members is the right move for our organization; however, shifting down can be challenging for many reasons.
Firstly, shifting down requires a significant cultural shift in the organization, as teams must be willing to give up a little more control and work collaboratively. Secondly, there needs to be a significant investment in tooling, infrastructure, and training for less experienced team members to support the shifting down approach.
Tips for overcoming the challenges posed by the shifting down approach
To navigate the challenges in shifting down to the platform, organizations can adopt a number of practical strategies, some of which include:
- Start with a small project and team, then gradually expand the approach. Shifting down the entire project at once is exhausting.
- Invest in proper tooling and infrastructure that can support the shift down approach. Embrace automation and easy-to-use self-service tools that can empower developers to adapt and thrive in platform engineering
- Build a strong team of platform engineers that have a deep knowledge of shifting down to platforms
Benefits of shifting down to the platform instead of shifting left
Shifting down to the platform offers significant long-lasting benefits, and these benefits include:
- Increased efficiency in the software delivery process: Shifting down to the platform helps to free up resources and experienced engineers to focus on more complex tasks to streamline development, testing, and operations processes. Shifting down to platform leads to faster issue resolution and faster time to market
- Improved agility: Shifting down to the platform makes it easier to deploy and debug new components and features, thereby improving the overall code quality
- Reduced costs: Shifting down can reduce costs by centralizing infrastructure and resources, leading to lower IT costs and more efficient use of resources
Conclusion
Shifting down to the platform offers a transformative approach that optimizes resource utilization to fast-track and enhances organizations’ software delivery pipeline process. Organizations traditionally employed the familiar shift-left strategy in software development, but its limitations have spurred the shift down approach.
In the world of platform engineering, organizations can leverage existing platforms and tools to design, build, and deploy robust toolchains that offer standardized processes, automation, and simplified deployments transcending intricate technical complexities.
Embracing the shift down philosophy, hand in hand with platform engineering, ensures not only efficient utilization of resources and expertise but also an ecosystem where continuous learning, collaboration, and innovation flourish.
Leading platform builders like Mia-Platform empower organizations to seamlessly integrate platform engineering into their software development and deployment cycles.
Download this white paper to understand more about Why and how to evolve into a Platform Company and the advantages of shifting down.