Shifting left with Lightlytics

Michael Schwartz
Found on CloudWiki:
No items found.

TL;DR

Shift-left is a concept that has been gaining traction within many organizations in the past few years.
With the shift-left methodology, quality and security issues are handled earlier in the development process.
If you shift the process of reviewing, testing, detecting issues, and resolving them to the left, you are helping teams work on preventing issues. This is instead of working reactively to identify and rectify them.

As an example, the existing dependencies between the development and operations teams pose a huge challenge.
In order to be truly independent and apply the shift-left approach to development, developers today need to be knowledgeable and comfortable with various technologies and areas they don't necessarily work in every day.
In a cloud-native organization, for example, a developer should know the cloud environment, its services, and dependencies, so that he or she can perform all the necessary tests at the appropriate stage.

Shifting left in the Infra world

A more reactive approach is currently being implemented in the infrastructure sector - for instance, Terraform is being used as an infrastructure as a code tool. Each code change is reviewed at both the TF code and the TF plan levels.
Due to the complex nature of resource dependencies, it is almost impossible to predict the impact of TF codes from the code review stage. In addition, senior Devops engineers, or even Devops team/group leaders, are some of the busiest engineers in the organization. This makes the code review process slower since they need to be involved.
The market is currently taking the reactive approach precisely due to the reasons previously mentioned - if something unexpected happens after deploying the revised infrastructure code, all engineers will work as hard as they can to revert it back to the previous state.
We still lack a platform that will enable us to handle these unexpected behaviors before actually deploying the new infrastructure code.

What are the reasons for shifting left in Ops?

An overview of what can be achieved by moving testing and security to earlier stages in infrastructure development is as follows:

  • Continuous Delivery - Identify and fix infrastructure code vulnerabilities early on in the development process.
  • This will lead to fewer complex problems later on.
  • Reduce the risk of bugs and issues in production. This can be achieved by automating the availability and security testing and security rules in the CI/CD pipeline.
  • Lay the groundwork for continuous deployment and testing.
  • Maintain a secure environment by avoiding exposure to security risks and configurations that violate compliance and business standards.
  • As issues are discovered later in the deployment cycle, the cost impact and mitigation time significantly increase

Current methods of shifting left for Ops teams

  • Unit tests ensure that a section of code (called a "unit") conforms to its design and behaves as intended. Let's take a look at Terraform code that creates a virtual machine. It creates a VM in this case and does not fail. For instance, Terratest is an awesome tool for Terraform unit testing.
  • As part of a Code Review, static code analysis (also known as source code analysis) is performed. The term "Static Code Analysis" refers to running static code analysis tools that attempt to highlight vulnerabilities within "static" (non-running) code. The use of this method helps organizations enforce guardrails and detect security issues and deviations from best practices.
  • Run the same code in a dev/staging environment and destroy the tests. The major issue with this method is that most of the time, the staging and dev environments will not contain the exact workloads that a production environment contains, and the behaviour in the production account will probably be different.

With Lightlytics, you can shift left and take advantage of Continuous Simulation

Continuous Simulation is the missing link to fully automate your pipeline and avoid unexpected behaviour when deploying your infrastructure code.
Imagine knowing the impact of a certain infrastructure change, before it hits production uptime.
It's basically the holy grail of DevOps, and it's finally possible with Lightlytics!

Before deploying new configurations to production, Lightlytics allows you to simulate all possible dependencies to predict all possible outcomes. Once a PR is simulated, you can easily assess how each line of code affects your production environment. This will enable you to avoid failures such as service interruptions, data loss, redundancy issues, and compliance violations. At this stage, you can also enforce architectural and security standards at the system level and not at the resource level, as in static code analysis.

It is possible to predict impact even in the most complex scenarios, such as multi-account deployments, and across layers of infrastructure - since they do not always work together well.

Through continuous simulation, you can automate your pipeline completely, and it eliminates the time-consuming process of code review between parties by providing an accurate picture of what production will look like after the change is implemented. People are not able to see and assess the countless risks associated with new configuration deployments because of all the dependencies. The more dependencies there are, the more that can go wrong. Thus, the higher the cost will be when business-critical operations fail, customer service or payments stop, and time-to-market slows.

Advantages of shifting left with Lightlytics:

  • Drastically reduce availability and security risks when deploying new infrastructure code.
  • Shorten the code review time. Allow your senior engineers/ Team leaders to utilize their working hours in a more efficient way.
  • Make sure that the intent of the change is actually met, before applying the code - this is the end of multiple Terraform apply and destroy attempts until you receive the desired outcome. With Lightlytics, no matter how complex your Terraform code is, Lightlytics will show you in a visual way whether your Terraform code achieves your tasks or not.
  • Enable more engineers to understand and modify infrastructure with confidence - Currently, the ability to create, modify and destroy infrastructure belongs to the most skillful DevOps engineers in the organization, however, who says it should be like that? Lightlytics will show you in a visual way how the entire AWS is going to be impacted by the new infra code, and exactly what changes are needed to meet a certain requirement

So what are you waiting for? Schedule a demo or sign up and start your free trial now!

Read the GigaOM CXO Decision Brief:
Cloud Change Intelligence
What's new
Deploy cloud infrastructure changes with confidence. Troubleshoot faster with the complete context of your cloud environment.
GET STARTED