WavebreakMediaMicro - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

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:

  • Know more than just the programming language.
  • Possess both front- and back-end developer experience.
  • Work with numerous technologies including containers; PaaS; and CI/CD and DevOps tooling, such as Jenkins and Git.
  • Understand Agile and Scrum

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.

This was last published in February 2019

Dig Deeper on Microservices and DevOps

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

How do you find microservices affect your IT structure?
Cancel
Good points, but there are nuances that need to be addressed:

One nit: the article says, "In test-driven development, the code creator thinks about all the ways that product could fail to thus prevent failures in production." Well, I have never seen that. TDD is about very low level tests, whereas production failures usually pertain to integration issues - integration issues are outside the scope of TDD. In TDD, you think about the very low level failures (e.g., this method returned a 0 but it should have returned 1), but you don't think about the production failures (e.g., this service hung or sent a message too late, or threw an error that the caller did not know what to do with).

The J2EE platform was amazing because it defined a standard ecosystem. The problem was, it could not scale to "Internet scale". For Internet scale - to handled millions of users - one has to "roll one's own", and that means microservices, events, streams, NoSQL, and elastic resources. Those are the things that can do Internet scale, and they are not part of the J2EE model.

But if you are building to less than Internet scale, you are still better off with J2EE. The reason is that to create a system using microservices and the other things I mentioned, you have to learn a-lot, and there are no "standards" - each cloud provider has its own APIs. It is a-lot like the days when each computer vendor had their own OS.

It is also really complicated architecturally to build Internet-scale things. It is not a matter of just learning the APIs. To create well functioning microservices, you need to consider inter-service latency; and you have to provide for cleanup that using an "eventually consistent" database provides; and you have to learn about how to manage access control at an API level, how to embed SSO, and many other things. It is much, much more complicated than the J2EE world.

Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close