Since 2014 when Amazon Web Services (AWS) Lambda introduced serverless architecture, serverless systems have gained traction amongst the tech community; they are now offered by all major cloud service providers, including Microsoft and Google. In serverless systems, computing resources are provisioned on-demand, using either back-end-as-a-service (BaaS) or function-as-a-service (FaaS) methodology. The name is a bit misleading because there are still servers in serverless environments; however, they’re essentially invisible to customers who don’t see, manage, or interact with them.
Joining forces with microservices and containers, serverless systems form a “technology trinity” at the core of modern cloud-native application development. This has become so central to cloud-native development that most mainstream companies are now brainstorming how to best leverage serverless technology to accelerate their engineering teams and increase their bottom line.
It’s a beautiful thing when business and engineering teams can work together in harmony. But, if you’re a DevOps organization like us, you might be wondering what this means for your DevOps teams.
DevOps in Serverless Applications
Before diving into how serverless computing affects DevOps, it’s important to understand the differences between serverless and other computing models:
Management and maintenance of infrastructure are offloaded to cloud providers and tools.
Code is run “on-demand only” in a stateless container that auto-scales itself transparently, adapting to dynamic requests.
This model removes the cost of idle capacity – end-users only pay for the resources actively being used.
With these improvements, it’s easy to see how going serverless positively impacts DevOps; developers now have more time and resources to optimize code and develop innovative new features and functionality. Unfortunately, because developers are essential regarding serverless applications, this attention promotes the fallacy of NoOps – that going serverless negates any need for modern organizations to do operations.
The concept of NoOps stems from a long-lived misunderstanding: that businesses need operations because operational problems are a product of technical architecture. That means that better architecture eliminates the need for operations, right? Nope!
Even though architectural decisions impact the operations bandwidth an organization needs, ops-minded people will always be necessary. In particular, they play a crucial role regarding application criticality and modification to the processes and toolsets around adopting new technology. They answer the questions every organization must know:
How do you know the software is working?
How can you push a production fix quickly and efficiently?
While ops-minded individuals are an integral part of serverless application success, they need to be prepared for how this model innately changes the “ops side” of DevOps. For instance, most operations-minded professionals learned their skills when physical, deployed servers ruled the land. With serverless applications, virtual cloud resources break the connection to the physical world and require operations teams to plan hosting and redeployment in new ways. In particular, operations teams need to adapt to complicated updates regarding monitoring cost and usage, service governance, performance management, and business continuity and disaster recovery (BC/DR).
Monitoring cost and usage
In traditional systems, cost and usage monitoring were static; fixed costs were allocated to each respective department. With serverless environments, this gets more complicated. Ops teams must pivot to monitoring cost and usage at the function rather than server level. This requires a deep understanding of the application and monitoring its usage using native monitoring tools. In this case, there is an increased demand for ops minds who exhaustively understand applications and databases.
Service governance
Traditionally, service governance was passive and straightforward, with no enforcement using automated governance tools. It’s important that service usage limits are created; it’s integral that they are also enforced regarding who can use the services, when they can be used, and how much. To do this, operations teams need the knowledge of what individual serverless functions are programmed to do and the wisdom to know when limitations should be placed on the execution of each function.
Ultimately, your organization depends on the monitoring and management tools that are cloud-native. More importantly, your DevOps teams are limited to the capabilities of the tools within the cloud-based, serverless computing system you utilize.
Performance management
Part of the allure of serverless applications is the flexible and elastic system performance. However, with the benefits of a dynamic performance computing environment comes operational complications. Previously, if you were looking to increase the performance within your organization, you could provision more servers – a reactive approach that required human intervention in most enterprises. With the rise of serverless architecture, ops teams now need to understand what back-end resources an application needs, keeping an eye on latency, cold starts and invocation errors, and responding dynamically to changes in performance.
Business continuity and disaster recovery (BC/DR)
Typically, this aspect is most neglected in serverless computing environments because of the cloud provider assurances that business continuity and disaster recovery are innately integrated. This is partially true; however, the caveat is that it only really covers simple operations and lacks options for more detailed coverage. Because this is still a work-in-progress in serverless architecture, DevOps teams need to work together to determine the best course of action for their application.
The takeaway
Serverless computing is still very much in its infancy, requiring rapid adaptation and experiments in trial and error to determine best practices. Despite the many unknowns still associated with DevOps in serverless applications, one thing is sure: organizations must customize their applications for serverless use to gain maximum benefits. A key component in this customization is modifying your “ops” approach. While this approach is similar between traditional systems and public clouds, serverless is more complex and dynamic. Ops-minded individuals will need to pivot to focus entirely on the applications themselves, rather than the servers they run on.
Our group of ops-minded DevOps engineers understand the challenges associated with serverless applications and are continuously adapting to promote superior safety, efficiency, and performance for all organizations we work with.