In April I changed company. I had a problem with my line manager, I try to stand the situation as much as I could (reason why, lately, a big percentage of my posts were related to leadership and culture) but when I got an offer for a similar place, similar technologies, similar everything, I just said “Thank you and goodbye” and, although it has been really sad for me to lose all my colleagues, and even if I loved the project, and even with all the usual doubts that a person may have when he/she changes company, I moved.

I was used to code Java applications, with Spring Boots, running in a container (Docker) in a kubernetes cluster hosted on AWS, with a discovery server, a config server and just few managed services, like ELK or some databases. Everything related the architecture was managed by a dedicated team of devops. When I arrived I started working on a team that was central in the company.

Here the concept was different: every team has complete autonomy on what to use and how to use it for achieving the purpose of the projects. Do you want to use a new technology: you can. YOU TOTALLY CAN! Ok, this can be done, obviously, also because of the culture of the company, but I don’t want to focus on that again… for now.
I found the first two weeks a bit stressful: I didn’t know the business, technologies, and I felt not really productive, because indeed I was not really productive (and I hate when it happens). And I was also a bit demotivated: I did my interview on Java, and I was not at all working on that at all: I was coding in Python, Javascript (with NodeJS), writing script in groovy… All of this in a kind of environment that was not perfect, maybe, but… ehy, it was working. In the previous company the turnover was impressive: in my team, more or less for the same reasons than me, we lost 8 people in 6 months, the average was one year, one year and an half between the date of start and the one of exiting the company. In the new one people are staying more than three years and still nobody is thinking of leaving.

And the company was migrating to microservices but… also to completely serverless architecture. From a monolith. I was kind of surprised, and maybe also not totally agreeing: I see a possible big risk in creating all the architecture of a company based on a single provider (AWS).

The company decided that devops are just caring about generic architecture frameworks, but every team has the full responsibility of what it deliveries in terms of code, support and deployment. So, the more the serverless architecture is used, with right scaling and right monitoring, the less team members will have to care about being called for support, and somehow the more robust the full stack is.
I still see a problem in using too much serverless services that are only available on AWS, but this company is not the only one doing that: Netflix and Coca-cola not so much time ago have both migrated into a serverless architecture.

And of course, I cannot even describe how exciting working like that it is: you have to study new technologies everyday, you use the most interesting ones, all of this looks just great, and there is nobody just not being updated on the projects (I still remember how many times, during outages, I had to draw all the architecture of our infrastructure also for senior developers). Not only, but in the first two weeks I thought that mostly the reason why the company could have gone serverless, was related to the type of business, but then I discovered several managed services, like AWS Api Gateway, that simply could have made much easier and reliable also the kind of work we were doing before. So now I am much more motivated to discover all the managed service that can be used.

Now, reliability, ease of development and support, small quantity of (business) code to write and support, lower costs (especially compared with costs of servers that are used only on a specific part of the day) and fun are some of the advantages of this approach. There may be disadvantages (like bounding the company to the provider, or problems like latency for the cold starts, or others… but keep in mind that, unless you are not really creating high performance low latency real time systems, this problem may be more abstract that the real advantages you get), and I appreciate any comments on that, but the advantages are great.
This discussion obviously is much more complicated, so I will hopefully try to go deeper as soon as I will have a bit of time.

Stay tuned!

Share