In my previous post, I discussed what serverless architecture is and why companies should care about it. The bottom-line: Serverless offers a powerful, new way for companies to dramatically reduce IT operational costs while cutting application development time and boosting customer responsiveness.
Every company should consider it for applications that are a good fit—for example, those that are only used intermittently or need near-instant scalability.
But what if you’ve already decided to go serverless? If so, there are six important items to consider first.
Don't try to reuse existing application code in a serverless environment.
You may have a specialized application you spent a lot of money building that you’d like to repurpose.
Don’t do it—it doesn't work very well. You’ll end up having way more code and heft than what the serverless environment was designed for. Remember, serverless architecture mobilizes on demand. The more code it has to process, the slower its response will be.
Instead, create entirely new—and minimalist—code that’s purpose-built for serverless.
Use existing AWS platform components for non-business logic application functionality.
We’ve seen many companies essentially try to reinvent the wheel and build in things they don’t really need, which defeats the whole purpose of going serverless. Serverless architecture already has all the execution components you need, so it’s designed to work within the serverless paradigm.
For anything that’s not related to business logic, the platform component should always be your first choice.
Create a reference architecture to guide all application development.
A reference architecture has many benefits: By creating a blueprint for what systems should look like, you ensure consistency across all your applications. You can move people across different projects, and they’ll still understand the components. Also, you minimize support issues inherent in “rogue” code. Many companies skip this important step, and that’s a mistake.
Make sure your application supports a DevOps-enabled SDLC process before you begin development.
Countless times, I’ve seen a company, needing to produce quickly, rush into development with none of what it needs to support subsequent development and delivery. All that effort ends up being an afterthought, to be dealt with later.
Problem is, besides slowing down delivery, this is orders-of-magnitude more difficult (and more expensive) than ensuring DevOps and good architecture upfront.
One company, for instance, spent about $3 million to quickly build an application and about $10 million afterward to retrofit the apps for continued rapid development, aiming to meet commitments for a fast-release cadence.
If they had just dealt with it upfront, it would have cost them a sliver of that—around $200,000 for a couple weeks of set-up and architecture design.
Recognize that the skills required for success in serverless are different from those of the average developer.
Developers who deal with serverless need a good understanding of the platform and how all its components interact.
That’s more of a generalist “full stack” skillset. But often, companies will try to deploy single-technology specialists to serverless, with predictable results: code is bloated, the wrong database is chosen and components are created from scratch, while well-used platform components are passed over due to simple ignorance.
When adopting serverless, it’s likely you’ll have to either re-train some of your existing people or bring on new talent who are well-versed in the environment.
Be prepared for a massive cultural shift.
In our experience, arguably the biggest factor has nothing to do with technology, and isn’t unique to serverless.
It’s the same problem many companies face when trying to adopt new IT: You need to be ready to do as much organization and culture restructuring as you do building serverless applications.
Here’s why: The massive horizontal IT bureaucracy that’s common in most companies is antithetical to radically simple applications that are the hallmark of serverless. You don’t need huge, siloed teams, each working on a specific aspect of development, to go serverless, because the platform provides all of what those teams provide.
All you need is a small, vertically-focused team to concentrate on writing the logic for a purpose-built application for a specific business function.
Think of the culture shift in military terms: Instead of having a large infantry division that does it all, you’ll need more of a special-forces focus—fewer but more highly-trained people. This is definitely a big cultural shift with which many companies struggle.
To reiterate, serverless offers considerable potential. Maintaining an open mind and learning from others’ experiences helps turn that promise into reality.