Moving “shadow” service workloads to Serverless Functions

How many times have you had a job/process that needed to wake up and perform a unit of work then shut down? The IT landscape is littered with these services, batch jobs, and timer jobs throughout data centers, standalone servers, and personal PCs.  These services become relegated to the back alleys of IT infrastructure, long forgotten until an event happens. An even worst offense is when these services are allocated dedicated resources i.e. VMs or physical servers and these resources are under-utilized until the service executes.
              The reason for labeling these services as “shadow” because they become forgotten and hidden in the shadows. Their locations and knowledge of functionality become lost as subject matter experts (SME) move on. This becomes quite apparent when servers need to be decommissioned or migrated, and there are no preparations for these services. I have seen numerous times, after decommissioning or migration of servers people scramble to track down servers to get the service back and transfer services off the machine. After the services has been recovered and migrated, only to have this pattern reemerge. Some of these “shadow” services are the perfect workloads to shift to Serverless functions.
              Serverless functions can be invoked in different ways; event based, scheduled, and invoked. Shifting your workloads to Serverless functions, allow services to be aligned with the following principles:

• Discoverable
• Reusable
• Faster time to delivery
• Minimum resource consumption
• Elasticity
• Monitored

Depending on the Serverless platform  (Amazon Lambda, IBM OpenWhisk, or Microsoft Azure functions) the functions are deployed to a portal. Having a single point of deployment, the services become discoverable allowing for them to potentially be leveraged by other resources. Time to market is greatly increased because developers don’t need to wait for infrastructure to procure, build, and configure resources.
              Capacity planning is part art part science. When rolling out new functionality it is hard to get capacity planning right. Changes in the business and applications can also change the parameters of your capacity planning. This is where the elastic nature of Serverless functions shines. Serverless functions can easily be scaled to meet demand. Once the demand is met the resources will be scaled down and reallocated to other processes. As for cost, you only have to pay for what is utilized in the execution time of the function. Services that have dedicated resources can potentially go from CapEx + Opex spend to just Opex spend at a cheaper run rate. Because the functions are monitored, gathering metrics for usage is an easier task. These metrics can be used for budgetary planning and forecasts.
              To start select a small proof of concept (POC) that can be done to build experience and gain confidence in using Serverless functions. Develop a best practice that works for your business. Work on building an application portfolio can help drive this effort to prioritize key systems. The portfolio can be leverage to build system blueprints and system architectures diagrams. The system blueprints will show the interactions between systems at a logical level. Systems architectures diagram will provide a detailed architecture of the application interactions. Gradually working through the system architecture will highlight key areas where Serverless functions can be replace particular component or processes.