Stop with the undifferentiated heavy lifting already
Luckily for all of us a lot of really bright people have been hard at work figuring out how to spend more time solving our business’ problems, and they’ve been sharing this information publicly for years. Entire conferences are dedicated to it. These practices and cultural changes are commonly referred to as DevOps. Practitioners and evangelists don’t always frame DevOps as a way to spend less time on technology problems and more time solving your business’ problems, but it’s all there. What is faster time to market if not the ability to try and solve your business problems more quickly than before?
The thing is you probably know all of this. Most of the people in your organization probably know all of this. So why aren’t you spending more of your time solving your business’ problems?
Everybody wants to spend less time performing undifferentiated heavy lifting
Serverless is the most compelling catalyst out there to help your organization make these changes. As with all buzzy words serverless can mean different things to different people. By serverless I mean ephemeral functions which encapsulate your business logic and expose organizational capabilities. These functions integrate with and consume managed utility services, and all of this is supported by tooling that structures your solutions and takes care of boilerplate, undifferentiated heavy lifting for you.
The Serverless Framework is the secret sauce that was missing before
Guard rails for the yellow brick road
If DevOps Oz is the destination, getting there entails following the yellow brick road. As many organizations have discovered, this road has sign posts but no guard rails. Tools like Docker have helped some companies along their journey, but the experience of many has been that doing the wrong thing is still easier than making the right choice. These kinds of tools and patterns work great and expedite the process for organizations that were going to make the change with or without the tool’s help, but do little for the organizations that need a tool to enable the change.
Serverless, and especially the Serverless Framework, make doing the right thing easier. Trying to put too much functionality into a single service? While nothing will technically stop you, you’ll feel the pain right away and get nudged into decomposing into multiple, smaller services. Having a hard time restructuring into embedded product teams? The Serverless Framework combines infrastructure and code into a single package, making it easier to deploy in complete, self-contained units.
There are still technology problems to solve with serverless — it’s a catalyst, not a panacea. The important thing is that even with these new problems you’re miles ahead of where you were before, and the self-correcting nature of the framework and tooling helps you stay on the right track for your entire journey.
No more death stars
Friends don’t let friends build death stars
Have you ever been part of a project that was planned to last over a year? How well did that go?
These types of projects happen to organizations caught in a painfully reinforcing cycle of shortsightedness. Common ingredients include monolithic systems with overlapping capabilities, integration as an afterthought, and organizational silos within which decision makers only maximize against ultra-local consequences — tragedy of the commons be damned. In this type of environment a boiling-the-ocean approach appears to be the only option for solving Today’s Most Pressing Problem. The problem is a hard one to address because death stars breed more of the same — each ocean boiling leaves the enterprise less able to deal with Tomorrow’s Most Pressing Problem and the cycle is perpetuated.
By helping you decompose your teams and systems into smaller ones, serverless helps you escape this death spiral. API design is a first-class citizen of serverless architectures, and the tools make it dead simple to create clean, simple, and friendly APIs for others to consume. This clean decoupling helps you break down the monoliths and frees up your teams to operate and iterate more independently of each other. This type of decomposition has always been the right way to do things, and by making the right thing the easy thing serverless saves you from yourself.
Breaking the technology diversity & governance dichotomy
Running and maintaining your software is critical to the ongoing success of your company and it would be irresponsible to not have some form of governance in place to support it. At many organizations software governance takes the form of limiting developers’ choices by standardizing — becoming a Java shop, for example. Too often this results in a dry and barren technology landscape, even while the outside technology world grows in complexity and diversity. The key to falsifying the governance-diversity dichotomy is to decouple the cost of governance from the process of exploring new and innovative technologies.
Through built-in support for automation, extensibility, functional decomposition, and code-driven access control, serverless can help keep governance costs constant even while the overall system complexity grows. Code-driven governance is a paradigm shift for what is often the most conservative group within an organization, but it’s one that serverless makes easier.
Don’t let command and control governance keep you in a technology wasteland
Data-driven decision making & ongoing experimentation
Many times organizations have a two-tiered model of decision making, where complex analysis and the tools to support them are available for customer facing applications while backend systems languish in a decision making stone age, relying on HiPPO (highest paid person’s opinion) or anecdotes and stories about what people want. And some poor souls are working in a place where all decisions get made in these types of haphazard ways. These decision making processes could make sense in a simple or even complicated domain (see the cynefin framework), but they hold no muster for solving complex problems where patterns and causality are not clear and ultimately must be disentangled through probing and experimentation. If you don’t see the problems your teams face as complex that generally means you haven’t solved the simple or complicated ones yet, which itself can be a result of stagnating in a state of undifferentiated heavy lifting — stay there too long and you’ll find that your competitors have solved the complex problems for you.
By breaking systems down into small, decoupled services bounded by APIs, serverless builds a strong foundation for collecting usage information and meta data on a per-service or even per-function basis. By tying this information back to SLAs, KPIs, or other measures of business outcomes teams have the information they need to iterate and experiment — and the loose coupling of the underlying architecture gives them the space and freedom to do so.