5 Ways Serverless Changes Software Development
As a new approach to the design of distributed systems at scale, serverless ripples out in waves of changes across an implementer’s stack. First come the experiments to test the value of serverless: does it reduce costs, increase developer velocity, and integrate well with existing IT systems? But once this is being tested it becomes apparent that it is not just about whether serverless fits an organization’s needs, it is whether the organization has the capacity to implement serverless successfully.
Similar to Martin Fowler’s famous quip that “you must be this tall to ride the microservices train,” serverless also has organizational requirements for teams. Organizations must be able to encourage independent, autonomous decision-making amongst developer teams; must have the capacity to learn from experiments; must be willing to build in the dark where the ecosystem maturity doesn’t already provide necessary tooling; and must document architectural components in a way that other team members can pick up at their point in the workflow.
While there must be some of these characteristics already in place for an organizational team to benefit from serverless, it is once serverless is being implemented that those ripple effects wave out with a stronger pulse. Team dynamics change. Business processes change. Budget processes change.
Nate Taggart, CEO and co-founder of serverless DevOps tool, Stackery, says serverless is changing some of the fundamentals of how applications are designed within enterprises: “Basically, companies adopting serverless are transitioning from a process of designing their app, going through an architecture review, and then handing to the ops team who takes it and delivers it. That’s worked well for years,” said Taggart. But with serverless, that changes, and brings cultural changes to organizations along with it.
Oliver Friedmann, chief technology officer at video platform-as-a-service provider, Ziggeo, is now trying to ride the ripple effect of serverless across the award-winning business, founded by Susan Danziger. Danziger points to the company’s latest feature, a first for video APIs according to Danziger: providing video analytics to their customers. That feature is being driven via a serverless architecture. Over the next year, Friedmann now plans to move the entire Ziggeo stack to serverless.
Taggart and Friedmann, are seeing these changes play out firsthand and have identified at least five ways that serverless is impacting on business culture.
1. Upfront Architecture Mapping as a New Leading Practice
Friedmann said that when Ziggeo’s engineering teams were introducing the new video analytics feature, the first task was to define the data flow.
“First we had to define properly what each service does, and we had to map the data flow, and write the service specs in such a way that if a service crashes, the critical data doesn’t disappear. All failures had to be handled gracefully,” said Friedmann. That task was done by him, as CTO, and his vice president of engineering.
Taggart says he is seeing this upfront architecture mapping become the norm amongst serverless adopters. “We are seeing new leading practices, especially as companies need to automate their policy and review processes,” Taggart says in the old application development model, Ops teams would be responsible for creating static identity and access management (IAM) policies after the fact.
“But in a serverless model, you go from having a team of 10 ops engineers to having a team of 100 developers, and those developers often don’t have that same level of ops expertise when setting IAM policies. So they are creating the IAM policies on the fly, and you don’t want them to make access to resources too loosey-goosey.”
Taggart says this is the new culture change: doing IAM policies as part of the architecture mapping. “You create a rules set, you say here’s how we define the policies, these are the reasonable rules for that. Then you let the serverless tooling create the IAM policies according to those rules.”
2. Closer Frontend and Backend…
Once the architecture map was defined, said Friedmann, “There were two teams. One was writing the client side, where the analytics events were being generated. But the client-side team was also working hand in hand with the backend team, who was creating the lambda services for receiving the analytics events data. So both teams were together. Our backend team then independently deployed the databases.”
Taggart sees a similar blurring of front and backend skills. “You can replicate AWS on your laptop,” Taggart said. “In serverless, we often focus on the FaaS (function-as-a-service) part, but there is also a compute layer: you still have an API and a database connected. So devs need all of those components. Which means they end up doing their dev cycle in the cloud. They have to be able to provision into the cloud. Some companies are creating that each dev has their AWS account, some are saying here is our joint account with higher privileges, and then having a separate one for production.”
3. …But More Developer Independence
So while projects may start with devs having more of a full stack mentality, once the architecture is mapped and the components of a serverless stack start to get built out, each developer ends up working independently on their own service component, and here the culture change harks back to what others, like Steve Faulkner, have already noted: the need for greater autonomy amongst developers.
“The handoff of the data is not as close as it used to be. Each developer in the team has to determine their own internal APIs, once they spec them out, they can work on them independently,” said Friedmann.
4. Build in Production
With the launch of the analytics feature, Ziggeo customers can configure their analytics to see how their end customers use any aspect of the video platform: which browser they view, how people interact with the videos, whether people watch the first 30 seconds or skip ahead and play it again, how many times the video recordings were done, how often users re-recorded their videos… In order to give customers a richer data experience, Ziggeo split the new feature into two components: They have been collecting the data to feed the analytics system for a year, but have only created the visualizations and features for customers to use the analytics in the last few months, and launched six weeks ago.
“We wanted to see how well serverless worked because we had been playing around with Fargate, the backend container service before so we knew that part of the data flow would work,” said Friedmann. “Since this wasn’t an officially launched product, we wanted to see what happened if Lambda failed, and we could do that without upsetting customers.”
Friedmann explained that with serverless systems, it is more difficult to get a full picture of how systems work in staging environments. “Testing in production is important to see if this is a good fit, and its best to do that without raising customer expectations. In staging, we do not get massive amounts of data, so we wanted to see how it would perform in the production environment under a heavy load.”
Taggart explained this type of under-the-hood testing in production accentuates the benefit of developer velocity when leveraging serverless.”The big gain is velocity but we will slow it down by going through a review cycle, it is just too slow. Typically, the review cycle happens before deployment, but now we are developing and shipping incrementally at least into a developer account.”
5. Less DevOps for Launch
Finally, when Ziggeo did launch the new feature, they had less work for the DevOps team to review. This is the culture change Taggart had flagged when he said that the application development process was changing from building an app and then handing it off to Ops to launch.
“What I am most excited about when using serverless components, is that DevOps really goes down. We don’t have to worry about the servers going down, we don’t worry about making sure security patches have been updated, we don’t have to worry about traffic spikes,” said Friedmann. “DevOps boils down to making sure the databases are strong enough to handle the load. So there are much fewer bottlenecks.”
No doubt, there are more examples of the impact serverless can have on engineering teams. These four concepts were already part of the organizational culture for many architectural and engineering teams when building distributed applications at scale, but with serverless, they are reconfiguring how teams communicate and work together, the level of independence each team member must show, and even the way new features and products are built in production environments and launched from there, with fewer worries on initial spikes as new customers start playing with newly announced features or whole products.
Feature image: Photo by veeterzy on Unsplash.
