devopsy.kinsta.cloud

Tag: automation

Harness Invests in Automating Continuous Delivery

Fresh off raising an additional $60 million in funding, Harness plans to make more investments in machine learning algorithms to advance continuous delivery through automation.

Harness CEO Jyoti Bansal said the startup, which he co-founded with Rishi Singh, a former DevOps platform architect at Apple, is now in a position to invest more aggressively in additional engineering and sales resources needed to expand adoption of the cloud-based service, which provides a level of abstraction through which much of the continuous delivery process can be automated using drag-and-drop graphical tools. Bansal and Singh co-founded Harness after AppDynamics, provider of an application performance management (APM) platform Bansal also co-founded and served as chairman of the board, was sold to Cisco Systems.

Bansal said Harness takes advantage of YAML files and machine leaning algorithms to present DevOps teams a set of visual tools accessed via a cloud service that enables them to build sophisticated pipelines as quickly as 10 minutes. That approach promises to significantly advance DevOps adoption by making it easier for IT operations teams to set up those pipelines as part of continuous delivery process without needing deep programming expertise.

While there’s been a lot of progress made in terms of driving adoption of best continuous integration practices among developers, the continuous delivery side of the DevOps equation has proved much more difficult to achieve. Most IT organizations rely on multiple platforms that have their own unique attributes. As such, IT operations teams typically have created their own scripts or rolled out automation frameworks such as Ansible to allow them to automate some aspects of the application deployment process.

However, Bansal noted, custom scripts typically don’t scale very well and usually have not been well-documented. What’s more, frameworks such as Ansible are still too low-level to enable DevOps teams to build pipelines in minutes. The approach Harness has designed enables DevOps teams to describe their intent using a set of visual tools, which then employs machine learning algorithms to automate the deployment process regardless of the underlying platform, he said.

That approach is further augmented by a set of rules that can be added to make sure security and compliance requirements are met, he noted, adding Harness also provides views into how processes are being automated to provide DevOps teams with the confidence required to trust a highly automated platform.

Bansal said the goal is to not just make it simpler to build and deploy pipelines, but also maintain them in what have become highly dynamic IT environments where there is simply too much data that needs to be tracked for human administrators to effective manage relying on low-level tools and frameworks. Rather than having to build and deploy the framework needed to achieve that goal, he said, Harness is making it possible to automate the continuous delivery process using a cloud service on demand.

It may take a while for IT organizations get comfortable with the level of automation being enabled by machine learning algorithms. But like it or not, it’s already becoming apparent the ability to dynamically manage IT at scale is clearly on the cusp of making another significant leap forward.

— Mike Vizard

April 23, 2019
5 Mistakes to Avoid When Chasing DevOps Transformation

In less than a decade, DevOps has become a buzzword of the IT industry, and enterprises are already reaping its benefits.

But the implementation part still remains a question for many firms, considering the key mistakes that many organizations report in their very approach to DevOps. Most firms are also unsure about what outcomes they want to see from the process.

Wondering if you’re making the same mistakes? Here are the five most common mistakes that can be included as part of a checklist to successful DevOps implementation.

Misaligned Focus

While automation and tools are the elements that steer DevOps, most firms believe that DevOps is all about tooling and automation. In reality, tools are mere enablers and automation takes off the burden of manual work. This collaboration helps firms to realign focus, eliminate process repetition and effectively manage the available software.

Ultimately, the value of tools lies in what people achieve through them and hence, firms should focus on utilization to achieve expected goals.

Faster = More Value

Time-to-market is another key aspect of DevOps that needs a different viewpoint. In general, most firms think of DevOps as a process to increases the pace of the software process.

But it has to be understood that DevOps takes a lean movement. By developing software on an exponential pace, DevOps process lets you have products delivered more frequently.

