The three most common reasons payments solutions providers are adopting DevOps is for security, efficiency, and application reliability.
DevSecOps
The responsibility and even accountability for security is rapidly shifting in the direction of DevOps engineers, as they have a view into the broad architecture of the processes and systems used to deploy microservices. Going forward, DevOps engineers and DevSecOps processes are going to be even more accountable for security. This trend should be a strong consideration, as good DevSecOps also makes application deployments, operations, and service monitoring easier, and more secure.
When designing a new distributed system or refactoring/enhancing a monolithic application into microservices, one thinks about the business app and processes by which each microservice communicates with other microservices. With that picture in mind, it makes more sense to provision the identities at that microservice level. The benefits are that:
- This makes it easier to understand the distributed application process, as it typically does not change as frequently.
- It makes the most out of container orchestration agility because we don’t need to restrict certain microservices to offer certain nodes.
- It enables platforming, as the identities abstract the host identity that they are running on – whether a container, virtual machine, etc.
Integrate Security Using Automation
The need to respond to security attacks manually is daunting. Using Red Hat Ansible or Hashi Terraform you can automate and integrate different security solutions that can investigate and respond to threats across the enterprise in a coordinated, unified way using a curated collection of modules, roles and playbooks.
Collect logs across firewalls, intrusion detection systems (IDS) and other security systems programmatically, enabling on-demand enrichment of triage activities performed through security information and event management systems (SIEMs).
Using these tools in a DevSecOps process can automatically tune the level of logging, create new intrusion detection system (IDS) rules and new firewall policies facilitating the detection of more threats in less time.
You can also remediate faster-automating actions like blacklisting attacking IP addresses or domains, whitelisting non-threatening traffic or isolating suspicious workloads for further investigation.
Ansible Automation is the common language to use between security tools. Security encompasses a broad variety of products and services designed to protect individuals and organizations from the loss or damage to their data, applications, IT systems, networks and devices from malicious or unintended activities.
Managed Services
For payment platforms, the most common driver we are seeing now is that a cornerstone application will get moved to a cloud environment. In the Digital Revolution, timelines for product delivery and information analysis are slim. Customers set the pace by consuming products and information on-demand — their way. This places immense pressure on payment solutions providers to deliver continuously and reliably to satisfy the rapidly escalating demand for all types of services. Software is the center of the business universe, vital to all aspects of operations. Building and reliably delivering software is now vital to short and long-term success.
As payments processors continue to maintain and modernize older applications, they are also creating and delivering new applications that in the sum total, can wear out their staff and budgets while increasing technical and process complexities between organizations.
In the digital economy, failure to deliver, delivering the wrong solutions, or delayed delivery greatly affects organizations’ ability to satisfy required business outcomes. Forrester tells us that a significant portion of technology spend is devoted to software engineering infrastructure. The blend of workloads, applications and broad access to the resources paired with consistent delivery methods to support software development is vital. How technology is used is as equally important as to the methods and processes for creating and delivering software code.
Most development teams have limited visibility across and within their software “production” — the coding and delivery processes. Visibility is paramount and getting the process data into the hands of key stakeholders is critical. Lead-time, deployment frequency, MTTR, and change failure data enabled with a complete and automated delivery and a mapping of the value-stream can provide great value to the enterprise.
A very powerful and proven method for companies to access and wrap their arms around the data and constraint resolution is through DevOps managed services. These services provide real-time visibility into the integrated technical-development operations processes. Data is generated from the use of hardware and software systems in response to the actions of the contributors in the value-stream from code design to release and into production.
DevOps managed services help organizations identify vulnerable process areas to remedy and improve suspect code and provide feedback for continuous improvement. Code scanning detection also helps identify code weak points and anomalies and improvement, providing improvement assurance. When there are fewer issues, the value-stream operates more efficiently, placing less stress on the contributors, including testing processes and the infrastructure they leverage to produce and reliably deliver.
Eliminating Alert Fatigue
Anyone who’s been in the devops space is probably familiar with alert fatigue. At the beginning of a devops transformation, engineers set up as many monitors as they can to catch issues before they happen or to understand when things are happening. The next thing that happens is that their inbox is getting flooded with all these alerts and, suddenly, everything becomes less meaningful and no one is reacting to anything, which is essentially the same as not having any monitoring in the first place.
It’s a big problem and finding the balance between making sure everything is captured and not overloading everybody that’s responding to these issues is a key devops transformational issue. Managers quickly have to fix the problem of engineers being woken up at three o’clock in the morning and then looking into something that’s actually a false positive. Managers need the right tools and processes to efficiently catch meaningful events and only alerting people when it’s absolutely necessary.
One way to clearly quantify alert fatigue is to look at the number of alerts per person, and the frequency and timing of the alerts. Devops leaders can use a kanban to measure green and red zones.
Every time you have an alert, there are three possible outcomes. It’s either an actual problem and we fix it, it was alerted but it was either a premature alert or we should have waited some amount of time before we actually should have acted on it. In the latter two cases we just adjust the threshold or decide that it is really doing nothing for us and we turn it off. It’s a process of continuous improvements and ultimately, we wind up with meaningful alerts.
