The tale of migration to Serverless

This story is the figment of imagination, and references and facts are purely coincidental.

Once upon a time, a software development team was made of clever players. The team was like a basketball team. These players apply the best schema to win each game, and so they built a microservices application architecture with docker containers. They knew that this was the best tactic to win games than using a single, monolithic codebase, so they broke it down into a collection of microservices.
This approach should have offered them several benefits:

• the ability to scale individual microservices
• keep the code simpler
• easy testing

Docker was and still is an excellent tool for managing and deploying microservices. Each microservice could even be broken into processes running in separate Docker containers, which can be done with Dockerfiles and Docker Compose configuration files.

Everything was green, and everybody was happy, and with the first programming rule tattoed on their brains, everything was good.

Timepass and requirements are coming in, changes are made, and the happy team start noticing something:

• They were slowing down
• They were not in agreement anymore
• The bugs start accumulating
• The release was taking longer

How was it possible? Culturally speaking, they were following the first rule of programming, they were using Docker containers, they were ClusterFantastic

The simple answer was they stopped living the dream because, with time, they were all feeling comfortable with what they got.

The first rule of programming said do not touch it. So the not so happy team went ahead, making the boundaries or responsibilities of the application not very clear anymore, and with time without noticing, they made their life a nightmare. The team started losing games. Their schema did not seem such a winner anymore.

The new architecture paradigm adopted from the team it is a very well know standard in the industry:

This approach offered several benefits:

• The ability NOT to scale individual microservices
• Messy code
• Impossible to test
• Fix one bug to create another one
• Focus on maintenance
• Increase cost

One day, a new coach was drafted. Everybody was lovely and very good, but the coach noticed that something was not right and so he sat and observed and observed some more. The problem was not technical. All the people in the team were great, but as in every sports team, the alliance and relations could make the team a winner or a loser.

This new coach seems strange to the players because while trying to bring the competencies and skills up, he was all about connections attempting to be a friend first then a colleague. The coach had a theory that because the team was with each other 8 hours a day at minimum to be successful, they should go over the "good morning" and "bye-bye", and so he started knowing his companion:

• Asking what they want from the job
• Asking what they care about
• Making an anonymous poll
• Making jokes

The coach was the first to cross the line, making errors on purpose to show their fellow team members that they were not a problem and that they could go over any challenge as a team.

The coach was continuously changing the rule of the team with things like:

• Diverse team
• Make the group HR free
• No competition zone
• Task shifting
• No reward

This "no reward" no sense was the worse. So instead of giving them a medal to do "x y z", now the coach was saying something like:

• Thank you
• Great job
• Can you replace me for this meeting
• What do you think of
• Do it now
• I do not like, do it again

The players were in shock moving from "we do not step on somebody's toe" to this "continuous feedback".

But it turned out that these unusual approaches pushed the team to reach a level never achieved before and, more important, to create the condition of friendship.
The team trusted each other, and it was eager to learn and acquire new skills, and it was at this time the coach changed again, bringing something revolutionary, a vision to break the first rule of programming language.

The coach started blabbering about a new tactic to win games again. It was about replacing the current working but permanently on fire application in about six months, presenting best practices and new things. But, of course, everybody was against it because vision, strategy, goal, plan and decision cannot come from anybody but only from the general manager.

The team decided to listen to their coach. After all, he never stopped speaking about Serverless.

Completely replacing a complex system can be a huge undertaking. Therefore, gradual migration to a new application is often needed while keeping the old application alive. The coach wanted incrementally replace specific pieces of functionality with new applications and services.

This technique is called the Strangler pattern, and it is used to incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new design eventually replaces all of its features, strangling the old system and allowing you to decommission it.

However, it seems strange to the group to have this feeling of happiness and be pushed to learn new things at their own time, experiment with something, and be allowed to fail. After all, they had this deadline and not one but two applications to maintain, and it was clear that this Serverless thing was a crazy word because it was not possible to deliver a new system so fast.

Serverless eliminates infrastructure management tasks such as cluster provisioning, patching, operating system maintenance and so on. Other benefits are:

• Increase agility and lower total cost of ownership.
• Services are fully managed services
• Building serverless applications means that developers can focus on features
• Provide infinite scalability and built-in high availability
• Less-Ops
• Pay for execution time

The team starts building up the system with a strategic plan that defines a goal or desired outcome and includes the significant steps or milestones needed to reach it. Every success for the team was topped up with a higher expectation by the coach. What was considered impossible was now possible. The entire team was pushing together in one direction, believing the dream.

The initial struggle of serverless mindset was overtaken by the most straightforward design and the realized promise of serverless:

Building serverless applications means that developers can focus on features

In no time, the team found that time spent on the initial setup for:

• Automation test
• Unit tests
• Define boundaries
• Go micro

Allow them:

• To quickly deploy features
• Reduce the number of bugs
• Increased the observability of the system
• Free time to experiment
• Lowering cost

The team has gone a long way since they adopted Serverless. They are a different team since they began to draft new players, and overall they increased competencies and efficiency, making them one of the league's best teams. Since then, the coach has stepped back, orchestrating the tactics of new seasons and assisting players to achieve their full potential, keeping the bar high and giving them significant autonomy. As a result, he can now rely on the players to deliver results when a game is on.

Conclusion

I tried to use a sports analogy to tell a story on migrating to serverless. Serverless is not a silver bullet for everything, but it went a great length in the last few years, and pretty much everything could be built with a serverless mindset first. I tried to point out that any migration must have three fundamentals:

• Relation
• Vision
• Delivery

Success is not just about hard skills. Success is about engagement and a relationship. You can be the most remarkable person in the room, but you will fail without engagement and a relationship with your team.
Migrating applications (of course, it depends all-time) cannot be a process that takes years because you will make all your effort obsolete. Migration is a matter of strategy and decisions. If you understand what matters, you will be guided on what you think and your daily actions. Serverless is a tool that will ease your migration, focusing on what is essential, making the delivery part simple.