3 tips for serverless success in 2019

Let’s cut through the noise. The “serverless” label is slapped onto an ever-growing number of products nowadays, but there are a couple of characteristics that should always hold true: anything that qualifies as serverless computing must have utilization-based (not allocation-based) billing and remove all need for infrastructure pre-provisioning or management. That means your application isn’t running (or incurring charges) when idle, and that you aren’t exposed to any aspect of server setup or maintenance. Think Azure Functions or Amazon Aurora Serverless database.

What should you do in 2019 as you evaluate and start using serverless products? Let’s look at three action items.

1. Have a conversation about “and” not “or”

Your team just started deploying Kubernetes and seriously using public cloud infrastructure, and now you’re feeling the heat to start exploring serverless, too? It’s a lot. The key thing to know: serverless platforms complement what you have; they won’t replace every other application host. Don’t think of it as “use containers OR functions.”

It’s addictive. You’ll introduce serverless platforms to augment (and selectively replace) what’s already there. Also, you’ll find serverless computing a natural extension of your already-underway technology efforts to build microservices, deploy an event-driven architecture, establish a DevOps culture, and initiate continuous delivery. By itself, serverless can be just another way to build the wrong thing, faster. Combined with other efforts to get better at software, serverless is an accelerator.

One big reason you won’t switch to running entirely serverless systems anytime soon is all the software architectural changes required. You can’t “cheat” like you did when moving physical boxes to virtual machines, or from virtual machines to a platform-as-a-service. It was entirely possible to adopt those platforms without changing the workload at all.

Not so with serverless. Virtually nothing in your app portfolio lifts-and-shifts to a serverless platform. Rather, you’ll need to refactor or rewrite software to accommodate the scale-to-zero, event-driven nature.

2. Think of functions as the glue connecting managed services

So what will run in these new serverless platforms? Lots of things. You may serve up static sites, create lightweight APIs that return data from line-of-business systems or handle webhooks.

What’s important to recognize, though, is that serverless platforms aren’t just another home for your code. Rather, they’re about limiting the code you’re writing in the first place! Don’t decompose an existing application into a set of a few dozen functions and try to stitch them back together in a function-as-a-service environment. That approach will increase your complexity and operations cost, without returning many benefits.

Rather, return to the initial business problem, replace code with managed services wherever possible, and write the glue-code necessary to connect it all. What kind of managed services am I talking about? User management systems, messaging, data synchronization, and more.  For instance, you might continue to use a Spring Boot web application to collect data from customers, but leverage managed services to authenticate users, transmit data to downstream services, and send real-time notifications when a product ships. In that architecture, you might convert your stateful inventory processing app written in .NET to a series of lightweight functions that respond to state changes in the system of record.

When building brand new applications with serverless systems, follow the same ideas. Build as little code as possible, use managed services, optimize for quick learning, and don’t create technical debt by over-engineering your solution.

SEE ALSO: What can serverless do for Node.js developers?

3. Embrace the immaturity, but isolate your risk

It’s hard to find a technology domain evolving faster than serverless. The three major cloud providers keep introducing new capabilities to their function platforms: AWS Lambda now supports more runtimes and managed service integrations; Microsoft’s been adding new languages and robust support for stateful functions and Google’s Firebase keeps getting better for mobile developers. Don’t overlook the novel distributed serverless approach by Cloudflare.

Recently at Kubecon, a host of software vendors took the wraps off their software-based function platforms, most based on the Google-led Knative project: Pivotal took the wraps off the multi-cloud Pivotal Function Service; IBM, Red Hat, SAP and GitLab also shared Knative-powered products; and Oracle announced a new cloud-based service, Oracle Functions, based on the OSS Fn project. Note that all of these are at various levels of maturity and readiness. But between these commercial products and the variety of open source projects, the landscape of choices is undeniably wider.

What questions should you ask yourself when deciding how deep to wade into this pool? Here are a few to keep in mind:

• How will you connect functions together into an “application”?
• What’s the right way to track dependencies and keep your functions up-to-date and secure?
• How are your datastores evolving to deal with short-lived, stateless services?
• How do you monitor and trace a distributed mesh of functions?
• What operational aspects “work” with a dozen functions, but collapse when you have a few hundred?
• Where can I experiment and learn about these platforms without prematurely making business changes that add significant risk?

In 2019, take a serious look at the business and technical implications of adopting a serverless platform (and mindset!). See this as initially complementary to what you’re already doing, while recognizing the inevitable march towards connecting on-demand managed services together. If 2019 is the year that you commit to getting better at delivering software, serverless is part of the equation.

The post 3 tips for serverless success in 2019 appeared first on JAXenter.