The lean manufacturing process achieves success in software delivery by breaking the chunks of code into manageable units, which naturally results in continuous delivery. Moreover, if you need to alter one component, you can do it simultaneously without impacting the other. This allows you to deliver at optimum speed and still maintain business agility.

Lack of Continuous Improvement

As you learn more and get better, you’ll find better ways to improve or cut down steps that add no value. But this will require some amount of effort and investment.

DevOps delivery pipeline consists of feedback loops, which allow you to inspect, reflect and decide if you are going in the right direction. The faster you improve, the sooner you benefit from the improvements in the process.

It’s just not about reviewing the process twice a year or every quarter. Continuous improvement demands that every individual part of the DevOps process should get better all the time.

Dishonesty About Your Progress

It is important to be clear about goals and timelines as an individual contributor in the software development process. A delay from an individual contributor can lead to a delay on everyone’s part in the process. This also adds to the lack of trust on a team’s potential.

Whether it is about building features or changing processes, make realistic estimates. It is important to break your tasks into smaller pieces, making it easier for estimates.

Change Comes Easy

Change is a part of the growth process and it’s inevitable. But most people fail to adapt to change and continue with familiar patterns, especially when change is difficult.

It is important to keep adapting to changing trends in the industry, processes and technological advancements including the software delivery lifecycle to evolve and grow, even when it is tough. Increased success will always bring more willingness to change.

Conclusion

DevOps is a process that drives innovation and business growth at a faster rate, provided you keep a check on the pain points that hinder the successful DevOps implementation.

— Veritis

April 23, 2019
What Can Automation Learn From DevOps?
A recent Capgemini survey revealed that while enterprise-scale automation is still in its infancy, IT automation projects are moving along. IT is starting to view automation less tactically and more strategically.

IT leads automation implementation (respondents were asked to select all that apply: “In which of the following functions has your organization implemented automation initiatives?”). Capgemini Research Institute, Automation Use Case Survey; July 2018, N=705 organizations that are experimenting with or implementing automation initiatives.

The Capgemini survey also showed that IT automation can be responsible for several quick wins, including self-healing, event correlation, diagnostics, application releases, cybersecurity monitoring and storage and server management tasks. These projects not only lead to massive IT cost savings but, more importantly, to an increase in reliability and responsiveness to customer demands and business services. That would indicate that while automation is a great solution for manual work, it’s also a part of a high-level, strategic IT plan to innovate the business.

As DevOps practices such as agile methodology, continuous deployment and optimization start to take hold within the modern enterprise, it stands to question: Can automation be agile as well? This is the promise of artificial intelligence (AI) for IT operations, or AIOps, but if that’s not a possibility for your IT organization today, it’s important to make sure that your automation practices are continuously optimized to fit the task. Setting and forgetting was a practice of the server era, and in a world of on-demand infrastructure, automation ought to be continuously optimized and evaluated for maximum benefit.

The New Expectations of Automation

IT automation projects can have serious ramifications if anything goes wrong because when the machines execute a policy, they do it in a big way. This is perhaps the chief argument as to why it’s critical that progressive steps are used to define and evaluate both the process being automated and the automation itself—they mitigate the seriousness of any issue that can arise. This is why it’s important to consider the following:
1. Is this a good process, and is it worth automating?
2. How often does this process happen?
3. When it happens, how much time does it take?
4. Is there a human element that can’t be replaced by automation?
Let’s break down these steps and see how it can provide the basis for an iterative approach to automation:

Is this a Good Process?

This may seem like a rudimentary question, but in fact, processes and policies are often set and forgotten—even as things change dramatically. Proper continuous optimization or agile automation development will force an IT team to revisit existing policies and identify if it’s still right for the business service goals.

Some processes are delicate and automation may threaten their integrity, whereas others are high-level and automation neglects the routine tasks that underlie the eventual results. A good automation engineer understands what tasks are best for automation and sets policies accordingly.

How Often Does this Process Happen?

