Microservices are core to organizations’ flexibility and agility in the digital world. But that doesn’t mean that microservices are right for every use case or even for every organization—at least, not right now.
There is no doubt that microservices are becoming the mainstream. Within the next two years, 90% of all new apps will feature microservices architecture, according to “IDC FutureScape: Worldwide IT Industry 2019 Predictions.” Indeed, as organizations witness (and drive) more and more microservices success stories, they may feel compelled to join the race and accelerate their current microservices initiatives. Whether that is a good move or not depends not just on the readiness of the organization, but also on its willingness and ability to acknowledge some hard truths about the microservices model and culture.
Here is the reality behind three microservices misconceptions—and why that reality can sometimes bite:
1. Moving to microservices is not easy.
From what you read and hear, moving to microservices is simply a matter of breaking down monolithic applications into individual microservices. What you may not know is how big of a deal that is. Organizations—especially traditionally siloed companies–need to realize that microservices require an entirely different development methodology and culture.
For example, in the traditional model, the development team owns everything about an application–or, at least, most of it. In the microservices model, you own a small piece of the application, but you own it all—including not just development but also the release cycles, security, documentation and so on. Other teams own other parts of the app. These teams may be within your company, but they may not. In either case, you have to start treating each of these services as a business-to-business (B2B) connection. This a huge cultural shift, not least because …
2. … moving to microservices means ceding some control.
With an application monolith, you know what you’re up against. With everything in one place—and in your control–you can identify issues, as well as measure and optimize performance. The downside of this is a longer release cycle and slower reaction to needed changes. With microservices, you may depend on a service set up on the other side of the globe that is completely out of your sight and control. But no matter where a service you don’t own is located, depending on it means giving up the freedom of knowing, for example, what your network call speed and performance will be.
Indeed, there can be a performance hit when decomposing existing monolithic applications in favor of microservices. But the ultimate goal of microservices is deployment speed–and the ability to update and respond quickly–over API invocation speed. When deciding which is more important, the needs and goals of the business must come first, and, in the end …
3. … a monolithic model may be just what your company needs.
Microservices are not always the best solution. Indeed, there is nothing wrong with looking at a monolith and determining that it is not worth the time and resources it would take to completely break it apart. With that said, it’s not an all-or-nothing proposition. Some organizations are identifying and breaking out certain monoliths or discrete pieces of monoliths—especially those that would benefit from being updated more regularly and frequently than the monolith itself. In this way, they are moving toward a more agile model without forcing microservices across the board.
Maybe it’s enough to achieve a fast-moving monolith, where release cycles are every few months instead of a few times a year. That’s good because …
… the move to microservices is a complicated proposition. Breaking up the right monolithic application–or the right part of a monolithic application–can help developers deliver quality software in a speedy fashion. However, the microservices model brings with it added complexity. Once organizations have embraced this microservices reality–and have acknowledged its propensity to bite–it should enable them to manage complexity and intelligently move forward on the microservices path.
About the Author
Eric D. Schabell is Global Technology Evangelist and Portfolio Architect Director at Red Hat. He’s renowned in the development community as a speaker, lecturer, author, and baseball expert. His current role allows him to share his deep expertise of Red Hat’s open source technologies and cloud computing.
Sign up for the free insideAI News newsletter.
