This is a rant. If you have some experience with microservice architecture then you will probably find nothing new here. I focus here on an architectural choice where a single team works on multiple deployment units especially where there are more deployment units than developers on the team. For me a team consists of up to 6 developers. If you have more, then your organization has other, more pressing, problems.

—

First of all, if you do not know what your business process is going to look like, especially if your product is not in production yet, do not make it a distributed process. I am not talking about orchestration vs choreography here. I am all for orchestration, and a clearly visible process that is defined in one place, however that discussion is for another post. I take issue with a business process that has to communicate with multiple deployment units in order to perform its task, regardless of the communication protocol (REST, event driven, message driven, etc). Apparently some believe that developing a process that changes weekly (or even daily), is easier to do it when it spans multiple services/repositories. 

– We are not in production, we can break our platform for a small period of time to save time. No worries. 

– Sure, but then why are you applying microservices architecture right now in the first place? 

– So that the team can learn how to work with microservices before we are in production.

– That is great, but if you are deploying services with breaking changes then how are they supposed to learn?

– Ok, let’s do it properly then. With backward compatibility and versioning.

And then you fail to meet deadlines arbitrarily set by business. 

Here is a simple calculation. We have two aggregates that are in two different services and a business process that interacts with them. New requirements require us to change a single field in each of the aggregates. If the process and aggregates were in a single deployment unit this would probably result in a single 20 – 30 line PR (this includes business logic, storage changes, unit and integration tests, etc). Consider a case where the aggregates and the process were in separate deployment units. If we were to introduce breaking changes then we would need 3 PRs of 20 – 30 lines of code. At least 3 times as much work plus higher chance to get it wrong on the service boundaries. If we were to adhere to backward compatibility then this would result in at least 5 PRs. As to why I will leave it to the reader.

Alternatively, although some consider it a heresy, you could keep all your code in a single repository. This would limit the amount of work needed, while providing an additional benefit of keeping the code in a consistent state. The trade off is the swelling of the repository (think indexing in IDE).

I once heard that no breaking changes will be introduced since only additive changes will be done to the integration model. This was for a system that was not even live yet. I have no comment. Even for a system that would be live this seems highly irresponsible. Will it result in a huge mess? Probably.

—

Next, continuous delivery. By continuous delivery I understand that, after a PR is merged to master, it gets built (e.g. as a docker image), then goes through automated testing and finishes in a state that it could be deployed to production (e.g. canary deployment) at any time, without the need for further testing. If your organisation does not have a reliable system for continuous delivery you should not do microservices. This guideline is not something I came up with but I wholeheartedly support. To be honest I would go as far as to say that if you have more than one deployment unit per team then you should have continuous deployment. Continuous integration is not enough. If for some reason you can’t, be it due to some weird regulations, or whatever, then do not do microservices.

—

Continuing, the size of the microservices. This has been debated to death. If you follow DDD approach then this should be straightforward and you should not go wrong with bounded context as a boundary. However. If you think that DDD is not for you or your product does not have a domain (do not ask me how), you might end up with one service per database table, or smaller. I draw the line where half of the microservice code is infrastructure. My preference is one service per team of 6 developers (this includes QAs, since I treat them as developers).  If service is too big for them to handle, split it. If there is not enough work to go around, reduce the team.

—

Microservices are not an excuse for poor design. Neither strategic (e.i. spanning the whole application, multiple services), or tactical (within the bounds of a single service). I have heard Greg Young once talk about treating services as small classes that could be easily written in a week. If you can write it in a week then it shouldn’t be a problem to rewrite it from scratch if needed. This is an awesome concept but this does not mean that the services are supposed to be unreadable. Small classes still are a subject to clean code principles. When time comes to rewrite it in 6 months time you have to be able to understand what this service does. After all the code is the documentation, isn’t it?

—

Monitoring. This is another thing that has been talked about multiple times. When applying microservice architecture your monitoring has to be top class. You will not be able to test all the integration variations that happen between services. Neither in an automated or manual manner. If your organisation cannot supply metrics in an easy to access way (and searching though individual AWS ECS instances does not count), then get this straightened out first before diving with multiple deployment units. 

IMPORTANT NOTE: I believe determining what should be monitored is the first thing that should be done when starting working on a new product. Both from a technical and business view. Reason for this is that if you know what you need to measure then you know what your product should deliver. Treat it as a specification of the fitness function for your product.

—

Whenever you start working on a new service, always run it with two nodes from the start. Regardless of the size of the service. If you cannot develop multi-node service, then your service is not horizontally scalable, you cannot provide at least some sensible measure of availability, doing zero down or canary deployments becomes very hard, etc. If I see such a service in development, that is a huge red flag.

—

