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 at a disadvantage 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, a lot of companies don’t expect you to be a hands-on and coding on a daily basis. 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 problem recently when I interviewed at an organisation 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.
Another common problem when interviewing is that the job descriptions don’t often give you a full picture and sometimes might be distorting the reality of the role.
But I let it be and after speaking to the recruitment team, I decided I’d interview. I expected an interview of 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 wasn’t 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 knew it was going to be a technical interview, I would have refreshed my technical fundamentals. But what has happened 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 allows 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 type of workloads, that get triggered, gets completed really quickly, 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 problem has been solved in many different 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 depends on a number of 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 initialisation too - how complex is it.
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 very large 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 get popular and probably become more critical to the business, you might want to consider, being able to move from one vendor to another, either for the best cost effective deals or for preparing 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 quite days, and oddly during a specific season, holiday, etc, your workload might grow exponentially or maybe like a factorial function! You’d know. So 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 and as the workload gets back to normal, you aren’t charged the same way any more!
In fact serverless solutions give you the power to even throttle scaling, you can choose to limit maximum number of connections at any given point of time to ensure that you are 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 keep latency to a minimum and globally scale as and when you need! 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.
On that note, let’s take a look at another such question that I enountered in the next post