Patching, updating, load balancing or orchestration can follow an on-demand or time-series schedule. As workloads become more ephemeral moving to serverless cloud-native infrastructure, this process’s schedules will change as well. An automation schedule ought to be continuously adapted to the workload need, customer demand and infrastructure form. As the business continues the march toward digital transformation, the nature and schedule of particular work may become more dynamic.

When It Happens, How Much Time It Takes?

This also depends on the underlying infrastructure. Some legacy systems require updates that may take hours and some orchestration of workloads will be continuous. Automation must be tested to be efficient and effective on the schedule and frequency of the manual task.

Is There a Human Element that’s Irreplaceable?

As much as you may want to, it’s difficult for automation to shift left (to more experienced tasks and teams) without the help of AI or machine learning. Many times, there is a human element involved in deriving insights, creating new workflows, program management or architecture that take place. When building an iterative automation practice, make sure you identify where human interaction must occur to evaluate and optimize. In our lifetime, technology has advanced at lightning speed, with robots now completing jobs that were once held by people. However, there are times when a machine just cannot deliver the same quality a human can.

Automation for All

Automation is perhaps one of the most defining signatures of the future of IT operations management. It relieves teams of routine work and helps improve overall efficiency, all while driving quick wins that turn an IT team into heroes. But don’t let automation be the end goal. Instead, consider it a tool that can drive action from data. And until AI is an everyday option, it’s inherent on the IT professional to continuously optimize the data that drive that action.

— Bhanu Singh
April 22, 2019
5 DevOps Trends Worth Knowing in 2019
DevOps today is more than the buzzword it was 10 years ago. Back then, the idea of combining development with production in your IT infrastructure was not common; the logistics were nonexistent and most of the time businesses decided it was far too much effort.

However, if the last nine years has taught us anything, it’s that DevOps is worth every penny businesses invest. It helps companies streamline production, keep customers happy and provide agile services to attract new audiences.

But as with anything in the IT field, there is a paradigm of change. This article discusses some of the top DevOps trends happening now and how to implement them in your own system.

Automation Will Be a Bigger Focus

Automation has always been the way for businesses. Whether it’s speeding up the pipeline with machines, providing better response times for angry customers with chatbots or better inventory management with tracking and logging system, automation is behind it all.

DevOps is no exception.

But as with everything, there can be too much automation. The best thing to do is break down processes and find simple, redundant tasks that can save time if automated and apply the changes.

The most important aspect of automating DevOps is to understand the six pillars in the DevOps cycle, which are:
- Continuous business planning
- Collaborative development
- Continuous testing
- Continuous release and deployment
- Continuous monitoring
- Collaborative customer feedback and optimization
DevOps Assembly Lines: The Next Big Thing

To track the development of your application, we have pipelines. These visually represent the product from its initial stage right through until final development and release.

However, continuous integration (CI) is no longer the priority focus when it comes to effective monitoring and implementation. Continuous delivery and automation are a major part that businesses have already started delving into in 2019.

This is where DevOps assembly lines enter the picture.

Assembly lines are focused on bridging the gap between manual and automated tasks, ensuring there is no redundancy while providing several tools for teams to implement, to ensure apps are hitting the production lines as reasonably quickly as possible.

Microservices Architecture Adoption Taking Off

Microservices architecture may as well be that new kid in school trying to fit in. These smaller services compound into agile, implementable tools that DevOps teams can use to scale and test software over the course of weeks—not years.

As you can imagine, this can help some businesses streamline their development and production lines, setting them way ahead of their original production estimates—which is never a bad thing.

Implementing microservices into your DevOps team can also help companies focus on the runtime and efficient delivery of new development sources, without the hassle of creating dependency errors when something decides to bug out for no apparent reason.

Security Needs to Step Up

Cybercrime is on the rise—we all know that’s old news. But as a business, cybercrime can either make or break your sales and weigh down your DevOps team.

