Insights from Nate Taggart of Stackery on The Serverless Revolution

I recently had the pleasure of hosting Nate Taggart, Co-founder and CEO of Stackery, for a great discussion on serverless computing. Stackery, the enterprise serverless operations console, helps enterprises operationalize serverless applications to run in production.

We at YL Ventures have been looking closely at the space for some time now (see VentureBeat article on the opportunities in serverless, co-authored by several of my colleagues back in October), and so we were excited to hear Nate’s current view on the market.

I recommend checking out the recording, but below are some key takeaways from this insightful conversation:

On enterprise adoption of serverless

• It’s already happening, though it’s not necessarily a top-down directive from the CTO – it’s often developer driven.
• Enterprises have a high bar for what a technology should look like before they can adopt it. Until they can understand how to test it, reliably and automatically release it, manage observability, governance and – of course – security, adoption will take time. These challenges represent opportunities for startups.
• The leaders in adoption aren’t necessarily who you would think. It’s not Silicon Valley unicorns leading the way, rather it’s companies like Nordstrom, Capital One and iRobot (maker of the Roomba) who are ahead of the curve. Organizations with highly transactional workloads and spiky traffic are the ones most incentivized to adopt serverless, as it can help them manage costs as they scale. Taking Google as an example, they have massive traffic, but it’s more predictable and the business case for them to adopt is not as strong.

Advantages and Disadvantages for Developers

• Giving control to developers, allowing them to iterate and shift software quickly is a big benefit. It’s also cheaper from the organization’s perspective.
• There are challenges as well. Unlike containers or virtual machines, where you can recreate your production environment locally, you can’t replicate the environment on a local machine. Developers tend to have to build code, ship it to the cloud, and test on the cloud; developers need to manage their release workflow tightly, and they must configure their cloud account to have a sandboxed developer environment.

On Security

• Advantages include the isolation and granularity that comes with compute instances spinning up on demand and shutting down after a transaction; it is stateless by nature.  This granularity also allows you to isolate vulnerable areas of an application in a more precise manner.
• There is also risk that comes with the fact that companies’ existing tooling doesn’t work anymore. If they are used to instrumenting code for security monitoring, software tools that they’ve used may not work – there is no server to put code onto. An organizational shift needs to happen as developers now have to instrument for operational AND security concerns during the development cycle (e.g. with logs, if you aren’t configuring Lambda to log data that you want to see, there is no server to SHH into after the fact to pull data out of).

Where should/shouldn’t startups compete?

• To compete with cloud vendors, you should build adjacently to their market, not compete directly with them.
• Take AWS as an example – it is a commodities business. They do volume and want you to take these (many) generic services and build what you want; no one can buy as many servers as Amazon, and they know this is where they are guaranteed a win. Custom, use-case driven, value-add workflow software is riskier for them; they may win (they have a lot of talent), but they aren’t guaranteed victors.
• Think about starting with a small niche, and employing a land and expand strategy. New Relic started out with performance monitoring for just Ruby on Rails applications and ultimately built an IPO-level business.
• What about observability (a space where we have seen a lot of startup activity)? Again, go back to Amazon – they are great at doing the first 30% of everything; they give a basic offering and support broad, generic use cases. CloudWatch, for example, is an adequate, but not great, logging platform. It’s built-in and convenient, but there is a reason that there are logging vendors in the market. Same thing with CloudFormation for infrastructure as code – it is really powerful, but hard to use, and so you have Terraform.

On the Future of Serverless

• Is the future multi-cloud? Concerns around vendor lock-in are, though talked about a lot, overrated. It’s a nice-to-have, but every decision you make has some sort of lock-in, and Nate doesn’t see cloud vendors as a particularly special case of this.
• What should DevOps teams do? Firms are no longer responsible for scaling, orchestration, and configuring hardware to handle failures, but Amazon doesn’t own errors in your software or the availability of the services you attach your serverless code to. Serverless isn’t ops-less, rather it changes who needs to do the ops – it’s impossible to have mature serverless program without a mature DevOps program.
• Today with serverless, we are mainly talking about public cloud managed services (AWS Lambda and Azure functions). In 5 years, the definition will broaden, and we will see serverless as a technique, architecture, pattern, and design choice. A lot of technologies will fit the serverless model.
• When it comes to acquisition in serverless, Nate is bearish on the cloud vendors. Look more for legacy IT companies like Oracle or IBM that want to modernize in a cloud-based world would with a winning story.

And there you have it! Thanks again to Nate Taggart for sharing so much of his expertise with us; we enjoyed the discussion immensely and hope that our audience did as well.

If you have feedback or suggestions for future episodes, please let us know! You can reach me at @jbrennan09 on Twitter or via email at [email protected].