Regarding performance. I am not that sold on the benefits of microservices regarding performance. Sure you can scale horizontally the services that are under heavy use (although I am yet to see a spring application that has a small startup time), or make sure that a service that needs low response time doesn’t get killed by that report generation. When you reach this point and these become true problems that can’t be fixed with just adding another machine, it will most likely mean that you succeeded in making a valid product and you have traffic that is probably in top 1%. Rejoice.

—

As a closing remark, people that often warn against microservices mention that you are not like Netflix. I say the opposite. You are like Netflix and you should behave like them. They had a monolithic application until well over 100 developers were working on it. That is when they decided to split the application. So be like Netflix.

Disclaimer: I am writing only my opinions that in no way reflect my previous, current or future employers. They are based on my experiences and reflections.

The purpose of this piece is mostly to organise my thoughts and ideas regarding the functioning of teams. If anyone finds something interesting or something they totally disagree with, then great!

I have been pondering upon the idea of a product development team and how they function for a while now. I have been a part of a few and had seen a few, be it in the workplace or spoken about in conferences. This lead me to a number of conclusions as to what, according to me, works well and what does not.

Team size

This feels fairly straight forward. I have worked in a full spectrum when it comes to a number of people on the team. I was the only team member and I was part of 20+ people. In my experience Scrum (not saying this is the origin of the idea), regardless if you like it or not, got this right. Four to six team members is more than enough to get the work done while not too many for the communication overhead to get too large. This, however, comes with a few caveats.

Team member competencies

The first are the team member competencies. The most performant teams I have seen were those where each member was capable of working on every area of the product. What do I mean by this? Let’s take a look at a typical web application that has both a frontend and a backend. Often times the product development team will naturally split into those that work only on the front side and those that work on the back side of the App. Of course there can be other splits, however I find this to be the most common one. My opinion is that allowing such divisions is highly irresponsible.

Let’s start with the ability to replace. Eventually, only people that know only one part of the application will be available. Be it due to holidays or sick leave, or because some people will change teams or even employers. The development, bug fixes, the planning will effectively halt. Some work will still be possible but this makes the employer vulnerable to unexpected circumstances. Its surprising that these situations are still permitted to occur. You could argue that for products that are not yet on production this shouldn’t be such a problem. On the contrary. This cripples the development and the ability plan further work which in effect drains the product funds.

We can go even further. Consider a modern continuous deployment pipeline. I would say that having only one person doing code reviews in such a case is unwise. Now to be able to deploy new code you need a person that publishes a PR and two people that review the code. In a team of six this means that you need to have half of the people working front and half working the back. This might not be optimal regarding characteristics of the project. Maybe UI is very simple and one person would normally suffice? But you need three. What happens if one leaves on a two week vacation? Deployments stop. No hot fixes. No bug fixes. You have two week sprints? Yeah, no new features. Even if you dial down to one reviewer you still need to have two team members in each area present at all times. 

Another huge problem with this approach is that such a split effectively creates two or more sub teams that need to communicate and integrate with each other. Each additional point of integration adds to complexity. This is costly. Instead of limiting the need for communication and overhead, we’re increasing it.

If developers know only a part of the product and how it works then the solutions they come up with will be sub-par. They will be operating with a limited knowledge when designing the product. This is unavoidable in a larger corporation where multiple teams have to cooperate but on a single product level this is unacceptable.

You might be tempted to split the team into e.g. two teams, front and back. Ignoring the fact that this goes against Scrum (if you are using it) idea of a team being able to deliver the whole business functionality from start to finish, you will now need to deal with the overhead associated with having two teams. Double number of meetings, double the amount of work for the business side, etc. In my opinion it is far more efficient to have a single team of six, where.each member can handle every area of the product at least in a basic capacity, rather than to have two, or even three, teams that focus on separate parts.

That is not to say that each member can not have a preference as to what they like to work on. Some might prefer to work more on optimising the database indexes while others configuring the network routing. This is OK. As long as each member has a working knowledge and has done some work in every area. The team should be, then, resistant to team member changes, while limiting the communication overhead and cost of development.

There might be a rare case where you will need someone with highly specialised knowledge, e.g. some detailed behaviour of Oracle Database. To handle this you do not swap out an existing member for one that only works with Oracle Databases. Instead use an external expert as either your teams consultant or add him to the team as a temporary member. We will talk more about this later.

The only reason that I see where such a team could exist is when the budget is lacking. Excuses like we can’t find the right people means that you can’t find the right people at this salary level. If such is the case then maybe you should consider the notion that maybe you can’t afford to build such a product.

Team roles

Generally speaking, each team member should be considered an equal in terms of competences and simply referred to as a developer. However, I would distinguish two other roles that I think are critical for efficient performance.

Side note: Regarding team leads. I have once heard that their role is to make the team better. The team makes the team better. Not one person. There should be no need for a team lead.

Architect

