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:

The make-up of your team tasked with embracing microservices, including the roles of individuals, is an important consideration before implementing this architecture.

Roland Barcia:

“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?'”

Kyle Brown:

“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.”

Erin Schnabel:

“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.

Watch more of this series on developerWorks TV

Join The Discussion

Your email address will not be published. Required fields are marked *