Why some emerging technologies, such as serverless computing, make life complicated...

Working as a technical evangelist I get to see numerous different architectures and recognize how customers implement certain designs.

While I am an advocate of emerging technologies I have also seen how they can be overly complex and how some emerging technologies result in complicating simple solutions. The opinions below are my own and do not reflect the company I work for, Red Hat.

Some of these new emerging technologies provide limited analytics or hard data for usage, in the end, the customer is presented with a graph or values that say "You have used this much of X and you now owe Y dollars." Getting access to enhanced data is also either too complicated or not possible, depending on the specific platform and the service.

I remember reading a recent about a startup whose billing grew by 7000% in just a single day due to bandwidth utilization. The resulting bill increase was due to a change at the infrastructure layer. It seems this customer was using a REST API to interface with the native cloud service since their previous original code was no longer supported. A change at the service layer resulted in their application misbehaving and thus the incredible increase in cost.

I find it amazing that an application that for years had worked without issue suddenly was misbehaving because of changes that happened in the service layer. What even more unexpected was that the changes at the service layer were not communicated effectively to customers. I am sure this is not a one-time event or occurrence and situations like this happen quite often.

These are changes that customers may not immediately realize until it’s too late and their application is no longer working or in this specific case, the billing blew up exponentially.

Then recently I read an article about how a customer elected to select PaaS over IaaS as they saw it as a shortcut to allow them to focus on their mobile platform and not infrastructure and server management.

Similar to the other situation the first couple of years, things worked fine. They had some issues that would cause the occasional bad deployment and as a result, at times their services were down for minutes or hours while trying to debug the problem but they considered this acceptable.

One of the main complaints I hear have heard about many serverless architectures are logs, if available, can be misleading and at times cryptic.

In the article, the customer ran into an issue with Memcache and while attempting to resolve the issue with the cloud providers technical support it was determined the problem was specifically with their code.

This is where I find things to become amazingly interesting.

In serverless computing, you don’t own the infrastructure and have limited visibility. This can make troubleshooting even simple things remarkably complicated.

What may take hours to resolve could take longer, sometimes even days. I have even seen customers completely re-platform their entire application or service as they could not figure out what specifically broke and it was easier for them to deploy greenfield than to try and fix the broken infrastructure.

Of course, while serverless architecture provides many great benefits it can also introduce complexity as well. While rewriting code can be tedious, eliminating the specifications of a serverless platforms restrictions can help simplify a lot of the code.

Also, pricing can be easier in traditional architectures as you simply pay for what you deploy and consume. The answer for a lot of serverless architectures is to control scale with billing. However, the main problem with that perception is settings hard limits on billing can restrict scale and thus cause outages.

I am a firm believer that opaque billing simply doesn’t work. With the adoption of stateless and stateful micro services, such as containers and such, you can manage scale, billing and also still have insights into what the underlying infrastructure is doing.

Overall, some of the conversations with customers have been very eye opening.

One customer specifically mentioned their annual spend on infrastructure has been relatively constant since moving back to a traditional infrastructure. Another mentioned and they spend less now than when they used serverless computing services.

I think there are many details that have to be taken into consideration, though, such as scale and the services being provided.

A multi-billion Fortune 100 company can possibly benefit more from serverless computing than a smaller corporation, but you must also take into consideration the technical aptitude of the staff and what services you are providing.

It always reminds me of when I worked at a company previously and a developer started using a cloud service provider for all of his team's development environment activities. He was charging everything to his credit card and one day he came to me in a panic. I asked what was wrong, he told me he had a credit card bill of 20k dollars!

Apparently, he was not keeping track of the instances his teams were deploying, the storage consumed and other things such as shutting instances down when not in use. The end result was a very large bill that could easily have been mitigated by proper use.

It's easy for me to see how someone can get themselves in a lot of trouble quickly just when using IaaS via a cloud service provider, it’s so easy to spin up new infrastructure that billing becomes an afterthought.

I imagine it’s even easier to get yourself into a nightmare billing situation when using serverless infrastructure that is designed to scale.

Imagine if something malfunctioned and you write a bunch of erroneous data to a scalable database that had no limits on billing or size.

Or what if some function started to misbehave and was firing off thousands of times per second.

Even if you act quickly the damage, from a billing perspective, can also be done and there honestly is not much you can do about it since it’s your application or service that is misbehaving.

I guess as with anything, the ROI should be evaluated. It may make for some companies sense to adopt a serverless infrastructure while for others a more traditional design might provide a more suitable fit.