Why Serverless Requires Rethinking the IT Department
There is a story from Melissa Jurkoic, Senior Solutions Architect for Enterprise Solutions at Amadeus Hospitality. When her team was introducing APIs into the organization, they found that they were often challenging existing ways of working between business and tech leads. Overcoming those obstacles paid off, and as the API team grew, they realized they needed an API Evangelist on deck. That’s when Jurkoic came across a new challenge with APIs she hadn’t seen before: APIs were about to disrupt the HR department.
Today, APIs are requiring new internal team relationships, and this is disrupting traditional and large enterprises. As can be seen currently in many banks around the globe who are moving towards APIs, current recruitment processes are ill-equipped to understand what sort of team members should be brought on board to manage their APIs as products, to evangelize them internally, and to work with external developers to encourage adoption.
Now, that same type of tech-to-HR disruption is being seen with serverless. The team makeup that can work on serverless applications is considerably different from traditional IT hires, so existing job description templates and selection criteria don’t necessarily apply. This is set to fork even further from existing practices as developers continue to have more say over budgets and to set business direction through the architecture styles and applications they create.
Paul Johnston worked as Chief Technology Officer at tech startup Movivo and helped manage teams working in serverless environments. He believes there are specific aspects to managing serverless developments (and deployments) that will change the dynamics of teams, and the type of characteristics sought after in new team members.
Serverless architecture, said Johnston, is a system that costs you nothing if no one is using it (except for the data storage component), so it reduces maintenance in one aspect, but developers and architects need to ensure automation is maintained: “you can’t escape that,” Johnston warned. But there are several unique aspects that are more present with serverless systems: functions as small units of code for business logic orchestration, using event-driven architectures that avoid connections to servers, and infrastructure-as-code approaches.
Speaking last year at Serverlessconf in New York, Johnston said that serverless teams are beholden to today’s developer and DevOps best practices: daily standups, version control, managing CI/CD pipelines, QA testing, code reviews and agile product management. “No one is doing these 100 percent of the time,” Johnston admits, but urges all teams to make best practices the baseline for serverless.
Paul Johnston also warned against making a single service team member responsible as a support contact.
Beyond that, the biggest differences between how serverless teams work compared with usual DevOps and application engineering teams can be summed up by Johnston’s formula: Slack and Automate and Document (SAD). Serverless engineers need a broad skillset, they are pragmatic hackers. “Because functions are small, but also high-value units, engineers need to be able to ship them fast. They don’t need to make them overly complicated, they don’t need to be perfect,” suggested Johnston, “they just need to work, and if they break, a new one can easily be built.”
Johnston identified four smaller teams within a serverless environment, responsible for key management areas:
- Functions-as-a-service engineers
- Services engineers
- Events and queues engineers, and
- Infrastructure-as-code.
The functions-as-a-service team needs to be extremely disciplined, suggested Johnston, with everyone on top of the business priorities. He preferred Kanban over scrum and sprint approaches, as tasks and tiny code units work very well.
Johnston suggested pair programming is a highly effective learning technique in FaaS teams. FaaS team members need to be all-rounders, unlike some other engineering teams where specific tasks may be handed off, in FaaS “it is never someone else’s job,” noted Johnston, “you have to handle all the small bits.” Also, because of the challenges in explaining event systems, team members need to be excellent communicators.
Services team members are all about understanding how to use services, rather than encouraging the team to “roll their own.” They need to be integrators and cloud-first in their focus, recognizing what to use and when. For example, the StdLib services library lists over 500 examples in their catalog. Internal teams may have already created a number of services, while there are also directories in other serverless platforms, like AWS. Services team members need to be able to avoid doing the heavy lifting of creating new services and instead be proficient at being able to find available services, choose the right ones, ensure best practices over API keys, and document why to use the particular service.
Johnston also warned against making a single service team member responsible as a support contact. In serverless, there are many odd parallels between hackathon approaches and real world, enterprise use cases. For one hackathon team competing at Serverlessconf last year, their stitching together of functions led to a confirmatory email update being sent, only, the team couldn’t demonstrate this had been sent as the team member whose email had been used had needed to leave early. Several participants on the day joked this was almost an exact real-world situation they had seen happen in their company.
Events and queue teams need to take a principled architecture approach, argued Johnston: “They need to build up principles of how to use what type of queue and when, for example, each Lambda should only do one type of data transformation.” Again, Johnston recommended pair programming as a particular technique for sharing knowledge in these teams.
Infrastructure-as-code team members need to be automators at their core. The distinction between development and operations disappears with infrastructure-as-code: they need to be all-rounders, fast learners, and need great communication skills, as they are managing a much higher number of deployments daily. “You cannot scale without processes in place,” Johnston explained.
All up, this means changing the type of engineers that enterprises are looking for, with a preference for those with a broad skillset. “Ingrained thinking is problematic, you need to be able to play with technologies,” suggested Johnston. He said HR departments need to move away from code challenges, which aren’t a useful hiring process and look to employ new team members who won’t be obstinate about sticking within their role. New technologies are bringing in new skills requirements: communication, documentation, pragmatism, and working more closely with other team members are becoming key requirements for the newly emergent serverless engineer professional.
