Join the panel in part two as they continue their discussion of client issues about microservices operations – this time, they talk people roles and team composition.
In this video:
- David Hodges, Program Director, IBM Cloud Architecture Center
- Roland Barcia, Distinguished Engineer for Cloud Architecture and Engineering Solutions
- Gang Chen, Executive IT Specialist
- Rick Osowski, Senior Solution Architect and host of dWTV’s Microservices TV
- Erin Schnabel, Senior Software Engineer
- Kyle Brown, CTO and Distinguished Engineer for Cloud Architecture and Engineering Solutions
“Clients are really scared. They think ‘I’m going to be throwing my data all over the place. How do I sync this? Who owns the data? Can I really achieve database per service or will I have to make compromises?'”
“There always will have to be some compromises. The only place you can do that is with a greenfield application and you can design everything from the start.”
Another question Kyle likes to answer before a client asks is “Yes: You will still need DBAs. Moving into microservices is not going to eliminate the need for database administrators and some level of entity modeling.” (An entity model describes related things of interest in a specific domain of knowledge.) He explains that in some cases the need for these structures will disappear, especially if you’re moving to a smaller database, because you’re dealing with a smaller volume of data:
“But what’s left are the hard problems.”
“Compromises and compensation logic. Even then [with greenfield], even if you start from vanilla you can get into inconsistencies.”
Erin recounts a very recent conversation with a DBA and she asked him the question: “What does this [microservices] mean to you? How does this make you feel?” His reply:
“Actually, some of my colleagues are freaking out and the rest of them understand that microservices relieves them of a lot of administra-trivia.”
Rick Osowski sees a large component of implementing microservices as a people problem:
“How do you work together? Smaller teams, working together, working on smaller jobs. But they’re not doing the administra-trivia; they’re doing the work that they are experts on.”
Rick emphasizes that the team structure conversation is one of the most important he has with clients who are adopting microservices.
Everyone on the panel agrees: The organizational problem is the toughest one to solve with implementing microservices.
Roland says that the skillset of individuals on these teams need to be able to expand into areas beyond their traditional roles.
“Not into every area,” Erin adds, noting that you also need a team whose skills knit together. But the consensus of the panel is that when you use microservices, the roles of the individual team member should be expandable.
“Maybe I need to have an ‘understanding’ of all areas at the least,” Roland says.
Maybe like an entity model, you need to know what the different areas represent and how they relate to each other. Roland points out that “things are starting to spill over into everyone else’s domain”; microservices seems to draw attention to that.
Learn how to maximize the power of the components for cloud computing.