The idea of microservices appears to be quickly gaining fame among today’s enterprises, however some IT experts warn that organizations may not be “culturally” prepared to leverage this new paradigm in a way that is beneficial for their business.
“People are asking about it a lot. They’re interested in what it is and how it’s helping companies become successful,” says Christian Posta, Principal Middleware Specialist/Architect at Red Hat and committer to the Apache Software Foundation. “But since it’s much more, at least in my opinion, about how an organization structures itself, it’s going to be difficult for some of these large enterprises that are structured the way that they are to adopt that architecture and really take it to its full extent. I think that’s the big challenge.”
But why is this organizational structure so important when it comes to delivering microservices? And what does it take to establish the “culture” needed to realistically adopt this approach to application development?
Arun Gupta, director of technical marketing and developer advocacy at Red Hat, says that this cultural requirement can be directly linked to Conway’s Law, a technology-based “philosophy” which claims that an organization’s application structure is going to be a very close mimic of their IT organizational structure.
“If your organizational structure is one UI team, one database team, one middle-tier team, etc., your application code will start showing those layers,” says Gupta. “[These layers] might not work well with each other, and they will have to have a ‘workaround’ to work with the other layers.”
“With microservice,” he adds, “because we are following mostly the domain-driven approach, the idea is to have a cross-functional team.”
So how do you create these types of microservice-friendly teams? The first step, says Posta, is to think small and take what Amazon calls the “two-pizza box mentality” – as in, create smaller, multi-functional teams that are no bigger than what two pizzas can feed.
“You need small teams that are focused on their one service or set of services – and that team is typically made up of both developers and operations-type people, or at least developers who do a lot of operations-type stuff,” says Posta. “And to me, that’s the pinnacle of what people want when they talk about DevOps.”
But not only do you need the right team structure, says Posta – the quality of these team members matters too. Do you have people do that are willing to learn? Are they interested in building a better product? Do you have developers that understand the business side of things as well?
This is a challenge for many larger enterprises, Posta believes, where business-decision makers may not see technology as core part of their business’s ability to innovate. However, he stresses that maintaining this focus is one of the three major qualifications for success with microservices, alongside having the right team structure and creating a culture for rapid innovation.
Gupta stresses that establishing this DevOps culture should absolutely be the first step an organization takes in their microservices journey, even if it doesn’t necessarily pan out. Establishing these strong DevOps practices will still benefit your organization.
“Today it’s microservices…tomorrow it’s going to be picaservices or nanoservices,” says Gupta. “So look at DevOps as the first, because that’s in general good. Whether you’re doing microservices, monolith, or whatever it is that you’re doing…that organizational alignment is one of the biggest challenges I’m seeing.”
Have you recently made, or do you plan to make, changes in your IT organizational structure in order to prepare for microservices? Tell us about your experiences with your comments.