That’s why more companies are hopping onto enterprise security options. Although there are third-party programmers for almost every situation you need, none of them have the same security levels as the tools from the enterprise version provides. Safeguarding both your company and your clientele.

Riding the Artificial Intelligence Wave

Finally, we have artificial intelligence (AI) and machine learning (ML). When you think about it, these two elements are literally the sum of everything we want in the DevOps community—the ability to crunch out hours upon hours of menial labor and saving your teams hours to focus on higher-priority tasks.

The combination of AI, used to predict algorithmic influencers, and ML’s ability to adapt to new situations will be key for DevOps teams to get to the next level in 2019.

— Gil Artmoore
April 11, 2019
Pivotal Software Previews Automation Framework

At the North America Cloud Foundry Summit 2019 conference, Pivotal Software announced it is beta testing an automation framework that promises to keep its distribution of the platform-as-a-service (PaaS) environment continuously updated.

In addition, Pivotal revealed it will be adding support for open source technologies including Envoy load balancing and Istio service mesh software developed outside the auspices of the Cloud Foundry Foundation (CFF) to its Pivotal Cloud Foundry (PCF) distribution. Envoy and Istio are being employed to add a new routing tier to tier to PCF to give developers more control over network traffic.

Richard Seroter, vice president of product for Pivotal, said Platform Automation for PCF consists of a series of building block modules that will be applied to all the components of PCF as well as eventually the distribution of Kubernetes that Pivotal curates in collaboration with sister company VMware.

Pivotal also announced that Pivotal Application Service (PAS), the runtime for PCF, will soon support Windows Server 2019 along with the ability to configure multiple custom ports per PAS container to make deploying containerized applications in a PaaS environment more efficient from a networking perspective.

Finally, Pivotal is adding more descriptive metadata to the application programming interfaces (API) it exposes across the PAS runtime.

Seroter said Pivotal continues to focus on automating as much of the IT operations pipeline as possible. Rather than allocating IT staff to create and manage these pipelines, Pivotal is making a case for relying on a set of managed services that span instances of Cloud Foundry and Kubernetes running on top of virtual machines deployed on either a public cloud or on-premises. That approach relies on a highly opinionated operational pipeline defined by Pivotal that IT organizations will need to adopt to benefit from a highly consistent and repeatable approach to managing IT operations at scale, he said.

The need for a more structured approach to managing IT operations is only becoming more acute as organizations embrace Kubernetes platforms alongside Kubernetes, Seroter added. In fact, a survey of 501 IT leaders published by the CFF finds almost half of respondents (48%) report using some combination of PaaS, containers and serverless technologies together.

It’s still unclear how much IT organizations will standardize on a particular application development platform. PaaS environments typically have a more robust set of application development tools, but they can consume tens of virtual machines to stand up. Development tools for Kubernetes platforms are still evolving, but the platform provides a more efficient way to consume both virtual machines and bare-metal servers. It is apparent that for some time to come that many IT organizations will find themselves managing multiple platforms. The challenge that creates for DevOps teams is finding a way to manage those platforms consistently using a common framework rather than having to deploy and master separate management. It may take quite a while for IT leaders to rationalize their management platforms, but with each passing day it becomes clearer that goal increasingly is within reach.

— Mike Vizard

April 3, 2019
How to Design DevSecOps Compliance Processes to Free Up Developer Resources
Anything that gets rolled out quickly in the technological world is a major step forward—as long as it doesn’t compromise security.

DevSecOps is able to provide compliance processes far more effectively than before, and without jeopardizing security while also freeing up developer resources.

How do you direct your IT team to keep your applications and customers safe without completely draining your resources in the process?

The answer: automation.

Why is Security Vital to DevSecOps?

To take full advantage of the agility and responsiveness of DevOps, you must bring forward an IT security team through the entire life cycle of your apps.

In the past, when software could take months or years to complete, it was perfectly acceptable to bring in the security team in the final stage of development. But in the days of DevOps, a security team must get consulted from day one due to rapid and frequent development cycles.

