Creating the architecture of a project is not an easy task. There are a lot of factors we may need to consider to ensure the architecture accomplishes the product’s and client’s needs. However, sometimes we don’t consider one key factor… our team! And without the right team, the proposed architecture is just an excellent but useless blueprint.
In this article, we will review some lessons learned while developing one internal application (People App) and how we updated our architecture to match our team’s characteristics.
In general terms, AWS documentation mentions that Serverless computing “allows you to build and run applications and services without thinking about servers. With serverless computing, your application still runs on servers, but AWS does all the server management.” (Build Your First Serverless Web App | Amazon Web Services)
Besides the execution of the code functions in a fully serverless application, the whole environment is executed in a serverless mode, including the Database, the web content, the storage and any other resource needed.
The “serverless-first” approach seemed the natural path for the development of the new application so that we could benefit of:
No server management: We may not need to consider managing a server for our application.
Flexible scaling: The application’s capacity varies depending on the total number of requests, which eases the billing in a project like this.
High availability: The configuration allows the application to run in different availability zones to ensure high availability of the service.
No idle capacity: The application will have a lot of times where we have no users, so having no resources allocated to the application would profoundly reduce expenses.
With those new developers, we found that obtaining resources with solid experience in the project’s technologies was complex, so we had to begin training them. Initially, that seemed like the best approach, but we didn’t consider the learning curve a project like this one may have
After the first round of training, we noticed the training time to have someone ready to develop the application’s backend was between a month- and two months. In a typical project, that may not be a considerable amount of time, but in our case, it was! Furthermore, most of our team members were interns who may stay no more than four months So, spending almost half the time with us in training was not the best deal to complete the project on time
THE BREAKTHROUGH
We detected a problem with the approach, but we were not sure what the actual problem was.
Initially, we determined the areas where the team members had the most experience. During this research, most of them had experience developing Monolithic applications using Python, which interacts with a Relational Database in most cases. Also, most had limited experience with a non-SQL database and working in a microservices architecture.
With those details in mind, we began looking for alternatives to reduce the learning curve for team members. The first and most significant change was
In general, implementing this application has challenged many people, both in the technical and personal aspects. However, as a software architect in charge of the definition and implementation of the project, it’s possible to summarize the learning lessons to:
Consider the capabilities of your team:
Consider the capabilities of your team: The team is critical for the project’s success, so considering its characteristics and abilities is vital. Also, it’s essential to think about the complexity of adding new team members to your team.
Defining the “best” technologies for a project is relative:
Defining the “best” technologies for a project is relative: The term best is always close, and we may need to consider at least what’s the best for the project, the timeline, the client, and of course, for the TEAM.
There are no good or bad architectures, only suitable or unsuitable: . architecture of a project should evolve: . Documentation is vital:
There are no good or bad architectures, only suitable or unsuitable: In some projects, microservices could be crucial and ideal. But in other cases, having a monolithic app can be the right solution for the problem. Generally, it’s essential to determine your project’s exemplary architecture without preconceptions.
The architecture of a project should evolve: The architecture of a project should follow the principle of a plan, implementation, testing and improvement. As your requirements grow, the project’s architecture should evolve to meet the needs.
Documentation is vital: It’s essential to keep up-to-date documentation of at least project architecture, DB schema, how to configure the application, share features, and other important information that may ease the understanding of the project.
Automate as much as possible:
Automate as much as possible: It’s crucial to automate as many things as possible to ease the different tasks. Automating things like deployments, project setup, database updates, ticket notifications, code revisions, etc., is easy.
Try the serverless-first approach:
Try the serverless-first approach: Creating serverless applications requires a mindset change so the results can be achieved as in a server-oriented application. But definitely there is no turnaround once in the serverless world The benefits are
Finally, as mentioned in the article, adding the characteristics of your team to the variables used to define the architecture of an application is key to accomplishing the desired output without affecting any other architecture requirements (also known as “-ilities”).
Join our dynamic engineering teams. We support your professional journey by providing educational programs, English training and tailored growth opportunities aimed at accelerating your development. Plus, you will engage in exciting projects and collaborate with smart individuals to achieve remarkable results.
