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 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. I do review their technical proposals and other documents or design diagrams etc. But 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. I give them the feedback they need, covering their blindspots when necessary.

This does mean that I could be at a disadvantage if I were to start as an engineering manager in another company. As some companies would need their engineering managers to be pretty hands-on or fairly recently hands-on. And 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.

A lot of times I see these type of roles open but at the same time, I wonder how much of that is true. From my experience 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 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.

When would you use a serverless approach vs the other?

A serverless solution and a fully orchestrated solution are two different approaches to deploying and managing applications or services.

Serverless Solution:

  1. Deployment Model: In a serverless solution, an app developer could focus solely on writing the application logic, without the need to manage or provision any underlying infrastructure or servers. The cloud provider takes care of all the infrastructure details, including scaling, fault tolerance, and resource allocation.
  2. Resource Allocation: Serverless functions are automatically scaled up or down based on the demand, allowing efficient resource utilization. They are typically billed based on actual usage (e.g., execution time or number of invocations), which can lead to cost optimization.
  3. Event-driven Architecture: Serverless solutions are often built using event-driven architectures, where functions are triggered by events or requests, such as HTTP requests, database updates, or message queue events. This enables a highly decoupled and scalable system.
  4. Function Granularity: Serverless functions are usually small and focused on performing a specific task or handling a particular event. This granular approach enables better modularity, code reusability, and independent scaling of individual functions.
  5. Development and Deployment Speed: Serverless solutions can be developed and deployed quickly since the developer only needs to focus on the business logic and can leverage pre-built components or services provided by the cloud provider.

Fully Orchestrated Solution:

  1. Infrastructure Management: In a fully orchestrated solution, the developer has more control over the underlying infrastructure and needs to manage it explicitly. This includes provisioning servers, load balancing, auto-scaling, and ensuring fault tolerance.
  2. Containerization: Fully orchestrated solutions often use containerization technologies like Docker and orchestration platforms like Kubernetes. Containers encapsulate the application and its dependencies, making it easier to deploy and manage across different environments.
  3. Scaling Flexibility: Orchestrated solutions offer more flexibility in scaling, as developers can scale not only individual components but also the entire infrastructure. This allows for more fine-grained control and optimization based on specific requirements.
  4. Complex Workflows: Orchestrated solutions are suitable for complex workflows and applications with multiple interconnected components. Developers can define and manage the flow of data and control the sequencing of tasks across different containers or services.
  5. Portability: Fully orchestrated solutions are often more portable since containerization provides an abstraction layer between the application and the underlying infrastructure. This allows applications to be deployed across different cloud providers or on-premises environments with minimal modifications.

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