An effective DevSecOps system can be completed in days, so the outdated approach to handling security during the development phases also must change.

How Did Security Radically Change DevOps?

It is important to remind developers that security is a shared responsibility that must be integrated from end to end to guarantee a smooth and functional application. The mindset is so important that many have changed from using the term DevOps to DevSecOps to stress the importance of the need to build a very sound security foundation.

If you are already making the transition to the cloud with AWS, chances are you have already implemented DevOps strategies into your interface so you can test new virtual machines (VMs) and deploy applications quickly without waiting for infrastructure to get manually configured.

For those who prefer the old-school method of developing applications, neglecting security until the end leaves their applications exposed. One of the most common security issues with most SMEs is misuse of security during beta tests, which is basically akin to leaving your front door wide open when you go to sleep at night. It’s just a terrible idea.

Making the transition from DevOps is not a luxury but a necessity for developers who want a secure environment, even during the dev/test period.

Designing Compliance Processes for IT

Even if you add “security” to the term DevOps, it means little without properly adding the processes you use into the building of the applications.

Security must be built into the processes by design, or you are not correctly taking advantage of what DevSecOps means—and your developer resources will get neglected, too.

Like the name implies, security must be in the center of development and operations. To maintain compliance, you must enforce a shared responsibility between AWS and the customer:
- AWS is responsible for security of the cloud, including the hypervisor and hardware.
- Customers are responsible for security in the cloud. They do this by securing your applications and network with services through a third-party vendor.
The best examples of DevSecOps in the cloud take this philosophy to heart.

Automation is Critical to Compliance Processes

A “security first” mentality is good , but are you really taking action with your compliance processes to free up developer resources?

The answer for many developers is, “Not quite.” Automation is essential to DevSecOps, yet so many systems lack the right tools. This is especially unfortunate for organizations that have the necessary skills and procedures in-house to implement built-in security processes directly into the application by design.

For other organizations, automation is only achievable by leveraging their services from a security integrator, who can then provide services to help define processes and roles, unveil security tools and set up automation procedures.

Steps to Establish Automation on DevSecOps

Now that you know automation is crucial to the success of any system, here are a few basic steps you can take from day one to start building the security processes into your design:
1. Consider a “shift-left” mentality when adding new processes, ones that incorporate design thinking from customers’ security needs and remain consistent. Steps such as threat-modeling storyboards build cyber resilience into the application before the first code is even written.
2. Consider a cloud-based vulnerability scanning solution. It will help you define standards for the AMI as well as validate adherence to those standards.
3. Implement an audit, logging and monitoring solution to track changes to the in-use AMIs. It helps combine account activity and AWS resources from the cloud with data related to security incidents. The in-use AMI changes can do everything from providing ongoing insights to allowing other security controls and having influence over network security.
4. View the AWS Marketplace catalog. Along with what an internal staff or a systems integrator can help automate, there are a number of other terrific resources out there for automation. The software listings are all from independent software vendors that make it straightforward to locate, test, buy and deploy software that runs effectively on your AWS environment. Like other AWS services, the providers are billed based on consumption, so you pay only for what you need.
By asking yourself the important question, “What am I trying to accomplish with my security controls?” you can get a variety of answers regarding what measures you need to take for compliance processes.

Final Thoughts

Speed, speed, speed. Developers today simply have no time to waste when it is time to launch new applications and get them out the door.

You have little time to burn on extra features, but you also can’t afford leaving your systems exposed and vulnerable to attacks. That’s why DevSecOps uses superior security processes to free up developer resources by utilizing as much automation as possible.

— Sam Bocetta
April 3, 2019
How DevOps Orchestration and Feedback Loops Can Enhance Your DevOps Pipeline

DevOps orchestration and feedback loops can significantly impact and improve your organization’s delivery pipeline. In this post, we’ll define and illuminate the importance of DevOps orchestration and feedback loops, and how together they can make a difference in your pipeline.

