WavebreakMediaMicro - Fotolia
Expect microservices implementation to break down IT norms
No role is safe during a transition to microservices. JP Morgenthal, distributed architecture expert, enumerates the ways in which a microservices implementation shakes up IT teams.
Microservices are on the rise among enterprise IT shops, to decompose monolithic applications into manageable components and put forth the next generation of app capabilities. But there's another byproduct: They also decompose traditional IT roles and responsibilities.
Microservices implementation means more work than code by independent features. It's not enough to just isolate some code in containers and call it a microservice. The service needs to be designed around business domain entities and take into consideration the role of IT architecture in a larger microcosm of microservices, said JP Morgenthal, CTO of application services at IT services provider DXC Technology. "It's about having a better understanding of the role of that service in the ecosystem, rather than have blinders on," he said.
Morgenthal shared five ways in which the microservices architecture and its deployment model rewrite the script for IT organizations, from development, test and operations techniques to cultural and structural change.
Expect more development responsibilities
Microservices broaden the developer's responsibilities to include everything from network communications to business interactions.
"J2EE developers got away with a lot," Morgenthal said. "With an opinionated platform, you'd design to the spec and deploy your file, and ops would be responsible for that entire resilient infrastructure to run it."
To implement microservices, developers must understand the language, the container and how to automate that container's creation. They should perform some tests and know how network communications work and which ports to open, Morgenthal said. Database and storage demands also fall under the developer's purview, such as how to ensure separation of service and files.
But before they design a single microservice, developers must grasp how the architecture all fits together. "Don't overload microservices with capabilities," Morgenthal said. "Do one thing well." Microservices should fit into appropriate business domains and be organized by business logic. Component changes should not break any dependency models upon which applications work.
While there is no set list of qualifications for a microservices developer, Morgenthal ticked off several skills that will help a professional make the transition:
Trade-offs lead to microservices benefits
Alongside the benefits to microservices, there's a trade-off for more complexity on the operations side of IT. More discrete components in play make it harder for ops to ensure everything works together and dependencies don't spiral out of control.
"Frankly, we're not at the point where we have comprehensive tooling on the ops side to gain control over this" Morgenthal said.
Enterprise IT operations teams should brace for security holes, latency problems and even outages due to the complex interactions of numerous microservices.
However, complexity in deployment and support isn't a reason for operations to delay microservices implementation, because monolithic applications aren't easy either, Morgenthal pointed out. Monolithic applications drain time and money in maintenance overhead, and small development changes are difficult to implement because the design depends upon the platform, the libraries and components of the build, and how ops must compile and deploy them.
QA models weather microservices
Enterprises that pick up microservices should grok behavior-driven and test-driven development (BDD and TDD), as these QA models consider the ecosystem where the development product will live, Morgenthal said. But TDD and BDD require developers to break their own stuff, and that's painful, he added.
In test-driven development, the code creator thinks about all the ways that product could fail to thus prevent failures in production. Based on these hypotheticals, the developer builds test cases and produces code to pass those tests. TDD addresses as many edge cases as possible, whereas other test models focus on only the most likely issues.
Behavior-driven development goes a step further and accounts for execution behaviors and modeling prior to code creation. Teams convert to BDD through code reviews and questioning. Morgenthal recommended BDD for small teams to implement microservices, because success depends on personal coaching to train developers' mindsets.
Team approaches to microservices, from factories to tribes
Team organization is an important factor in a microservices implementation, particularly when it comes to where team members spend their time.
A chief architect can lead the microservices transition, as the architect translates a business domain into requirements for developers. Morgenthal said he envisions a kind of factory model for code creation, delivery and support: Programmers push out code and senior staff facilitate connections between development and QA to ensure microservices' resiliency before production.
Automation gives team members room to focus on their most valuable work, so an IT team that considers the move to microservices should have a code repository already in place, with push-button builds. If developers must take on responsibilities around deployment architecture and testing, they shouldn't also build a development environment from scratch.
There's no shortage of team management approaches to microservices, and Morgenthal suggested that enterprise IT organizations investigate the following:
- the Spotify approach of guilds, tribes and chapters;
- Scrum teams;
- cross-functional teams;
- integration of a full-stack developer to foster new thinking and skills; and
- pair programming, espoused by Pivotal's engineers.
How microservices change culture
Cultural fit in an enterprise IT context stirs up many different beliefs. Some organizations champion a rigorous team culture, while others de-emphasize culture and value skills first and foremost.
In most enterprise IT shops, the microservices transition will change team culture and expected skills. Leaders should vigilantly create room for junior professionals to gain a skill set alongside senior people.
Culture matters especially on self-organized teams, which select the user stories they build, Morgenthal said. Team members' responsibilities must fit together, and any dearth of skills will slow projects down. In an approach that could be considered counter to the culture ideal, Google's engineers focus on each member's contribution to a project and de-emphasize how team members mesh, Morgenthal pointed out.
Skill and responsibility expectations are a different matter in enterprise IT than they are at the largest organizations, Morgenthal said. "We've seen unicorns that moved everything to the developer. ... When something goes wrong, it's on the developer." He's skeptical about how that approach holds up in mainstream IT's microservices implementations across banks, manufacturing companies and retailers.
