In a recent Twitter conversation, I asked if serverless is anything new, and if so, where are the documents expressing what is new about it. I was asked in reply if I needed a document to understand the difference between Uber and taxicabs. That got me wondering: is the serverless movement a business plan, or is it an approach to technology? If it is a business plan, then it is about how to make money; if it is an approach to technology, it is about architecture. It could also be a combination of the two. Serverless is also known as servicefull. But before we delve further, let us consider the difference between Uber and taxis.
For both Uber and taxis, the goal is to dispatch a driver to pick up a passenger at that passenger’s location and then drop them off at their destination. Technology allows Uber and taxis to do both things. Taxis use one method and accept payment at destination. Uber uses a different method and requires payment up front. Technologically, they are different, yet the same. The real difference between the two centers on the use of technology and the business plan of each organization. One simplifies the driver’s life one way, and the other simplifies the driver’s life another way. The Uber approach probably reduces fraud as well, as payment is made before the driver arrives and does not require a card swipe, which is how fraud often happens in taxis. However, which plan is better hinges not on technology, but on how to make money. Technology is an adjunct and a tool of the business plan, so much so that some taxi companies are following in Uber’s footsteps and testing their own approaches to dispatch and payment. Are they really all that different? The answer is “yes” in business plans, but not necessarily in technology.
Servicefull has been around for ages as well. For well over a decade, several companies have been providing services to their customers to include within their own organizations. What makes up a service? Usually, the use of an API to perform some critical function for another application. One of the earliest services available for developers was advertisement. A developer would add in a call to an advertisement platform, which did all the heavy lifting instead of reinventing the wheel. Use of services is the new form of reuse. We reuse our services. However, is using the services a technological decision or a business decision?
The technology is available via an API. Some services, like Amazon S3, are the de facto standard for object storage, enough that there are now S3 providers for all forms of storage, including local storage. However, the service in use may not be from Amazon. The API in use is the same: S3. Use of S3 is a technological decision. However, how to implement S3 is a business decision. These decisions are governed not by technology but by compliance, security, and cost—most importantly, cost that includes maintenance, development, etc.
When moving to a servicefull or serverless environment, it is a business decision whether to use one service over another, but a technical decision to choose an API over another. It is a business choice to use on-premises or off-premises services. Issues arise in this model when technology that does not yet exist is required by the business. Then, there is a decision to either switch services or wait for the feature to exist. This ends up being a business decision once more.
Many companies are starting out servicefull instead of using traditional mechanisms. Hooking disparate services together into a whole is the new approach. Previously, the approach was cloud-only. Before that, it was to buy hardware and services. Yep, services. Where did those services live? Outside the environment. We have been using services for accounting, marketing, and other business use cases., with and without APIs, etc.
Serverless and servicefull are business plans: plans that incorporate technological decisions into the business. This is the real difference in going servicefull vs. traditional plans. Technology is a part of the business decisions. Understanding the strengths and weaknesses of using a service is now critical to the business instead being seen of as an adjunct to the business. To go servicefull or serverless, the business needs to understand the costs, risks, and concerns with using services provided by others. When those services go out for whatever reason, what is the risk to the business? Is there a business continuity plan? If so, what are the costs?
Using servicefull or serverless strategies are about understanding risks, costs, and other concerns to the business. Technology is around to answer those questions for the business.
Share this Article:
Latest posts by Edward Haletky (see all)
- Finding your Sensitive Data to Protect - March 27, 2017
- Scale and Engineering - March 23, 2017
- SDS and Docker: The Beginnings of a Beautiful Friendship - March 21, 2017