By Percy Mohale, Synthesis DevOps Engineer and input from Rodney Ellis, Rolf, Eusoph and Gareth Hone
The role of the Managed Service Provider is to take responsibility for looking after the organisation’s infrastructure and tooling services, whether it be in cloud or on-premises. This frees up time from the organisation’s resources to accelerate business value and time to market. There are several aspects within your organisation that MSP can add value to – Automation, Infrastructure as Code (IaC), Continuous Integration and Continuous Deployment (CI/CD) pipelines, DevSecOps, and Incident Management.
CICD Pipelines
Developing release pipelines is one of the practices implemented by the DevOps team to accelerate the rate for delivering code changes more frequently and reliably to production. Utilising agile methodology best practice, it enables the organisation to focus on business logic, code quality, and security whilst the deployment and testing is automated within the pipeline.
Pipelines enable the organisation to deliver services to customers quickly and consistently. It saves time and eliminates human errors during deployment by automating the process from code to customer using best practices, resulting in a consistent and repeatable pattern.
CICD has revolutionised how applications and systems are being deployed compared to traditional methods.
Automation
Automation is a critical function of DevOps that eliminates the need to perform repetitive tasks manually. It enables the teams to focus on high-impact, high-reward project work.
Automation eliminates human error and relieves teams from repetitive fatigue.
Automation is not built into the cloud or systems; it requires expertise and the use of specialised tools which can be leveraged from public cloud vendors such as Amazon Web Services (AWS), Microsoft Azure or third-party cloud tools that perform automation in the cloud environment.
Infrastructure as Code (IaC)
IaC is one of the key enablers of the DevOps revolution as it allows complex and consistent systems and environments to be written and expressed with code.
Different environments are easily and reliably replicated to avoid the conversation of “It works on development, but I am not sure why it is not working on staging or production.”
It eliminates wasteful expenditure as it removes all associated resources within an environment or workload if it is no longer required by the organisation.
Most of the IaC tools such as Terraform allow collaboration which allows for more than one person to contribute code. This in turn allows the DevOps team to respond faster to customer or system demands.
Incident Management
The first goal of the incident management process is to restore service operation as quickly as possible to minimise the impact on business operations. This ensures that the best possible levels of service quality and availability are maintained. “Our system is down” is simply not an acceptable excuse for a client to present in terms of its infrastructure.
Applying DevOps to your incident management process flows/workflows can improve software delivery and enhance service reliability. Unplanned interruptions to an IT service and quality reduction of an IT Service can cause major business disruptions, resulting in reduced efficiency and ultimately, erosion of the profitability of a business.
The role of MSPs around incident management is to manage the lifecycle of all incidents, right from detection to resolution and closure of the incident. An MSP allows you to restore normal service operations as quickly as possible (i.e., with as low as possible MTRS – “Mean-Time-to-Restore”) and minimise the impact on business operations, through root cause analysis.
The role of MSPs is to ensure business continuity. Unplanned business disruptions will be attended to based on the Service Level Agreement (SLA) signed with the customer.
This saves a lot of time. For example, faster incident resolution can save development time which can be allocated to improving and building new features rather than responding to issues.
DevSecOps
The DevSecOps role in organisations was developed due to the shared responsibility for security shifting left in the development and operational life cycle. InfoSec is no longer a separate department doing traditional security such as centralised firewall management and access control. Security is now a more collaborative exercise with developers and system architects. With the move to cloud computing, perimeter and identity security is becoming decentralised and most security services can now be created and managed by the developer directly without the knowledge or involvement of a central InfoSec department.
By bringing security closer to DevOps, there’s a faster turnaround time for critical changes since the DevSecOps engineers are aware of customer requirements, and already have the intimate knowledge of systems to ascertain the impact and risk of implementing changes. Security can be built into systems from the start of development, rather than being detected by a separate security team before deployment. DevSecOps can see first-hand the risks of certain features being proposed and suggest mitigating controls early in the planning stages.
DevSecOps is also responsible for the development of security automation and controls within production environments. Automation such as compliance controls, automated remediation, automated security reporting, log analysis, incident and investigation can all be created through a security developer. The end state is that the overall security posture of a system can be increased through visibility, controls, and automation which are compatible with customer environments.