DevOps Orchestration

Although people widely use the terms “automation” and “orchestration” interchangeably, their scopes vary with significant process differences between them. DevOps automation automates a single function or a task in a DevOps pipeline that is routine and monotonous. Orchestration describes a string of such automated tasks consolidated into a streamlined workflow. In environments where automation would not work because of barriers among the groups, orchestration can be used to help organizations solve issues despite such barriers. Hence, DevOps orchestration simply brings together already existing automation networks into a cohesive, consolidated platform.

The Need for DevOps Orchestration

DevOps teams deal with constant navigation between development and operations. It would be highly beneficial if a single platform could pull together the tools teams typically use as various automation pieces from multiple DevOps toolsets. This is where DevOps orchestration services come into the picture, as orchestration enables teams to achieve that.

The primary goal of DevOps orchestration is to ensure seamless and quick delivery of new builds into production. It also aims to achieve streamlined and error-free software releases. Different organizations use various coding standards, guidelines and policies. DevOps orchestration plays a major role in efficiently managing and ensuring adherence to such policies. DevOps orchestration also is pivotal in properly defining and maintaining third-party software and their multiple versions across different environments.

DevOps Monitoring

Effective DevOps monitoring is vital. It is the key to understanding and evaluating various performance metrics in the production environment. When done right, DevOps monitoring can provide visibility into different critical aspects such as deviations in performance, application functionality issues and service availability problems. In any DevOps environment, the ability to identify and pinpoint such issues proactively can be highly beneficial, and DevOps monitoring enables executives to do so.

Feedback Loop

Feedback loops are the essence of any process improvement and DevOps is no exception. Typically, such loops initially function with an organization’s policies and progress all the way through implementation, policy adjustments (if any) and usually ending with reimplementation. They are not limited to specific process cycles in a DevOps environment—for example, it’s applicable to CI/CD practices, infrastructure monitoring and application development

Types of Feedback Loops

Broadly, there are two categories in feedback loops: reinforcing feedback loop and balancing feedback loop. People refer to the former as “a loop of accelerating change.” In a reinforcing feedback loop, increased value in the first entity results in an increase in the second entity, which in turn further increases the value of the first entity. Conversely, in a balancing feedback loop, value increase in one entity results in a decreased value in the second entity, which consequently decreases the value of the first entity.

Significance of Feedback Loops

One of the major capabilities that differentiates and carves a unique niche for DevOps from the rest of its predecessor methodologies is its feasibility to incorporate feedback from customers as well as other systems in the pipeline, including the monitoring system. The feedback obtained helps to bridge the gap between the software’s function and customer expectations. It also provides valuable insights about what you can do to improve the build of the software and ultimately enhance its functionality and reliability.

Feedback loops are particularly crucial when it comes to continuous testing. To carry out continuous testing effectively, building automated tests is only a job half done; the rest depends on the visibility of the test results and how you can utilize them to enhance the existing process. To do that, you need comprehensive feedback of your software’s performance across various stages of the software development life cycle (SDLC), starting right from development and continuing all the way to post-production. Implementing the right feedback loops will help you gather such detailed feedback.

Thus, feedback loops serve as the difference between merely speculating how an end-user might consume a product and methodically improving the existing workflow to better suit the end-user requirements through feedback.

— Kavin Elango

March 22, 2019
Perfecto Applies AI to Writing Test Scripts

Artificial intelligence (AI) is starting to be applied to the writing and update test scripts. Perfecto has unfurled Perfecto Codeless, which employs machine learning algorithms to automate writing of test scripts in a way that allows them to not only run continuously, but also adjust to changes made to the application.

Eran Kinsbruner, chief evangelist for Perfecto, a unit of Perforce, said writing test scripts is still largely a manual process, which means as the number of applications being developed continues to escalate, the testing process becomes highly constrained.