Team should have a dedicated Architect that is part of the development team and counted as a developer. I don’t want to get into minutia of titles (whether this is a system, enterprise, solution, etc) so for the sake of the argument I will refer to the role as simply the Architect. The purpose of the Architect in a development team is to be responsible for (obviously) the whole architecture of the product and its documentation. What I mean by architecture is very broad. It includes not only what you would get from the C4 diagrams (or whatever) but also package structures, design patterns, etc. Of course the Architect is not the only one responsible for it and the decisions should be made by the complete team as they are responsible for the product as a whole. It is however his main purpose.

Another responsibility of the Architect is for the teams best practices. Developing them and making sure they are followed. Actually, the whole team should be responsible for that but the Architect should lead by example.

The Architect must also write code on day to day bases. Not only the fun, cool one that flexes the brain matter (or even worse just POC) but also the boring and mundane one. This is so they can truly understand the ins and outs of their system and get a feel for which architectural/technical decisions were correct and which were not. The Architect is a technological leader and should be the most experienced developer on the team but he is not a team leader and not the boss of the other developers.

There is one more reason for having an Architect on the team. It is hard to swallow but is the reality of our industry. In a corporation, a person with an Architect in his email signature will have more sway and be able to get things that the team needs that other team members would have much bigger difficulty getting (or not at all).

The role of an Architect is a difficult one. It requires from them to be humble enough to allow the whole team to make decisions while being assertive enough to convince them to go another way if needed. They need to be able to understand how the product works as whole, from a greater perspective. How it interacts with the other systems. But, be also able to work on the detail implementation.

Specialists

We have touched upon specialists earlier. Specialists are people outside your core product development team that bring with them a very narrow but deep knowledge in some area. This can range from databases, through networks, security or even UX design. Core team members can work on all of these by themselves but as the saying goes “Jack of all Trades, Master of None”. In the vast majority of projects this is OK. Core team members do not need to be technological experts. They need to be product experts. When the situation comes where you do need that additional knowledge you can hire one for the team. Those specialists can take two forms. As mentioned before, either a consultant (not meaning a type of contract they signed, they can be salary workers from within the company) where you ask for help with a specific problem or as a temporary “visiting” team member. For example a DevOps joins a team for a month when work on new product starts and all the pipelines and environments need to be setup. He joins all the meetings, sits with them and for all intents and purposes is a part of the team. Until his services are no longer needed.

Regardless of which form the cooperation will take, they add up to the team member count and communication overhead. This is why teams of six should be a max. Add two experts like DevOps and UX designer and now there are eight.

Their role is not only to support but also to teach the core team members. Each member has all the same accesses and privileges. They only lack the knowledge. Once they pass that knowledge they shouldn’t be needed to access any resources. There might be some derogation from this rule for security reasons. Care must be taken that those are truly security reasons and not some imaginary managerial hogwash.

In larger organisations those specialists can form their own teams. Just to make sure this is clear, those teams are not product teams. They might even be developing some tools (be it internal or, better, open source) for their work but their main job is to provide specialised support to the product teams.

Team structure

Teams should have a good mix of experience. Of course this is very dependent on the project difficulty (although in my experience most of the complexity in projects comes from interactions and lack of communication than actual technical difficulty). Please do not get hung up on the titles that follow. I use them only to distinguish relative experience levels.

Ideally a team of six would consist of an Architect, Senior Developer, two Regular developers and two Junior developers. This is beneficial for both the employer and employees. The employer will get enough work power from a team to get the job done while not spending a fortune on only experienced developers. The less experienced developers will get a chance to learn while the more experienced developers will be able to delegate most of the mundane work. I know that this seems harsh but that is the truth. Someone has to write those mappers :).

Scaling Down

When scaling the teams down I would first remove one Junior, then one Regular. Making the team even smaller might make it too small to be effective except for the most unique cases. If you must, I would remove the last Junior in order to have a very small but highly performant expert team. Any less is not a team. It’s a pair. If you face a situation where you need to develop a small piece of software where one or two people should be sufficient then consider doing the development as part of one of the existing products. This will give the piece of software an immediate client that will validate (or not) its purpose. There is no need to create an artificial team. If other products could use it as well then make it available to them in any form you seem fit.

Scaling Up

This has been repeated multiple times but let’s repeat it again. You shouldn’t need to scale the team up because the communication overhead will become significant. If you must do so, I would only add Regular developers. You will need someone that can get quickly up to speed and this disqualifies less experienced developers. On the other hand, by the law of diminishing returns, adding a Senior will not get you the bang for your buck. If you need to implement something difficult then it would probably work better to assign an existing team member to it than a new one, even if they are very experienced.

Conclusion

These are my thoughts. You could say my dream team. It would seem that this would be easy to achieve. There really aren’t any hard elements to this. They seem common sense to me but my view is obviously subjective. I once had a chance to work in an environment that somewhat resembled this but only for a short time. And it was glorious.