Unlocking Speed & Agility
This is the fourth in a multi-part overview of serverless and native cloud technologies for beginners. This series looks at the origins of the PAAS model, at what defines serverless, what you can build with it, and what benefits it offers.
Back in the first post of this series, we touched on the payoff in terms of speed and agility that comes for development teams from adopting serverless. In this final post of the series we're going to flesh out this topic a little further by stepping through a series of increasing organization sizes. To give a hint of where we're going with this, we'll see that the largest organizations, which are the most cautious about adopting new technology, probably have the most to gain from serverless.
Small Organizations
So, let's start with an imagined small organization, one that might have a single, unified DevOps team. As an example, let's say that this team needs to deploy a secure backend API for a mobile app. This work is considerably easier for them to achieve with serverless, once they have the necessary cloud skills, than it would be with traditional servers and network infrastructure. As you can see with the sample code for the Learning AWS Serverless course, it's possible to define an entire, secure, high-performance API and service stack, including dedicated build pipeline using declarative IAC, and deploy all of that with a few commands. This adds up to far less effort than working with a disparate set of network and server management tools.
Mid-sized Organizations
Now let's imagine an organization that's sufficiently large to maintain multiple applications, and as a result, to also have separate development and infrastructure teams. In the course of developing something new, or making non-trivial changes to an existing system, a development team might need to set up new deployments on existing infrastructure, or even set up entirely new infrastructure. Assuming that teams in an organization of this size work together fairly seamlessly, there will, nonetheless, be some coordination overhead and occasional blocking of progress for work that cuts across these teams.
A development team that can define and test its own deployments, as serverless makes possible, will have its progress slowed by this cross-team coordination overhead much less. This benefit is even more pronounced when it comes to tinkering and experimentation. If you're an architect prototyping a solution or part of a development team working through a design spike, you're free to stand up and tear down work-in-progress solutions (in a suitable cloud account, as discussed below) with almost no effort.
Large Organizations
Smaller organizations are kind of inherently agile. They don't suffer as much from the insulation of decision-makers from customer experience, or the slow-moving processes that sometimes plague larger organizations. In an effort to overcome these challenges, a lot of large organizations have initiatives to inject agile practices into their IT efforts, sometimes with mixed results.
This is another area where adopting serverless can help. Let's illustrate how with an imagined project that's making changes to a system that runs services on traditional on-premise application servers and middleware. Let's say this is an "agile" project for which the team is practicing emergent design. As such, it needs to update these services on a regular basis as they evolve their solution.
If, like me, you've spent time in large organizations, you can perhaps see where this is going. The problem is that the software and hardware on which the team's services run are very expensive, so there are necessarily a limited number of environments set up. Because these environments are scarce resources that have to be shared across teams and projects, they also have to be guarded by gatekeepers of some kind. These gatekeepers, in turn, are often themselves shielded by a layer of management.
How this often plays out is that in order to test an updated solution, a development team has to get their manager to coordinate with the managers of the infrastructure and/or integration teams. This person will probably have to call a meeting, or maybe a series of meetings, so that the changes can be explained, prioritized and scheduled. I will point out that there's nothing wrong or irrational about this kind of process. It's the natural result of, first, how the software systems work, and second, the consequences of mistakes in large organizations. So it's understandable, but none of this helps when you're trying to be agile.
However, when a solution incorporates serverless technologies, there is an opportunity to sidestep this gatekeeping process and more fully adopt agile work practices. Here's how. First, as pointed out above, for low-volume development or test environments, usage pricing means that setting up serverless environments doesn't necessarily cost anything. Second, cloud services (and serverless especially) are elastic. So, given the absence of a cost deterrent, there's nothing standing in the way of setting up as much capacity as needed, which means there's no reason to be sharing. If you have five projects on the go and need to test all of them concurrently, with serverless you're free to set up separate environments for each.
The other issue concerns guardrails. Even without capacity or cost constraints and therefore no sharing of resources, you might still want some kind of supervision or gatekeeping before letting a development team deploy whatever they want in the cloud. This is where good cloud practice, first, in the form of segregated accounts for different workloads, and second, the use of policies as guardrails is key.
As I outlined in the first post of this series, what makes the modern cloud powerful is its unified control plane. This control plane gives you the ability to define your solutions in code, and then set them up and tear them down at will. But what this control plane also gives you, by being the one entry point for making changes, is the power to define rules about what can be deployed and how, using policies. Using this mechanism, you can put in place guardrails for your cloud accounts that act, essentially, like automated gatekeepers.
Fully describing how to set up accounts and policies will take a separate post, but I can provide an overview here. In a nutshell you can define different workload accounts within an overall enterprise tenant in the cloud, and depending on how they're to be used, you can grant access to different groups of users, and apply distinct policies.
For example, you might have a "lab" account where developers have a lot of freedom to set up services, but network access to other cloud accounts or on-premise data centers is blocked by policy. Other non-production environments might be exclusively managed by an infrastructure team, but could grant developers read-only access so that they can help with diagnosing problems. To ensure there are no unwanted surprises in lab-style accounts, you can also set up billing alarms to give advanced warning when monthly spending exceeds some specified threshold.
What this all Means
In smaller organizations, DevOps teams adopting serverless can still apply all their current engineering practices in terms of continuous integration and automated testing. The benefit is that they can build and deploy new solutions faster.
In mid-sized organizations the serverless payoff comes both from enabling development teams to work more autonomously and from supporting the kinds of tinkering and experimentation that might otherwise be organizationally impractical.
Large organizations can see the biggest benefit, I think, because serverless in combination with the policy-based guardrails noted above, makes it possible to realize the agility that might otherwise be thwarted by process.
Finally, we've spoken, so far, only about agility as a software or IT concern. But I would argue that by lowering the time and effort threshold for a lot of projects, serverless can also unlock business agility. Basically, when you lower cost and speed up the timeline for projects, you make some feasible that previously might not have been.