To address that issue, Perfecto has created a codeless approach delivered via a cloud service as part of the company’s Smart Automation platform. If any code within an application gets deleted, moved or changed, the changes will automatically be reflected in the test script. That capability eliminates the need for DevOps teams to wait for a developer to update the test script.

Exactly who in an organization is writing those test scripts varies: Kinsbruner noted that many developers now prefer to write their own test scripts during the development process before their code is reviewed by a peer. That approach eliminates many of the more routine errors, enabling more time to be spent on optimizing code. Other organizations employ dedicated testers who spend most of their time writing test scripts. But many of those organizations are finding that testers cannot keep pace with the current rate at which applications are being developed in the DevOps era.

There’s no doubt machine learning algorithms are about to play a much bigger role in application testing and DevOps at large. AI is not going to replace DevOps teams anytime soon, but many mundane functions such as the writing of test scripts can be automated using machine learning algorithms. Arguably, testing is one of the areas that lends itself most to emerging AI-based platforms and services. After all, if testing becomes a bottleneck, the chances that applications with issues are deployed in a production environment increase substantially. Many of those issues can be fixed easily, but many times at the risk of annoying end users who increasingly are unforgiving when it comes to application experiences. It’s not uncommon for users to discontinue using a mobile app if the first experience isn’t immediately gratifying.

Of course, many DevOps teams already view machine learning algorithms with a certain amount of skepticism. But the rise machine learning algorithms within DevOps is now all but inevitable. IT leaders, however, should realize it may take a while for those algorithms to learn the environment. The return on investment for any AI project is not likely to be immediate because a significant amount of time needs to be invested in training the algorithms. The good news is, those algorithms never take a day off and suddenly don’t resign one day to take a better-paying job elsewhere.

— Mike Vizard

March 21, 2019
G2G3 DevOps Simulation: Lessons from the Facilitator POV

The G2G3 DevOps Simulation is a three-round game that gives a complete immersive experience to the participants. It has software that’s controlled by the facilitator and used to see the performance and improvement in each round.

As a facilitator, I help on the retrospective at the end of each round, as the participants share about what they did and didn’t do well. At the planning stage for each round, the participants decide what they want to change and get to see the result.

Below is a list of what I focus on as a facilitator.

Looking at the Same Objective

Participants in the G2G3 DevOps Simulation learn that, regardless of role, their only objective is generating maximum revenue. This is the common goal. They can see this objective on the screen from the system. The participants begin to understand the goal on round two and by round three the objective becomes clear. This helps them to work in collaboration, working in a “squad” and helping each other to achieve that one common goal.

Collaboration and Sharing

The G2G3 DevOps Simulation gives the participants the chance to experience how collaboration and sharing helps in delivering stable products faster. Each team starts helping each other to ensure that their business makes the maximum revenue. They understand the need for delivering the outcome.

The simulation also shows the challenges of communication between “run the business” and “change the business.” They experience how the communication drops between the two and how to take care of it with better knowledge management.

Project-to-Product Approach

The participants learn how to work as a squad—one single team responsible for both development and operations. They learn how the value flows from the time change is requested, until it is deployed and then the deliverable is maintained.

Business is Most Important

The G2G3 DevOps Simulation shows the participants that business is the most important—and IT is business. Everyone in the value chain must work toward the same objective.

Automation

The simulation also gives the participants the experience of how automation helps in achieving the objectives faster and better. This is clearly shown in the performance report at the end of each round and the comparison can be seen between rounds with more automation in place.

DevOps: 3 Ways

The G2G3 DevOps Simulation explains the basics of DevOps, bringing all participants to the same page on various DevOps terminologies, the principles (Three Ways) and DevOps values.

Conclusion

The G2G3 DevOps Simulation is a good practice for anyone in any organization who is on the journey of DevOps or is planning to start the journey. The best can be achieved if members from the various departments of the organization participate, which is required to deliver any change.

