Come January, pretty much any current tech keyword you type into Google News will result in hundreds of prediction op-eds and roundups. The fact that it's an entirely new decade has amplified this phenomenon and serverless is no exception.

As the CEO of a company dedicated to helping software teams build, manage, and deliver serverless applications, it's a joy to read these posts by some of the brightest minds in the industry. Selfishly, consuming these articles has been an almost tailor-made way to start my workday these first few weeks of January!

But as enlightening as they are, too many of these look-ahead posts ironically overlook a crucial part of the serverless narrative. That is, the outdated assumptions and some of the historic roadblocks to implementing serverless---ones that we get to leave behind this year.

With that framing in mind, I'd like to eschew the temptation to focus on serverless predictions this year and instead take a look at how far the industry has come.

Moreover, let's explore what this serverless maturity means for your software delivery team.

What we're ditching in 2020

Implementation battles with management 

2019 set the stage for evolved serverless offerings and investment from cloud heavyweights (AWS, Google, Microsoft) and established enterprise vets like IBM. Real teams are now implementing serverless architecture today. Serverless is far from a smile-and-nod topic in 2020 which means there are more widespread use-cases available for team leaders to see.

Given that the industry has overcome a lot of serverless opacity over the past few years, there is far less toil and friction when making the case for adopting serverless architecture.

A couple years ago software teams spent time justifying a move to serverless--- usually because they needed to assure management's concerns about security, expense, and scalability. All of those things are relevant concerns and great questions to ask when exploring any new architecture, but the market for supportive tools to fill these gaps and provide advanced serverless observability is booming.

As an example from Stackery, we allow you to fully manage the serverless applications you build, giving you advanced insights into your total spend on AWS resources, along with policy enforcement, secrets-management, and more.

We're also integrated with observability offerings like Epsagon, which provides deep meta-data insights about your serverless environment as a whole. These kinds of capabilities give managers the confidence they need to have teams move forward with serverless initiatives.

Poor serverless developer experience

Software developers are constantly expected to adopt increasingly complex tools to innovate the software architecture at their company. Too often, this routine feat is taken for granted---we expect engineering teams to adopt the latest tools in order to address enormous business challenges and get perfect results at the speed of light. But developers are human beings, too and their experience of these tools and technologies is extremely important. To further advance the serverless movement, its functionality and and usability must be tightly interlaced.

In the wider community, serverless has raised two consistent DX concerns in the past: 

1. "If serverless involves many third-party services and function platforms, doesn't this limit my control?"

2. "Serverless seems to have incredibly complex architecture diagrams... doesn't this undermine the larger goal of greater efficiency and abstraction of extraneous efforts?"

Developers expressing these concerns are really worried about their daily experience and ability to put their name on quality work. Business leaders hearing these concerns interpret a huge risk of inefficiency, burnout and thus, lost dollars.

Stackery has always been focused on serverless usability---especially for teams. Our Visual Editor lets users toggle between Visual and Template mode and equips them with a drag and drop interface for AWS resources. But over the past year, we've taken even greater leaps towards addressing serverless DX.

Teams worried about interrupting a pre-existing tooling workflow were greeted with our 2019 release of our VS Code plugin, which allows teams to use the tools and patterns they are already working with, but now with more efficiency, observability, and confidence.

We are excited to play such a key role in improving serverless DX in 2020.

Latency and performance concerns

Late last year, the AWS Lambda team shared a very big announcement: Provisioned Concurrency.

Those who aren't currently using AWS for serverless development might not have felt the true impact of this news. But even the teams considering a stronger commitment to serverless in 2020 should take it as a sign of true industry maturity.

In short, Provisioned Concurrency has changed the game. It allows AWS Lambda users to pay a marginal fee to keep functions "initialized and hyper-ready to respond in double-digit milliseconds". This means former latency concerns (i.e. "cold starts") can be a thing of the past and it's all managed by a simple AWS configuration. Provisioned Concurrency allows the languages with longer startup times, like .NET and Java, to be unaffected by cold starts.

The announcement of Provisioned Concurrency was the perfect punctuation to a year filled with major serverless evolution: AWS' largest serverless performance concern  is now a footnote in serverless history and teams should feel empowered to adopt AWS for their serverless needs today.

AWS Serverless = Lambda misconception

Since its release in 2014, AWS Lambda has become synonymous with AWS serverless. Yes, Lambda is the primary serverless compute service offered by Amazon, but to claim it encapsulates serverless overall is a massive oversimplification and one that could overwhelm your engineering team down the line. For teams in the earlier stages of exploring AWS serverless, it's critical to understand that it's much more than just AWS Lambda. You'll need a firmer understanding of the full suite of AWS tooling like Amazon API Gateway, S3, Cognito and much more. Used together, these services are what make up your serverless architecture. Sound complicated?

With Stackery, it isn't. Your team can sidestep the need to become experts in AWS tooling or reinvent the wheel in order to steer it. By leaving that nuanced understanding of AWS' total library to us, your team can confidently go forth to utilize those more complex and advanced tools without wasting any precious development time.

Watch our drag-and-drop Visual Editor in action to see what I mean. 

Kubernetes hype

Kubernetes is probably the most widely-adopted container-orchestration platform amongst industry stalwarts and much smaller organizations alike. But too many people accept the unnecessary complexity of Kubernetes as a dogma, and not enough teams honestly question if such a complex and costly implementation is right for their business.

I believe that the rush to adopt Kubernetes simply doesn't make sense for many organizations. Kubernetes was built by Google to help them manage the massively complex feat of indexing the entire internet. It's also useful for aforementioned stalwarts like Pinterest, Reddit, Twitter, and other cutting edge organizations that differentiate and compete on their ability to manage infrastructure complexity to support the scale of their offering.

Kubernetes makes sense for those companies that have the size, massive bank account, and people-resources to remain on the bleeding-edge of technological advancement and maintain the software architecture that fuels the effort.

The fact is, most companies looking to modernize their architecture don't differentiate on their infrastructure management---they see that as a commodity. They differentiate with the technology they deliver to their customers, partners, and employees.

Kubernetes is simply not for everyone, or reasonable for each business. We have seen firsthand that AWS Serverless can help organizations achieve the benefits they seek without having to take on the architectural and organizational complexity that Kubernetes brings with it.

It's time to leave the Kubernetes hype back in the last decade and embrace a leaner and more gradual modernization strategy that tackles the most pressing architectural components out of the gate. That strategy rests on serverless development (not containers) for most businesses.  

Team takeaways: harnessing serverless maturity  

Serverless is arriving at a point of maturity and that can be seen in the outdated assumtions and challenges we can leave in the previous decade.

In 2020, the case can clearly be made for migrating from legacy, monolithic architectures to microserverless. Though it's never a turnkey process, it can be a very straightforward one.

At Stackery, we've witnessed this shift firsthand and have helped many of our customers break the monolith and undergo true architectural transformation. We do this by bridging the gap between cloudside and local development while automating safeguards and AWS best-practices.

This year, I'd obviously like to see the serverless evolution continue, but I hesitate to predict that this will happen on its own. To fulfill any of the serverless takeover prophecies published this month, software delivery teams must do the following:

• Protect developer productivity 
• Focus on differentiation
• Clarify business logic
• Get advanced support

Stackery is here to help you do all of these things on day one.

>> Make that day today by scheduling some time with our serverless engineers.