Perhaps you’ve learned how to explain microservices in plain English and make the case for microservices to people inside and outside of your organization. But can you debunk the common misunderstandings about microservices? This is important, because you will bump up against some people who will insist that microservices, APIs, and IT’s old friend, SOA, are all the same thing. (Actually, no. More on this in a minute.) Such misconceptions can sabotage your hard work to get buy-in from IT teams and others in the business. So we asked IT leaders and software experts to clarify common misunderstandings about microservices – the kind that can cause you trouble up front and in implementation.
As with any new technology approach, you want to go into microservices with eyes wide open, and a carefully considered plan to keep moving toward goals. Understanding the misunderstandings will help you head them off. Let’s dive in, starting with what the microservices approach isn’t.
Misconception 1. Microservices is a warmed-over version of an older idea, SOA
Microservices separate out single functions, unlike monolithic software applications, making updates easier, and decentralizing control – to help developers experiment and iterate quickly. Microservices plus their frequent partner, Linux containers, represent “a general shift to delivering applications through modular services that can be reused and rewired to perform new tasks,” notes Red Hat technology evangelist Gordon Haff. This makes particular sense in the hybrid computing environment. It’s also about agility and speed, Haff notes in his recently published book, “From Pots And Vats To Programs And Apps” (Get the free download here.)
“Containerizing services like messaging, mobile app development and support, and integration lets developers build applications, integrate with other systems, orchestrate using rules and processes, and then deploy across hybrid environments,” Haff writes. “Don’t think of this as merely putting middleware into the cloud in its traditional form. Rather, this approach effectively reimagines enterprise application development to enable faster, easier, and less error-prone provisioning and configuration for a more productive developer experience.” In other words, faster work, fewer errors, and more time for developers to experiment.
SOA never delivered a radical new level of of speed. “Although the idea of modularity has been around for years, microservices architecture brings much more flexibility through the independence of services, enabling organizations to become more agile in how they deliver new services or respond to changing market conditions,” says Rich Sharples, Senior Director of Product Management, Red Hat.
In fact, the “micro” in “microservices” leads to some misunderstandings, as Red Hat’s Raffaele Spazzoli, an architect with Red Hat Consulting's PaaS and DevOps practice has written. The term microservices was coined at a time when some Silicon Valley companies were breaking up their large code bases into smaller chunks and assigning those smaller pieces to small, autonomous dev teams. The key to success was not the size of the pieces but the second part - the nimble, independent teams, he notes. “The full autonomy, the lack of bureaucracy and the full automation of all the processes (including infrastructure provisioning) were the factors that made those small teams successful,” he writes. (For more advice on implementations, see the full blog, An Incremental Path to Microservices.)
Misconception 2. Microservices completely eliminate complexity
It may be tempting to treat microservices as a universal salve for the pains of an enterprise application’s technical complexity. While the microservices approach can certainly offer advantages relative to a monolithic architecture, don’t make the mistake of assuming it will rid your environment of complexity altogether. For instance, poorly-executed microservices could cause latency problems on the network.
[ How can you tell a fantastic DevOps organization from a mediocre one? See our related article, DevOps Jobs: How to spot a great DevOps shop. ]
Nic Grange, CTO at Retriever Communications says “Most people don't realize that you should have a minimum set of operational practices to even consider a microservices approach,” Grange says. “With microservices, there is considerable trade-off in reduction of development complexity for an increase in operational complexity. So, if you don’t have the problems that a microservices approach solves, then they’ll probably be more pain than they are worth.”
If you’re already using DevOps methodologies, your teams have embraced a new kind of speed. But if your IT organization has pushed back on DevOps or updating traditional processes to increase development speed, you have some culture change work to do.
“Don't attempt to implement a microservices architecture unless the organization understands how it is going to deliver software faster,” says Red Hat’s Staples. “As a practice aimed at delivering software faster, DevOps goes hand-in-hand with microservices. Without the capability to deliver software quickly – tools, processes, mindset – microservices will not help.” As we’ve noted previously, it’s the mindset piece - leading the culture change, that IT leaders find the hardest. (For more advice on this topic, see our related article, The 7 Habits of Highly Effective DevOps.)
Misconception 3. Microservices have rigid implementation requirements
You will often hear a misconception that microservices come with strict and inflexible implementation requirements, says Dr. Ratinder Ahuja, founder and CEO at ShieldX Networks. That's not true. In fact, microservices are well-suited for our increasingly hybrid IT world.
“Microservices can be implemented in many different computing environments including standard hardware as well virtualization and cloud infrastructures,” Ahuja says.
Misconception 4. Microservices and APIs are the same thing
Ahuja also notes a misunderstanding that microservices and APIs are the same thing. “Rather, APIs specify how software components should interact,” he says. “On the other hand, “microservices offer a unique architectural approach to help enterprises realize an efficient and scalable way to implement the services.”
Experian CIO Barry Libenson uses a cooking analogy to explain APIs: “In many ways, APIs are like data recipes – creating internal structure and order to find new ways to use data to ensure that companies can innovate – and produce better outcomes for consumers,” he notes in our recent article, Experian CIO: 4 ingredients for API success.
Misconception 5. Microservices suit every application
“The largest misunderstanding is that a microservices architecture is a one-size-fits-all solution,” says Justin Bingham, CTO and Janeiro Digital. “A microservices architecture should be carefully applied based on specific technology and business strategies – every application in an enterprise environment is not a good fit for a microservices architecture.”
Seek balance and evaluate carefully. “I've heard of organizations that go overboard with this concept and end up wasting a lot of time on things that probably shouldn't be a service,” says Michael Frye, founder and CEO of BigPicture.io. “There needs to be a balance.”
Plan wisely to unlock speed
Sorting out those applications is a big part of your prep work for microservices. Keep the end goals firmly in mind – and communicate clearly to the team. “It is unwise to leap into a microservices architecture without the planning around the domains and responsibilities within a system,” Bingham says. “While microservices can unlock velocity within an IT organization, the lack of a proper roadmap can yield false starts and undue complexity.”
