A recent article on Medium stated that serverless is a doctrine, not a technology. This raised the age-old question of what is serverless – Is function as a service everything serverless? To answer this question and more, we got Hillel Solow, CTO & Co-Founder here at Protego and Ryan Jones, CEO of Serverless Guru to discuss all the latest topics in cloud-native and serverless.
Function-as-a-service is often conceived as what serverless is, but Hillel reckons it is only a part of what the definition of serverless encompasses. As the article mentions, serverless is a doctrine and the way you approach software. Ryan conquered and added that, in his mind, the real value that serverless brings is the holistic user-centric and product approach, which molds teams together into one unit, focusing on their product and customers’ needs, rather than dockers or servers.
Hillel presented another concept, claiming that you could do serverless with containers or even virtual machines if that fits the use case. Serverless is really about trying to own as little as possible, operate the smallest set of operations possible, and not manage things you don’t need to manage. The bigger question here, in Hillel’s eyes, is when will people start wrapping their heads around how to approach serverless beyond the basics of lambda functions and cloud providers.
From Ryan’s experience at Serverless Guru, he learned that companies can move slow from all sorts of reasons such as company size, the number of teams, the number of customers they actually service with their applications, and many more factors that prevent them from moving fast. So without even considering the complete shift that serverless provides, there’s still a long way to go before people start fulfilling and realizing the full scope of the serverless doctrine.
An article on TechTarget grabbed Hillel’s attention, raising another age-old question – should companies put the effort into trying to stay cloud-agnostic, or should they focus on one provider and put their efforts in making the most out of what they have to offer. The article by Chris Moyer stated some interesting points, one being that the cost of moving to another provider is not as high as they used to be, so it is possible for as little as one application to use multiple cloud providers in case one doesn’t support all its needs. Another possibility that became available is A-B testing between platforms to map out the best uses for each one, depending on the needs. At the same time, the article makes a valid point by saying that for most companies, there is more complexity than gain when it comes to being cloud-agnostic, and in most cases, they will be better off getting some mileage trying to figure out how to best use the one cloud provider.
As Ryan works with a lot of customers on building their products, he was able to gauge and weigh the different approaches, and test which one has the most benefit, and in which use-cases. Ryan’s conclusion after working with many clients on different platforms with different approaches, is that the AWS platform and its services provides much greater automation possibilities than Google Cloud.
With that, Ryan found that what works best for them is using Google Cloud Build to do the CI/CD pipeline as if it was a recipe for a meal and passing it to Amazon to make the whole thing happen. Using Google Cloud Build for deployment has benefited their process a lot, mainly because it’s almost like an isolated piece for implementation. This enabled Ryan’s team to move fast since they keep the same structure. Being able to fully manage services, and pick and choose which providers are best by finally creating patterns to harden that process, is a real game-changer in Ryan’s opinion. Hillel added to Ryan’s point that this approach could be described as picking the best technology for what your needs are, rather than picking the provider you are going to stick within advance.