"Serverless" is a new computing paradigm that has emerged from the worlds of cloud and Agile that's beginning to surface in large enterprises such as AOL and Nordstrom. Other major enterprises are likely to have IT service management (ITSM) practitioners who need to learn about this new compute paradigm, because it changes the agility, control, and cost of service delivery and IT operations.
To start with, serverless is a misleading title - servers are involved, just not yours - but the capability and usefulness is very real. Underneath the title, the technology and processes are vastly different from the traditional IT world of monolithic applications, infrastructure servers, networking, and storage. And serverless should be good news for ITSM practitioners because it's all about better quality service.However, the lack of understanding and misapplication of serverless has the potential for a negative impact on service and thus this blog lays out the top three insights on serverless operations for ITSM practitioners.
1. What's in a Name? From InfraOps to AppOps
When serverless first appeared as AWS Lambda in 2014, the first remark people made was that AWS did almost everything for you. Therefore, this was a NoOps service. You had no operations to do at all, apart from the operation of the service and code that you deploy on serverless, so it wasn't really true. Then Brian Liles came up with a more accurate description for serverless - AppOps.
Why is this of interest to ITSM practitioners? Consider the current interactions of ITSM practitioners with the business and the rest of IT, then add in this definition of AppOps:
The basic idea behind AppOps is that the person who writes an app - AKA "the developer" -is also the person responsible for operating the app in production, 24/7, and with SLOs.
Think about who is now doing what in support of a service, when there's:
1. No procedures or change impact risk assessments for replacing a HDD or mounting a rack
2. No upgrading the operating system, or keeping up-to-date with security patches
3. No provisioning of a hypervisor or Kubernetes or Apache Mesos cluster
With serverless, an ITSM practitioner needs to be involved with fewer people, and less process and technology to deliver service to customers.
Watch the video above and learn how AI can improve ticket consistency for service requests!
2. Serverless CSI
The ITIL Practitioner Guide from AXELOS includes significant content on continual service improvement (CSI), and serverless is a computing paradigm that underpins CSI better than traditional IT systems.
The reasons for this are two-fold:
1. Serverless offloads a lot of the time, and cost-consuming IT activities that drain time add little value, to the cloud service provider (CSP), such as changing hard-disks, patching operating systems, and "turning it off and on again". So, you can focus more on the service and the application, along with improvement.
2. By focusing all your resources on the service and application, you are looking at valuable metrics such as latency from the customer perspective. For instance, if you are slow in updating their shopping cart, the customer will leave and revenue will drop.
Serverless can run on-premise and on your IT with IBM OpenWhisk, but really serverless is an opportunity to refactor and launch your applications, in a modern way, in the cloud. So, with serverless, it might also be that your application and service continually improve without you doing anything. Imagine that!
3. Serverless Operations
In the ITIL framework, the objective of service operation is to ensure that IT services are delivered effectively and efficiently. This includes fulfilling user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks.
When an application runs on the serverless computing paradigm - and on a public cloud service such as AWS Lambda, Azure Functions, or Google Cloud Functions - then a lot of operations is offloaded onto the CSP. This immediately reduces the load on a business' ITSM team, freeing them up to focus more on the business, services, and critical applications.
Digging a little deeper, operating an IT service-based upon serverless has a number of differences that the ITSM practitioner needs to consider:
1.Event management - there are no infrastructure events any more. Key metrics have changed to latency, function completion, and scaling events.
2.Incident management - the identification and immediate recovery of service uses different tools and requires different skills and procedures.
3.Change management - changes to the application will be made via a DevOps Continuous Integration/Continuous Delivery (CI/CD) pipeline, which ITSM will need to "plug into."
4.Access management - it's common for developers not to have access to production (the separation of responsibilities) so the CI/CD build/release pipeline needs to reflect this.
5.Problem management - this will need to involve the CSP as they are responsible for large (hidden) parts of the service. ITSM need to establish related working practices with the CSP, which is not always easy with public cloud providers.
6.Operations and control - there's no need to monitor infrastructure (which is good) but new application-level monitoring tools are needed to understand application and distributed system behavior (a challenge).
7.Application management - DevOps is the common framework for this in serverless.
8.Technical management - serverless requires new skills and working practices, and changes to processes "adjacent" to it, and thus also organizational change management.