Experts have said it over and over - you can’t be too careful when it comes to Microservices adoption. And according to Microservices.io’s Chris Richardson, there are antipatterns to avoid when it comes to adoption.
Many organisations around the world are considering taking a technological leap by utilising a microservices architecture. In a survey by O’Reilly on microservices adoption in 2020, over 61% say that they have been using some form of microservices for a year or more. Add this to the fact that the microservices market is projected to grow to $8 billion by 2026.
There’s no denying that we would be seeing more and more companies implementing microservices in the future. However, according to Chris Richardson, microservices aren’t the be-all, end-all solution that will work for everyone.
Richardson, the author of "Microservices Patterns with examples in Java" and creator of Microservices.io, shares how many organizations have "misadopted" microservices, which led to antipatterns emerging during their migration process.
"If you have issues with your development process and your organisational structure, throwing microservices into the mix won't fix those problems, and it's very likely to make them worse." he says, during an interview on Coding Over Cocktails, a podcast by Toro Cloud.
There, he discussed some of the common antipatterns he had encountered while working with clients, and gave insights on how organisations should be able to properly approach the adoption of microservices.
Common microservice antipatterns
Magic pixie dust
One of the antipatterns he mentioned was "Magic Pixie Dust."
"That's sort of believing that microservices are this magic pixie dust. You just sprinkle it on your development organisation, and it will solve all of your delivery problems, right?"
However, he adds that microservices may even complicate an organisation’s development process even more if an organisation believes that microservices are the ultimate solution to their software delivery process.
"That ties back to the earlier thing about microservices hype and just seeing them as this amazing thing that you should just use always, right?"
Microservices as the goal
Another antipattern he discussed was making microservices the "goal" for the organisation.
"There was one client where the CIO just announced ‘We're going to do microservices.’ And it's a very sort of top-down hierarchical organisation. And I meet developers. And it was like, ‘Why are you doing microservices?’ ‘Well, my manager told me to.’"
This antipattern also led organisations to believe that having more and more services was the measure of success.
Richardson described this belief as "terrible" and ignores the other challenges in delivering software rapidly and frequently, such as inefficient processes and organisational silos.
The Red Flag law
The "red flag law", according to Richardson, originated from a 19th century traffic law.
"In the early 19th century, when the automobile came out, some jurisdictions required a pedestrian to walk in front of the car waving a red flag. So, you had this vehicle which presumably could go faster than a walking pedestrian, but they were slowed down," he explains.
In this antipattern, the organisation has adopted microservices but still retains existing organisational structure and processes during their monolithic era. He says that refusing to leave these processes defeats the purpose of adopting microservices in the first place, which is to accelerate the process of software delivery.
"Like one client I worked with, you could only deploy to production on the third Saturday of the month at midnight. Right? That was the rule, which is great. But, you want to adopt a microservice architecture that lets you deploy safely into production many times a day."
Focusing on technology
Richardson says that focusing too much on the technology aspect of microservices is an antipattern as well.
"That’s sort of a generic thing. It's sort of like ‘Technology, technology, technology,’ whereas in reality, the most critical issues and decisions that you have to face really are around, ‘What are my services’ and ‘What are the responsibilities of each service?’, ‘What is the API that each service offers and how do the services collaborate?’"
Instead of focusing too much on the technology aspects, Richardson advises that organisations focus on the essence of microservices, such as service decomposition and definition. Decisions on the technology stack will become more educated as the number of services and the organisation’s experience grow.
"The only aspect of technology that's critical is that you should have, primarily, a loosely coupled asynchronous architecture as opposed to one way your services are communicating using synchronous protocols like, REST and the synchronous aspects of gRPC."
Catch more of this discussion on Microservices antipatterns on Chris Richardson’s interview on Coding Over Cocktails - a podcast by Toro Cloud.
Coding Over Cocktails is a podcast created by Toro Cloud, a company that offers a low-code, API centric platform for application development & integration.
This podcast series tackles issues faced by enterprises as they manage the process of digital transformation, application integration, low-code application development, data management, and business process automation. It’s available for streaming in most major podcast platforms, including Spotify, Apple, Google Podcasts, SoundCloud, and Stitcher.
