Background
As a relatively senior engineering manager, I have been transforming into a less technical person over time. The reason being, I am in charge of two fantastic teams that both have excellent engineers. I generally rely on the technical leads of the respective teams to own the technical aspects of their domains and try to interfere as little as possible. I do this to empower them to take more ownership and learn to be accountable. After all, it is humanly impossible to be everywhere at the same time. I build my teams based on trust, psychological safety and accountability. However, I do review their technical proposals and other documents or design diagrams etc. and I challenge them by asking questions. I have never had to tell them what is right or wrong so far, and I don’t think that I’ll ever need to do that either because our hiring process is good enough to filter out problem candidates. I give them the feedback they need at the time they need it, covering their blind-spots when necessary.
This does mean that I could be disadvantaged if I were to start looking for a job as an engineering manager in another company. The term engineering manager has different expectations in different companies. However, many companies don’t expect you to be a hands-on and coding daily. But most companies when hiring are looking for engineering managers who are pretty technical, which, in my view, are engineering managers starting their managerial journey. Some claim to have a hands-off role, but at the same time have tailored their interview questions to pick a technical candidate.
I encountered a similar issue recently when I interviewed at an organization that posted a Software Engineering Manager role and suggested that the role would be hands-off. I didn’t expect any technical questions and hence hadn’t brushed my fundamentals. As much as I love hands-on engineering work, I know when not to step in and compete with my team of engineers. I started stepping back from the priority exciting projects back in late 2015. Thus, over time, I have lost the luxury of sitting and coding day in and day out.
But I let it be and after speaking to the recruitment team, I decided I’d interview. I expected an interview about my managerial experience.
However, the questions were like the ones I generally ask during the first round interview of a tech lead or an individual contributor.
I don’t blame them for their process, as they wanted a high-level view of an engineering manager who could also be a tech lead. But what, I felt, was high level was not the level they expected, they wanted a bit more. It is a fine line, and it is a hard one to figure out, especially during the interview while you are being judged. And if I had known it was going to be a technical interview, I would have refreshed my technical fundamentals. But what has happened and all I can do is take this opportunity to learn from it.
I was asked how I would compare serverless solutions to a fully orchestrated solutions.
Disadvantages of Serverless
Harder to test and debug code
I haven’t worked with a serverless solution that can replicate what goes in the cloud on my machine. Over the years, I have appreciated that this is something developers have to come to terms with. However, this can slow down figuring out what’s broken where. There are cloud services that enable developers to work in a sandbox and allow them to test and debug solutions, but I haven’t trialled any to give my review on them.
Long-running processes
If you are going to have workloads that take a long time to execute, you are going to rake up a huge bill by choosing a serverless solution. Thus, if you have long-running workloads, do not use a serverless solution. That is not what it is intended for. On the other hand, if you have plenty of fire and forget types of workloads, that get triggered, gets completed rapidly, moves on to another, then serverless is ideal. In other words, event-driven workloads might be a good one to use serverless solutions.
Performance and cold starts
A common problem faced by engineers who owned and deployed applications in the early days of serverless was something called Cold Start. This issue has been solved in many ways by any cloud providers. Some offering a slightly more expensive plans to keep your function execution pods warmed up to reduce such issues. But it is something to keep in mind. Every request that triggers the creation of a new node, to scale, would take a little time. These cold-start issues depend on several factors, and not just the operating system. It also depends on your application’s programming language, it’s ability to start quickly and the application code initialization too - how complex it is.
Lock-in
Vendor lock-in is a nice little term that cloud architects throw around as they please. This is something that you might only have to worry about if you have a huge cloud-based system that is also quite critical. Serverless offerings are cloud provider specific. Code written for one cannot be easily ported to another. Thus, if you are a small company just starting up, this might not even be your concern. However, as your systems become more critical to the business and become more popular, you might want to consider moving from one vendor to another. It could have one or both of the following advantages:
- Prove to be more cost-effective
- Prepare for the worst-case disaster and be ready with a multi-cloud setup.
Advantages of Serverless architecture
Server management not included
As the name suggests, one does not need to care about the infrastructure management aspect of running their services on the cloud. This is an attractive proposition for developers. When I was a developer, I didn’t care about infrastructure management, as I have historically worked in companies where we had a separate dedicated team for that. So I used their expertise to deploy the infrastructure necessary and then deployed my applications on them.
Pay as you use
Just as you wouldn’t have to care about managing the infrastructure, you wouldn’t have to pay for purchasing all the compute capacity upfront. You are charged on a pay as you go basis.
Scalability is baked-in
If you have unpredictable workloads, then it might be a great contender for a serverless solution. You might have quiet days, and oddly during a specific season, holiday, etc, your workload might grow exponentially or maybe like a factorial function! You’d know. In these cases, serverless solutions provide the most economical way of responding to your scalability needs as you only pay more when the workload is higher. As the workload gets back to normal, you aren’t charged the same way any more.
Serverless solutions give you the power to even throttle scaling. It is possible to limit the number of connections at any given time to make sure that you are not overloading your bottleneck service and creating a Denial of Service.
Run it where your clients are
Serverless applications can be deployed across multiple regions simultaneously!
This sort of model allows you to keep latency to a minimum and globally scale as and when you require! The convenience factor is indescribably high!
Summary
In summary, a serverless solution provides a higher level of abstraction, allowing developers to focus on writing code while the cloud provider handles infrastructure management. It is well-suited for event-driven, modular, and rapidly deployable applications.
On the other hand, a fully orchestrated solution gives developers more control over infrastructure and is ideal for complex workflows and applications that require fine-grained scaling and portability across different environments.
How did I answer?
Although, the summary I wrote above is after refreshing my memory and technical knowledge, I didn’t give a structured answer to the question at all. I roughly touched on the abstraction advantages and the fact that it improves the speed to market and ability to auto-scale on demand. I failed to touch on the aspects of the advantages for event-driven architecture. This costed me an opportunity. Not going to let that happen again.