December 07, 2017 / by Ian David Rossi / In microservices, continuous-delivery
To Be Or Not To Be A Microservice - Part 1
by Ian David Rossi
Microservices have evidently taken hold in the industry and are definitely here to stay. There is still ongoing debate regarding the necessity of the microservices architecture, since it does require significant overhead. Nonetheless, the approach has become so popular that it does little good to debate it and more good to focus on providing solutions that will support the microservices architecture and make projects that have adopted it truly successful.
At aimtheory, here is what we have found to be the biggest challenges in implementing a microservices architecture, in order of importance:
- Organizational leadership
- Governance/Standardization
- Service delivery tooling
- Scalability
Below, I’m going to expound on each of these points in more detail and why we have found these to be the biggest challenges and in that order. But first, lets address the title. How do you define a microservice? I’ve seen (and coded) microservices that are 10 lines of code. I’ve also seen other “microservices” that are even thousands of lines of code and comprised of three different git repositories. So, what’s a microservice? Here’s what I say:
It doesn’t even matter.
A microservice is not a thing, it’s an architecture.
“To be, or not to be a microservice, that is the question.”
No, it’s not. More importantly, we should be really concerned if developers in our organizations are asking this question. Microservices is a way of doing things. If a project has adopted that “way”, then it should be clear to everyone involved in the project what that is and how to contribute to the project in that “way”. Which brings us to our first, and most important challenge to successfully implementing the microservices architecture.
Organizational Leadership
Any project, microservices or not, reflects upon its leadership. A project can only have as much success as the quality of its vision permits. If the leadership of an organization can’t decide on what the microservices architecture is, then it will have little chance of success. So, that should naturally be the first order of business. How do you decide for your organization what microservices are?
This requires a tight partnering of the organization’s management and technical leadership. Management must provide enough autonomy and authority to the technical leadership (whether in-house or outsourced) to set the cornerstone for standardization and governance. This is so important because the microservices approach is really all or nothing. There is a great amount of overhead involved in the microservices architecture and it must be done properly and in a calculated way or chaos will quickly ensue and none of the benefits of the microservices architecture will be reaped. “Microservices” does not happen by grassroots movement. According to Conway’s Law, each team is going to advocate and build solutions for their own organization (or team), not for the greater cause. Microservices is an architecture and, therefore, a microservices project needs to be architected properly from the beginning. This doesn’t mean using a waterfall methodology, but it does mean that a strong, opinionated direction must be initially adopted and then governed. Then, the Agile methodology can be used to subsequently change or enhance the initially adopted approach.
What will happen (speaking from experience) if this strong direction (and therefore governance) is missing from a microservices project is that debates will ensue, and as usual, the loudest developers will impose their own opinions. However, this ungoverned loudest developer will impose opinions based on a narrow view of the landscape and perhaps his limited (or nonexistent) experience with the microservices architecture. Other developers will protest (either vocally or quietly by moving on to other organizations) and chaos will ensue. The project has a good chance of failing.
The microservices approach represents an entirely new paradigm (based on containerization). Many talented developers and engineers still don’t really understand this new paradigm. Any grassroots movement toward microservices would surely be tainted by old paradigms. Some have even just moved their old siloed applications into containers and said that they had microservices. Containers are not the new VM. Some have even decomposed their new applications into microservices properly, but have huge amounts of difficulty delivering them to production due to lack of governance and standardization for delivery. Tooling can’t be properly built to support every non-standard scenario and configuration.
This section began by discussing leadership at the top of an organization and ended by painting scenes of drama that unfold at the bottom. Interestingly, this is representative of what happens with leadership, it trickles down. If you want your microservices project to be successful, make sure that your leadership really understands what it is, has a strong opinion of where to go and intends to govern.
Standardization and Governance
This bears repeating: The microservices approach is all or nothing. Some may say this is an extreme view, but with the large overhead required by the architecture in the way of infrastructure management, monitoring, logging, etc., this proves true in the real world. With all of this overhead, resources must be used wisely. Tooling will enforce this, but tooling can’t be written to support every scenario. Therefore, standardization is required around which tooling can be built. Standardization cannot take place without governance, which holds people accountable for their contributions. So you can see how microservices is all or nothing. If all these things aren’t in place, what will happen? Complexity will creep up on the project. There may be seeming wins early on, but once the project starts to scale complexity will rear its ugly head, placing hurdles in the way of agile development. Additionally, the lack of organization and efficiency will start to exponentially increase the amount of resources that are being used when the project scales. I have seen this first hand.
So, how do you properly incorporate standardization and governance without making everyone feel that their creativity and individuality isn’t being taken away by some “mandate”? First of all, governance is an extremely old concept, as we all know. The best analogy I can think of is in raising children. If a child grows up without any rules or guidelines, they will not develop proper balance and have a very difficult time in life. However, if they are given proper boundaries and then allowed to run the gambit within those, they can accomplish amazing things. Additionally, if you provide children with a few choices they will learn to make decisions more easily and will hopefully develop a pragmatic approach to problem-solving and decision-making. On the other hand, if they have too many choices, or unlimited choices, they’ll become overwhelmed and probably frustrated. Giving children a choice lets them be involved with the direction they take and gives them a sense of individuality. Of course, there are also some areas where there is no choice, a choice is made for them, like not being allowed to play in the street, for instance.
In the same way, a group of developers, architects, technical people, etc. can be involved successfully in the process of creating the standardization and governance around the microservices approach for a particular project. However, it cannot be a grassroots movement, according to Conway’s Law. Therefore, strong leadership is required to decide which points in the architecture will be a choice, what those choices are and when there is no choice. For example, the project leadership may decide that they want to provide a great deal of choice in that:
- Developers can choose any language or tool that they want to create their microservices
- They can create as many experimental branches of their project that they want, within a resource quota
They may decide not to allow room for any choice in the following areas:
- The environment names in the path to production are the same for all services (no choice in this area)
- Test coverage must reach a certain level before a change can enter the pipeline
In my experience, the balance that allows developer communities to thrive (high agility) is:
- Be permissive in design and development
- Be restrictive in delivery
Developers don’t really care that much about how they get their stuff into production, as long as it is reliable and provides good feedback. It’s much better if they have very few choices here and know exactly what is expected from them.
Giving architects and developers more autonomy in the areas of design and development will give them a great sense of fulfillment in their respective roles and will make them a lot more amenable to the rules of delivery, once they get there.
When a strong leader ultimately sets the direction (has the decision-making authority) for these kinds of policies, the project has great chance of success. Complexity can be avoided, efficiency can be attained and the impact of the large overhead that comes with microservices can be minimized/mitigated. This all comes to fruition through good tools. Which is what I’ll discuss in the next section. Look for To Be Or Not To Be A Microservice - Part 2, which will cover tooling and scalability.
Please comment to let me know what you think about this.