— Niladri Choudhuri

March 20, 2019
4 Steps to Improving Your Team’s Continuous Security

A recent npm survey revealed that 77 percent of developers were concerned about the quality and security of the open source libraries they use, while 52 percent said the tools currently available were inadequate. Given the trust issues in open source and the ongoing discovery of website and application vulnerabilities, security should be top of mind for developers at the start of every project—but also on an ongoing basis. I call this practice of constant re-assessment “continuous security.” Here’s how I like to describe it:

Imagine you are standing at the bottom of an escalator that’s moving downward. Your goal is to reach the top. You might think, “Easy, I’ll just sprint my way to the top! Run as fast as possible and I’ll get there, and the problem is solved.”

It’s not that easy, though. As you start your climb, you realize that you haven’t really trained for this and you’re slower than expected. The people traveling down toward you become obstacles to be evaded. Through all this, you have to maintain your upward momentum, or you’ll end up back where you started.

Now, it might sound a little cliché, but that’s how I view security. Security is something you have to continually train for—a constant cycle of risk discovery, prioritization and skill-building to close the gap to get results.

Continuous security is all about becoming more efficient at this entire life cycle and reducing the time to risk discovery and the overall cost of mitigation.

Risk Discovery

The first step to improving your security situation is to find something that needs improvement. These tend to be risks to the business and look different depending on your focus area. For a legal team, that might be license compliance; for a development team, it’s likely to be a security bug in a production service.

When you start out, your abilities to discover risk are going to be pretty poor, but that’s okay. I like to apply this discovery process at the natural gates of the development life cycle. Major ones include: when the feature is designed, when code is first written and when someone makes a pull request, pushes code to staging and pushes it to production. The tooling and techniques you use in each of these stages will vary greatly by the needs of the business and change as your security program matures. There will be arguments continually about what is considered a risk and how it should be prioritized. This is part of the process of refining your risk discovery skills and tools.

Policy and Standards

There is rarely any change without pressure, and because we don’t always have an active incident to force improvement, that pressure sometimes has to come from within. Motivating your team through policies and standards can be the ideal way to influence improvement.

Everyone in your organization will have their own perspective, so developing a strong set of policies and standards to measure yourself against will go a long way. Writing and adopting these standards should be collaborative, both with your security team and the organization as a whole.

These policies help you determine what is a risk and how you prioritize it as an organization. At npm we have a standard rating scale that security assigns to risk (P0 = drop everything and fix critical, to P3 = fix within 180 days). This tells engineering how long each risk should take to mitigate, helping them prioritize their work accordingly.

Mitigation and Improvement

This is where the technical practitioner will have the most fun—fixing lapses in security is usually satisfying work. The important part is to use each incident as an opportunity to scale your efforts in risk identification.

For development teams, that means pushing more automation in your CI/CD pipeline to arm developers to be able to find security issues earlier in the development process. I like to call this the CI/CD/CS pipeline: continuous integration, delivery and security. However, automation is far from perfect, and the best way to improve decision-making is to provide a human with the right amount of information in the right context whenever a decision needs to be made.

An important thing to remember is that your solution does not have to be perfect. There are many situations in security where “better” is good enough to mitigate risk to an acceptable level. In the end, what you need to have is a constant feedback loop of risk discovery and mitigation, using technology and processes to manage and improve.

Continuously Improving Continuous Security

Setting goals and expectations is a part of continuous security, but you should keep in mind that “security” is not a set destination. The word “security” lies to us by suggesting that it’s possible to secure something, when in truth the mitigation of all risk is an impossibility.

Instead, always try to maintain your upward momentum. Measuring all successes and failures honestly allows you to be effective at all times, whether in the middle of a security issue or a period of relative calm. A continuous, proactive approach to security is the only way to effectively ensure the safety of developers and code.

— Adam Baldwin

March 14, 2019