Serverless Computing Doesn’t Mean Forgetting About Ops
Serverless computing lets software engineers outsource some of the operations elements of their applications. It offers benefits like cost control, simplified operations and even energy efficiency. IT leaders make a mistake, however, if they think this means no operations — or “NoOps,” for short. Your engineers still have to design applications with ops in mind.
Charity Majors, a former Facebook engineer and co-founder of Honeycomb, says engineers now have to own their applications from end to end, even if they’re using serverless architecture. She says operations engineering is becoming a niche all its own, and instead of solving problems at the local level, top ops engineers work for big companies solving internet-wide problems. Tapping into those talents provides invaluable benefits for organizations under pressure to downsize local ops teams. At the same time, application engineers still have the ultimate responsibility to deliver great user experiences.
What Serverless Computing Can Do
Serverless computing is another term for function-as-a-service (FaaS). It executes a concrete function of an application, performing specific tasks based on specific inputs. In a post for IT Biz Advisor, Cloudcast Media founder Brian Gracely describes FaaS as a granular subset of cloud computing, specifically platform-as-a-service. It’s good for highly specific application functions that are intermittent or for which demand can be unpredictable.
Some applications fully depend on third-party applications, but others still utilize some server-side logic — it’s written by the developer but runs on stateless containers. These containers, says Mike Roberts, a New York-based engineer, are event-triggered, ephemeral and fully managed by the third party. As Roberts explains on MartinFowler.com, horizontal scaling becomes automatic, elastic and completely provider-managed.
With cloud, your ops team has to program systems to scale up or down. With FaaS, DevOps teams no longer have to script scaling and provisioning workflows based on predictions about demand. Remote FaaS providers ensure resources for FaaS are always available, providing added computing power when demand increases.
Instead of running an application that gets one request per hour on its own server instance, multiple applications can share the same central processing unit. Getting a FaaS up and running is also faster to deploy than deploying an entire server, because code gets compiled and uploaded without the need to write automation scripts. And since fewer servers are constantly running, FaaS makes data centers greener. Taken together, these time, cost and energy efficiencies make FaaS a compelling choice.
What FaaS Can’t Do
When one of your applications doesn’t work, your customers don’t care why. They don’t know you’ve outsourced FaaS and the provider is at fault. They just know they’re unhappy. As you write code, even with FaaS, you still have to think about reliability, security, storage models, querying and how your application services communicate with one another. You also have to consider how you’ll debug and reprogram when things go wrong.
If you’re using FaaS without an in-house ops team, you can’t fix ops problems yourself. You’re dependent on the provider to ensure ops delivers a good application experience. You can outsource functions, but you can’t outsource the job of caring about your product.
“Your mission is not writing software,” Majors writes. “Your mission is delivering whatever it is your customers are paying you for, and you use software to get there.”
NoOps Is a Myth
Serverless computing doesn’t mean servers no longer exist; it just means developers don’t have to worry about operating them. Tools like IBM Openwhisk enable faster code deployment via microservice so developers can focus on their value-added code.
At the same time, if you deploy FaaS without thinking about ops, you’ll be stuck with problems you could have prevented. You’ll also be dependent on third-party providers to debug and remediate, leaving you at the mercy of their processes and time frames. As you expand your FaaS deployments, choose providers and partners with strong track records and transparent service-level agreements. When there are problems, your customers won’t blame the FaaS provider — they’ll be too busy blaming you.