Navigating the map of corporate IT can be treacherous for New World technology folk. Here are the top five objections to expect when you want to go serverless. You’re ready to get serverless into your organization — you’ve identified an opportunity, know how to build out the project, and now it’s time to get IT on board. The only problem is the Big Department of No has issues with this newfangled technology so how are you going to convince them to allow this heresy? Knowing the layout of Middle Management Earth is the key. Let’s take a look at some common concerns and see if we can address their major objections. Objection #1: We don’t need this. What’s Lambda good for? Resizing images. It’s awesome at resizing images, especially ones in S3. Unfortunately, most company applications cannot be replaced by image resizing alone, so we need to expand the realm of possible use cases and get people thinking. The same examples are recycled so frequently that we need to talk about how serverless is used. actually Almost is a good candidate for serverless — and these represent a number of workloads in typical companies. Cron jobs, reports and batch processing are at the top of the list. Even many supposedly synchronous tasks can work too, mainly because the latency just isn’t that terrible. any asynchronous task huge When your IT leaders give you the side-eye on serverless, remind them that it’s also . Functions are nice but if you add CDNs, object stores and databases, you now have all the toys needed to turn any flowchart into a working application. much more than functions Better yet — and they should like this — you can now build highly secure applications that scale automatically and cost a fraction to run. And you don’t have to manage any infrastructure to get these workloads to run forever. Let’s TL;DR those bullet points again: Highly secure Scales automatically Costs very little No infrastructure to manage So if they if want applications that just work with minimal management — you know, like congratulations, you just found the answer. Say it with me: Serverless is for everyone. most applications — Objection #2: This is nothing new. Bonus: Serverless is just a buzzword. According to some people who are wrong, serverless is nothing new. There’s an eye-rolling tendency with new tech to compare it to some past experience in a way that dismisses the actual benefit of the new. In this view of innovation, FaaS is sorta kinda like time-sharing on the mainframe much like taxis are the same . de minimis horse-drawn Hackney carriages This is tough one but I think we can dig ourselves out. Hopefully we can agree that horses and cars are different. Never mind the speed, convenience, air conditioning and lack of horse odor, there is a general ecosystem upgrade with taxis — the cost collapsed, taxis are everywhere on-demand, you can scale up the passenger count easily, and they gave rise to the next iteration — ride-sharing. The lack of horse manure on the streets is pretty wonderful too. So my point is, FaaS is to time-sharing on the mainframe as Uber is to horse rides. As a bonus, I was recently informed that ‘serverless is just a buzzword’ in that ‘everything you’re working on is a waste of time’ sort-of way. Both these sentiments were common in the early days of cloud too. Sure, I could tell you that serverless is so much more than an efficient use of an idle system, from practically no concurrency limits, infrastructure management, increased agility, and to a total refocus on business need instead of systems management — but I know these guys. They just want to tell you nothing is really new. Best just to agree and move onto to the next roadblock. Objection #3: “But vendor lock-in!” I’ve only ever heard this complaint from companies with multi-year Oracle contracts, Windows on every desktop and zero diversity in their infrastructure. It’s really strange to me. I can’t decide if it’s a catch-all gotcha in response to new ideas or genuine hand-wringing over committing to a single cloud provider. If we’re honest, any choice of technology involves vendor lock-in at some level, especially in enterprise IT. The question is really: are you trapped? Is there a 5 year contract (like Oracle)? Are prices going to suddenly spike after a cheap honeymoon period (like Oracle)? Can you move to another platform (unlike Oracle)? By any metric, committing to any serverless provider has significantly fewer lock-in issues than, say, choosing an on-premise RDMS provider (I can’t think of an example). Still not convinced? Well the good news is that you can mix-and-match serverless providers. Run your functions on Lambda, do your authorization in Google and store your data in Azure — go for it, it’s totally possible. Better yet, add an abstraction framework like and you can become much more provider-agnostic. Serverless From a business perspective, unlike the old days of rising IT vendor costs and multiyear commitments, all the major cloud providers have shown the opposite — costs continue to fall and this is now a pay-as-you-go world. Even if you choose to lock yourself into Amazon or Microsoft, you might be happy that you did. Objection #4: “My [team|manager|boss|cat|dog] won’t like this.” I used to think this was a flip-side to the tech Holy War problem — you know, where a group using one technology will never try anything else. But I’ve found it’s more related to fear of change in relation to people’s jobs. Beswick’s Law says that . Go ahead — Google it and I’ll wait. any mainstream discussion of artificial intelligence will eventually lead to a headline with a picture of The Terminator So it follows that since serverless means no servers, no servers means more automation, and more automation means a huge line of DevOps people in unemployment offices. DevOps people will just love the paper forms, fax machines and human interaction needed to get $100 a week. And to think it all started thanks to a harmless Lambda function resizing images. At least, that’s what some executives are hearing, and the #NoOps movement is ruffling some feathers in some entrenched teams. But it’s all bogus — in every serverless implementation I’ve seen, the DevOps engineers become the most important developers in the group. In fact, the man below, from ServerlessOps, frequently makes that exact point, even though his first presentation slide can suck the air of out most DevOps meetings. Tom McLaughlin Ops Teams — Don’t be scared of the man in the pumpkin suit. Why? Serverless management requires all the smarts that DevOps is good at — from security to deployment management — and this function is central to a fully serverless environment. It’s true that the job changes — you lose the annoying, repetitive, dull parts of managing infrastructure — but (I’d argue) it’s much more interesting. And you’ll get more sleep. This objection tends to have an aura of the Fear Of The Unknown — understandable but unfounded. As IT departments move from being a cost center to a strategic engine of most companies, we have to shake off the activities that aren’t a good use of our time. And yes, that means change for everyone — but no Terminators. Objection #5: “Serverless isn’t ready yet.” There’s a good portion of IT executive management who are terrible at predictions. Over the years, I’ve heard… Nobody will ever buy anything online Nobody will ever use their phones for banking Nobody will ever trust their data in the cloud … and these same voices that are consistently wrong and never held to account are often driving their IT departments. Go figure. The specific charge against serverless tends to take two forms. First, “nobody is using it”. Nobody apart from Coca-Cola, Zalora, Nordstrom, Next Door, Blackboard, CodePen, A Cloud Guru, Bustle, Localytics and thousands of others. Well, “nobody is using it ” — apart from Zillow, iRobot, Thomson Reuters, Netflix and (let’s not forget) Amazon itself. at scale Okay, so what they mean is serverless tools are currently immature and don’t support < >. It’s all true but it’s like complaining that flying cars are terrible because they don’t cure vertigo. There are new companies populating the ecosystem to address these gaps at all the time— take a look at Stackery, Epsagon and Binaris as shining examples. insert arbitrary requirement here Don’t get me wrong — some people have legitimate gripes against the cloud provider’s consoles, API limitations and problems with observability and debugging. Some of the brightest people I know in this space have glorious rants about all these issues and more. And you know what? They still use serverless. Second, the ‘too early’ claim is based around serverless being new, which it’s not. Lambda, the grand-daddy of the FaaS movement, is 4 years old and the development pace has been accelerating continuously. I don’t know what’s been put in the water at AWS but the Lambda feature release log has gone crazy over the last 12 months. First release on the far left: “Do timesharing like the mainframe”. Just because you haven’t heard of something doesn’t mean it’s new — serverless has been around for a while, it’s used by some major projects and companies, and the general hum of should be an indicator that’s it’s ready for you. On the plus side nobody has said, “There are servers in serverless” in quite a while so we’re making progress. success stories
